Cloud migration pre-flight checklist

Business alignment (5)

• The reason. The written reason for the migration is more specific than "we need to be in cloud". Cost reduction, capability, resilience, exit from a lease — one primary driver, agreed with the sponsor.
• The success criteria. Three measurable statements. Not slogans. E.g. "p95 order submission latency ≤ 400 ms", "monthly infra spend ≤ $X after 90 days", "RTO ≤ 30 min for tier-1 workloads".
• The date it can't slip past. Because otherwise the datacenter contract renews / the audit fails / the growth blocks. If no such date exists, the project has no forcing function and will slip.
• The owner. A named executive owner who can approve trade-offs mid-project without a committee. Not "the transformation office".
• The budget. Includes build, migration, first-12-months of run, and a documented 20% contingency. Signed off before RFP.

Architecture & platform (5)

• Cloud provider. Picked and justified — not because a partner recommended it, but because the workload characteristics match. Multi-cloud is usually not the answer for a first migration.
• Landing zone. A written landing-zone design: account/subscription structure, network topology, identity boundary, logging pipeline. Reviewed by security before any workload lands.
• Data model. For every dataset that moves: where the source-of-truth lives during cutover, how consistency is maintained, and what "done" looks like for that dataset.
• Identity boundary. Federation strategy, break-glass account policy, third-party access model. Documented and delegated ownership.
• Observability. Metrics, logs, traces — what's collected, where it lives, who gets paged when. Pre-existing dashboards ported before cutover, not after.

Migration mechanics (5)

• Waves. Workloads grouped into migration waves by dependency, not by organisational chart. Each wave has an entry and exit gate.
• Cutover runbook. Every workload has a written runbook: pre-checks, sequence, decision points, expected duration, rollback trigger, comms points.
• Rollback plan. For every wave, what does "abort" look like operationally? Rehearsed at least once in a non-production wave.
• Data reconciliation. How you prove the destination matches the source. Automated checks that run continuously during the cutover window.
• Business freeze windows. Agreed with the operating teams. Communicated to customers where relevant. Not decided the week before.

Governance & exit (5)

• FinOps model. How costs will be tagged, allocated, reviewed, and controlled after go-live. Alert thresholds set before spend starts.
• Security baseline. Every workload meets the same baseline (encryption in transit + at rest, least-privilege, secret management, audit logging). Documented as code where possible.
• Change process. How production changes get made post-cutover. Who approves. What gets automated.
• Skills plan. Which existing operators become cloud operators. Their training path. Where you'll bring in outside help for the first 6 months.
• Exit strategy. Not a plan to leave — a documented understanding of what it would take to move off this cloud if commercial terms changed materially. Prevents lock-in accidents.

Scoring

• 18–20: You're ready. Start scoping the delivery.
• 14–17: Close the gaps in a 4-week paid discovery, then proceed.
• Below 14: The migration is not the project yet. The decision-making is.

If you'd like a second pair of eyes on where you land on this checklist, book a 30-minute consultation. We'll walk through it with you and tell you honestly whether we're the right team to help.