CONSULT CIRCLE | CLOUD MIGRATION
The ten steps that separate migrations that land on time from the ones still running eighteen months later.
Cloud migrations rarely fail on technology. They fail because a dependency was found late, a cost was not modelled, or a workload moved successfully and then sat unaccepted for six weeks because nobody had arranged for anyone to test it.
This checklist is ordered deliberately. Each step reduces the risk of the ones that follow, and several of them have lead times that will consume your schedule if started late.
What this guide covers
- The ten steps, in the order that reduces risk
- Typical durations and when to start each activity
- The ten mistakes this checklist prevents
The ten steps
1. Build an accurate inventory
Not the CMDB - the actual estate. Servers, applications, databases, integrations, certificates and the appliances nobody remembers. Reconcile discovery output against the asset register and investigate every discrepancy, because the discrepancies are where the surprises live.
2. Map dependencies with real traffic data
Flow-based dependency mapping, run long enough to capture monthly and quarterly cycles. A fortnight of data will miss the month-end batch that couples two systems you were about to separate. Follow it with interviews, because flow data shows what talks to what but not which conversations matter.
3. Decide disposition per application
Retire, retain, rehost, replatform, repurchase or refactor. Retiring unused applications is the cheapest win in any migration and every estate has more candidates than expected. The decision sequence is set out in How to Choose the Right Cloud Migration Strategy for Your Legacy Applications, and where the answer is "stay put", in Hybrid Cloud Architecture Decisions.
4. Model the cost properly
Right-sized consumption, not provisioned capacity. Include reservations for steady-state workloads, egress, backup, tooling, licensing on the new platform, and parallel running for the duration of the programme.
5. Build and prove the landing zone
Networking, identity, security baseline, tagging, backup, monitoring and logging - validated with a real workload end to end before wave one. A landing zone that has not been proven with a real workload is an assumption.
6. Sort connectivity early
Circuits, peering and firewall rules have procurement and change-control lead times you do not control. This is routinely the longest pole in the programme and is routinely started too late.
7. Plan waves around testing capacity
Group applications into move groups with a single accountable owner, and size each wave to what your application teams can validate in parallel. Migration throughput is almost never the constraint; testing capacity is.
8. Run a pilot with real users
Low criticality but genuine users, so you rehearse the acceptance process and not just the mechanics. Pure test workloads validate the tooling and teach you nothing about how the organisation handles a migration. Choosing that first workload well is covered in 3 Quick Signs Your Business Is Ready to Move Non-Critical Workloads to the Cloud.
9. Migrate, validate and accept per wave
Each wave closes with a named person signing acceptance. Without that, waves complete technically and accumulate as unfinished work that looks like progress on a plan. Databases need their own validation pass - see Migrating Legacy Databases to Cloud.
10. Right-size and decommission
The step that determines whether the business case survives contact with reality. Right-size against observed usage after workloads have settled, and decommission the source properly - including circuits, licences and backup media.
Timeline and lead times
| Activity | Typical duration | Start it |
|---|---|---|
| Discovery and dependency mapping | 4-8 weeks | Immediately. Flow data needs time to be representative |
| Connectivity procurement | 6-12 weeks or more | Week one. You do not control this timeline |
| Landing zone build | 4-8 weeks | In parallel with discovery |
| Wave planning | 2-4 weeks | Once disposition decisions are made |
| Pilot wave | 2-4 weeks | As soon as the landing zone is proven |
| Production waves | Bulk of the programme | Paced by testing capacity, not tooling |
| Right-sizing and decommission | 4-8 weeks | Begins during migration, not after |
Table 1 - Indicative durations and when to start each activity.
Ten mistakes this checklist prevents
- Trusting the CMDB instead of discovering the estate.
- Mapping dependencies over too short a period to catch monthly cycles.
- Migrating applications that should have been retired.
- Modelling cost on provisioned capacity at on-demand rates.
- Building a landing zone that has never carried a real workload.
- Starting connectivity procurement after the plan is written.
- Sizing waves to bandwidth rather than to testing capacity.
- Piloting with test workloads and no real users.
- Never formally accepting waves, so unfinished work accumulates invisibly.
- Declaring success at cutover and never right-sizing or decommissioning.
Where to go next
- Choosing a cloud migration strategy per application
- Cloud cost optimization playbook
- Migrating legacy databases to cloud
- How to migrate to VCF using HCX, step by step, and our VCF Migration Services
- VCF migration estimator for an indicative wave plan and effort model
Frequently Asked Questions
How long does a cloud migration take?
For 500 to 1,500 workloads, typically three to nine months end to end. Discovery and landing zone build take six to ten weeks, after which pace is usually set by how many application teams can test in parallel.
What is the first step in a cloud migration?
An accurate inventory and dependency map. Every subsequent decision depends on knowing what you have and what talks to what, and this is the phase most often compressed when programmes start late.
How do we reduce cloud migration costs?
Retire what nobody uses, right-size against real utilisation rather than provisioned capacity, use reservations for steady-state workloads, and decommission the source promptly to limit parallel running.
What is a cloud landing zone?
The foundational target environment: networking, identity, security baseline, tagging, backup, monitoring and logging. It should be built and proven with a real workload before the first migration wave.
Should we migrate everything at once?
No. Wave-based migration with per-wave acceptance limits blast radius and lets you improve the process between waves. Big-bang migrations remove your ability to learn cheaply.
Talk to Consult Circle
We run cloud migrations end to end, from discovery and landing zone through wave execution to decommission certification. Book a free 30-minute call - 0203 916 5593 - info@consultcircle.com