ESXi to Proxmox Migration: The Complete 2026 Playbook

With VMware's per-core pricing model making renewals sting, more admins are asking how to move workloads off ESXi without an outage. The answer in 2026 is a staged migration: convert each VM's disk to a Proxmox-native format, swap VMware Tools for VirtIO drivers, and live-migrate the rest, so production keeps serving traffic the entire time.

Key Takeaways

Pricing math — VMware now bills by physical core, so consolidating onto Proxmox VE's per-socket licensing often cuts the renewal bill in half or more.

Right tool per VM — use migrate2kvm for VMDK-based guests and OVA import for appliances, then verify before you cut over.

Disk format — convert VMDK to QCOW2 on an NVMe-backed datastore, roughly 5–10 minutes for a 100 GB disk.

Windows first — load the VirtIO storage driver before switching controllers, or Windows BSODs with INACCESSIBLE_BOOT_DEVICE.

Back it up — snapshot the migrated VM and confirm a restore works before you retire the ESXi copy.

Why the VMware Per-Core Shift Is Driving Migrations Now

VMware's move to per-core licensing changed the renewal math entirely. On a densely packed ESXi host, every physical core now carries a line item, and a 48-core box can double your vSphere subscription cost overnight. That is exactly why the breakdown in VMware Per-Core Pricing vs Proxmox VE Renewal Savings tends to land in Proxmox's favor: you pay for the socket, not for every vCPU pin the guest happens to request.

The good news is that the migration path itself is mature and well-documented. You are not gambling on a brand-new hypervisor; Proxmox VE 9 runs production KVM workloads quietly, and the tooling to move a live VM off ESXi has been refined for years. The hard part is sequencing, not technology.

How to Plan the ESXi to Proxmox Migration

Before you convert a single disk, take a full inventory. Write down every VM's vCPU count, disk size, guest OS, and whether it is stateless (a web tier) or stateful (a database). Stateless tier-2 and tier-3 workloads migrate in minutes; the few stateful databases are where you earn your keep with extra care.

Locate each VM's configuration and disks on the ESXi host so you know exactly what you are moving:

# SSH into the ESXi host to find the VM's config and virtual disks
find /vmfs/volumes/datastore1/my-vm -maxdepth 1 -name "*.vmx"
find /vmfs/volumes/datastore1/my-vm -maxdepth 1 -name "*.vmdk"

Then classify every VM into one of three buckets: convert in place (a plain VMDK guest), reimport (an appliance you can re-export as OVA), or rebuild (a legacy guest whose config no longer survives conversion). Most homelab and small-fleet environments fall into the first two buckets, which is why the whole job often finishes in a single weekend.

Which Migration Tool Fits Each VM

Proxmox ships three practical ways to move a VM off ESXi, and the right choice depends on what the guest actually is.

Migration method	Best for	Cutover downtime	Driver changes needed
migrate2kvm	VMDK-based Windows/Linux VMs	Seconds (final boot)	Usually yes for Windows
OVA/OVF import	Appliances and small VMs	Minutes (reimport)	Yes
Manual qemu-img + importdisk	Custom or odd disk layouts	Controlled	Yes

migrate2kvm reads a VMware .vmx file and its .vmdk disks, then creates the matching KVM VM for you. It is the fastest route for a straightforward guest:

# Confirm the current flag names first — the script evolves between releases
./migrate2kvm --help

./migrate2kvm --vmid 150 --datastore local-lvm --vmconfig /tmp/my-vm/vm.vmx --force

OVA/OVF import is ideal for appliances you can export cleanly from vCenter or ESXi. Power off the source VM, export it as an OVA template, then pull it into Proxmox:

qm importovf 200 /root/appliance.ova local-lvm --format qcow2

Manual conversion gives you full control when the other two tools choke on an unusual layout. You convert the disk yourself with qemu-img, then hand the result to Proxmox:

qemu-img convert -p -f vmdk -O qcow2 /tmp/disk0.vmdk /var/lib/vz/store/local/vm-200-disk-0

qm importdisk 200 /tmp/disk0.vmdk local-lvm
qm set 200 --scsi0 local-lvm:vm-200-disk-0

Converting VMware Disks to Proxmox Storage

The disk conversion is the step that eats most of your afternoon, so put it on fast storage. A 100 GB VMDK converts to QCOW2 in roughly 5–10 minutes on an NVMe-backed datastore, but the same job can take thirty minutes or more on spinning disks or a congested NFS share. Plan the conversion window around that reality, not around wishful thinking.

QCOW2 is the default Proxmox format and it compresses nicely, which matters when you are moving several large disks at once:

qemu-img convert -p -f vmdk -O qcow2 -o compression_size=64 /tmp/disk0.vmdk /var/lib/vz/store/local/vm-200-disk-0

The -p flag shows a progress bar so you can watch a long conversion without guessing when it will finish.

Once the disk lands on the target storage, attach it to the new VM and pick a controller. VMware guests commonly ship on LSI Logic SAS or a paravirtual SCSI controller; Proxmox rewards you for moving to virtio-scsi after the guest can see the driver:

qm set 200 --scsi0 local-lvm:vm-200-disk-0

Do not forget the network adapter. VMware's vmxnet3 maps cleanly on Linux guests, but Windows needs the matching VirtIO network driver before it will hold an IP address. Linux guests almost always bring virtio-net in the kernel, which is one reason the Linux side of the migration usually just works.

Migrating Windows Guests Without a BSOD

The single most common migration gotcha hits Windows guests when you switch storage controllers too early. Move a Windows disk from VMware's LSI Logic or IDE controller onto virtio-scsi before the VirtIO storage driver is loaded, and Windows cannot find its boot volume. The familiar result is a blue screen reading INACCESSIBLE_BOOT_DEVICE, and the VM looks dead even though the data is perfectly fine.

The fix is to load the driver before you change the controller. Attach the VirtIO driver ISO and boot:

qm set 200 --sata3 local-lvm:iso/virtio-win.iso
qm start 200

Inside the running Windows guest, open Device Manager, install the viostor (storage) driver for the disk controller, and the netkvm (network) driver for the adapter. Once both are confirmed working, you can move the disk onto the fast controller and drop the ISO:

qm set 200 --scsihw virtio-scsi-pci
qm set 200 --scsi0 local-lvm:vm-200-disk-0

This is the same principle behind Windows VM performance tuning swaps emulated devices for VirtIO: the drivers have to be present in the guest kernel before the emulated or paravirtual hardware can talk to it. Skip that ordering and you will be chasing a blue screen instead of finishing the migration.

Verifying and Tuning the Migrated VMs

After the VM boots on Proxmox, verify it before you trust it with production. Check that the guest agent reports healthy, that the disk is actually the QCOW2 you converted, and that the network holds an address. Then apply the tuning that makes Proxmox feel faster than the ESXi box you replaced:

# Expose the host CPU directly instead of emulating an older model
qm set 200 --cpu host

qm set 200 --cores 4

qm set 200 --balloon 2048

qm set 200 --agent enabled=1

Setting the CPU to host removes the emulation layer and is the single biggest win for compute-heavy guests. The balloon device lets Proxmox reclaim idle memory, and the guest agent lets the web UI report real memory and disk usage instead of guessing. These same knobs matter whether you are running a migrated Windows 11 guest or a fresh Windows 11 VM on Proxmox with VirtIO.

Backing Up Your New Proxmox Fleet

Never cut over a VM until you have a verified backup of it on Proxmox. Take a snapshot of the freshly migrated VM, then push a backup to Proxmox Backup Server so you can restore from a different host if something regresses:

qm snapshot 200 pre-cutover

qm backup 200 --storage pbs --mode snapshot --compress zstd

If you are still deciding where the migrated disks should live, read ZFS vs LVM-Thin Backups: Which Proxmox Storage Is Right for You before you commit to a pool. ZFS gives you snapshots and replication for free, while LVM-thin is simpler and cheaper on flash; both back up cleanly to PBS.

When you are ready to relocate a running VM to another node, live migration does the heavy lifting with a near-instant cutover:

qm migrate 150 proxmox-node2 --online --storage local-lvm --bwlimit 100000

The --bwlimit cap protects your network while the disk copies over, and --online keeps the guest serving traffic during the move. After the fleet settles, schedule a recurring PBS sync so the whole new Proxmox cluster stays protected.

Conclusion

Migrating from VMware ESXi to Proxmox VE in 2026 is a staged job: inventory the workloads, pick the right tool per VM, convert the disks to QCOW2, load VirtIO drivers before you touch the Windows storage controller, and verify a backup before you cut over. Net result is a lower per-core bill and faster guests, with production never blinking. Your next step is to run migrate2kvm --help on one idle VM this week and prove the path end-to-end before you touch anything in production.