Migration · Guide ·
AWS migration without extended downtime: what is realistic
How to plan cutovers, rollback triggers, and hypercare so go-live week is boring — not heroic.
“Zero downtime” is a sales phrase. Minimal downtime with a rehearsed rollback is an engineering deliverable. Here is how we set expectations with clients before a cutover.
Define downtime in business terms
Agree on:
- Maximum acceptable outage window (minutes vs. hours)
- Read-only vs. hard down — can users view data while writes pause?
- Rollback trigger — who decides, and what metric flips the switch?
Document these in the runbook, not in a slide deck.
Patterns that reduce risk
| Pattern | When it fits |
|---|---|
| Blue/green at the load balancer | Stateless web tiers, parallel stacks |
| Database replication + controlled failover | RDS/Aurora with tested promotion |
| Maintenance window + read-only mode | Legacy apps that cannot dual-run |
| Phased migration by workload | Many apps — migrate the easy win first |
Lift-and-shift often uses maintenance window + rehearsed cutover; refactor projects may achieve near-zero user impact because traffic shifts gradually.
The week before go-live
- Full dress rehearsal in a sandbox or isolated stack
- Freeze on non-critical changes
- Hypercare roster with named primary and backup
- Communication plan to stakeholders (what users will see, when)
The first 72 hours after
- Elevated monitoring on error rates, latency, and database replication lag
- Daily standup with app owners — even if “nothing broke”
- Capture a punch list for optimization (right-sizing, backups, alarms)
Downtime anxiety usually comes from unknown dependencies, not from AWS itself. Pair this guide with our pre-migration checklist and lift-and-shift vs. refactor framework before you commit to a date.