How to Migrate Off VMware ESXi with Veeam Instant VM Recovery

Leaving VMware ESXi usually stalls on one question: how do you move production VMs to a new platform without a long outage and without betting the business on a one-way conversion? Veeam Instant VM Recovery answers it in an unusual way. It uses your backups as the migration path. This guide explains how it works, which platforms it can land VMs on, the steps we follow and what to check before cutover.

Why use a backup for migration

Most migration tools copy a live VM to the new platform. Instant Recovery works from something you should already have, a Veeam backup, and starts the VM on the new platform straight from that backup file. Veeam describes it as useful when you want to migrate infrastructure from one environment to another, or recover in minutes with limited performance. Three things follow from that:

• The source VM is not touched. The original on ESXi keeps running until you choose to retire it, so the fallback is built in.
• Downtime is a cutover window, not a copy window. You are not waiting for hundreds of gigabytes to transfer before the VM comes back.
• The backup is tested as a side effect. A migration that starts from your backups proves they restore, which is worth knowing regardless.

How Instant Recovery works

Veeam's documentation describes the mechanism for Hyper-V like this: Veeam reads the workload configuration from the backup file, creates a placeholder VM on the target host, and mounts the VM's disks from the backup repository. A driver on the target host redirects the VM's reads to the backup file. The VM is running within minutes, but its disks are still in the repository, so performance is limited until it is finalised.

Finalising means you test the recovered VM, then choose to migrate it to production. Veeam then transfers the VM's disk data to the production storage you selected on the new platform.

Which platforms it can land on

Veeam Backup & Replication 13 supports Instant Recovery between VMware vSphere, Microsoft Hyper-V, Nutanix AHV, Proxmox VE and Oracle Linux Virtualization Manager. For a move off ESXi that gives you these direct targets:

Nutanix AHV is a hyperconverged platform in its own right, so Instant Recovery can be a direct route into HCI.

Sangfor, H3C and xFusion HCI

The platforms in our platform comparison do not all work the same way here:

• Sangfor aSV: Veeam 13.1, released on 30 July 2026, added a plug-in for Sangfor aSV. Its documentation lists entire-VM restore from other hypervisors, and instant recovery from Sangfor backups out to vSphere, Hyper-V, AHV and Proxmox. Sangfor also has its own agentless tool, SCMT, that migrates through vCenter with a brief restart at cutover.
• H3C UIS and xFusion FusionOne: we did not find native Veeam hypervisor support for either. The usual path is the vendor's own conversion tool, or exporting disks from a Veeam backup as VMDK, VHD or VHDX, with the Veeam backup as the safety net. Confirm which disk formats and tools the vendor supports before you plan around it.

In each case the honest answer is that the method follows the target. Use Instant Recovery where the platform supports it, and the vendor's tool where it doesn't.

The migration steps we follow

1. Size and survey first. Inventory the VMs, their dependencies and their downtime tolerance. Pick the target platform and size it before any VM moves.
2. Back up everything to be migrated. Take fresh Veeam backups, and confirm the backup repository is fast enough, since VMs run from it until finalised.
3. Prepare the target. Build the new cluster, install any Veeam plug-in it needs, and map networks and storage.
4. Pilot on non-critical VMs. Instant Recover a few into an isolated network, and test boot, applications and access.
5. Cut over in waves. For each production VM, take a final backup, stop the original at an agreed time, and Instant Recover it on the new platform.
6. Finalise. After testing, migrate the VM's disks to production storage on the new platform.
7. Retire the source and protect the new platform. Keep the ESXi VM until you're satisfied, then decommission it, and confirm that Veeam backs up the VM in its new home.

What to check before cutover

• Repository performance. Recovered VMs read from the backup repository until finalised, so a slow repository means slow VMs during that window.
• Networks, IP addresses and integrations. Confirm each VM's network mapping and anything that depends on its address.
• Guest tools and drivers. VMs move between hypervisors, so tools and drivers for the old one need attention after the move.
• Licensing tied to the platform. Some applications and support contracts care which hypervisor they run on.
• Backup on the new platform. Confirm your Veeam coverage of the target before, not after, the first VM moves.

Sabah context

Many Sabah sites can't take a long outage on core systems, and few have a second site to test on. A backup-based migration lets you test the new platform with real VMs before committing, and keeps the ESXi originals as the rollback until you're ready. Hakobi is a registered Veeam partner and holds the relevant Veeam certification, and we run this method as part of our ESXi migrations, alongside our Backup & Disaster Recovery work. Pricing depends on the number of VMs, the target platform and the storage involved, so request a quote and we'll scope it after a site survey.

Sources: Instant Recovery to Microsoft Hyper-V, Instant Recovery to Nutanix AHV, Sangfor aSV support, Veeam Backup & Replication 13.1 what's new, VMware ESXi to Nutanix AHV migration, Veeam; VMware end of availability of perpetual licensing, VMware; Sangfor migration guide, Sangfor.