What Happens When You Migrate Off VMware: A Plan for Proxmox, Nutanix AHV and Hyper-V

A VMware migration moves each virtual machine (VM) from an ESXi source host to a new target platform. The disk copy is the easy part. The risk sits inside the guest: the boot driver, the firmware, the network settings and the tools that run there.

This guide gives the technical steps to migrate off VMware to Proxmox VE, Nutanix AHV, and Microsoft Hyper-V or Azure Local. It also covers Red Hat OpenShift Virtualization, HPE VM Essentials, VergeOS and XCP-ng. To select a platform first, read our guide to VMware alternatives in 2026. This guide starts after that decision.

Short answer: To migrate off VMware, prepare each guest before you copy it. Install the target drivers, record the network settings and remove encryption that depends on the vTPM. Then copy the disks with a tool that matches your target platform. Use warm migration with Changed Block Tracking (CBT) to keep downtime short. Keep the source VM powered off and intact until the target VM passes its tests.

IT Leaders Report 2026

What are your IT peers investing in 2026?

We spoke to about 1,300 IT leaders from various organisations to understand what they're evaluating. Most of it is the kind of thing you'd only hear from a peer you know well enough to ask, so we've put it in one place.

Read the report

vSphere 8 End of Support and the VDDK Change: Why the Migration Window Is Now

Two technical dates set the schedule for most VMware migration projects. vSphere 7 reached end of general support on October 2, 2025, after a six-month extension. vSphere 8 reaches end of general support on October 11, 2027.

If your ESXi 7 hosts have no parts support, both an upgrade to ESXi 8 and a migration need new hardware. Plan one purchase that serves the migration.

What happens when your VMware support expires

The hosts keep running when support expires, without new patches or security fixes. In May 2025, heise reported that Broadcom sent cease-and-desist letters to perpetual-license holders with expired support. The letters told them to remove patches installed after the support end date.

Broadcom removed public VDDK downloads

The Virtual Disk Development Kit (VDDK) is the VMware library that many migration and backup tools use to read ESXi disks. On or about August 25, 2026, the public VDDK download pages stopped working, as Platform9 documented. Broadcom told TechTarget that VDDK is not a customer entitlement. It stays available through select Technology Alliance Program partners.

Copies of VDDK that you already installed keep working. A new migration appliance that needs a fresh copy is the problem. The tools section below shows which tools need it.

‍

What Happens to a VM When You Migrate Off VMware

Every target platform changes the same six layers inside or under the VM. Prepare each layer on the source VM, and your cutover becomes a copy and a boot.

Disk conversion: VMDK to QCOW2, raw and VHDX

KVM platforms store disks as QCOW2 or raw. Hyper-V stores disks as VHDX. Most migration tools convert the disk during the copy, so you rarely run qemu-img convert by hand.

Consolidate snapshots first. SCVMM and the virt-v2v SSH method refuse them, and they slow the Proxmox import.

Storage controller and boot driver

This layer causes the most failed first boots. A Windows guest that boots from a VMware controller needs a driver for the new controller before cutover. With no driver, Windows stops with INACCESSIBLE_BOOT_DEVICE (bug check 0x7B).

On KVM targets, install the VirtIO drivers from the virtio-win ISO while the VM still runs on ESXi. If a Windows guest still fails, attach its boot disk as SATA for the first boot. Then add a small temporary VirtIO disk, let Windows load the driver, and switch the boot disk to VirtIO SCSI.

Linux guests need the VirtIO modules in the initramfs. Rebuild the initramfs with dracut or update-initramfs before the copy. virt-v2v rebuilds it for you when it does the conversion.

Guest tools: VMware Tools out, target agent in

Remove VMware Tools from each guest. The virt-v2v documentation warns that its automatic removal of VMware Tools on Windows often fails, so plan a manual step. Then install the QEMU guest agent on KVM targets. Hyper-V integration services are already in current Windows and Linux releases.

Firmware, Secure Boot, vTPM and BitLocker

Match the firmware type on the target. A UEFI guest started with BIOS firmware cannot find its bootloader. On Proxmox, UEFI guests use OVMF and an EFI disk. On Hyper-V, BIOS guests use Generation 1 and UEFI guests use Generation 2. You cannot change the generation after you create the VM.

The vTPM state does not move with the disk. If BitLocker or LUKS keys are sealed to the vTPM, the guest asks for a recovery key at first boot. Export every recovery key before cutover. For Azure Migrate and the Proxmox importer, turn off disk encryption first.

Network identity: NIC names, static IPs and MAC addresses

Linux uses the PCI slot in the interface name. A VMware guest with ens192 often comes up as ens18 on Proxmox, and its netplan or ifcfg file no longer matches. Windows sees a new network adapter, and the static IP stays on the old, hidden adapter.

Record the IP configuration of each VM before cutover. Some tools keep static IPs: Nutanix Move, Azure Migrate (Windows guests) and the Windows Admin Center VM Conversion extension. Keep MAC addresses only where DHCP reservations or software licenses depend on them.

‍

Warm vs Cold VMware Migration: How Much Downtime Each VM Takes

The copy method sets the downtime for each VM. Select it per VM, to match each outage window.

Cold migration copies the disks while the source VM is off. Downtime equals the used data divided by the effective throughput. A VM with 2 TB of data at 400 MB/s stays offline for about 85 minutes before the first boot.

Warm migration copies the disks while the VM runs. It uses VMware Changed Block Tracking (CBT) to copy only the changed blocks in each later sync. At cutover, the tool stops the source VM, copies the last delta and starts the target VM. Downtime falls to the final delta plus the boot.

Warm migration has its own limits. Red Hat MTV needs CBT on each VM and each disk, allows up to 28 CBT snapshots, and syncs every 60 minutes by default. Windows guests also need the VSS service available. A VM with a very high change rate can produce deltas that never get small enough for a short cutover.

In my experience, the throughput number is the one that teams guess wrong. Measure it in the pilot over the real network path, with the real source datastore. Then use that number for every wave plan.

‍

VMware Migration Tools Compared: Copy Method, Warm Sync and VDDK Dependency

Select the VMware migration tool for each target platform on three questions. How does it read the ESXi disks? Can it sync while the VM runs? Does it need a VDDK copy that you can no longer download?

Three tools read ESXi disks without VDDK today. The Proxmox importer reads the ESXi API through its own user-space file system. Xen Orchestra uses its own reader for the VMware NFC protocol. Nutanix Move 6.3.3 adds DirectPath, which needs no VDDK. DirectPath works only on new Move deployments, with the appliance on the source vSphere environment.

Three tools depend on VDDK. Azure Migrate for Azure Local needs VDDK 8.0.x on the source appliance. Red Hat states that MTV without VDDK can run at much lower speeds, and VDDK is mandatory for vSAN-backed VMs. Standard Nutanix Move also asks you to upload the VDDK file.

If your tool needs VDDK, do these steps before wave one:

1. Find out if your team already has a VDDK copy from an earlier project.
2. Ask the tool vendor how it gets VDDK through the Broadcom partner program.
3. For MTV, open a case with Broadcom support, as the Red Hat KB tells you. If your array supports storage copy offload (XCOPY), Red Hat lists it as a workaround.
4. Test the full copy path in the pilot, with the same appliance build that you will use in production.

‍

How to Migrate VMware to Proxmox: Import Wizard, Live-Import and First Boot

A VMware to Proxmox migration uses the ESXi import wizard that shipped in Proxmox VE 8.2. The wizard adds an ESXi host as a storage source. It then reads each VM's configuration and disks over the ESXi API, with no VDDK.

Connect the wizard to each ESXi host directly. The Proxmox wiki states that an import through vCenter works, but performance drops sharply. Run imports one after another, with no more than four disks at the same time. The ESXi API limits its connections, and too many parallel reads can stall the import.

The wizard has no CBT delta sync, so each import is a cold copy. The live-import option shortens the outage. It starts the VM on Proxmox after the source VM is off, and it copies the remaining data in the background. Use live-import only on a fast, stable network, and test it on a non-critical VM first. If the import fails, the VM loses all writes made since the import started.

After cutover, Proxmox gives you live migration and high availability (HA). Live migration also moves local disks over the network. HA needs shared storage, at least three nodes for quorum and a fencing watchdog. Set one CPU model that all nodes support, so a VM can live-migrate between hosts of different CPU generations.

‍

How to Convert VMware to Hyper-V and Azure Local: Three Microsoft Paths

A VMware to Hyper-V migration has three Microsoft-supported tools today. The target platform selects most of the choice for you. Microsoft Virtual Machine Converter, the older tool, has reached end of support.

Azure Migrate is the path to Azure Local. Microsoft made VMware to Azure Local migration generally available in October 2025. A source appliance runs on the VMware side, and a target appliance runs on Azure Local. VM data moves between them on premises. Only metadata and replication state go to Azure.

Azure Migrate writes a seed disk, then runs hourly delta replications. At cutover, you run a planned failover with an optional shutdown of the source VM. Shut the source down; that gives you a consistent final sync. The source VM must run with VMware Tools during replication, and the source appliance needs VDDK 8.0.x.

SCVMM 2025 is the path to standalone Hyper-V hosts and clusters. It converts offline only. The VM must be stopped, with no snapshots and with VMware Tools uninstalled. It supports ESXi and vCenter 7.0 and 8.0, and it does not convert vSAN disks or IDE-bus disks.

The Windows Admin Center VM Conversion extension adds warm migration to Hyper-V. It makes an online first copy, syncs CBT deltas and copies a final delta at cutover. It is still a preview, so use it for test and non-critical waves until Microsoft releases it.

Current Windows and Linux releases include the Hyper-V storage and network drivers, so boot failures are rarer than on KVM. Microsoft's Azure Local FAQ says static IP retention covers Windows only, so set Linux IPs by hand after cutover.

‍

VMware to Nutanix Migration: Nutanix Move, DirectPath and In-Place Cluster Conversion

A VMware to Nutanix migration has three technical paths. The source hardware and the storage layout select the path. The decision flow below shows the order of the questions.

Nutanix Move: warm migration with CBT

Nutanix Move copies a full seed of each VM while it runs. It then copies CBT deltas on a schedule and waits for you to start the cutover. The Move user guide requires CBT support on each source VM, which means VM hardware version 7 or later.

In Automatic mode, Move prepares the guest for you. It needs guest credentials. Windows needs an account with the Log on as a batch job right. Linux needs root or sudo access and curl. Move then uninstalls VMware Tools, installs the Nutanix VirtIO drivers and runs an IP retention script. In Manual mode, Move shows the scripts, and you run them yourself.

Check IP retention in the pilot. A Windows guest keeps its IP only if its NICs are connected at migration time. A VM with more than one NIC can lose some of its addresses.

Move DirectPath and zero-copy migration

Standard Move needs a VDDK file that you upload to the appliance. On October 13, 2026, Nutanix released Move 6.3.3 with DirectPath, which copies ESXi disk data with no VDDK. DirectPath needs a new Move deployment on the source vSphere environment. You cannot upgrade an older Move appliance to it.

Move 6.3, released July 29, 2026, added zero-copy migration from ESXi to AHV on supported external storage. AHV now runs with Dell PowerFlex, Pure Storage FlashArray and, since NCI 7.6, Dell PowerStore. Nutanix announced NetApp ONTAP over NFS on October 8, 2026, but it is not available yet.

In-place cluster conversion for ESXi on Nutanix

If your VMware cluster already runs on Nutanix AOS, you can convert it in place. In Prism Element, open Settings and select Convert Cluster. Prism checks the cluster with your vCenter credentials. It then reimages the nodes to AHV one at a time and keeps VM state and MAC addresses.

The decision flow below lists the prerequisites from community and Nutanix staff posts. Confirm them in the current Nutanix conversion guide for your AOS version.

‍

Other VMware Migration Paths: OpenShift Virtualization, HPE VM Essentials, VergeOS and XCP-ng

The same seven layers change on these platforms.

VMware to OpenShift migration with MTV

Red Hat's Migration Toolkit for Virtualization (MTV) is at version 2.12. It runs cold or warm migrations from vSphere into OpenShift Virtualization. MTV uses virt-v2v for the conversion, and virt-v2v adds the VirtIO drivers to Windows guests from virtio-win.

Before the first plan, map each source datastore to a storage class and each port group to an OpenShift network.

HPE VM Essentials

HPE VM Essentials runs HPE's KVM-based HVM hypervisor and can manage ESXi and HVM clusters from one console. Its built-in migration tool tries to install VirtIO drivers over WinRM before the transfer. Users on the HPE community report failures, so install the virtio-win guest tools yourself first. The tool does not carry static IPs over. Set them again after cutover.

VergeOS ioMigrate

VergeOS ioMigrate connects to vCenter on port 443 and uses the VMware backup APIs with CBT. It turns on CBT for each VM, copies a first backup while the VM runs, then copies incrementals. At cutover, it powers off the VM, copies a final increment and imports it with the same MAC addresses.

XCP-ng with Xen Orchestra

Xen Orchestra imports VMs from ESXi 7.x and 8.x through its own reader for the VMware NFC protocol, with no VMware library. It copies a snapshot of the running VM. If you select Stop source, it powers off the VM and copies only the last changed blocks. Raw device mappings, independent disks and encrypted disks cannot be imported. XCP-ng 8.3 LTS is the current release.

‍

What Breaks Around the Hypervisor: Backup, DR, NSX and Automation

Layer 7 is outside the guest, so the migration tool does not move it. Treat each item as its own workstream with its own owner.

• Backup. Agentless backup jobs read ESXi through VMware APIs and CBT. At cutover, those jobs stop, and the first backup on the target is a full. Confirm that your backup product supports the target hypervisor before wave one. Our guide to what happens to your backup strategy when you leave VMware covers the failure modes.
• Disaster recovery. VMware Site Recovery Manager and vSphere Replication work only on vSphere. Rebuild each runbook on the target platform, and run a test failover before you decommission SRM.
• Network security. NSX distributed firewall rules have no automatic converter. Export the rules, remove the stale ones, and rebuild them in the target firewall or SDN layer.
• Automation and monitoring. PowerCLI scripts, vCenter alarms and vROps dashboards stop at cutover. Rewrite automation for the target API, and connect monitoring before the first production wave.
• Application support. Get written support statements from application and appliance vendors for the target hypervisor. A missing statement keeps that VM on VMware until you have one.

‍

A Phased VMware Migration Plan: Inventory, Pilot, Waves and Rollback

A VMware migration plan has four phases. Each wave of VMs goes through phases 3 and 4, after the pilot results are in.

1. Inventory (weeks 1 to 4). Export the estate with RVTools, map dependencies and group VMs into waves by application. Confirm VDDK access and backup support for the target.
2. Pilot (weeks 4 to 12). Migrate 10 to 20 low-risk VMs that cover each OS and firmware type. Measure throughput and delta sizes.
3. Production waves. Move tier-3 VMs first, then tier-2, then tier-1. Prepare every guest before its cutover window.
4. Close each wave. After a parallel run of 2 to 4 weeks and owner sign-off, delete the source VMs and retire whole ESXi hosts.

The checklist below holds the full list of tasks for each phase.

Rollback: keep the source VM until sign-off

Your rollback point is the powered-off source VM. If the target VM fails, shut it down and power on the source VM. Do this only before users write new data to the target. After that point, a rollback loses those writes, so the application owner must decide.

Emergency path: a failed host with no parts support

A failed out-of-warranty host becomes wave zero. Restore its VMs from backup directly onto new hardware with the target hypervisor. Veeam 13.1 restores VMware backups to Proxmox VE, Nutanix AHV, HPE VM Essentials, OpenShift and Hyper-V. Then run the guest repair steps from your pilot.