Most hypervisor exits start as migration programs. Inventory the VMs, pick a target, choose a migration or conversion tool, build waves, and move the workloads. That gets virtual machines from one platform to another. It does not prove the application can run, be protected, or be recovered after the source platform is gone. Please see Veeam Hyper-V Backup Failing with “Incorrect Function” During Checkpoint Creation, and Synology Surveillance365: Cloud-Based Camera Management Without an On-Premises Surveillance Server.
I would plan the exit the same way I plan recovery. Build a runbook around each application or recovery group. Define the source, target, recovery point, dependencies, startup order, network changes, guest changes, validation steps, owners, and rollback conditions. Then test that process while the source environment is still healthy enough to give you options.
Exit criterion: A workload has not really left a hypervisor until it can be recovered, validated, protected, and operated without that hypervisor.
Migration tooling solves movement, not acceptance
Migration products are good at moving data and creating a target VM. Some also handle replication, target sizing, network mapping, guest preparation, and cutover. Those capabilities matter, but the migration job finishing is still an infrastructure event. The application owner cares whether the service works after the move.
Microsoft makes that separation explicit in Azure Migrate. Its VMware migration workflow supports a test migration before final cutover, keeps the source VM running during the test, and recommends validating the application on an isolated target before performing the real migration.[1] Veeam exposes the same basic idea from the recovery side. Current Veeam Backup & Replication 13.1 documentation supports restoring VMware vSphere workloads to other targets, including Microsoft Hyper-V, Nutanix AHV, and Proxmox VE.[2][3][4]
Those products do not make every workload portable. They give the operator mechanisms that can be tested. Firmware, virtual hardware, guest drivers, network identity, application dependencies, licensing, performance, and vendor support still have to be proven for the workload being moved.
The runbook is where that proof belongs.
Also, see Strategic breakdown and step by step guide to upgrading to VBR 13.1, Veeam Oracle RMAN Troubleshooting: Connection Timeout, Broken Pipe and a Stuck RMANPluginManager, and SizeTrend: A Fast Windows Disk Space Analyzer for Storage Analysis.
Build recovery groups, not a spreadsheet of VMs
A VM inventory is useful, but it is the wrong unit for deciding whether an application can leave a platform. A three tier application with a database, middleware server, web nodes, load balancer, DNS records, service accounts, certificates, file shares, and an external API is not seven independent VM moves. It is one service with a dependency chain.
I would group workloads the same way I would group them for disaster recovery. Start with the business service, then identify every component required to bring that service back. The hypervisor objects are part of the list, but so are identity, DNS, time, routes, firewall policy, storage, load balancing, secrets, certificates, monitoring, backup, and application validation.
| Runbook item | What to record | What the test must prove |
| Recovery group | Application components and startup order | The service can start in the intended sequence |
| Recovery point | Backup, replica, or migration checkpoint to use | The selected point is accessible and usable |
| Target mapping | Cluster, host, storage, VM sizing, firmware, and networks | The target can create and run the workload |
| Dependencies | Identity, DNS, time, databases, middleware, shares, APIs | Required dependencies are available before the application needs them |
| Network cutover | VLAN or segment, IP, DNS, load balancer, firewall, routes | Clients and dependencies can reach the recovered service correctly |
| Guest conversion | Platform tools, drivers, agents, hardware specific settings | The guest is stable and supportable on the target |
| Acceptance | Application transaction, data check, login, job, API, or owner test | The business service works, not just the VM |
| Rollback | Trigger, last safe point, data handling, source state, owner | The team can return safely if acceptance fails |
| Operations handoff | Monitoring, backup, patching, CMDB, support ownership | The workload is protected and operated on the new platform |
The table is deliberately broader than VM conversion. If the runbook only records source host, destination host, and maintenance window, most of the hard questions are still waiting for cutover night.
The first real test should happen before cutover
The best time to discover that a guest will not boot on the target is while the production copy is still running. The same is true for a missing route, hard coded IP address, license tied to virtual hardware, old storage driver, firewall dependency, or application check nobody documented.
A test does not have to reproduce the final cutover perfectly. It needs to reproduce enough of the target state to expose the assumptions. Recover or migrate a representative copy to an isolated network, apply the expected guest conversion, bring up the required dependencies, and run the same acceptance tests that will be used during the real move.
Veeam Recovery Orchestrator uses a similar operating model for recovery. Restore plans have defined recovery locations and target RTO and RPO values, and Orchestrator provides readiness checks plus isolated DataLab testing for supported recovery locations.
The tooling is different from a hypervisor exit project, but the discipline is the same: check that the target is ready, execute the plan, verify the workload, capture the result, and fix the runbook before the event that matters.
Operational view: A successful test should create changes to the runbook. If nothing was learned, either the workload is unusually simple or the test did not exercise enough of the real cutover path.
Please see Veeam ONE 13.1.0.7034 Upgrade: Complete Pre-flight and Step-by-Step Guide, Upgrading Veeam Backup Enterprise Manager to v13.1 and Applying System Updates, and In-place upgrade of Veeam Recovery Orchestrator to version 13.1.
Track three clocks during an exit
Migration projects often collapse every timing question into one maintenance window. I prefer to track three different clocks because they fail for different reasons.
Data movement clock
This starts when initial replication, copy, or restore staging begins and ends when the target has enough data to support cutover. Large disks, change rate, repository throughput, WAN capacity, storage performance, and conversion overhead live here. Most migration tooling is very visible at this layer.
Service cutover clock
This starts when the production service is intentionally interrupted or traffic begins moving away from the source. It includes the final sync or recovery point, source shutdown, target startup, dependency sequencing, network changes, DNS or load balancer changes, and any guest conversion that cannot be completed earlier.
Acceptance clock
This starts when the target is technically available and ends when the application owner accepts the service. Authentication, data consistency, background jobs, integrations, scheduled tasks, certificates, monitoring, security agents, performance, and actual user transactions live here.
A fast data copy can still produce a long outage when network and application validation are slow. A VM that boots in five minutes can still spend two hours waiting on DNS, a firewall change, a broken integration, or an owner who does not have a defined acceptance test. Measure the clocks separately so the rehearsal tells you where the cutover is actually spending time.
Cutover should read like a recovery procedure
Once the test path works, the production cutover should be boring. The steps should already have owners, inputs, expected results, and stop conditions. The exact sequence will vary, but a practical runbook usually looks something like this:
- Confirm target compute, storage, network, credentials, and recovery tooling are ready.
- Confirm the last successful protection job and the recovery point that will be used if the migration path fails.
- Freeze application changes or place the service into the planned maintenance state.
- Complete the final replication, backup, export, or synchronization step.
- Shut down or isolate the source workload according to the cutover plan.
- Create or recover the target workload and apply the documented target mappings.
- Start dependencies and application components in the tested order.
- Apply DNS, routing, firewall, load balancer, and external integration changes.
- Complete guest cleanup and install the target platform integration components required for normal operations.
- Run infrastructure checks, then run the application acceptance test.
- Enable monitoring, backup, patching, security tooling, and operational ownership on the target.
- Hold the source state for the defined rollback period, then decommission it only after acceptance and recovery protection are confirmed.
The recovery point in step 2 matters even when the primary move uses a migration product. It gives the team an independent way to recover when the migration workflow fails after the source has already been changed, shut down, or partially decommissioned.
Veeam documents Instant Recovery to Hyper-V as a recovery mechanism that can also be used to migrate infrastructure between environments. Workloads run from backup with limited I/O performance until they are moved to production storage.[7] I would treat that kind of capability as a fallback path inside the exit runbook, not as a reason to skip a controlled migration when the normal path is healthy.
Guest conversion is part of the recovery test
Cross platform recovery proves quickly that a VM is more than its virtual disks. The guest may need a different virtual storage controller, network adapter, firmware mode, platform tools, drivers, or boot configuration. Appliances and workloads with passthrough devices, shared disks, virtual TPM requirements, hardware bound licensing, or vendor support restrictions may need a different path entirely.
The point is not to build one giant universal conversion checklist. Record what each recovery group actually needs and prove it. If a Windows server needs old platform tools removed after the target boots, script it and put the script in the runbook. If a vendor appliance is only supported on a specific platform, treat that as a workload constraint instead of discovering it after the project has already committed to the destination.
Architecture point: Portability is a tested property of a workload. It is not a property you can assign to the whole VM estate because the backup product has a cross platform restore button.
Rollback becomes a data problem as soon as the target starts taking writes
Rollback is often written as “power the old VM back on.” That is only safe if the source is still authoritative and nothing important changed on the target. Once users, jobs, or integrations write new data to the destination, a return to the source can lose or split data.
The runbook needs a rollback boundary. Define the point after which rollback requires data reconciliation, database recovery, reverse replication, transaction replay, or an application specific recovery step. Decide who can call the rollback, how long the source is preserved, and what evidence is required before the target becomes authoritative.
This is one of the reasons I prefer a recovery mindset for exit work. Recovery teams already think in terms of known points, data authority, dependency order, validation, and controlled return to service. Those are exactly the questions that appear when a migration fails halfway through a cutover.
A migration wave should end with recovery ownership on the new platform
Moving the VM is only the middle of the wave. The application should leave the old platform with its operational dependencies moved too. Backup jobs must protect the target. Monitoring must know the new object. Security agents and vulnerability tooling need to report. Patch and configuration management must still work. The CMDB and support team need the new location and owner.
I would also run a recovery test from the new platform before declaring a critical workload complete. The project has already proved movement from source to target. The second test proves the organization can protect the workload on the destination and recover it again without using the platform it just left.
That test catches a different class of problems. A backup integration may not be configured for the target cluster. Recovery networks may still reference old port groups. An operations script may call the old management API. A monitoring check may use the retired hostname of a management server. None of those problems stop the migration job, but they can make the new environment unrecoverable the day after the old one is removed.
Know when the old platform is actually out of the path
A hypervisor exit is complete when the source platform is no longer required for normal service or for recovery. That is a higher bar than “all VMs moved.”
Before the last host is decommissioned, I would want evidence that critical recovery groups can start on the new platform, application owners have accepted them, backups are succeeding, restores have been tested, monitoring and security are active, and the recovery documentation points only to infrastructure that will still exist after the project closes.
Keep the source platform as long as it is serving a deliberate rollback purpose. Do not keep it indefinitely because nobody knows whether an old script, recovery workflow, or operational dependency still needs it. The runbook should tell you exactly when that dependency ends.
Key Takeaways
- Plan hypervisor exits around application recovery groups, not individual VM moves.
- Use migration tooling for movement, but require isolated testing and application acceptance before production cutover.
- Track data movement, service cutover, and application acceptance as separate clocks.
- Give every wave a tested recovery point and an executable rollback rule before the source is shut down.
- A workload is not finished until backup, recovery, monitoring, security, and operational ownership work on the destination without the old hypervisor.
Source Notes
Product behavior changes. These sources were checked against public vendor documentation available on September 13, 2026.
1. Microsoft Learn: Migrate VMware vSphere VMs with the Migration and modernization tool.
https://learn.microsoft.com/en-us/azure/migrate/tutorial-migrate-vmware-agent?view=migrate
2. Veeam Backup & Replication User Guide: Data Recovery for VMware vSphere.
https://helpcenter.veeam.com/docs/vbr/userguide/data_recovery.html
3. Veeam Backup & Replication User Guide: Nutanix AHV.
https://helpcenter.veeam.com/docs/vbr/userguide/nutanix_ahv.html
4. Veeam Backup & Replication User Guide: Proxmox Virtual Environment.
https://helpcenter.veeam.com/docs/vbr/userguide/proxmox_ve.html
5. Veeam Recovery Orchestrator User Guide: Restore Plans.
https://helpcenter.veeam.com/docs/vro/userguide/restore_plans_overview.html
6. Veeam Recovery Orchestrator User Guide: Running Plan Readiness Check.
https://helpcenter.veeam.com/docs/vro/userguide/running_readiness_check.html?ver=13
7. Veeam Backup & Replication User Guide: Instant Recovery to Microsoft Hyper-V.
https://helpcenter.veeam.com/docs/vbr/userguide/instant_recovery_to_hv.html
I hope you found the following article on “Your Hypervisor Exit Plan Should Be a Recovery Runbook” very useful. Please feel free to leave a comment below.
