VMware to Proxmox in 2026: A Real Migration Guide

TL;DR: Admins are moving from VMware to Proxmox because Broadcom ended perpetual VMware licensing and moved pricing to a per-core subscription model, often multiplying renewal costs. Proxmox VE is free to run, has a built-in ESXi import wizard since version 8.1, and by 2026 handles most production workloads that don't depend on vSAN or NSX.

If you manage VMware in any capacity, you've had this conversation in the last two years: the renewal quote comes back, and it's not a modest bump — it's a different number entirely. That's the whole reason "vmware to proxmox" has gone from a homelab search term to something IT directors are typing into Google at 11pm before a budget meeting.

I've walked a handful of environments through this move over the last year — a couple of small business clusters, one MSP client with about 40 VMs. None of them were painless, but none of them were the disaster people expect either. This is what actually happens, not the marketing version.

Why is everyone suddenly talking about VMware alternatives in 2026?

Short version: Broadcom bought VMware in November 2023 and by early 2024 had killed perpetual licensing entirely. Everything is subscription now, billed per physical core instead of per socket, and the old à la carte catalog of 8,000+ SKUs got collapsed into a handful of bundles — mainly VMware Cloud Foundation (VCF) and vSphere Foundation (VVF).

The number that actually stings is the core minimum. Every CPU is billed at a minimum core count regardless of how many cores it physically has. If your box has an older 8 or 12-core chip, you're paying for cores that don't exist. There was a brief, chaotic period in April 2025 where Broadcom pushed that minimum up to 72 cores per CPU — which would have wrecked smaller estates — before backing off after industry pushback. As of this writing the widely reported minimum is back down to 16 cores per socket, but core minimums have moved twice in under two years, so don't take my word for it — check your actual quote against Broadcom's current published terms before you budget anything.

None of this means VMware is going away, or that vSphere is a bad product technically. It's still the most feature-complete hypervisor stack on the market if you need NSX-level networking or vSAN at scale. What changed is the math for everyone who doesn't need the full stack — and that's most small and mid-size shops.

What is Proxmox, and is it actually a fair VMware alternative?

Proxmox VE is a Debian-based hypervisor platform combining KVM (for full VMs) and LXC (for lightweight containers), with a web UI, built-in clustering, and its own backup product (Proxmox Backup Server). It's open source, free to download and run indefinitely, and the current stable line — Proxmox VE 9.2, released May 21, 2026 — sits on Debian 13.5 "Trixie" with Linux kernel 7.0, QEMU 11.0, and ZFS 2.4.

You don't have to pay Proxmox anything to run it in production. Subscriptions exist and start at €115 per year per CPU socket, but they buy you access to the more conservative "enterprise" package repository and official support — not extra features. The free "no-subscription" repository gets the same code, just less battle-tested before it lands on your host. Plenty of production clusters run on it; you just accept a slightly shorter soak time between a package landing and it reaching you.

Where Proxmox genuinely isn't a drop-in VMware replacement yet: there's no vSAN-grade native distributed storage (you'd reach for Ceph, which Proxmox integrates well but which is its own beast to run), no NSX-equivalent for advanced micro-segmentation (Proxmox SDN has grown a lot — WireGuard and BGP fabrics landed in 9.x — but it's not the same maturity level), and vCenter-style fleet monitoring is thinner out of the box. If your environment leans hard on those, budget time to replace them with something else, not just Proxmox.

Proxmox vs VMware: how do they actually compare?

Factor VMware (Broadcom, 2026) Proxmox VE 9.x
Licensing Subscription only, per-core, bundled (VCF/VVF) Free (AGPLv3); optional paid support subscription
Base OS Proprietary ESXi kernel Debian 13 "Trixie" + custom kernel
Hypervisor type Bare-metal (Type 1), proprietary KVM (Type 1) + LXC containers, open source
Clustering / HA vSphere HA/DRS, mature Built-in HA, affinity rules, Dynamic Load Balancer (new in 9.x)
Distributed storage vSAN (licensed separately, by capacity) Ceph (self-managed, included, steeper learning curve)
Advanced SDN / micro-segmentation NSX (mature, expensive) SDN with VXLAN/EVPN, BGP and WireGuard fabrics (newer, improving fast)
Backup Third-party or VMware Live Recovery (add-on) Proxmox Backup Server (free, integrated, dedup + incremental)
Migration tooling from the other side Built-in P2V/V2V wizards for older platforms Native ESXi import wizard since PVE 8.1

How do you actually migrate VMs from ESXi to Proxmox?

There are two realistic paths, and which one you use depends mostly on how much automation you want versus how much control you need over the disk conversion.

Option 1: the built-in Import Wizard (do this first, for most VMs)

Since Proxmox VE 8.1 there's a native import wizard that talks directly to the ESXi host's API — no OVF export, no third-party conversion tool. It reads the VM's config and disks straight off the ESXi datastore and rebuilds an equivalent VM on Proxmox.

  1. On the Proxmox host, go to Datacenter > Storage > Add > ESXi.
  2. Give it an ID (letters, not just digits), the ESXi host's IP, and root credentials. Check "Skip Certificate Verification" if the host uses a self-signed cert, which is the default on most ESXi installs.
  3. Once added, click the new storage entry in the left pane. Give it a moment to enumerate the VMs on that host.
  4. Right-click the VM you want and choose Import. Pick your target storage and disk format — qcow2 if you want snapshot support later, raw if you're on ZFS and want the best raw performance.

A few things I've hit in practice that aren't obvious from the docs:

If the source VM has snapshots, the import will be noticeably slower — flatten them on the ESXi side first if you can afford the downtime window. And if you're on ESXi 6.5 or 6.7, you may need to raise the SOAP session limits on the source host before a long-running import will complete without dropping.

To fix that session timeout issue on older ESXi:

vi /etc/vmware/hostd/config.xml
# add or edit inside the <config> section:
<soap>
  <sessionTimeout>0</sessionTimeout>
  <maxSessionCount>0</maxSessionCount>
</soap>

# then restart hostd
/etc/init.d/hostd restart

The wizard also supports "live import" — you power off the source VM, click import, and Proxmox boots it immediately while it fetches disk blocks on demand in the background. It genuinely cuts downtime, but it's also the one place I've seen imports fail mid-stream on flaky networks. If the import errors out, everything written since the import started is lost — so test this on a throwaway VM before you trust it with anything that matters. On a clean gigabit LAN between source and target it's been reliable for me; over a VPN link between sites, less so.

What this wizard won't touch: VMs with vSAN-backed disks, disks encrypted via a VM Storage Policy, or datastores with a + in the name (rename the datastore as a workaround). If you hit any of those, you're on the manual path below.

Option 2: manual disk import via qm disk import

This is the fallback when the wizard can't reach a VM, or when you want to script bulk migrations yourself. The idea: get the VM's .vmdk files somewhere Proxmox can read them, create a matching empty VM, then import the disk directly.

# Create the target VM first in the GUI (or via qm create),
# matching CPU/RAM/OS type, then remove its default disk.

# From the Proxmox shell, with the vmdk files on accessible storage:
qm disk import <vmid> /path/to/server-flat.vmdk <target-storage> --format qcow2

# Then attach the resulting disk to the VM in the GUI
# (Hardware > Add > Hard Disk, pointing at the imported volume)

The command handles the format conversion on the fly, so you don't need a separate qemu-img convert step. The annoying part is getting the .vmdk files somewhere both hosts can see — an NFS or SMB share both sides can mount is the least painful option I've found. Copying files manually works too, it's just slower for anything over a few hundred GB.

What do you need to fix inside the VM after migration?

The import gets the disk and general config across. It doesn't touch the guest OS, and there are a few things that reliably break or need attention:

  • Remove VMware Tools before you migrate, not after — uninstalling it post-migration on Proxmox throws errors because the hardware it's looking for is gone. Do this on the source VM while it's still running on ESXi.
  • Install the QEMU Guest Agent on the new Proxmox VM — it's the equivalent of VMware Tools for reporting IP addresses, clean shutdowns, and filesystem freeze/thaw during backups. 
    apt update
apt install qemu-guest-agent
systemctl enable --now qemu-guest-agent
  • Network interface names will change. A Linux guest that had ens192 under VMware will likely come up as ens18 or similar under Proxmox's virtio NIC. Fix your netplan or /etc/network/interfaces before you assume networking is broken — it's usually just a naming mismatch.
  • Windows guests need VirtIO drivers for storage and network to get decent performance — mount the official VirtIO driver ISO and install them, then switch the boot disk controller to VirtIO once the driver's loaded (do this in two steps, not one, or the VM won't boot).

Should you migrate everything at once, or in waves?

Waves, every time. Don't touch production on day one. The sequence that's worked for me:

  1. Migrate two or three genuinely disposable test VMs first, just to shake out network and storage issues specific to your environment.
  2. Pick a real but non-critical application group — dev/test, or a small internal tool with 3-5 VMs — and run a full pilot including your actual backup and monitoring setup.
  3. Document baseline performance numbers on the VMware side first (CPU, memory, disk latency) so you have something to compare against once the workload is on Proxmox — otherwise "does it feel slower" is just a guess.
  4. Only then move production, and keep the ESXi host and VM intact (powered off) until you've confirmed the migrated VM is stable for at least a few days.

Don't bother trying to migrate an entire cluster in a single weekend unless it's genuinely small. I'd rather take three extra weeks and never have an angry call about a production database VM that didn't come up clean.

FAQ

Is Proxmox actually free for production use?

Yes. The hypervisor itself has no license cost regardless of how you use it. The paid subscription only buys you the more conservative enterprise package repository and official ticket-based support — it doesn't unlock features.

Can Proxmox import VMs directly from vCenter, or only from individual ESXi hosts?

The import wizard talks to individual ESXi hosts, not vCenter itself. In a vCenter-managed cluster you point the wizard at each ESXi host in turn rather than at vCenter as a single source.

What ESXi versions does the Proxmox import wizard support?

Proxmox has tested it against ESXi 6.5 through 8.0. Older or newer versions may work but aren't officially validated — check the current wiki page before relying on it for anything outside that range.

Does migrating to Proxmox mean giving up vSAN or NSX-equivalent features?

Effectively, yes, in the sense that there's no direct drop-in replacement. Ceph covers distributed storage but is a different operational model to learn. Proxmox's SDN stack has grown quickly — VXLAN/EVPN zones, plus BGP and WireGuard fabrics as of 9.x — but it's not a one-to-one NSX equivalent yet.

How long does a typical ESXi-to-Proxmox migration take for a small business?

Depends entirely on VM count and how much you value uptime during the move, but a few dozen VMs with a proper pilot phase is realistically a multi-week project, not a weekend one — even though the actual import wizard runs in minutes per VM.

Is it worth the disruption?

If you're running a straightforward compute-and-storage estate without heavy vSAN or NSX dependence, and the VMware renewal quote just landed on your desk looking like a typo, Proxmox is a legitimate option in 2026 in a way it wasn't five years ago. The import tooling is native, the platform is actively developed, and you're not locked into anyone's per-core math ever again. It's not a magic swap-and-forget move — budget real time for the pilot phase and the post-migration guest cleanup — but the actual technical risk is lower than the licensing panic makes it feel.

← Newer Posts Older Posts →