The Cloud Migration Checklist We Actually Use

Cloud migrations do not usually fail because a workload would not run in the cloud. They fail because a step that felt like overhead was skipped, and the consequence arrived four months later dressed as something else — an unexplained bill, an audit finding, a cutover that could not be reversed.

This is the checklist we work from. The items are ordered, and the ordering matters more than any individual item.

Phase 1 — Assessment

Inventory every workload, including the ones nobody owns. Not just servers: applications, scheduled jobs, integrations, file shares, certificates and the Access database in finance that turns out to be load-bearing. The last category is the one that causes cutover surprises, and it is only found by asking people rather than by scanning.

Map dependencies in both directions. For each workload, what does it call and what calls it? Network flow logs are far more reliable than documentation here. Dependency direction determines migration order, and getting it wrong is the most common cause of a wave that has to be rolled back.

Establish real current cost. Hardware amortisation, data centre, licences, support contracts, and — the one always omitted — the staff time spent operating it. A migration business case that compares cloud spend to hardware spend alone will look bad and will be wrong.

Assign a disposition per workload. The six Rs: rehost, replatform, refactor, repurchase, retire, retain. Be aggressive about retire. On a typical estate, 15–25% of workloads have no meaningful users, and removing them before migration is the cheapest optimisation available.

Model the target cost with assumptions written down. Not a number — a model, with the assumptions visible and stress-tested. Egress is the line item most often forgotten and most likely to surprise.

Phase 2 — Landing zone

This is the step teams under time pressure skip, and it is the most expensive one to retrofit.

Account or subscription structure. Separation by environment and by blast radius, with an organisational policy applied centrally. Deciding this after two hundred resources exist is a migration in itself.

Network topology. VPC or VNet design, address space that will not collide with future acquisitions, connectivity back to on-premises, and egress control. Address space in particular is nearly impossible to change later.

Identity and access. Federation with your existing identity provider, role design based on real job functions, no long-lived access keys anywhere, and break-glass procedures that are documented and tested.

Guardrails as code. Policy that prevents public storage buckets, unencrypted volumes, untagged resources and oversized instances — enforced at the pipeline, not detected by a monthly report.

Logging and evidence from day one. Centralised, immutable audit logging with retention set to your compliance requirement. Turning this on after the fact means you have no record of the period you most want a record of.

Cost allocation tags, enforced. A tagging standard that is mandatory at creation. Retrospective tagging is a project nobody ever completes, and without it FinOps is guesswork.

Phase 3 — Pilot wave

Pick one workload that is genuinely low-risk but structurally representative. Not the simplest static site — something with a database, an integration and a real user base.

The pilot is not about proving the cloud works. It is about proving your process works: the tooling, the runbook, the cutover choreography, the rollback, the validation criteria, and the accuracy of your cost model. Expect it to take longer than it should. That is the point of doing it first.

Phase 4 — Migration waves

Order by dependency, then by risk. Move things that are depended upon before things that depend on them, unless you are willing to run a hybrid connection for the interim — which is fine, but should be a decision rather than an accident.

Write the runbook before the rehearsal, and rehearse before the event. Every cutover gets a written sequence with owners and timings, rehearsed at least once against a copy. The rehearsal always finds something.

Define validation criteria in advance. "It looks fine" is not a criterion. Specific checks, run by named people, with a documented pass or fail. Agree in advance what result triggers a rollback, because that decision is much harder to make well at 2am.

Prove rollback, do not assume it. A rollback plan that has never been executed is a hypothesis. For database migrations in particular, know exactly how you get back, and how much data you lose if you do.

Plan data migration as its own workstream. It is the critical path on nearly every migration. Continuous replication, consistency verification, and a short cutover window rather than a long copy.

Phase 5 — Post-migration

Right-size against observed utilisation, not against the old hardware. Servers were provisioned for peak plus a safety margin plus three years of growth. Cloud instances should be provisioned for actual observed load, with autoscaling for the rest. This alone is typically 20–30%.

Buy commitments once you have data. Savings plans and reserved instances are large discounts, but they are commitments. Wait until you have two to three months of steady-state usage, then buy against measured baseline.

Turn off non-production outside working hours. Development and staging environments running 24/7 are pure waste. Scheduled shutdown is a few hours of work and often 10–15% of total spend.

Apply storage lifecycle policies. Data ages. Move it to cheaper tiers automatically and set expiry where retention policy allows. Storage is the line item that grows quietly forever.

Give each team its own cost visibility. Cost that appears only in a central finance report changes nobody's behaviour. Cost attributed to the team that generates it changes it within a month.

The six steps most often skipped

If you take one thing from this, take this list — each of these is skipped regularly, and each has a predictable consequence.

1. Landing zone before workloads. Consequence: a governance retrofit across a populated estate, typically costing several times what doing it first would have.
2. Retiring dead workloads. Consequence: you pay to migrate, then to run, systems nobody uses.
3. Rehearsing the cutover. Consequence: the first discovery of a missing step happens during the real event.
4. Testing the rollback. Consequence: at the moment you need it, you find out it does not work.
5. Tagging enforcement from day one. Consequence: cost allocation is impossible, so optimisation is guesswork.
6. Post-migration optimisation. Consequence: the bill stays at lift-and-shift levels and the business case never materialises.

What good looks like

A migration that went well is boring in retrospect. Cutovers happened in scheduled windows and finished early. Nobody was surprised by the bill. The audit found the evidence it was looking for. And the internal team — who were embedded throughout — can now provision an environment in forty minutes instead of eleven days, which changes how they work far more than the change of hosting location did.

---

We run cloud migrations end to end, and we also review other people's migration plans when a second opinion is useful. Get in touch — or read how we migrated a regional bank's 43 workloads with no unplanned outages.