Planning a zero-downtime AWS migration: waves, rehearsals and rollback

The migrations that go badly are rarely the ones with hard technical problems. They are the ones where a dependency nobody documented turns out to be load-bearing, discovered at 2am during a cutover window with no way back. Preventing that is a planning exercise, not a tooling one.

Discovery is the whole game

Before anything moves, we build a dependency map: which services talk to which, which share a database, what has a hardcoded IP or hostname, and which licences are tied to specific hardware. Automated discovery tools get you most of the way, but the gaps are always found by talking to the people who operate the system.

Application and database inventory with owners named for each

Network dependency map, including anything crossing environments

Data volumes and acceptable replication lag per system

Licensing constraints that affect instance choice

The real recovery time and recovery point objective per workload

Group workloads into waves

Tightly coupled systems must move together, or you introduce cross-cloud latency on a hot path. Loosely coupled systems can move independently. We group workloads accordingly, and deliberately put a low-risk, well-understood system in wave one so the team learns the process where the stakes are low.

The first wave is a training exercise disguised as a migration. Choose it for what it teaches you, not for how much it saves.

Rehearse, then cut over

Every wave gets a rehearsal against replicated data in the target environment. We run functional tests, compare performance against the pre-migration baseline, and time the cutover steps so the maintenance window is based on measurement rather than optimism. The rehearsal is also where the rollback plan gets tested — a rollback you have never executed is a hope, not a plan.

Cutover itself should then be an execution of a written runbook: freeze writes, complete final replication, switch DNS or connection strings, validate, and monitor. If validation fails, you roll back to a system that is still running, because you never decommissioned it on the same day.

Decommissioning the old environment comes weeks later, after the new one has carried real production load through a full business cycle including month-end. That patience is what turns a migration into a non-event.