The AWS migration checklist: every box to tick, start to finish.

IHow the checklist works: waves, owners, exit criteria

A migration is a series of waves. You group applications by how tightly they are coupled, move one wave end to end, validate it in production, then start the next. Low-dependency systems go first; critical systems go last.

Treat each item as a checkbox with an owner and an exit criterion. "Done" means a named person signed off against a defined condition, not "we talked about it". The grid at the end collapses everything into a phase, task and owner table you can paste into a tracker.

IIPre-migration: seven items you build once

Nothing moves until these are done. They are sequenced: discovery feeds the dependency map, which feeds the cost model and the funding question; the landing zone, accounts and security baseline are what every wave lands into.

• 1. Discovery: Inventory every server, container, database and data store, with real utilisation (p95, not average), versions, ports and several weeks of network-connection data. AWS Migration Hub and Application Discovery Service closed to new customers on November 7, 2025; AWS now points to AWS Transform. Exit: a reconciled inventory with a 7 Rs decision per asset.
• 2. Dependency mapping: Build a graph of which service talks to which, on which port, and how often. It surfaces the cron job writing to production and the internal API three teams use. Tightly coupled systems move in the same wave. Exit: a signed-off wave plan with no "we will figure it out at cutover" unknowns.
• 3. Cost model: Compare today's run-rate (hardware, hosting, licences, ops time) with the projected AWS bill, sized to real p95 usage. Include the parallel-run period, data transfer and backups. Migration Evaluator builds a business case at no cost. Exit: a projected monthly AWS spend the business agrees with.
• 4. Funding question: MAP (Assess, Mobilize, Migrate and Modernize) is filed by an AWS partner. If the migration qualifies and AWS approves, startups typically see $50K to $150K. Depends on the workload; AWS approves. Exit: a clear yes or no from your partner on whether MAP applies, before you commit dates.
• 5. Landing zone: A governed multi-account setup (AWS Control Tower over Organizations), with VPCs across Availability Zones, a Transit Gateway if needed, central logging, and a VPN or Direct Connect link back to the source for the migration period. Exit: core accounts deployed from code, hybrid link tested.
• 6. Account structure: Separate accounts per environment and workload, grouped into OUs with Service Control Policies; IAM Identity Center for access; a tagging standard (owner, environment, cost centre, wave). Exit: an account map agreed with security and finance, and tags published.
• 7. Security baseline: CloudTrail organisation trail, AWS Config, GuardDuty and Security Hub across the organisation, encryption by default, no long-lived keys. Encode it as guardrails so member accounts cannot switch it off. Exit: controls live and verified in Security Hub before the first workload lands.

IIIPer wave: nine steps for every batch of workloads

Run these in order for each wave. Do not advance until the current step's exit criterion is met, and do not cut over wave N+1 until wave N is validated in production. The rollback plan is listed last but written first.

• 1. Wave assessment: Confirm the 7 Rs decision per application now that you know more (a "rehost" often becomes "replatform" when the managed equivalent is little extra work). Exit: cutover and rollback windows agreed with the business owner.
• 2. Target design: Per workload: EC2 sized to p95 for rehosts; ECS or EKS for containers (ECS Express Mode for simple web services; App Runner closed to new customers on April 30, 2026); RDS or Aurora for databases; SQS, ElastiCache and so on. Exit: a target diagram reviewed against the AWS Well-Architected pillars.
• 3. Infrastructure as code: Terraform, CloudFormation or CDK, never console clicks, so test and production are identical. Exit: the wave's infrastructure provisioned in non-prod from reviewed code, with a clean destroy and re-apply.
• 4. Data sync: MGN for whole servers, DMS for databases (plus the Schema Conversion Tool for engine changes), DataSync for files. Bulk copy first, then stream changes where the source allows it. Exit: replication caught up and an integrity check (row counts or checksums) passed.
• 5. Test cutover: Launch test instances in an isolated subnet without touching the source, run the full test suite, and write a timed cutover runbook from the test run. Exit: tests pass on AWS and the runbook exists.
• 6. Validation criteria: Define "working" in advance: functional correctness, performance within SLO, data integrity, every dependency from the map responding, security baseline inherited, alarms firing. Exit: a pass or fail checklist with a named decision owner.
• 7. Production cutover: Freeze writes on the source, let replication flush, check integrity, launch on AWS, validate, take traffic. Exit: live on AWS with the source still intact (do not decommission yet).
• 8. DNS cutover: Lower TTLs a day or two before, then shift traffic with Route 53 weighted records (10%, 50%, 100%) while watching error rates. Exit: traffic on AWS, error rates healthy, TTLs restored.
• 9. Rollback plan: Written before the cutover starts. Define the point of no return (when AWS accepts writes the source has not seen) and the procedure on each side of it. Exit: an owner-assigned rollback runbook. No rollback plan, no cutover.

IVWhich AWS tool for which move

Picking the wrong data-sync tool quietly costs a week. This maps what you are moving to the AWS service that moves it.

VPost-migration: optimise, right-size, decommission, hand over

The migration is done when the source is off, the bill is optimised, and your team can run the platform without the partner. Two of these items decide whether the migration saves money or just moves the spend.

• 1. Optimise and modernise: After a soak period, move steady compute to Graviton where it fits, containerise where it cuts ops load, swap self-managed parts for managed services. Exit: a prioritised modernisation backlog.
• 2. Right-size: Use Compute Optimizer and Cost Explorer recommendations, then commit the steady baseline with Savings Plans (AWS says up to 72% off On-Demand) and switch non-prod off out of hours. Exit: right-sizing applied and a monthly cost review in the calendar.
• 3. Decommission the source: Once the workload has soaked long enough to trust, confirm no stray traffic, take a final archival snapshot, power off or terminate the old resources and cancel contracts. Until then you pay twice. Exit: source off and the parallel-run cost gone from the bill.
• 4. Knowledge transfer: Runbooks, IaC repos, diagrams, monitoring and on-call setup handed over, and an incident drill run on the new platform. Exit: your team has shipped a change and handled a drill without the partner.

VIWho runs this checklist, and who can fund it

This is weeks to months of work, with judgment calls that go wrong when improvised.

CloudRoute matches you with one vetted AWS partner chosen for your source (Heroku, GCP, Azure, on-premises, Oracle, SAP) and your stack. The partner runs the execution rows; your team owns the sign-offs (windows, acceptance, go or no-go, decommission approval).

Partner-filed funding: AWS says MAP helps offset initial migration costs. Your matched partner files it when the migration qualifies and AWS approves. For startups this is typically $50K to $150K. Depends on the workload; AWS approves. Smaller moves may not qualify; the partner tells you before you commit.

CloudRoute is free for startups. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.