Migrating from VMware to Proxmox VE: a complete guide

Since Broadcom acquired VMware, subscription bundling and steep price increases have pushed many teams to look for an alternative. Proxmox VE is the most common destination: an open-source hypervisor, no per-core or per-VM licensing, and a feature set that covers what most production workloads actually need. This guide walks through a migration that does not disrupt your services.

Why teams leave VMware

The trigger is rarely the technology. ESXi still works. What changes is the contract: perpetual licences gone, mandatory subscription tiers, and renewal quotes that no longer fit the budget. Proxmox VE is open source and far lighter on this front: there is no per-core or per-VM licensing. A per-socket subscription, which funds Proxmox development and gives you the stable enterprise repository and vendor support, replaces VMware’s licensing at a fraction of the cost.

Assess before you move

A migration succeeds or fails in the assessment phase. Before touching anything, inventory:

• Every VM: vCPU, RAM, disk size, OS, and how critical it is.
• Dependencies: which VMs talk to which, and what cannot tolerate downtime.
• Networking: VLANs, port groups, firewall rules.
• Storage: datastores, total capacity, IOPS profile.

This inventory tells you how to size the Proxmox VE cluster and which VMs migrate first. Start with the low-risk ones.

Choose a migration approach

There are two realistic paths.

Cold migration. The VM is powered off, its disks are exported, converted and imported into Proxmox VE, then booted. Simple and reliable, with a maintenance window per VM.

Live or staged migration. The VM is replicated to Proxmox VE while still running on VMware, then cut over with a short final sync. More complex, but the downtime drops to minutes.

Proxmox VE ships an integrated import wizard that can connect directly to an ESXi host and import VMs, which removes most of the manual conversion work.

Convert the VMs

The disk format moves from VMDK to qcow2 or raw. The import wizard handles this, or you convert manually with qemu-img:

qemu-img convert -f vmdk -O qcow2 source-disk.vmdk target-disk.qcow2

Two things matter on the guest side:

• VirtIO drivers: install them so the VM gets paravirtualised disk and network performance. On Windows guests, do this before the migration while VMware Tools is still present.
• Boot mode: match BIOS or UEFI to what the VM expects, or it will not boot.

Cut over and validate

For each migrated VM, validate before declaring it done: it boots, the network is reachable, the application responds, and performance matches the baseline you recorded during assessment. Keep the VMware copy until validation passes. That is your rollback.

Migrate in waves, grouped by dependency. Critical VMs go last, once the process is proven on the rest.

Where this gets hard

The mechanics are well documented. What is harder is doing it without a gap in service: sequencing dependencies, sizing the target cluster correctly, getting HA and storage right on day one so you are not migrating onto a fragile platform.

That is the work our Proxmox migration service takes on. We assess the existing VMware estate, size and build the Proxmox VE cluster, run the migration in waves and validate each one. You move off Broadcom pricing without carrying the migration risk yourself. Once migrated, you run the cluster yourself or hand it to managed Proxmox hosting.