How it ran
Planphase 1 · before anything moved
With the network, server and application teams: inventory every VM, map dependencies, build the Hyper-V cluster and sort servers into waves.
Testphase 2 · wave 0, in the lab
Clones of every OS and route went through the checks below, including a timed rollback, before the go/no-go for production.
Executephase 3 · waves 1 to 5
213 servers in all: non-production first, then over 200 production servers, lowest risk first. Zero production downtime, finished in May 2026, ahead of the November 14 deadline.
The plan for 213 servers
This is roughly how the move was planned, tested and run live. The total of 213 is exact. The batch sizes, timings and thresholds are approximate.
Converting a VM means stopping it for a final sync, so avoiding production downtime is decided server by server. Services with a redundant partner move one node at a time, and a server with no partner moves in a window agreed with its owner.
Plan: know what’s moving
Inventory
Export every VM from vCenter with its OS, firmware type, CPU, memory, disks, networks and snapshots. Reconcile it with the CMDB, so every server has a named owner and a criticality rating.
Dependencies
Combine application owner interviews with network flow data to find which servers must move together. Those groups set the order of the waves.
Landing zone
Build a Hyper-V failover cluster that can lose a host, map every VMware port group to a VLAN on the virtual switches, and connect backup, monitoring, patching and endpoint protection before any server arrives.
Conversion tool
Options include Virtual Machine Manager’s conversion wizard, Windows Admin Center’s VM Conversion extension and restoring from a backup product. Each has limits, such as VMM needing the source powered off and not converting VMs on vSAN, so the tool is proven in the lab first.
Every server then gets one of five routes:
| Server | Route | Effect on production |
|---|---|---|
| Load-balanced or clustered node | Drain it, convert it, test it and return it, one node at a time. | No outage. The other nodes carry the traffic. |
| Database with a replica | Move the replica, fail over to it, then move the former primary. | A brief, planned failover. |
| Domain controller | Promote new controllers on Hyper-V and demote the old ones, instead of converting them. | No outage. |
| Single server | Sync while it runs, then stop it for a final sync in an agreed window. | A short, planned outage. |
| Appliance or unsupported OS | Use the vendor’s Hyper-V image, rebuild it or retire it. | Decided case by case. |
The routes and dependency groups become waves, lowest risk first, moved in batches small enough to roll back in one window:
| Wave | Scope | Size | To move on |
|---|---|---|---|
| 0 · Lab | Clones covering every OS and every route | ~10 clones | All tests pass and rollback is timed |
| 1 · Non-production | Development and test servers | ~10 | No repeat failures, and the runbook is corrected |
| 2 · Low risk | Redundant services and internal tools | ~60 production | A quiet week after the last batch |
| 3 · Business apps | Applications, one dependency group at a time | ~95 production | Owners have signed off every group |
| 4 · Critical | Databases, identity and the most visible services | ~40 production | A quiet two weeks after the last batch |
| 5 · Exceptions | Appliances and anything held back | ~8 production | VMware is empty |
Test: prove it before production
Each OS and route goes through the same checks in the lab, and each check needs evidence before the go/no-go for production.
| Check | What passing looks like |
|---|---|
| Conversion | The VM boots on the right generation, BIOS to Generation 1 and UEFI to Generation 2, with every disk and its data intact. |
| Guest | VMware Tools is gone, Hyper-V integration services are running, Linux guests have Hyper-V drivers in their boot image, and Windows stays activated. |
| Network | Each new adapter keeps its static address, VLAN, gateway and DNS. Test on an isolated network first, so a copy can’t conflict with the live server. |
| Application | The owner runs a written smoke test against a copy and signs the result. |
| Performance | CPU, memory and disk latency hold up at peak against a baseline captured on VMware. |
| Resilience | VMs survive a live migration, a drained host and a host failed on purpose. |
| Operations | A backup restores cleanly, and monitoring, patching and endpoint protection all report in. |
| Rollback | The original comes back and passes its smoke test, within the change window, with the time recorded. |
Execute: the same runbook every time
| When | What happens |
|---|---|
| 14 days before | The change is approved, owners agree the window and smoke test, and users are told. |
| 7 days before | The first sync starts while the source runs. Snapshots are cleared and network settings are recorded. |
| 1 day before | A fresh backup is verified, and a named person is on point for rollback. |
| Drain | The server leaves its load balancer, or its application stops. |
| Cut over | VMware Tools comes off, the source shuts down, the final sync runs and the VM starts on Hyper-V. |
| Validate | Network, services and the smoke test are checked before any traffic returns. |
| Decide | Go or no-go, before users return. |
| 14 days after | The powered-off original is deleted, once backups are proven and the owner signs off. |
Rollback
The VMware original stays powered off and unchanged. Before users return, rolling back means stopping the Hyper-V copy, starting the original and rerunning the smoke test. After users return, new data lives only on the copy, so going back becomes a data decision with the owner. That’s why the go/no-go comes first.
Stop rules
A wave pauses on a major incident caused by the migration, a failed rollback, or the same smoke test failing on more than one server. The cause is fixed and added to the lab tests before the wave resumes.
Finish
After the last wave, backup and monitoring come off VMware, the hosts are decommissioned and the licenses end. The deadline was November 14, the contract renewal date, when VMware prices would have risen by over 180%. The project finished in May 2026, well ahead of it.
Who does what
| Team | Plan | Test | Execute |
|---|---|---|---|
| Network | VLAN and virtual switch mapping, firewall rules | Connectivity and failover paths | Load balancer drains, network checks |
| Server | Inventory, Hyper-V cluster, conversion tool | Conversion, performance, rollback | Runs each cutover |
| Application | Owners, dependencies, change windows | Writes and runs the smoke tests | Signs off, or calls a no-go |
Stack
- VMware
- Hyper-V