How Application Migration Service's Replication-to-Cutover Flow Works
~8 min read
The three phases of an MGN migration — replicate, test, cutover — and why splitting them apart minimizes risk and downtime.
Application Migration Service's flow deliberately separates three phases that a naive one-shot migration would collapse into one risky event. First, continuous replication: a lightweight agent on the source server streams ongoing block-level changes to a staging area in AWS, running for as long as needed (days to weeks) with negligible impact on the source server's normal operation. Second, non-disruptive testing: at any point during replication, a test EC2 instance can be launched from the current replicated state without affecting the source server or the ongoing replication process, allowing thorough validation — checking the application actually runs correctly, performance is acceptable, and nothing was missed — well before any real commitment is made. Third, cutover: when ready, a final, short synchronization catches up any very recent changes, and the production EC2 instance is launched from that fully synced state, with the source server's traffic redirected — the only phase involving real downtime, and by this point it's reduced to catching up minutes of delta rather than transferring the entire server's data from scratch.
💬 Deep Dive with AI
Key points
- •Phase 1 (replicate): continuous, low-impact, ongoing background replication of the source server
- •Phase 2 (test): non-disruptive test instances launched from current replicated state, validated independently
- •Phase 3 (cutover): short final delta sync plus traffic redirect — the only real downtime window
- •Separating these phases converts a risky one-shot migration into a validated, low-downtime process