AWS Migration Plan: 26-Week Template With Waves, Owners and Cutover

8 min read ยท 2026-10-25

An AWS migration plan is the schedule and method for moving your applications, data and servers from on-premises or another cloud into AWS. It names which applications move in which wave, which strategy each one uses (rehost, replatform, refactor and so on), who owns each cutover, and when the old environment is switched off. AWS describes the journey in three stages: assess, mobilize, and migrate and modernize. The template below breaks those into six phases you can schedule.

It covers 26 weeks for a mid-sized estate of a few hundred servers, with a pilot and three migration waves. Each phase ends with a milestone you can check. You also get the 7 Rs in plain terms, a filled-in example, a cutover runbook outline, roles, metrics and how to report to leadership. Adjust the durations to your estate size and your change windows.

The roadmap at a glance

Goal: Your in-scope applications run in AWS on a governed landing zone, the old servers and contracts are shut down, and costs are tracked against the business case. Duration: 26 weeks

  1. Discovery and portfolio assessment (Weeks 1-4)

    Know exactly what you run, how it connects and what it costs today.

    • Build an inventory of servers, databases, storage and applications from your CMDB, monitoring tools and an agent-based discovery scan.
    • Map dependencies between applications, including shared databases, file shares and batch jobs.
    • Record each application's business owner, criticality, data classification and licensing.
    • Capture the current cost of data center space, hardware refresh, licenses and support contracts.

    Milestone: An application portfolio with owners, dependencies and current costs, reviewed by infrastructure and application leads.

  2. Business case and migration strategy (Weeks 3-6)

    Decide why you are moving, what moves, and how each application moves.

    • Assign one of the 7 Rs to each application: retire, retain, rehost, relocate, repurchase, replatform or refactor.
    • Estimate the AWS run cost with the AWS Pricing Calculator, and compare it to current costs.
    • Group applications into waves by dependency, risk and business calendar.
    • Get sign-off on scope, budget and the data center exit date from the sponsor.

    Milestone: Approved business case with a 7 Rs decision per application and a wave plan with target dates.

  3. Landing zone and readiness (Weeks 5-10)

    Build a secure, governed AWS foundation before any workload moves.

    • Set up a multi-account structure with AWS Control Tower and AWS Organizations, with guardrails and centralized logging.
    • Configure network connectivity to on-premises (Site-to-Site VPN or AWS Direct Connect), DNS and IP ranges.
    • Set up identity federation with your directory and define roles for operators and developers.
    • Define tagging, backup, monitoring and patching standards, plus budgets and cost alerts.
    • Train the operations team on the new environment and runbooks.

    Milestone: Landing zone live and approved by security, with connectivity tested end to end.

  4. Pilot migration (Weeks 9-12)

    Prove the method on two or three low-risk applications.

    • Pick pilot applications with few dependencies and an owner willing to test.
    • Replicate servers with AWS Application Migration Service and databases with AWS Database Migration Service where they fit.
    • Write and rehearse a cutover runbook with rollback steps and go or no-go criteria.
    • Run the cutover, test with users, and hold a short retrospective.

    Milestone: Pilot applications live in AWS, signed off by their owners, with lessons folded into the runbook.

  5. Migration waves (Weeks 13-22)

    Move the remaining applications in planned waves without business disruption.

    • Run waves every two to three weeks, each with a freeze window agreed with the business.
    • Start replication early so cutover only needs a final sync.
    • Hold a go or no-go meeting before each cutover with app owners, operations and security.
    • Run hypercare for one to two weeks after each wave with a named on-call rota.
    • Track open issues and blockers in a single migration tracker.

    Milestone: All in-scope applications migrated and signed off by their owners.

  6. Optimize and decommission (Weeks 21-26)

    Cut the old costs and tune the new ones.

    • Right-size instances based on two to four weeks of real usage data from CloudWatch and Cost Explorer.
    • Review Savings Plans or Reserved Instances for steady workloads.
    • Shut down and wipe old servers, cancel support contracts and return or recycle hardware.
    • Run a Well-Architected review on critical workloads and plan the next round of modernization.

    Milestone: Old servers decommissioned, monthly AWS spend reported against the business case, and a modernization backlog approved.

The 7 Rs in plain terms

Every application in your portfolio needs one decision. AWS calls these the 7 Rs. Deciding them early is what makes wave planning possible, because a rehost takes days while a refactor can take months.

A common starting point is to rehost or replatform most applications to hit the exit date, then modernize the ones that justify it once they are in AWS. Do not let one refactor block a whole wave. Move it to its own track.

  • Retire: switch it off. Many portfolios contain apps nobody uses.
  • Retain: keep it where it is for now, often due to licensing, latency or a planned replacement.
  • Rehost: lift and shift the server as it is, often with AWS Application Migration Service.
  • Relocate: move a whole virtualized platform, such as VMware, with little change.
  • Repurchase: replace it with a SaaS product.
  • Replatform: make small changes on the way, such as moving a database to Amazon RDS.
  • Refactor: redesign the app to use cloud-native services.

Example: a 26-week plan for a 300-server estate

Take a regional insurer with 300 servers in a co-located data center whose contract ends in eight months. Discovery finds 120 applications, 25 of which nobody uses anymore.

The pilot is small on purpose. It tests the network, replication and cutover runbook before anything critical moves. The core policy system goes last, after the team has run three cutovers.

  • Weeks 1-4, owner infrastructure lead: discovery scan and dependency map. Milestone: 120 applications documented, 25 marked to retire.
  • Weeks 3-6, owner IT director: business case and wave plan. Milestone: 70 rehost, 15 replatform, 5 repurchase, 5 retain, approved by the CFO.
  • Weeks 5-10, owner cloud architect: Control Tower landing zone, Direct Connect, identity federation. Milestone: security sign-off.
  • Weeks 9-12, owner migration lead: intranet, ticketing tool and a reporting server moved. Milestone: three cutovers with no rollback.
  • Weeks 13-22, owner migration lead: three waves of internal tools, customer portal, then core policy system. Milestone: all apps signed off.
  • Weeks 21-26, owner finance and infrastructure leads: right-sizing, Savings Plans review, racks emptied. Milestone: data center exit before the contract ends.

What goes in a cutover runbook

Each wave needs a runbook that anyone on the team can follow at 2 a.m. Write it as a numbered list of steps with an owner, a planned time and a check for each one. Rehearse it at least once on a test copy.

Store runbooks in Confluence or a shared drive and keep a version per wave. After each cutover, update the template with what went wrong.

  • Pre-checks: replication healthy, backups verified, change approved, users notified.
  • Freeze: stop writes to the source system and confirm the final sync.
  • Switch: update DNS or load balancer targets and connection strings.
  • Smoke tests: a short list of tests run by the app owner, with expected results.
  • Go or no-go decision, with a named decision maker and a deadline.
  • Rollback steps and the point after which rollback is no longer possible.

Who owns what

Cloud migrations stall when infrastructure and application teams wait on each other. Name one migration lead who runs the plan and chairs the go or no-go meetings, and make each application owner responsible for testing and sign-off.

Security and finance should be in the plan from week one, not invited at the end. Security approves the landing zone, and finance tracks spend against the business case.

  • Executive sponsor (CIO or IT director): owns scope, budget and the exit date.
  • Migration lead or PMO: wave plan, tracker, runbooks and status reporting.
  • Cloud architect: landing zone, network design and target architecture per app.
  • Application owners: testing, sign-off and user communication for their apps.
  • Security lead: guardrails, identity, logging and data protection controls.
  • FinOps or finance partner: budgets, tagging rules and cost reports.

Metrics and how to report to leadership

Leadership wants to know three things: are we on track for the exit date, is anything breaking, and is spend in line with the business case. Report on one slide with a wave timeline, the counts below and the top three risks with an owner each.

Leave out server-level detail and tool names. Keep that in the migration tracker for the working team.

  • Applications migrated vs planned: per wave, against the baseline plan.
  • Cutovers with rollback: a count, with the cause of each.
  • Incidents during hypercare: number and severity per wave.
  • Monthly AWS spend vs forecast: from Cost Explorer, by tag or account.
  • Legacy decommissioned: servers switched off and contracts ended.

Risks and dependencies

Most delays come from things outside the migration team's control. List them on the plan with an owner and a fallback for each.

Review the list in every weekly status meeting and update it after each wave. A risk that hits during a pilot will hit again in a bigger wave if nobody fixes the cause.

  • Hidden dependencies found during cutover. Fallback: extend discovery with network flow data and test each wave in a rehearsal.
  • Software licenses that do not allow cloud use. Fallback: check terms in week 2 and move affected apps to retain or repurchase.
  • Network bandwidth too low for data transfer. Fallback: order Direct Connect early or use offline transfer for large datasets.
  • Business freeze periods, such as year-end closing. Fallback: build them into the wave calendar from day one.

Common mistakes to avoid

  • Skipping dependency mapping leads to broken apps at cutover, so map connections with discovery tools and confirm them with app owners.
  • Moving workloads before the landing zone is ready creates security debt, so finish guardrails, identity and logging first.
  • Trying to refactor everything delays the exit date, so rehost or replatform most apps and modernize later.
  • Leaving old servers running after cutover doubles the cost, so set a decommission date for every app in the wave plan.
  • Running a cutover without a rehearsed rollback risks a long outage, so rehearse each runbook and name the go or no-go decision maker.
  • Ignoring cost tags makes spend impossible to explain, so enforce tagging rules in the landing zone from day one.

Frequently asked questions

What are the phases of an AWS migration?

AWS describes three stages: assess, mobilize, and migrate and modernize. In practice, plans break these into discovery, business case, landing zone, pilot, migration waves and optimization. Each phase should end with a milestone you can check.

How long does an AWS migration take?

It depends on the number of applications, how many are refactored and how often the business allows change windows. A small estate can move in a few months, while large estates often take a year or more. Plan by waves and adjust after the pilot.

What are the 7 Rs of cloud migration?

They are retire, retain, rehost, relocate, repurchase, replatform and refactor. Each application gets one, based on its value, risk and how much change it needs. The choice drives effort, timing and cost.

What AWS tools help with migration?

AWS Application Migration Service replicates servers for rehosting, and AWS Database Migration Service moves databases. AWS Control Tower sets up a governed multi-account landing zone. Check current AWS documentation for the latest tool options.

What is a migration wave?

A wave is a group of applications that move together in one cutover window. Applications are grouped by dependency, risk and business calendar. Running waves on a regular cadence keeps the plan predictable.

Generate this roadmap with AI