Migrating Your VMware ESXi Workloads to Proxmox VE

Migrating Your VMs Off VMware ESXi: A Practical Playbook

Moving off VMware is rarely just about the license cost—it's usually a combination of that expense and wanting to consolidate your infrastructure under one management plane. This guide walks you through planning, converting, and validating a migration so you can get workloads onto Proxmox VE with minimal disruption. You'll end up with VMs running on ZFS-backed storage, backed by automated schedules using Automated Backups with Proxmox Backup Server or your existing backup strategy, and ready to run alongside the LXC containers you've been keeping separate for years.

Key Takeaways

Cost savings: Dropping VMware licensing can cut infrastructure spend by 30-50% depending on what edition you're currently running. Tool choice matters: qm import is fastest when your ESXi datastore is reachable; OVA/OVF export works everywhere but requires more steps. Validate before cutover: Disk format, network adapters, and storage paths are the three most common failure points during migration.

What Are You Actually Moving?

The biggest mistake I see people make isn't technical—it's not auditing what they're moving first. Before you touch a single VM, inventory your estate: which machines need downtime windows versus live migration tolerance, how much data is on each disk, and whether any are using features that don't map cleanly (like VMware-specific tools or specific network adapter types).

A typical homelab might have five to fifteen workloads—Home Assistant OS, a TrueNAS VM, two Docker containers, maybe an OPNsense firewall. A small business environment could be pushing 50+ VMs across several hosts and datastores. Your migration approach changes significantly depending on scale. If you're running Build a Private Cloud at Home with Proxmox VE as part of this journey, the consolidation story gets even stronger since your existing LXC containers can share storage pools with migrated VMs without extra licensing overhead.

Planning Your Migration Window

Two decisions drive everything else: downtime tolerance and network configuration during migration.

For a homelab setup where you're running OPNsense on Proxmox as your gateway, migrating the firewall last means you can keep existing workloads connected to ESXi's virtual switches while their storage gets repointed. For business environments with multiple hosts and vCenter-managed clusters, consider a phased approach—migrate in waves by workload priority rather than trying everything at once.

If downtime matters more than speed, plan your migration window around off-peak hours. A typical small VM (20 GB disk) takes about 15 to 30 minutes with qm import depending on network throughput and whether you're reading from a SAN or local datastore. Larger databases might need maintenance windows of an hour or two for final sync before cutover.

Three Migration Approaches That Actually Work

Approach One: Direct Import with qm importdisk and qm create

This is the fastest route when your ESXi datastores are directly accessible from Proxmox—either through NFS, iSCSI, or shared storage like iSCSI Block Storage on Proxmox from TrueNAS SCALE that you already use.

# Create a new VM in the destination datastore (e.g., local-zfs)
qm create 105 --name "migrated-webserver" \
    --memory 4096 --cores 2 --net0 virtio,bridge=vmbr0 \
    --scsihw virtio-scsi-pci

# Import the VMDK directly into Proxmox's storage pool
qm importdisk 105 /var/tmp/old-webserver.vmdk local-zfs \
    --format qcow2

# Attach and boot
qm set 105 --scsi0 local-zfs:vm-105-disk-0
qm start 105

The key detail here is the disk format. importdisk converts to whatever you specify with --format. QCOW2 gives you thin provisioning and snapshot support; raw VMDK preserves VMware's exact layout but uses more space. I tend toward qcow2 for new VMs because it plays nicer with Optimizing ZFS Pools in Proxmox VE when combined with compression enabled on the storage pool.

Approach Two: OVA/OVF Export and Import

This approach works everywhere—no special datastore access required—and is my go-to for VMs spread across multiple ESXi hosts or those that need to be moved between different Proxmox clusters later. The trade-off is extra time spent exporting from VMware's web UI, then importing on the target side.

# Export OVA from vSphere Client (or use ovftool)
ovftool --name=migrated-db esx://esxi-host/?dc=Datacenter \
    vmware:/datastore/vm-name/db-vm.vmdk \
    /var/tmp/migrated-database.ova

# Import into Proxmox using the built-in OVA tool (OVA2QM)
ovf --format qcow2 migrated-database.ova local-zfs 106 "db-server"

The ovftool command line utility is part of VMware's SDK downloads and handles most conversion scenarios reliably, including network adapter types and disk consolidation during export. If you're migrating Home Assistant OS on Proxmox or other appliances that come pre-configured in OVA form from their vendors, this approach lets you reuse those same files without reconfiguration headaches.

Approach Three: VMware's vCenter Converter Standalone (for Complex Cases)

When you're dealing with large databases, specific guest OS quirks, or when the source ESXi host is too far away to reach directly via network storage protocols, VMware's free converter tool handles most of the heavy lifting by creating a virtual appliance that performs live migration. The downside: it adds complexity and usually requires more downtime than direct import approaches since you're copying data twice—once from VMFS during conversion, once into Proxmox during final sync.

Common Pitfalls (and How I Avoid Them)

Disk format mismatch. This is the one that bites most often. If your ESXi disks are thick-provisioned on a datastore with specific alignment settings and you import them as thin without adjusting guest OS expectations, boot can fail silently or perform poorly for days before anyone notices. Always check qemu-img info after migration to confirm sector sizes match:

qemu-img info /var/lib/vz/images/105/vm-105-disk-0.qcow2

Network adapter type. VMware defaults to VMXNET3 for most modern guests. When importing directly, Proxmox may assign an E1000 or virtio adapter depending on the import method. Guest drivers might need updating—especially Windows VMs that expect specific NIC types at boot time. I always verify after migration by checking ip a in Linux and Device Manager in Windows before declaring victory.

Storage path changes. If your ESXi datastore uses paths like /vmfs/volumes/datastore1/VM_NAME/disk.vmdk, ensure the new Proxmox storage pool has sufficient space before starting, not after you've already copied 80% of a large disk and hit capacity. A quick df -h on your destination ZFS pool before beginning saves this headache entirely.

IP address conflicts during migration. When migrating workloads that share IP ranges with other services (especially when running Multiple Docker LXCs vs One Docker VM alongside), temporarily disconnect migrated VMs from the network until their DHCP reservations or static assignments are confirmed active on Proxmox's side.

Choosing Between qm Import and OVA/OVF Export

Scenario	Best Approach	Downtime Estimate
Single host, direct storage access	qm importdisk	15-30 min per VM
Multiple hosts or remote datastores	OVA export/import	30-60 min per VM
Large databases (>200 GB)	VMware Converter Standalone	1-4 hours depending on size
Homelab with mixed workloads	Mix of qm import + ovftool	Varies by workload priority

Post-Migration Validation Checklist

After migration completes, run through these checks before cutting over any critical services:

# Verify VM is running and accessible via SSH or RDP
qm list 105 --output json | jq '.[]'

# Check disk integrity on the new storage pool
zpool status -xv

# Confirm network connectivity from within the guest OS (via console)
ping -c4 8.8.8.8 && echo "Network OK" || echo "Network issue detected"

For Windows VMs, verify that VMware Tools has been replaced by virtio drivers and check device manager for any yellow exclamation marks on network adapters or storage controllers. For Linux guests running LXC Dev Environments alongside your migrated workloads, ensure the guest kernel modules match the host's version to avoid potential driver mismatches during future updates.

What Comes Next?

Once your VMs are settled on Proxmox VE and validated—ideally after running them for a few days under normal load—you're in good shape to explore further consolidation options like Running Docker Inside LXC Containers or setting up automated backup schedules with PBS. For environments where remote access matters, consider following the guidance on Cloudflare Tunnel on Proxmox for Zero-Trust Remote Access to secure your management plane without opening ports directly.

Migrating away from VMware ESXi doesn't have to mean months of downtime or complex tooling decisions. With the right planning, a clear migration path (qm import for speed, OVA/OVF for flexibility), and validation before cutover, you can move most workloads in days rather than weeks—and then start reaping those licensing savings immediately.