Guides
How to Migrate a VMware VM to Proxmox VE
Since Broadcom's licensing changes, a lot of teams are moving their virtual machines off VMware ESXi and onto Proxmox VE. The good news: you rarely have to rebuild anything. Proxmox 8.2 and newer include a built-in import wizard that pulls VMs straight off an ESXi host, and for the cases it can't reach there is a reliable manual path. This guide covers both, plus the post-migration steps that decide whether the guest actually boots.
Rather have someone do this for you? See our VMware to Proxmox migration service. The first step is an assessment of your environment.
Before You Start
- A working Proxmox VE host (8.2 or newer) with enough free storage to hold the migrated disks.
- Network access from Proxmox to the ESXi host on TCP port 443.
- Administrative credentials on the ESXi host (root, or an account with VM and datastore read access).
- A maintenance window. Plan to power off the source VM before importing.
- For Windows guests: the VirtIO driver ISO from the Fedora project, and a note of any static IP settings.
The import wizard supports ESXi 6.5 through 8.x. It cannot import disks stored on vSAN datastores; use the manual method in that case.
Method 1: The Built-In Import Wizard (Recommended)
If the source ESXi host is still online, this is the fastest and safest route. No third-party tools required.
Add the ESXi host as a Proxmox storage
In the Proxmox web interface, go to Datacenter, then Storage, then Add, and choose ESXi. Enter a name, the ESXi host's address, and the login credentials. Check Skip Certificate Verification unless you have trusted certificates on the host.
Prepare the source VM
Shut the VM down cleanly and consolidate or remove any snapshots. Snapshots make imports much slower. On Windows guests, uninstall VMware Tools and install the VirtIO drivers from the ISO before you power off. Note the current IP configuration, because the network adapter will change.
Run the import
Select the ESXi storage you just added. Proxmox lists every VM on that host. Pick the VM, choose the target storage and network bridge, and start the import. Proxmox copies the disks and builds a matching VM configuration automatically.
First boot and cleanup
Start the VM and watch the console. On Windows, open Device Manager to confirm the VirtIO SCSI and network drivers loaded. Set the IP address again if the guest used a static one. Install the QEMU Guest Agent so Proxmox can see the guest's IP and shut it down cleanly.
Method 2: Import an OVF or OVA
When the wizard can't reach the host, export the VM first. From the ESXi host client, power off the VM and export it as an OVF template. Copy the files to the Proxmox host, then run:
qm importovf <vmid> vm.ovf <storage>This creates the VM and imports the disks in one step. Check the resulting hardware settings before the first boot: VirtIO SCSI for disks, VirtIO for the network.
Method 3: Manual VMDK Conversion
The fallback for edge cases, and a good way to understand what's happening under the hood.
Export the VM from ESXi
With the VM powered off, export it as an OVF/OVA from the ESXi host client, or copy the .vmdk files off the datastore directly.
Convert the disk
Copy the VMDK to the Proxmox host and convert it: qemu-img convert -f vmdk -O qcow2 disk.vmdk disk.qcow2. Raw also works if your storage prefers it.
Create a VM and attach the disk
Create a new VM in Proxmox without a disk, then attach the converted image: qm disk import <vmid> disk.qcow2 <storage>. Set the SCSI controller to VirtIO SCSI and the network device to VirtIO.
Common Issues After Migration
- Windows blue-screens on first boot almost always mean missing VirtIO storage drivers. Install them on the VMware side before migrating.
- A hidden old network adapter in Windows can hold the old static IP. Re-enter the IP on the new VirtIO adapter.
- The import wizard cannot pull disks from vSAN datastores. Use the OVF or manual VMDK method there instead.
- Importing through vCenter is slower than connecting directly to the ESXi host. Connect to the host.
- Change the VM's BIOS setting to match the source. A VM installed for UEFI will not boot under SeaBIOS and vice versa.
When DIY Makes Sense (and When It Doesn't)
If you have one or two test VMs and a weekend to spare, this guide is honestly all you need. Where migrations go sideways is production workloads: an application server that has to be back up by Monday morning, a database that can't lose a transaction, or a fleet of twenty VMs where a missed driver on number eleven means a very long night.
The steps above are the easy 80%. The hard 20% is everything around them: sizing the Proxmox cluster correctly, staging the cutover so users never notice, having backups running before you touch the source host, and knowing exactly how to roll back when something unexpected happens at 2 AM. That judgment comes from having done it many times, not from a guide.
We run these migrations for businesses like yours, typically after hours, with a pilot VM first and a rollback plan for every step. If you'd rather spend your weekend on something else, let us take it from here.
Rather Not Do This Alone?
One wrong setting on a production VM costs more than the migration would have. We move VMware environments to Proxmox with staged after-hours cutovers, backups running from day one, and a tested rollback plan at every step, so your team wakes up to a working cluster instead of a recovery project.
Start with a migration assessment. We'll look at your environment, tell you exactly what the move involves, and give you a straight answer on cost.
Request a Migration Assessment