Migrate to AWS without taking your app offline

Most on-prem to AWS migrations are planned around a maintenance window: take the app down on a Saturday night, copy everything, bring it up on AWS, and pray. For a small internal tool that is fine. For a revenue system or anything your customers touch around the clock, a window is not a plan - it is a bet that nothing goes wrong in a fixed number of hours, with no clean way back if it does. Zero downtime is a different shape of migration, and it is achievable with the right runbook.

This is that runbook at the level that matters: the sequence, the reversibility, and the one component - the database - that decides whether you actually hit zero downtime or just hoped to. It assumes a typical stateful web application with a relational database, the case where a window is most tempting and most dangerous.

Why the maintenance window is the trap

The window approach fails in predictable ways. The data copy runs longer than estimated and you blow the window. Something does not start cleanly on AWS and you are debugging live with the clock against you. And the worst one: you are an hour past the window with a half-migrated system and no rehearsed way back, because the rollback was never built - it was assumed. The fix is not a bigger window or a more careful checklist. It is to stop treating the migration as a single switch and run both environments in parallel until the new one has earned your trust. That parallel-run discipline is the spine of every credible AWS consulting migration we run.

The runbook, in order

Each step is reversible until the very end. That is the whole point.

1. Stand up the target, idle. Build the AWS environment - compute, network, the managed database - and deploy the application, but send it no production traffic. Validate it end to end with synthetic and shadow traffic first.
2. Start continuous database replication. Replicate from the on-prem database to the AWS target and let it catch up, then keep it streaming. AWS Database Migration Service or native logical replication keeps the lag down to seconds. This is the step that makes zero downtime possible: when you cut over, there is no long copy, because the data is already there and current.
3. Verify continuously. While replication runs, compare row counts and checksums between source and target. Do not move on until the data matches and stays matched under live write load.
4. Shift read traffic first. Point a small slice of read-only traffic at AWS using a low-TTL DNS record or a load balancer weight. Watch error rate and latency. Reads are safe to move early because the AWS database is a live replica.
5. Flip the write path. The one moment that needs care. Briefly stop writes, let replication drain the final few seconds of lag, promote the AWS database to primary, and repoint the application's writes. For most workloads this is a sub-second pause, not an outage. Reverse replication so the old database stays a warm fallback.
6. Ramp traffic to 100 percent. Increase the AWS weight in steps, holding at each level long enough to trust the metrics, until all traffic is on AWS and the old environment is serving nothing.
7. Decommission, deliberately. Keep the source running as a fallback for a defined soak period. Only after it has served no traffic and you have a clean backup do you turn it off.

The dual-write question

Some teams reach for application-level dual-write - having the app write to both databases at once - instead of database replication. It can work, but it pushes consistency into your application code, and a partial failure leaves the two databases disagreeing in ways that are painful to reconcile. For most relational workloads, managed replication at the database layer is simpler and safer than dual-write at the application layer. Reserve dual-write for cases where you are also changing the data model mid-migration, and even then, build a reconciliation check. The trade-off here is the same judgement that decides who you trust to run the migration at all, which we lay out in our comparison of AWS consulting partners.

Rollback is a feature you build, not a hope

The difference between a calm migration and a 2 a.m. incident is whether rollback was designed in. Before you shift a single percent of traffic, you should be able to answer: how do I send all traffic back to on-prem in under five minutes, and is the on-prem database still consistent if I do? With reverse replication running after the write flip, the answer stays yes right up to decommission. Low DNS TTLs mean a traffic reversal propagates in seconds, not hours. Practice the rollback on a staging cutover before the real one - an untested rollback is not a rollback.

The other thing migrations expose is everything you deferred: compliance scope, backups, network controls. A cutover is the right moment to get those right rather than carry old gaps into the cloud, which is why we pair the runbook with the controls in our 2026 guide to cloud migration compliance, and why ongoing managed cloud services matter after go-live - the migration is the start of running on AWS well, not the end. If the workload is AI-heavy, the same parallel-run discipline carries into how you architect AI on AWS.

FAQ

Can you really migrate to AWS with zero downtime?

For most stateful web applications, yes - if you replicate the database continuously and shift traffic gradually rather than cutting over in one window. The only moment that needs a pause is the database write-path flip, and on most workloads that is sub-second. True zero downtime depends on the database step, not on luck.

What is the hardest part of a zero-downtime cutover?

The database. Stateless application servers are easy to run in parallel; keeping the data consistent across two live systems is the real work. Continuous replication, checksum verification, and a careful write-path flip are what separate a clean cutover from a corrupted one.

Should I use dual-write or database replication?

For most relational workloads, managed database replication is simpler and safer than application-level dual-write, which pushes consistency into your code and risks the two databases disagreeing on a partial failure. Reserve dual-write for cases where you are also changing the data model, and add a reconciliation check if you do.

How do I roll back if the cutover goes wrong?

Design rollback before you start. Keep reverse replication running after the write flip so the old database stays consistent, use low DNS TTLs so a traffic reversal propagates in seconds, and rehearse the rollback on a staging cutover. An untested rollback is an assumption, not a safety net.

The takeaway: do not migrate inside a maintenance window and hope. Stand up AWS in parallel, replicate the database continuously, shift traffic a few percent at a time while you watch the metrics, flip the write path in a sub-second pause, and keep every step reversible until the old system has served nothing for days. Zero downtime is not luck. It is a runbook with a rollback you have actually tested.