Migrating to AWS without downtime: a practical checklist

Downtime is the reason most migrations to AWS get delayed, not the technical difficulty of the move itself. A migration planned around sequencing and a tested rollback rarely needs any real downtime at all; the risk comes from skipping the planning and migrating on faith.

Inventory before you move anything

Before touching infrastructure, list what's actually running: every service, its dependencies, how much data each one holds, and which ones talk to each other. Migrations that go wrong usually go wrong because of a dependency nobody mapped, not because AWS itself behaved unexpectedly.

Databases move in parallel, not in one midnight copy

Copying a production database once and switching over is how downtime happens, because the copy is already stale by the time the switch is flipped. Setting up ongoing replication, so the AWS-side database stays in sync with the current system until the moment of cutover, means the actual switch is a configuration change, not a multi-hour copy with the lights off.

DNS cutover is a sequencing problem, not a single switch

Lowering DNS TTL well in advance of the move, then cutting over gradually, keeps the blast radius small if anything looks wrong. A cutover planned around "flip it and see" with no low-TTL window in advance turns a small issue into an outage, because the old DNS record stays cached for hours.

Test the actual migration in staging first

A staging environment that mirrors production, used to rehearse the real migration steps rather than just testing the application in isolation, catches the problems that only show up during the move itself: permission issues, missed environment variables, a dependency that wasn't in the inventory.

Write the rollback plan before migration day, not during it

If a problem shows up mid-migration, the rollback plan needs to already exist and already be tested. A rollback plan written under pressure during an actual incident is, in practice, no plan at all.

A short checklist

• Is every running service, and its dependencies, actually inventoried?
• Does the database replicate continuously, instead of a single pre-cutover copy?
• Was DNS TTL lowered well before the cutover window, not during it?
• Has the real migration been rehearsed in a staging environment first?
• Is there a written, tested rollback plan, not just an assumption that one exists?

Our AWS cloud support service starts with an account and dependency review before any migration plan is written, from a scoped, read-only IAM role, not full access. Get in touch to talk through what you're moving.