Migrating from VMware to Proxmox: the runbook
The decision to leave VMware is usually made before opening this guide. Here we cover the how: what has an equivalent and what does not, how to prepare each virtual machine, and why migration goes in waves, with a rollback always available.
Estimate my cost →The equivalents that reassure #
If you are still weighing cloud, on-premises or colocation, start with our guide on life after VMware: this one assumes the decision is made. Most of what you use in VMware exists on the other side: high availability (vSphere HA) maps to the built-in HA manager, vMotion to live migration, Storage vMotion to online disk moves, vSAN to Ceph, and snapshots remain snapshots. Placement rules (affinity and anti-affinity, the functional equivalent of DRS) let you forbid two redundant servers from running on the same host. The most visible difference is economic: no per-compute-unit licence, a subscription per processor socket.
What has no equivalent, and must be said #
Fault Tolerance, the mode where a ghost copy of the machine runs in parallel and takes over with zero interruption, has no equivalent. If an application truly depends on it, the answer is at the application layer (an active/active software cluster), not the hypervisor. An honest migration plan lists this on day one rather than discovering it during acceptance.
Prepare every VM before moving it #
A VMware virtual machine carries VMware drivers (the VMware Tools). On the new hypervisor it needs VirtIO drivers and the QEMU guest agent. Order matters: install the new drivers before the switch, remove the old tools after. Also think of Windows licences tied to hardware, and the boot mode (BIOS or UEFI) that must follow. A prepared VM switches in minutes; an unprepared one boots with no network and no disk, at the exact hour everyone is watching.
The import wizard, and the live-import trap #
Since version 8.2 of the hypervisor, an import wizard does most of the work: you declare the VMware host as a storage source, the list of virtual machines appears, you pick and import. The wizard reads the original configuration, transfers the disks and converts them. Two limits to know before relying on it. First, it cannot read vSAN storage: an intermediate step is then required. Second, the live-import option, which starts the machine before the copy finishes to shorten the outage, has a price: disk access goes over the network until the copy completes, which can make a database unusable, and above all, if the import fails midway, everything written since start-up is lost. You restart from the previous state. For a sensitive application, an announced maintenance window remains safer than a failed live import.
The Windows step nobody documents #
Installing VirtIO drivers inside a Windows machine is not enough: Windows only uses them once it has seen the matching controller. Hence a four-step manoeuvre that surprises the first time. Add a temporary one-gigabyte disk on a VirtIO SCSI controller, reboot, and Windows loads the right driver. Then remove the temporary disk, detach the system disk and re-attach it as VirtIO SCSI, and check the boot order. Rehearse this on a test machine before doing it on a production one: a wrong boot order is repairable, a lost database much less so.
Migrate in waves, never in one block #
The first wave is a set of test machines: it validates the whole chain, tooling, network, backup, monitoring. The second takes non-critical applications. Critical applications go last, once the machinery is proven. Each wave has an announced window, its DNS switch and its rollback procedure: until the wave is signed off, the old platform stays ready to take back over.
Databases: logical migration, not hot copy #
Hot-copying an active database is the best way to ship an inconsistent state. The safe path is logical: replication to the new machine, or a backup followed by a restore inside the window. It takes longer to prepare and far less time to repair.
The chance to re-choose your hosting #
A hypervisor migration is the natural moment to reopen the hosting question: the colocation contract, the subscribed power, the carriers present on site. Our Digital Architect sizes the target cluster and produces the requirement sheet (space, power, cooling) you can compare site by site before signing.
FAQ #
Switching a prepared VM takes minutes; the project takes weeks, because most of the time goes into inventory, driver preparation and wave-by-wave validation. That time is what prevents the surprise outage.
Often yes: major backup vendors support several hypervisors. Validate with your version, and test it on the first wave, restore included.
Address the need at the application layer (active/active software clustering) before migrating: this mode has no hypervisor equivalent, and finding out at the end of the project is expensive.
No: prefer a logical migration (replication or backup/restore) over hot copy, to guarantee a consistent state when starting on the new platform.
Written on 10 September 2026.
From reading to comparing: relevant data centers
Estimate my cost → Compare data centers