After Broadcom acquired VMware, the new subscription model and price changes pushed many companies to look for alternatives, and open-source Proxmox VE is at the top of that list. We covered pricing in our Proxmox vs VMware license cost 2026 post and the differences between the platforms in Proxmox vs VMware. In this post we get practical: how to migrate from VMware ESXi to Proxmox, which methods you can use to move virtual machines, and what to watch out for before and after, step by step.
Ways to Migrate from ESXi to Proxmox
There's no single right method; you pick based on the number of VMs, your downtime tolerance and your infrastructure:
| Method | Downtime | Difficulty | When? |
|---|---|---|---|
| ESXi Import Wizard | Low (even less with live-import) | Easy | First choice for most scenarios |
| OVF export/import | Medium–high | Medium | No direct access to ESXi, or existing OVF archives |
| VMDK disk import | Medium–high | Medium | Moving individual disks, custom setups |
| Restore from backup | Varies | Easy–medium | If your backup software supports both platforms |
| Cloning with Clonezilla | High | Medium | When other methods don't fit, physical/special systems |
Before Migrating: Checklist
80% of a smooth migration is done in preparation. Before touching any VM:
- Take inventory: For each VM, the OS, CPU/RAM, disk size, BIOS or UEFI, network/VLAN details and dependencies.
- Update Proxmox: The Import Wizard needs Proxmox VE 8 or later; install the latest packages.
- Prepare storage and networking: Make sure the target storage has enough space and Linux bridges for your VLANs are defined in advance.
- Take a backup: A recent backup you can fall back to if the migration fails is a must.
- Consolidate snapshots: VMs with snapshots import much slower.
- Uninstall VMware Tools (ideally right before migrating).
- Write down network settings: The virtual NIC and MAC address will change, which can affect static IPs and DHCP reservations.
- vTPM and BitLocker: vTPM state can't be migrated; make sure to back up BitLocker recovery keys.
- Plan a maintenance window and test with a non-critical VM first.
Method 1: Proxmox ESXi Import Wizard
The import wizard that came with Proxmox VE 8.2 lets you see VMs on ESXi right from the Proxmox UI and import them along with their configuration. It's tested with ESXi 6.5–8.0 and is the most practical way today.
- Go to Datacenter → Storage → Add → ESXi. Enter the ESXi host address, an admin username and password. If ESXi uses a self-signed certificate, tick the option to skip certificate verification.
- Click the new storage and you'll see the list of VMs on ESXi. Pick the VM you want to move and click Import.
- Choose the target storage and network bridge (e.g.
vmbr0). - In the Advanced tab you can pick a seperate target per disk, change the NIC model and disable unneeded devices like CD/ISO.
- Check the resulting Proxmox configuration in the Resulting Config tab.
- Power off the source VM on ESXi and start the import.
- When it's done, start the VM on Proxmox and run your checks (see the "after migration" section below).
Known limitations: disks on vSAN can't be imported directly (move them to another datastore first), encrypted disks aren't supported, and special characters like + in datastore names can cause problems. Connecting through vCenter slows the import down alot, so we recommend connecting directly to the ESXi host.
Method 2: Migrating with OVF
If Proxmox can't reach the ESXi host directly or you already have OVF exports, this method does the job. You export the VM with VMware's ovftool and import it on Proxmox with qm importovf:
# on a machine with ovftool: export the VM from ESXi as OVF
ovftool vi://root@ESXI_IP/web01 /export/
# after copying the files to Proxmox, import and add a NIC
qm importovf 120 /export/web01/web01.ovf local-zfs
qm set 120 --net0 virtio,bridge=vmbr0
qm importovf creates the CPU, RAM and disks but doesn't add a NIC, so we add the network card separately in the last line. For Windows VMs you also need to check the disk controller (explained below).
Method 3: VMDK Disk Import
This method gives you the most control: you copy the disk and create the VM on Proxmox yourself. Each VMDK disk has a descriptor file (web01.vmdk) and a -flat.vmdk file holding the actual data; you need to copy both:
# with the VM powered off, copy the disk files to Proxmox (SSH must be on in ESXi)
mkdir -p /root/import
scp root@ESXI_IP:/vmfs/volumes/datastore1/web01/web01*.vmdk /root/import/
# create an empty VM
qm create 121 --name web01 --memory 4096 --cores 2 \
--net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-single --ostype l26
# import the disk (added as unused0)
qm disk import 121 /root/import/web01.vmdk local-zfs
# attach the disk and set the boot order
qm set 121 --scsi0 local-zfs:vm-121-disk-0 --boot order=scsi0
Copying large disks can take a while; the VM must stay off during that time or the disk will be inconsistent. A fast NVMe disk and a 10 Gbit network shorten this a lot.
After Migration
Linux VMs
Linux usually boots fine, but since the virtual NIC changed, the interface name changes too (e.g. ens192 → ens18) and networking seems broken. Update the config with the new name and install the QEMU Guest Agent instead of VMware Tools:
ip -br link # see the new interface name (e.g. ens18)
sudo sed -i 's/ens192/ens18/g' /etc/netplan/*.yaml
sudo netplan apply
sudo apt install -y qemu-guest-agent
sudo systemctl start qemu-guest-agent
# enable the guest agent on the Proxmox host
qm set 121 --agent enabled=1
On Debian-based systems that use /etc/network/interfaces, just make the same change in that file.
Windows VMs
Windows doesn't ship with VirtIO disk and network drivers, so if you try to boot straight from VirtIO SCSI you'll unfortunately get an INACCESSIBLE_BOOT_DEVICE blue screen. The safe path:
- Attach the boot disk as SATA for the first boot; you can also set the NIC to Intel E1000 temporarily.
- Attach the virtio-win ISO published by Fedora and run the guest tools installer inside it; it installs the VirtIO drivers and the QEMU Guest Agent together.
- Add a temporary 1 GB VirtIO SCSI disk to the VM and let Windows detect it, so the driver gets loaded.
- Shut the VM down, detach the boot disk and reattach it as SCSI, update the boot order and delete the temporary disk. Switch the NIC to VirtIO as well.
Since the hardware changed, Windows sees the NIC as a new device; you may need to re-enter static IP settings.
VMware to Proxmox Equivalents
| VMware | Proxmox VE equivalent |
|---|---|
| VMware Tools | QEMU Guest Agent |
| VMXNET3 NIC | VirtIO (paravirtualized) NIC |
| PVSCSI controller | VirtIO SCSI single |
| vSwitch / Port Group | Linux bridge (vmbr) / VLAN tags, SDN |
| vMotion | Live migration |
| vSphere HA | Proxmox HA (cluster) |
| vSAN | Ceph |
| Snapshot | Snapshot (ZFS, Ceph, LVM-thin, qcow2) |
| Veeam and similar backup | Proxmox Backup Server |
Common Problems
| Symptom | Likely cause | Fix |
|---|---|---|
| VM won't boot, no disk found | BIOS/UEFI mismatch | If the source was UEFI, set BIOS to OVMF and add an EFI disk; otherwise keep SeaBIOS |
| INACCESSIBLE_BOOT_DEVICE on Windows | No VirtIO driver | Move the disk to SATA, install virtio-win drivers, then switch to SCSI |
| Linux boots but no network | Interface name changed | Find the new name with ip -br link and update the network config |
| IP conflict or DHCP hands out a different IP | MAC address changed | Update the DHCP reservation or set the old MAC manually in Proxmox |
| Import is very slow | Connecting through vCenter or snapshots | Connect directly to the ESXi host, consolidate snapshots |
| Import fails | vSAN or encrypted disk | Move the disk to another datastore, remove encryption |
Migrating from VMware to Proxmox with VECDC
You can move a few VMs yourself, but when dozens of servers, clusters, Ceph or backup infrastructure are involved, planning matters alot. With our Proxmox consulting and VMware consulting services we support every step of the migration, from inventory and the migration plan to cluster setup and testing. We also set up Proxmox Backup Server to back up your new infrastructure.
If you need hardware to run Proxmox, our dedicated servers are delivered within 24 hours and you can choose the location when ordering.
Frequently Asked Questions
Is there downtime when migrating from ESXi to Proxmox?
Yes, the source VM needs to be powered off for a consistent migration. The live-import option in the Proxmox Import Wizard starts the VM while the import runs, which can cut downtime to a few minutes; but if the import fails, data written during that time is lost.
Can I migrate without vCenter?
Yes. The Proxmox Import Wizard connects directly to the ESXi host and doesn't need vCenter. In fact, importing through vCenter is much slower, so connecting directly to the host is recommended.
Is the Windows license affected after migration?
Since the virtual hardware changes, Windows may ask for reactivation in some cases. Volume-licensed (KMS) systems usually have no issue; for retail licenses keep your product key handy and check the license terms.
Can I go back from Proxmox to VMware?
Yes. The original VM on ESXi isn't deleted during migration, so if something goes wrong you can power it back on. That's why you shouldn't delete the ESXi copy until you've tested the Proxmox VM for a while and are sure everything works.
In Short
Migrating from VMware ESXi to Proxmox is much easier than it used to be thanks to Proxmox's Import Wizard. Start with a good inventory and backup, test on a non-critical VM first, and you can move most servers in a few clicks. Just watch out for VirtIO drivers on Windows and the interface name on Linux. If you get stuck on a bigger migration, drop us a message, were happy to help.