Skip to content

AWS Updated 2026-09-28

The AWS migration checklist: everything that must be answered before cutover day

Use this AWS migration checklist to confirm a workload is ready before you book a cutover window. It groups the questions into six blocks, from inventory and DNS through rollback and day-two operations, and asks for a written, tested answer to each.

If your team is moving workloads into AWS, this checklist helps you decide whether you are ready for cutover. Cutover is the window when users switch from the old servers to the new ones. Each item is a question that needs a written, verified answer before anyone books that window.

When a cutover goes wrong, the servers themselves are rarely the gap. The trouble is more often DNS, rollback, software licensing, or who gets called at 3 a.m. if something breaks. The list is grouped into six blocks, and the items people skip most often get the firmest wording.

What you are deciding

Cutover day is a bet: that everything the workload depends on has been identified, moved or reconnected, and tested. The checklist exists to shrink the bet. Every unanswered item is a risk you are accepting silently; the discipline is to make each acceptance explicit. Two properties separate a real checklist from theatre. First, answers are written down — “Dave knows the firewall rules” is not an answer, because Dave is on a plane on cutover day. Second, answers are verified — “backups are configured” and “we restored a file from backup on Tuesday” are different claims, and only the second one counts.

The checklist below is grouped into six blocks. A workload is cutover-ready when every block is green for that workload — not when the project timeline says so.

What to check first

If you only have an hour, these five questions predict readiness better than anything else:

  • Can you name the rollback trigger? The specific condition and time at which you abandon the cutover and go back.
  • Has a test instance of the workload been launched and validated in AWS? Not “replication is green” — actually booted, logged into, and exercised.
  • Do you know every DNS record that must change, and its current TTL? A 24-hour TTL discovered on cutover night adds a day to your outage.
  • Has anyone restored a backup in the new environment? Restore, not configure.
  • Who is on call for the first 72 hours, and do they have working access? Credentials tested, MFA enrolled, VPN working — before the window opens.

How to verify

Spot-check the claims with commands rather than accepting status-report green. A sample per block:

# Network: is the site-to-site path actually up?
aws ec2 describe-vpn-connections \
  --query 'VpnConnections[].[VpnConnectionId,State,VgwTelemetry[].Status]'

# DNS: what is the real TTL on the records you will move?
dig +noall +answer app.example.com

# Replication: is every server in the wave current?
aws mgn describe-source-servers \
  --query 'items[].[sourceServerID,dataReplicationInfo.dataReplicationState]' \
  --output table

# Backups: has a restore job ever actually run?
aws backup list-restore-jobs \
  --query 'RestoreJobs[].[CreationDate,Status,CreatedResourceArn]' --output table

# Monitoring: do alarms exist and point at a subscribed topic?
aws cloudwatch describe-alarms \
  --query 'MetricAlarms[].[AlarmName,StateValue,AlarmActions[0]]' --output table

In the console, Application Migration Service > Source servers should show the whole wave Ready for cutover, and Backup > Jobs > Restore jobs should contain at least one successful entry that a human initiated on purpose.

The checklist

  1. Inventory and dependencies. Every server, application, database, scheduled job, and integration in the wave is listed with an owner. Dependencies are mapped both ways — what this workload needs, and what needs it. Anything discovered during cutover belongs on this list retroactively, with a note about why it was missed.
  2. Network and DNS. Connectivity between office/users and AWS is up and measured. Security groups are written and reviewed. Every DNS record that changes is listed with current TTL, target value, and owner of the change; TTLs are lowered at least 48 hours ahead. Hard-coded IPs have been hunted down or documented as accepted risk.
  3. Identity and access. Authentication works in the target environment and has been tested by a real user login. Service accounts, API keys, and certificates the workload uses are inventoried and valid in AWS. The on-call team’s access is verified. Licensing is confirmed for the new environment — some vendor licenses are tied to hardware fingerprints or cores and go invalid on new infrastructure.
  4. Data and backups. Data replication or seeding is complete and current, with lag measured, not assumed. A backup plan exists in AWS, has run, and a restore has been performed and validated. Retention matches whatever compliance obligation applies. For databases, the point-in-time story is understood — see PITR and snapshot strategy for what good looks like on RDS.
  5. Cutover plan and rollback. A written minute-by-minute sequence with named owners, a go/no-go checkpoint, validation steps a non-expert could execute, and an explicit rollback trigger (“if validation has not passed by 02:00, we roll back”). The rollback itself has been thought through mechanically: what gets repointed, what gets restarted, what data reconciliation is required if writes happened in AWS.
  6. Day-two operations. Monitoring and alarms exist before go-live — a baseline like the CloudWatch alarm set is the floor. Patching responsibility is assigned. The cost estimate is written down so the first bill can be compared against it. Someone owns the environment by name, and the first-month review is already in a calendar.

When this is the wrong move

A checklist this heavy is wrong for a workload that is disposable — a dev environment or a stateless service that can be rebuilt in an hour does not need a rollback ceremony. It is also the wrong tool when the real problem is upstream: if the inventory itself is fiction, no cutover checklist saves you, and the honest move is to stop scheduling windows and go back to discovery. Checklists verify readiness; they do not create it.

Common mistakes

  • Green-by-assertion. Items marked complete because someone said so, without a command, screenshot, or test to back the claim.
  • A rollback plan that has never been walked through. Rollback is a procedure with steps, timing, and its own data problems — not a sentence that says “we will roll back.”
  • Testing from inside AWS only. The workload works instance-to-instance and fails from the office, because nobody tested the path users actually take.
  • Freezing the checklist at kickoff. Estates change during a multi-month project; a checklist that ignores the new server someone stood up in week six is auditing the past.

Keeping it under control

  • Keep the checklist in one shared document with a status, an owner, and an evidence link per item — evidence, not adjectives.
  • Review it as a group 72 hours before the window; any red or unevidenced item triggers a postpone conversation, not a hope.
  • Re-run the verification commands the morning of the cutover; replication states and tunnel health can change in a week.
  • After each wave, hold a 30-minute retro and amend the checklist with what was missed — the checklist should be smarter by wave three.
  • Archive the completed checklist per wave; it is the audit trail when someone asks in six months why a decision was made.

A cutover that follows a fully evidenced checklist is dull, and dull is the goal. If nobody on your team truly owns the AWS environment end to end, that is the root of most of these problems — Stack Harbor runs AWS accounts daily under AWS Operations, and you can book an AWS review.