Retiring a Server Cupboard by Replicating It Into the Cloud First

The challenge

Eight production virtual machines ran on Hyper-V hosts in the building. The hardware had reached the point where continuing meant buying replacements, and a single site with a single set of hosts has no answer to the question of what happens if the building does.

Where we came in

Migrations fail at the cutover, not the copy. Using replication rather than a lift-and-shift meant each wave could be stood up in Azure and validated while the original was still running — so the decision to switch was made on evidence, and the way back was always open.

What we did

• Documented the inventory and mapped dependencies across all eight machines before proposing a target design
• Produced a migration assessment report, an architecture diagram and a risk register as written deliverables
• Right-sized each workload for its target rather than replicating existing over-provisioning
• Replicated machines into Azure and validated recovery points before any cutover
• Wrote a runbook per migration wave, and worked through a pre-migration checklist for each
• Ran test failovers so each wave was proven before it was relied on

Where it landed

• All eight production machines run in Azure, and the on-premises host hardware is no longer a dependency
• Each wave was validated by test failover before cutover, with a documented way back
• The environment now has disaster recovery capability it structurally could not have had on a single site