AWS migration checklist: phase-by-phase tasks, owners and exit criteria
Country Manager, India
AI, Manufacturing, DevOps, and Managed Services. 17+ years across Manufacturing, E-commerce, Retail, NBFC & Banking
An AWS migration checklist lists the tasks, owners and exit criteria for each phase: assess the estate and build the business case, plan the landing zone, waves and runbooks, migrate in waves with tested cutovers, validate each workload against its baseline, then operate with monitoring, backup and cost control. Use the table below as a working copy.
Key takeaways
- AWS structures migrations in three phases, Assess, Mobilize, and Migrate and Modernize. This checklist splits the last phase into migrate, validate and operate so each has its own exit criteria.
- Pick one of the 7 Rs for every application. AWS recommends rehosting, relocating or replatforming first in large migrations and modernising after.
- Retire before you move. AWS guidance flags applications under 5 percent average CPU and memory use as retirement candidates.
- Start small: AWS's example for a 1,000-server programme begins at about 5 servers a week and ramps up to 50–100.
- Every task needs a named owner and a "done when" test. A checklist without exit criteria is a wish list.
The phase-by-phase AWS migration checklist
The phases follow the AWS Migration Acceleration Program (MAP) method of Assess, Mobilize, and Migrate and Modernize. Owners are typical roles; rename them to match your organisation.
| Phase | Task | Owner | Done when |
|---|---|---|---|
| Assess | Agree business goals and constraints (exit date, cost target, compliance limits) | Sponsor, IT lead | Signed goals with measurable targets |
| Assess | Discover servers, databases, storage and network; collect utilisation over a full business cycle | Infrastructure lead | Inventory reconciled with CMDB and finance asset list |
| Assess | Map application dependencies with tooling and owner interviews | Application owners, architect | Every server assigned to an application; dependency groups agreed |
| Assess | Choose a 7 Rs strategy per application and flag retire candidates | Architect, application owners | Strategy recorded for 100% of in-scope applications |
| Assess | Build the business case: AWS run cost, migration cost, double-running period, licences | Finance, architect | Business case approved; MAP eligibility checked with AWS or partner |
| Assess | Map regulatory needs (GDPR, NIS2, sector rules) and data residency to AWS Regions | Security, legal | Allowed Regions and data classes documented |
| Plan (Mobilize) | Build the landing zone: multi-account structure, identity, guardrails, logging | Cloud platform team | Accounts, SSO, guardrails and central logs live; security review passed |
| Plan (Mobilize) | Design and build network connectivity (VPN or Direct Connect, IP plan, DNS) | Network lead | Bandwidth and latency tested from data centre to AWS |
| Plan (Mobilize) | Define the shared responsibility split and operating model | IT lead, security | RACI for patching, backup, monitoring, incidents and cost signed off |
| Plan (Mobilize) | Select and set up migration tools (for servers, databases and files) | Migration lead | Tools installed; test replication completed |
| Plan (Mobilize) | Write runbooks for rehost and replatform, including rollback | Migration lead | Runbooks reviewed and used in the pilot |
| Plan (Mobilize) | Plan waves by dependency group and business calendar | Portfolio lead | Wave plan with dates, owners and freeze periods published |
| Plan (Mobilize) | Run a pilot with a few low-risk applications | Migration lead, application owners | Pilot cut over; lessons fed back into runbooks |
| Migrate | Capture performance baselines before cutover | Application owners, operations | Response time, error rate and batch durations recorded |
| Migrate | Replicate servers and data; run test launches | Migration engineers | Test instances boot and pass smoke tests |
| Migrate | Agree cutover window, communication plan and go/no-go criteria | Wave lead, business owner | Go/no-go checklist signed for the wave |
| Migrate | Cut over: final sync, switch DNS, open firewall paths | Migration engineers, network | Users served from AWS; rollback not triggered within the agreed window |
| Migrate | Update runbooks after each wave | Migration lead | Revision logged; next wave uses the new version |
| Validate | Functional and user acceptance tests | Application owners, test lead | UAT signed by the business owner |
| Validate | Compare performance and cost with the baseline | Operations, FinOps | Within agreed tolerance, or a tuning ticket is raised |
| Validate | Verify data integrity (row counts, checksums, reconciliations) | Data owners, DBA | Reconciliation report signed off |
| Validate | Test backup restore and failover for the workload | Operations | Restore completed within the agreed RTO and RPO |
| Operate | Turn on monitoring, alerting and on-call for the workload | Operations | Alerts route to the on-call team; dashboards published |
| Operate | Apply tagging, budgets and rightsizing reviews | FinOps | Every resource tagged with owner and cost centre; budget alerts active |
| Operate | Patch, security posture and access reviews on a schedule | Security, operations | First monthly review completed with findings tracked |
| Operate | Decommission source servers and close data-centre contracts | Infrastructure lead, procurement | Source shut down after the agreed retention period; licences and contracts ended |
Phase 1: assess
The assess phase answers what you have, what it costs today and what it will cost on AWS. AWS's MAP describes it as identifying capability gaps across the six perspectives of the AWS Cloud Adoption Framework (business, process, people, platform, operations and security) and building a realistic TCO model.
Choose a migration strategy for every application
AWS Prescriptive Guidance lists seven migration strategies, the 7 Rs: retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect. For large migrations, AWS does not recommend refactoring during the move, because it is the most complex strategy. It suggests rehosting, relocating or replatforming first and modernising afterwards. Our 7 Rs explainer covers when each one fits.
Find what to retire
The same AWS guidance calls applications with average CPU and memory use below 5 percent "zombie" applications, and those between 5 and 20 percent over 90 days "idle" applications. An application with no inbound connection in the last 90 days is another retire candidate. Every application you retire is one fewer to migrate, test and pay for.
Phase 2: plan and mobilise
Mobilise is where you build the foundation and prove the method. The outputs are a landing zone, a network path, an operating model, runbooks and a tested pilot.
Agree who does what
Under the AWS shared responsibility model, AWS secures the cloud infrastructure and you remain responsible for what you run in it, such as the guest operating system, applications, data, identities and network configuration. Write this split into a RACI before the first wave, including what any managed service provider covers. See our guide to the AWS migration readiness assessment for the questions to ask.
Run a pilot
Pick a few applications that are low risk but representative, for example one Windows and one Linux workload with a database. The pilot tests the tools, network, runbooks and cutover communication on real systems.
Phase 3: migrate in waves
Migrate at a steady, increasing pace. In its guide for large migrations, AWS gives the example of moving 1,000 servers in six months by starting at about 5 servers per week and ramping up to 50–100 per week. AWS treats 300 or more servers as a large migration. The guide also recommends that wave planning stays about five waves ahead of migration execution, and that runbooks are revised after every cutover.
For each wave, keep a go/no-go list: replication healthy, test launch passed, rollback steps confirmed, business owner available, and change freeze periods respected.
Phase 4: validate each workload
A workload is not migrated until it is proven. Compare response times, error rates and batch durations with the baseline you captured before cutover. Reconcile data, run user acceptance tests, and restore a backup to prove recovery works. Only then start the clock on decommissioning the source.
Phase 5: operate and optimise
After cutover the work shifts to running the platform well. Put monitoring and on-call in place on day one, apply tags and budgets, and schedule rightsizing reviews, since right-sizing after a like-for-like rehost often brings the first savings. The AWS MAP overview explains how modernisation fits after the move, and our AWS managed service covers ongoing operations.
Example: a seasonal business moved to AWS
Branäsgruppen, one of Sweden's largest ski resort groups, ran its websites on on-premises VMware ESXi and had to scale manually ahead of each winter season. Opsio planned and executed an AWS migration ahead of the next ski season using a replatform approach: application logic was kept, while servers and databases moved to AWS-managed equivalents with auto-scaling and Multi-AZ deployment. Production systems are backed up daily (incremental) and weekly (full) with 60 days' retention. Branäsgruppen reports a 40% improvement in average page responsiveness, a 40% reduction in total cost of ownership and over 99.9% application uptime.
How Opsio helps
Opsio is an AWS Advanced Tier Services Partner with the AWS Migration Competency and runs migrations using the MAP method, from assessment to managed operations. See our AWS migration service.
Frequently asked questions
What are the phases of an AWS migration?
AWS uses three phases: Assess, Mobilize, and Migrate and Modernize. Many teams split the last phase into migrate, validate and operate so each step has clear exit criteria.
What should be on a pre-migration checklist?
Business goals, a reconciled inventory, dependency groups, a 7 Rs decision per application, a business case, compliance and Region requirements, a landing zone, network connectivity, runbooks and a successful pilot.
How long does an AWS migration take?
It depends on the number and complexity of applications. As a reference, AWS's large migration guide uses an example of 1,000 servers in six months, starting slowly and increasing the number of servers per week.
Which applications should not be migrated?
Retire applications nobody uses (AWS flags very low utilisation or no inbound connections in 90 days) and retain those blocked by data residency, recent upgrades or dependencies that must move first.
What is the AWS shared responsibility model in a migration?
AWS secures the underlying cloud infrastructure. You remain responsible for your operating systems, applications, data, identities and configuration, so patching, backup and access control must be assigned to an owner before cutover.
Related Articles
About the Author
Country Manager, India
Praveena leads Opsio's India operations, bringing 17+ years of cross-industry experience spanning AI, manufacturing, DevOps, and managed services.
Editorial standards: This article was written by a certified practitioner, named in the byline above. We revise it when the technology or regulation it covers changes; the dates above show the latest update. Opsio maintains editorial independence — we recommend solutions on technical merit, not commercial relationships.
