When Broadcom finalized its VMware acquisition and reshuffled licensing, thousands of admins started looking for a way out. I am one of them. I run a small homelab with a handful of VMs, and the day my renewal quote doubled, I started researching how to migrate VMs from VMware ESXi to Proxmox. This guide is what I wish I had on day one: a clear, ordered playbook that covers both migration methods, the prep work nobody talks about, and the post-migration gotchas that bite you three hours in.
By the end of 2026 you will know exactly which method fits your situation, how to keep your Windows and Linux VMs intact, and how to fix the network adapter mess that catches almost everyone on their first try. Let us get into it.
Table of Contents
Why Migrate from VMware ESXi to Proxmox in 2026?
Proxmox VE is an open-source virtualization platform built on KVM and LXC. It does almost everything ESXi does, plus clustering, ZFS, Ceph, and a web UI that does not require a separate vCenter server. For most homelabs and small businesses, the feature gap is now negligible.
The licensing shift under Broadcom is the obvious motivator. Perpetual ESXi licenses are gone for many customers, and subscription bundles now include things like Aria and NSX that smaller shops do not need. Proxmox has no per-CPU or per-VM licensing, which is a huge relief when you scale.
There are other reasons too. Proxmox runs on Debian, so you get apt, systemd, and a familiar Linux ecosystem under the hood. You can mix KVM virtual machines and LXC containers on the same host. Backup, replication, and HA are built in without extra modules. Once you start using it, the value becomes obvious.
Pre-Migration Checklist Before You Touch Anything
I learned this the hard way. Skipping prep is the number one reason migrations fail or leave you with a half-broken VM. Run through this checklist before you touch anything.
Take a full backup of every VM you plan to migrate. Use Veeam, Nakivo, or simply export the VM as OVF from vSphere. Do not skip this step.
Uninstall VMware Tools inside the guest OS. On Windows, use the Windows uninstaller. On Linux, run the vendor-specific removal script. VMware Tools left behind can cause driver conflicts.
Document the original VM configuration. Note vCPU count, RAM, disk layout (thin vs thick), network adapter MAC addresses, and BIOS or UEFI mode.
Record the VMware network adapter model. ESXi defaults to VMXNET3, and you will need this when you recreate the network adapter in Proxmox.
Check firmware type. Run
dmidecode -t systemon Linux or check System Information on Windows to confirm whether the VM uses BIOS or UEFI. Proxmox needs to match this.Verify storage capacity. Proxmox needs at least 20 percent more space than the source VM because converted disks often balloon during the qemu-img convert process.
Confirm network reachability. Your Proxmox host must be able to reach the ESXi management IP and the datastore on TCP 443 and 902.
If your VM sits on a vSAN datastore, stop here and read the limitations section below. vSAN-backed VMs cannot be migrated with the import wizard and need a different path.
Two Ways to Migrate VMs from VMware ESXi to Proxmox
You have two practical options for ESXi to Proxmox migration. Both work. They differ in convenience, control, and what they require from you.
The first option is the built-in Proxmox Import Wizard. This is the easiest method and the one I recommend for almost everyone. You point Proxmox at your ESXi host, it reads the VM list, and it copies the disks while converting VMDK to QCOW2 on the fly.
The second option is manual migration. You export the VM as OVF or copy the VMDK files manually, run qemu-img convert to change the format, then attach the disk to a new VM shell. This gives you full control and works in edge cases the wizard does not handle, such as air-gapped environments.
Below I walk through both. Pick the one that matches your situation.
Method 1: Use the Proxmox Import Wizard (Recommended)
The Proxmox Import Wizard was introduced in Proxmox VE 8.1 and improved in 8.2. It connects directly to ESXi and handles disk conversion automatically. This is the method I used for my last three migrations, and it cut my total time per VM by roughly 60 percent.
Before you start, make sure your Proxmox node has the esxi-import-tools package. If it is missing, install it with this command from the Proxmox shell:
apt update && apt install esxi-import-tools
Then reboot or restart the pvedaemon service. Now you can start the import.
Step 1: Add ESXi as a Storage Backend
Open the Proxmox web UI, click Datacenter, then Storage, then Add, and choose ESXi. Enter the ESXi management IP, the username (usually root), and the password. Leave the datastore field empty to see all datastores, or pick a specific one if you know it.
If the connection fails, check that ESXi allows management API access and that TCP 443 is open between your hosts. Self-signed certificates are fine; just accept the warning.
Step 2: Select the VM to Import
Once ESXi is added, click on it in the storage tree. You will see a list of VMs. Right-click the one you want and pick Import. The wizard walks you through target storage, disk format (QCOW2 or raw), and VM ID assignment.
Step 3: Configure the New VM
The wizard pre-fills CPU, memory, and disk size from the source VM. Double-check these values. For network, pick the right bridge (usually vmbr0) and choose the VirtIO model for best performance. Match the firmware type you documented earlier. If the source was BIOS, choose SeaBIOS. If it was UEFI, pick OVMF.
Step 4: Start the Import
Click Import. The wizard copies the VMDK over the network and converts it to QCOW2 in one pass. A 100 GB VM on a gigabit link typically takes 15 to 25 minutes. Watch the task log under the Proxmox node for progress.
When it finishes, do not start the VM yet. You still have post-migration configuration to handle.
Method 2: Convert VMDK to QCOW2 Manually
Use this method when the import wizard is unavailable, when you need an air-gapped migration, or when you want maximum control over the conversion process. It takes longer but is more predictable.
Step 1: Export or Copy the VMDK
You have three ways to get the VMDK out of ESXi:
Export the VM as OVF from vSphere and use
qemu-img converton the extracted VMDK.Use SSH to copy the flat VMDK directly from the datastore with
scp.Use VMware’s
ovftoolcommand line for scripted exports.
For a quick scp approach, SSH into ESXi, navigate to /vmfs/volumes/datastore1/VMNAME/, and copy the flat.vmdk file to your Proxmox host. The flat file is the actual disk, while the descriptor .vmdk is just metadata.
Step 2: Create the VM Shell in Proxmox
In the Proxmox UI, create a new VM with the same CPU, memory, and firmware type as the source. Do not add a disk during creation; you will attach the converted disk next. Choose the same network bridge and the same number of NICs.
Step 3: Convert the VMDK to QCOW2
From the Proxmox shell, run:
qemu-img convert -f vmdk -O qcow2 /path/to/source-flat.vmdk /var/lib/vz/images/VMID/vm-VMID-disk-0.qcow2
The -f vmdk flag tells qemu-img the source format. -O qcow2 sets the output format. Replace VMID with the actual VM ID you created in Proxmox. This step is the slowest part of manual migration and depends entirely on disk size and storage speed.
For a 200 GB VM on SSD-backed storage, expect 20 to 40 minutes. For 1 TB, you are looking at a few hours.
Step 4: Attach the Converted Disk
Run qm importdisk VMID /var/lib/vz/images/VMID/vm-VMID-disk-0.qcow2 local-lvm -format qcow2 to import the disk into the VM. Then edit the VM hardware, switch the unused disk to the new one, and set the boot order.
At this point you have a VM that should boot. Start it and watch for errors.
Post-Migration Configuration: VirtIO, Network, and Boot Order
Getting the VM to boot is half the job. The other half is making it perform well and stay connected. Here is the configuration work that catches most first-timers.
Install VirtIO Drivers
VirtIO drivers are paravirtualized drivers that give Proxmox VMs near-native I/O performance. Without them, your disk and network run in emulated mode, which is dramatically slower.
For Linux VMs, the kernel usually includes VirtIO out of the box. You may need to install qemu-guest-agent for proper Proxmox integration. For Windows VMs, download the VirtIO ISO from the Fedora project, attach it as a CD-ROM in Proxmox, and run the installer. Pick the drivers for your Windows version.
After installing VirtIO, switch the disk bus from IDE or SATA to VirtIO Block and the network adapter from E1000 to VirtIO. Reboot and check performance.
Fix Network Configuration
This is where most migrations break. ESXi uses VMXNET3 by default, and Proxmox defaults to VirtIO. Linux VMs that hard-code interface names like eth0 often end up with no network because the new adapter gets a different name like ens18.
Two fixes work. First, preserve the MAC address from the original VM before you delete it from ESXi. When you recreate the network adapter in Proxmox, use the same MAC. Some Linux distros will keep the original interface name when the MAC matches.
Second, if MAC preservation does not work, edit /etc/netplan/01-netcfg.yaml on Ubuntu or /etc/network/interfaces on Debian to point at the new interface name. Restart networking and verify connectivity.
Enable QEMU Guest Agent
The QEMU guest agent lets Proxmox communicate with the guest OS for clean shutdowns, snapshots, and time sync. Enable it in the VM options, then install qemu-guest-agent inside the guest. On Windows, the VirtIO ISO includes the agent installer.
Migration Limitations You Should Know Before Starting
Not every VM migrates cleanly. Here are the limitations I have run into or read about from other homelab admins.
vSAN-backed VMs cannot be migrated with the import wizard. The wizard reads from standard VMFS datastores only. If your VM lives on vSAN, you must first Storage vMotion it to a VMFS datastore on the same ESXi host, then run the import.
Live migration between ESXi and Proxmox is not supported. You will have downtime. Plan a maintenance window, especially for production workloads. The conversion process is offline by design.
Bitlocker and TPM can lock Windows VMs. If Bitlocker is enabled and the hardware hash changes, Windows may refuse to boot. The fix is to suspend Bitlocker before migration with manage-bde -protectors -disable C:, then re-enable it after the VM is up on Proxmox.
Shared disks and RDMs need special handling. Raw Device Mappings from ESXi do not survive the conversion. You will need to recreate shared storage inside Proxmox using Ceph, NFS, or iSCSI.
Troubleshooting the Issues Homelab Users Hit Most
From my own migrations and what I see in the Proxmox subreddit, these are the issues that come up over and over.
VM boots but has no network. Almost always a MAC or interface naming issue. Try setting the original MAC on the new VirtIO adapter. If that fails, edit the netplan config inside the guest.
Windows VM bluescreens on first boot. Usually VirtIO driver mismatch. Boot the VM with an IDE or SATA disk and E1000 network, install VirtIO drivers from the ISO, then switch back to VirtIO and reboot.
Import wizard fails with SSL error. ESXi self-signed certificates cause this. Either install a proper cert on ESXi or accept the warning in the Proxmox UI under Administration, then Certificates.
Disk conversion runs out of space. qemu-img needs temporary space. Make sure the destination storage has at least the same size as the source VMDK plus headroom.
Frequently Asked Questions About Migrating ESXi to Proxmox
How do I migrate VMs from VMware ESXi to Proxmox?
Use the Proxmox Import Wizard for the simplest path. Add your ESXi host as a storage backend in the Proxmox UI, select the VM, choose target storage, and start the import. The wizard copies the disks over the network and converts them from VMDK to QCOW2 automatically. For air-gapped setups, export the VM as OVF, copy the VMDK to Proxmox, and convert with qemu-img convert -f vmdk -O qcow2.
Can you migrate a VMware VM to Proxmox?
Yes. Proxmox supports importing VMware VMs directly through its built-in Import Wizard, which handles the VMDK to QCOW2 conversion. You can also import VMs that were exported as OVF or OVA files. The only common exception is VMs stored on vSAN datastores, which need to be moved to a standard VMFS datastore first.
What are the disadvantages of Proxmox compared to VMware?
Proxmox has a smaller third-party ecosystem than VMware, so niche integrations are less common. Enterprise features like vMotion live migration between ESXi and Proxmox do not exist; you need downtime. Some advanced VMware features such as vSAN, NSX, and vSphere+ are not available, though Proxmox offers Ceph, ZFS, and built-in clustering as alternatives.
How do I import a VMDK file into Proxmox?
Copy the VMDK to your Proxmox host, then run qemu-img convert -f vmdk -O qcow2 source.vmdk /var/lib/vz/images/VMID/disk-0.qcow2 to convert the format. After conversion, use qm importdisk VMID /var/lib/vz/images/VMID/disk-0.qcow2 local-lvm to attach the disk to an existing VM, then edit the VM hardware to enable it and set the boot order.
Your Next Step After Reading This Migration Guide
You now have a complete playbook for how to migrate VMs from VMware ESXi to Proxmox. Start with one non-critical VM, run the pre-migration checklist, use the Import Wizard, and verify boot, network, and performance before you commit production workloads. If you want my honest take after a dozen migrations: Proxmox is faster, cheaper, and easier to live with once you make the jump. The first migration takes a weekend. After that, each one gets faster.