Migration · Guide · · 4 min read
Pre-migration checklist: 12 items before you cut over to AWS
A practical checklist for discovery, networking, identity, backups, rehearsal, and runbooks — so go-live week is boring on purpose.
Cutover failures rarely come from “AWS being hard.” They come from assumptions that were never written down. Use this checklist in discovery and again 48 hours before go-live. Treat unchecked items as explicit risks in the plan — not surprises on launch night.
How to use the checklist
- Discovery: complete every section for phase 1 systems
- T-minus 14 days: re-validate network, identity, and backup restores
- T-minus 48 hours: confirm runbooks, owners, and rollback triggers
- Go-live: execute the runbook; do not improvise scope
If phase 1 is still “everything,” stop and shrink scope before you cut over anything.
Discovery and scope
- Inventory of applications, owners, RTO/RPO, and compliance tags
- Dependency map (databases, LDAP, file shares, SaaS integrations, batch jobs)
- Explicit list of in-scope vs. out-of-scope systems for phase 1
Why it matters: Most overruns start as hidden dependencies — a reporting job, a file share, or a vendor VPN that nobody listed.
Pass criteria: Every in-scope app has an owner, a dependency list, and a stated RTO/RPO. Out-of-scope systems are named, not implied.
Identity and access
- IAM Identity Center or SSO design documented (no long-lived admin keys for humans)
- Break-glass accounts MFA-protected; root unused for daily work
- Least-privilege roles for deploy pipelines and operators
Why it matters: Cutover week is when teams create “temporary” admin access that becomes permanent.
Pass criteria: Operators can deploy and diagnose through named roles. Nobody needs standing AdministratorAccess for the migration weekend.
Network and security
- VPC design: subnets, routing, NAT vs. endpoints, on-prem connectivity tested
- Security groups reviewed against least privilege (not “allow all internal”)
- Logging enabled: CloudTrail, VPC Flow Logs where required, GuardDuty considered
Why it matters: Connectivity surprises dominate failed cutovers — DNS, firewall rules, and “it worked from my laptop.”
Pass criteria: Critical paths tested from the target VPC (app → DB, app → IdP, app → external APIs). Logging is on before production traffic moves.
Data and backups
- Backup strategy matches RPO; restore tested, not assumed
- Encryption in transit and at rest documented (KMS keys owned by the right account)
- Data migration method chosen per datastore (replication, backup/restore, dual-write, freeze window)
Why it matters: “We have snapshots” is not a restore plan. Encryption and key ownership questions also show up in customer security reviews.
Pass criteria: At least one restore test completed for each critical datastore within the last 30 days. Rollback data path is documented.
Cutover mechanics
- Cutover runbook with ordered steps, time boxes, and communication plan
- Rollback triggers written in advance (not “we’ll know if it’s bad”)
- Named decision-makers for go / no-go and rollback
- DNS / traffic shift plan with TTL strategy and verification checks
- Hypercare schedule for the first 72 hours after go-live
Why it matters: Ambiguous ownership turns a technical issue into a political one at 2 a.m.
Pass criteria: A stranger on your team could follow the runbook. Rollback criteria are measurable (error rate, latency, data lag), not emotional.
Rehearsal (the item teams skip)
- At least one rehearsal on non-production or a parallel environment
- Timing recorded so the maintenance window is realistic
- Gaps from rehearsal folded back into the runbook
Why it matters: The first time you run the cutover should not be production. Rehearsal finds missing IAM permissions, wrong security groups, and optimistic time estimates.
Pass criteria: Rehearsal completed; runbook updated; window includes buffer based on measured timing.
Decision table: path per workload
Not every app deserves the same migration pattern.
| Situation | Lean toward | Avoid |
|---|---|---|
| Stable COTS app, low change rate | Rehost (lift-and-shift) | Premature rewrite |
| App needs managed DB / containers soon | Replatform | Big-bang rewrite during cutover |
| Core product with heavy tech debt | Refactor in waves after landing | Rewriting everything before any move |
| Unknown dependencies | Defer or isolate | Blind cutover |
More detail: Lift-and-shift vs refactor on AWS and migrating without extended downtime.
48-hour go-live gate
Do not proceed unless you can say yes:
- Phase 1 scope is frozen
- Identity and network paths tested
- Restore tested for critical data
- Runbook + rollback owners confirmed
- Rehearsal completed (or explicitly waived with documented risk acceptance)
- Hypercare staffing booked
If any item is a no, move the window. A delayed cutover is cheaper than an unplanned outage.
Budget traps tied to checklist gaps
Unchecked discovery and missing rollback plans are also how migrations blow the budget — dual-running environments longer than planned, emergency contractor hours, and rework after a failed weekend. See why cloud migrations go over budget.
We walk teams through this checklist in discovery before any lift-and-shift or replatform work begins. Assess your migration readiness or book a free discovery call.