Most failed migrations don't fail in the cutover — they fail in the planning. A migration that's discovered properly, sequenced into waves, and backed by tested rollback is almost boring to execute. Here's the checklist we work through on every engagement.
Before you move anything
- Define the why. Cost, agility, resilience, an exiting data center? The goal shapes every later decision.
- Inventory and map dependencies. You can't safely move what you don't understand. Catalogue workloads, data stores, and the connections between them.
- Pick a strategy per workload. Rehost, replatform, refactor, or retire — there's no single right answer for the whole estate.
- Design the landing zone. Accounts/projects, networking, identity, security guardrails, and tagging — before the first workload lands.
Planning the moves
- Sequence into waves. Group by dependency and risk. Start with something low-risk to prove the process.
- Write runbooks. Step-by-step cutover and rollback procedures for each wave, tested in a non-production dry run.
- Plan the data. Migration method, sync strategy, validation, and reconciliation — data is where migrations most often hurt.
- Set success criteria. Define what "done and healthy" means for each wave before you start it.
During and after cutover
- Communicate constantly. Stakeholders should never wonder what's happening.
- Validate before you flip. Functional, performance, and security checks against the success criteria.
- Keep the rollback ready. A reversible wave is a safe wave.
- Run hypercare. Heightened monitoring and on-call support for a defined window after each cutover.
- Optimize once stable. Rightsizing and cost tuning come after things are healthy — not during the move.
The meta-lesson
Phased, reversible, well-communicated migrations are the ones that succeed. If a plan relies on a single big-bang weekend with no way back, that's the risk to fix first. See how we run cloud migrations end to end.