Cloud · October 1, 2026 · 6 min read
Cloud Migration Readiness Checklist
Thirty questions to answer before you sign a migration contract, grouped by the five dimensions that decide whether a cutover goes quietly.
Every migration we have run that went badly for a previous vendor failed on something that was knowable in week one. This checklist is the list we use in discovery. Answer it honestly and you will know whether you are ready, and if not, what the first three weeks have to produce.
Inventory
- [ ] Every server, VM and container host is in one list with an owner
- [ ] Every application maps to the servers it runs on and the databases it uses
- [ ] Dependencies between applications are mapped by scanning, not by memory
- [ ] Licences that are tied to hardware or CPU counts are identified
- [ ] Anything nobody has logged into for six months is flagged for retirement
- [ ] The list has been reviewed by someone who will be blamed if it is wrong
Architecture
- [ ] Each application has a disposition against the 7 Rs
- [ ] Applications that need refactoring have a reason and an owner
- [ ] The target cloud is the one your identity provider and your team already know
- [ ] The landing zone design exists before the first workload moves
- [ ] Network paths to anything staying on-prem are designed, with latency measured
- [ ] Shared services (DNS, identity, monitoring, backup) land first
Data
- [ ] Every database engine and version is listed with its size
- [ ] Databases that must stay in sync during the move use continuous replication
- [ ] Cutover rehearsals include a timed restore from backup
- [ ] Data residency and retention requirements are written down
- [ ] Someone has tested that the application works with the managed database service
- [ ] The rollback plan for each database is a procedure, not a sentence
Compliance
- [ ] The compliance regimes in scope are listed, with the controls that apply to infrastructure
- [ ] Controls are implemented as code in the landing zone
- [ ] Evidence collection starts on day one, not before the audit
- [ ] The auditor or assessor has seen the target architecture
- [ ] Breach notification responsibilities are clear for the migration period
- [ ] Access to the new environment is through identity, with MFA, from the first login
Operations
- [ ] Monitoring and alerting exist in the target before the first cutover
- [ ] Runbooks exist for the first wave, and someone who did not write them has followed one
- [ ] On-call for the migration period is staffed and paid for
- [ ] Each wave has a rehearsal, a go/no-go gate and a rollback deadline
- [ ] FinOps guardrails (budgets, tagging, rightsizing) are switched on before scale
- [ ] The team that will run the estate after the move is involved in the move
If you ticked fewer than twenty, a three-week migration assessment will close the rest. Run the readiness calculator on the Cloud Migration page for a duration and cost range from your own numbers.
Next step
Apply this to your estate
A 30-minute call on what in this note transfers to your situation, and what the first fixed-scope engagement would cover.
30-minute call, no slides. We reply within one business day.
