Why migrations go wrong
Cloud migrations rarely fail on the technology. They fail because something was not known at the start: an undocumented dependency on a file share, a batch job that only runs on the last day of the month, a licence tied to a MAC address, or a database whose real size is four times what the CMDB says.
The fix is unglamorous. Spend longer on discovery than feels comfortable, group work into waves small enough to reverse, and rehearse every production cutover at least once against real data volumes. The checklist below follows that order.
Phase 1 — Discovery and dependency mapping
You cannot move what you cannot see. Before any target architecture is drawn, build an inventory that a stranger could act on. Automated discovery (AWS Application Discovery Service, Azure Migrate, or agent-based tooling) gets you 80% of the way; the last 20% comes from talking to the people who operate the systems.
- Every server: OS version, patch level, CPU/RAM actually used over 30 days — not what was provisioned.
- Every database: engine and version, real data size, growth rate, replication topology, and who reads from it.
- Network dependencies captured from live traffic, not from documentation — this is where surprises live.
- Scheduled jobs, batch windows and month-end/year-end processes that only appear on the calendar.
- Licensing: what is tied to hardware, what is transferable, and what gets cheaper or dearer in cloud.
- Data classification: what is regulated, what has residency requirements, what can never leave the country.
- Owners: a named person per application who can approve downtime and sign off on validation.
Phase 2 — Pick a strategy per workload (the 6 Rs)
Treating the estate as one project is the most expensive mistake available. Each workload gets its own decision, and most estates end up using four or five of these:
- Rehost (lift and shift) — move as-is. Fastest, lowest risk, no application change. Right for stable systems nearing a hardware refresh.
- Replatform — move with a targeted change, typically a managed database or a container runtime. Modest effort, real operational payback.
- Repurchase — retire the system and adopt SaaS. Often the cheapest answer for commodity functions such as email, CRM or ticketing.
- Refactor — rewrite for cloud-native services. Highest cost and risk; justify it with a business reason, not an architectural preference.
- Retire — roughly 10–20% of a typical estate is running for nobody. Turn it off and bank the saving.
- Retain — regulated, contractual or end-of-life-imminent systems stay put. A deliberate "not yet" is a valid outcome.
Phase 3 — Build the landing zone before you move anything
The target environment should exist, be tested and be reproducible before the first workload arrives. Building it by hand in the console guarantees the environment you cannot rebuild in a crisis.
- Account/subscription structure, with production separated from everything else.
- Network: address ranges that do not collide with on-premise, connectivity (VPN or Direct Connect/ExpressRoute), DNS resolution both ways.
- Identity and access, integrated with your existing directory — not a pile of local admin users.
- Everything as Terraform (or Bicep/CloudFormation), in version control, reviewed like application code.
- Tagging standard agreed on day one: owner, environment, cost centre, application. Retro-fitting tags is miserable.
- Logging, monitoring and backup configured before workloads land, not after the first incident.
Phase 4 — Group the work into waves
A wave is a set of workloads that must move together because they talk to each other. Get this wrong and you leave a chatty application talking to its database across a WAN link, which shows up as inexplicable latency the morning after go-live.
Sequence waves from low-risk to high-risk so the team builds muscle memory on systems that will not end up in a board report. Keep each wave small enough that a rollback is a decision, not a crisis — for most teams that means 5 to 15 servers.
Phase 5 — The cutover checklist
Every production cutover should be rehearsed end to end at least once against production-sized data. The rehearsal is where you find that the replication takes 14 hours rather than 4. Before the real cutover, confirm all of the following:
- A written runbook with named owners, timings and a hard go/no-go decision point.
- A rollback path that has actually been tested — not a paragraph asserting one exists.
- Replication caught up and lag measured, with a documented maximum acceptable lag.
- DNS TTLs lowered 24–48 hours in advance so traffic can be redirected quickly.
- A communications plan: who tells users, who tells customers, who declares success.
- A freeze on changes to the source system during the migration window.
- Monitoring and alerting live on the target before traffic arrives.
Phase 6 — Prove the data survived
"It looks fine" is not sign-off. Data validation should be objective, automated and produced as a report someone puts their name against.
- Row counts per table, source versus target, with any variance explained.
- Checksums or hash totals on financially significant columns.
- Referential integrity checks and constraint validation on the target.
- A functional test pass covering the business processes that matter most, run by the people who use them.
- Performance compared against a pre-migration baseline — regressions are far cheaper to fix in the first week.
- A parallel run for reporting and finance systems, comparing outputs side by side for at least one full cycle.
Phase 7 — The first 90 days after cutover
The migration is not finished when traffic moves. Cloud bills climb quietly when workloads are sized from legacy hardware specs and nobody revisits them.
- Right-size against 30 days of real cloud utilisation data — almost everything is over-provisioned at first.
- Apply reserved instances or savings plans only once usage has settled, never on day one.
- Set budgets and anomaly alerts so a runaway workload is caught in days, not at month end.
- Decommission the source systems on a planned date, after sign-off, and cancel the associated contracts.
- Hand over runbooks and documentation, and confirm the on-call team can actually operate the new environment.
Five mistakes worth avoiding
- Lifting and shifting everything because it is fast, then discovering the run cost is higher than the data centre it replaced.
- Skipping the rehearsal because the schedule is tight — the rehearsal is what protects the schedule.
- Migrating a database without checking whether the application supports the target engine version.
- Leaving the legacy environment running "just in case" for a year, paying for both.
- Treating the migration as an infrastructure project with no application owners involved.
Frequently asked questions
Discovery is typically 2–4 weeks. Delivery depends entirely on estate size and strategy: a contained set of workloads can be done in 4–8 weeks, while a full data centre exit usually runs 6–18 months across multiple waves.
For most workloads, yes — using replication and a short DNS or connection-string switch, the outage is measured in minutes. Genuinely zero-downtime cutovers are possible where the application supports dual-write or read-replica promotion, but they cost more to engineer, so it is worth confirming which systems actually need it.
No, it is a legitimate strategy — it is only a problem when applied to the whole estate by default. Lift and shift is right when you need to exit hardware quickly; plan the optimisation work as a follow-on phase rather than pretending it is unnecessary.
Not automatically. Migrations that simply replicate on-premise sizing usually cost more. Savings come from right-sizing against real utilisation, turning off non-production outside business hours, using commitments once usage is stable, and retiring systems nobody uses.
Less than most comparisons suggest. For a standard estate all three are capable; the decision usually comes down to existing licensing and agreements, the skills your team already has, and any specific managed services you depend on. Choose deliberately, then commit — running a split estate for no reason doubles the operational surface.
Set a decommission date at the start of the project and hold to it after validation sign-off. Systems left running "just in case" quietly double the cost of the migration, and they drift out of patching once attention moves on.
Only where the business case supports it. Managed databases, autoscaling and containerisation deliver most of the operational benefit without a rewrite. Refactoring is justified when a specific constraint — release speed, scale, or a cost model — is genuinely blocking the business.
How we can help
How we plan and deliver migrations, wave by wave, with a rollback path at every step.
Solution Design & ArchitectureTarget-state architecture and costed options before the build starts.