Migrations fail in predictable ways: no rollback plan, a dependency nobody mapped, a data cutover that loses writes. None of that is exotic, it comes from skipping the boring preparation. Here is the checklist we run, phase by phase.
Phase 1, Assess before you move anything
- Inventory every application, service, and data store
- Map dependencies, what talks to what, and over which ports
- Note compliance and data-residency constraints
- Record current performance baselines so you can compare after
- Identify the riskiest workload and plan to migrate it last
Phase 2, Pick a strategy per workload (the 6 Rs)
Not everything migrates the same way. Classify each workload:
- Rehost, lift-and-shift as-is (fastest, least optimized)
- Replatform, small tweaks, e.g. managed database instead of self-hosted
- Repurchase, move to a SaaS equivalent
- Refactor, rearchitect for cloud-native (highest effort, highest payoff)
- Retire, turn it off; you may not need it
- Retain, leave it where it is for now
Phase 3, Prepare the landing zone
Set up the AWS foundation before workloads arrive: account structure, networking, identity, and logging. Migrating into a messy single-account setup just moves the mess.
Phase 4, Migrate data carefully
Data is where migrations actually go wrong. Use replication to keep source and target in sync, then cut over during a low-traffic window with reconciliation checks on both sides.
# Lower DNS TTL a day ahead so cutover propagates fast
# Replicate continuously, verify row counts + checksums, then flip
aws route53 change-resource-record-sets ... # TTL 60s pre-cutoverA migration without a tested rollback is not a plan, it is a bet. Always know how to get back.
Phase 5, Cut over and validate
- Run the cutover in a low-traffic window
- Validate against your pre-migration performance baselines
- Keep the old environment warm until you are confident
- Have the rollback runbook open and tested
Phase 6, Optimize after landing
Once stable, right-size and clean up. Migrating and optimizing at the same time is how you introduce variables you cannot isolate when something breaks. Land first, optimize second.
If you want the landing zone and cutover handled by people who have done it before, that is exactly what our cloud migration work covers, with the rollback plan written before we touch anything.
About the author
Deep Mehta
Deep is the founder of 3 Dices Technology, a cloud engineering studio. He has shipped AWS architecture, DevOps automation, and production AI systems for startups and SMBs, and writes about the practical version of that work, not the conference-talk version.
Connect on LinkedIn