How to migrate from VMware ESXi to Proxmox VE (2026 guide)

Broadcom made VMware subscription-only, priced per core with a 16-core minimum per CPU, and a lot of ESXi shops are now doing the math on Proxmox VE (we put the two bills side by side in Proxmox vs VMware in 2026). The easiest way to migrate VMware to Proxmox is the ESXi import wizard that shipped in Proxmox VE 8.2 in April 2024 and is still there in 9.2. It does most of the job. The rest is where migrations fail: Windows drivers, VLAN mapping and boot mode. So plan for those first.

Inventory every VM

Do this in a spreadsheet, one row per VM. It’s the list you’ll work from on cutover night.

• vCPU, RAM, and every disk with its size and whether it’s thin or thick
• Each NIC’s MAC address, port group and VLAN ID, plus any static IPs
• Boot mode: legacy BIOS or UEFI
• Snapshots (consolidate them; they slow the importer badly)
• vTPM, disk encryption, and whether the disks sit on vSAN

The rule for every import: powered off, no snapshots, unencrypted, not on vSAN.

Some guest prep has to happen on ESXi. On Windows, uninstall VMware Tools while you still can, and clear any static IP config, or Windows will complain the address belongs to an adapter that no longer exists. vTPM state doesn’t carry over, so if BitLocker keys live in a vTPM, remove the encryption first and keep the recovery keys handy.

Build the target first

One host or a cluster?

One host is fine for a lab or a handful of VMs. For HA you want three nodes, because the cluster needs a quorum of votes to stay up; two nodes plus a QDevice (a small third vote running elsewhere) also works. Keep node-to-node latency under 5 ms and give corosync, the cluster heartbeat, its own 1 Gbit NIC. Our server clusters come with a 10 Gbps private network between nodes for storage and import traffic.

Storage

On a single box, use ZFS. On three or more, Ceph is built into Proxmox and gives you shared storage for live migration. Ceph keeps three copies by default, so usable space is about a third of raw. For capacity, see our storage servers for Ceph.

Networking

Make one VLAN-aware bridge per physical uplink (vmbr0, vmbr1 and so on) and tag each VM’s NIC with the VLAN of its old ESXi port group. Write that mapping down before import day. Run the import over a private network if you can, not your public uplink. Want the hypervisor already installed? Our Proxmox dedicated servers ship that way.

Pick your method

Method 1: the ESXi import wizard (use this one)

1. Update the Proxmox host.
2. Go to Datacenter → Storage → Add → ESXi and enter the host’s IP or name and an admin account. Self-signed certificate? Tick Skip Certificate Verification.
3. Point it at the ESXi host, not vCenter, which the Proxmox wiki says will “dramatically reduce performance”.
4. Click the new storage in the tree; the host’s VMs should be listed.
5. Pick a VM, hit Import, and choose a target storage and bridge. Advanced covers per-disk storage, NIC models and skipped devices.
6. Check the Resulting Config tab. A Windows boot disk has to start on SATA (or IDE). Windows has no VirtIO driver yet, and removing VMware Tools also removes the PVSCSI driver. If it lands on SCSI, reattach it as SATA before first boot.
7. Power off the source VM and start the import.

Read the limits twice. Import was tested from ESXi 6.5 to 8.0. vSAN disks won’t import, so move them to another datastore first, and storage-policy encryption has to come off. A + in the datastore name can break it. And don’t queue twenty VMs at once: the ESXi API has a low connection limit, and past it the host blocks clients for about 30 seconds and throws 503 Service Unavailable. Proxmox advises no more than four disks importing at a time.

Live import

Tick live import and the VM boots on Proxmox while the rest of its disk streams in. The ESXi copy is still off, so there’s some downtime, just less. The catch is serious: if the import fails partway, everything the VM wrote since it started is gone. Try it on something disposable first, and never over a slow or lossy link.

Method 2: OVF export or a raw VMDK

Use this when Proxmox can’t reach the ESXi API, the VM lives on vSAN, or the host is older than the wizard was tested on. Export with VMware’s ovftool (the Linux 64-bit build, new enough for your ESXi version):

./ovftool vi://root@{IP or FQDN of ESXi host}/{VM name} /path/to/export/location

Then, from the directory holding the .ovf and its .vmdk:

qm importovf 100 Server.ovf local-zfs

qm importovf creates the VM without a network card, so add one. It also puts the disk on SCSI: fine for Linux, but for Windows detach it and reattach it as SATA. Set the CPU type and controller while you’re there, for example qm set 100 --cpu x86-64-v2-AES --scsihw virtio-scsi-single.

For a single disk, create an empty VM, delete its default disk, and import the VMDK. Proxmox needs both the .vmdk and the -flat.vmdk file:

qm disk import 104 Server.vmdk local-zfs

The disk shows up as unused0 in the VM’s hardware panel. Double-click it to attach it to a bus (SATA for Windows), then set it first under Options → Boot Order.

Windows guests need VirtIO drivers

VirtIO devices are paravirtual: the guest talks to the hypervisor directly instead of driving an emulated SATA controller or Intel NIC. They’re faster, and Windows doesn’t ship the drivers.

Get the virtio-win ISO from Fedora’s archive. The Proxmox wiki currently lists no known issues with 0.1.271 and flags 0.1.285 for read errors on I/O-heavy Windows Server 2025 VMs, so check it on the day. Mount the ISO, run virtio-win-gt-x64, then virtio-win-guest-tools for the QEMU guest agent.

Here’s the part people get wrong. Flip the boot disk straight to VirtIO SCSI and Windows blue-screens with INACCESSIBLE_BOOT_DEVICE, because it has never loaded that driver. Boot once on SATA. Add a 1 GB dummy disk on SCSI with the controller set to VirtIO SCSI single, and let Windows install vioscsi for it. Shut down, remove the dummy, reattach the boot disk as SCSI, fix the boot order, start.

The symptom usually names the cause:

• Blue screen on boot: wrong controller, or you skipped the dummy disk. Reattach as SATA and redo it.
• No network: the NetKVM driver isn’t installed.
• Disk feels slow: it’s still on SATA.

Three things to check on Linux guests

First, the initramfs. A trimmed one may lack the virtio modules, so check with lsinitramfs (Debian, Ubuntu) or lsinitrd (RHEL family) before the move. If a VM already won’t boot, try its rescue boot entry, or boot it on SATA and fix it from inside.

Second, the NIC name. An interface that was ens192 on ESXi typically comes up as ens18 on Proxmox, and any netplan or ifcfg file pointing at the old name leaves the box offline.

Last, match the boot mode. Legacy BIOS guests get SeaBIOS. UEFI guests get OVMF plus an EFI disk, which keeps boot entries across reboots.

Cutover and rollback plan

Go in this order: test VMs, then dev, then stateless production, and databases last.

Drop DNS TTLs a day or two ahead so a rollback doesn’t wait on caches. Copy each old MAC onto the new NIC, or update DHCP reservations. After cutover, leave the ESXi VM powered off but untouched for a week; rolling back is then just shutting down the Proxmox copy and powering the old one on. Never run both at once.

A VM isn’t done until the guest agent reports its IP in the Proxmox summary, a backup has completed and monitoring is green.

Backups after the move

Proxmox Backup Server is open source (AGPLv3) and does incremental, deduplicated backups from inside the Proxmox GUI. Veeam and Nakivo both support Proxmox VE if you’d rather keep your current tool. Either way, don’t start a migration week without a working backup target on another machine.

Where GigeNET fits

We’ve run Proxmox in production for over 15 years. Our own VPS and cloud platform is built on it.

Proxmox VE comes preinstalled on our Proxmox dedicated servers at no extra charge. We help with the move. On larger deployments it’s often included; smaller jobs are quoted up front.

FAQ

Need hardware to land on? Proxmox comes preinstalled on our dedicated servers and clusters, and we’ll help with the move. Tell us what you’re running on our custom quote form.