Your AWS migration strategy starts with the 7 Rs — applied per application, not per company.

IAn AWS migration strategy is a set of per-application decisions

The phrase "migration strategy" makes it sound like one big choice. It is not. A real strategy is a portfolio of decisions — one disposition per application — plus the sequencing that turns them into waves and the business case that justifies the spend. The 7 Rs are the vocabulary for the first part.

AWS's migration framework — the same one its Professional Services and MAP partners use — breaks any migration into three phases: Assess (do we have the business case and the readiness?), Mobilize (build the landing zone, run a pilot, fix the gaps), and Migrate & Modernize (move the applications in waves). The 7 Rs live in the Assess phase — they are how you classify each application before you move anything.

The reason this matters: a 200-application estate does not get one strategy, it gets a distribution — some apps Retired, some Retained, the bulk Rehosted or Replatformed, a small number Refactored. The skill is assigning the right R to each app, not forcing everything into one favorite R. (Section III gives the realistic distribution.)

Gartner originally framed five Rs; AWS extended the model to seven by adding Relocate (move a whole VMware environment without converting the VMs) and splitting out Repurchase. The seven, in AWS's order, are: Retire, Retain, Rehost, Relocate, Repurchase, Replatform, Refactor — the next two sections take each in turn. One framing to carry through: the right strategy is almost always "less ambitious than engineering wants, more ambitious than finance fears," and the way to hit that balance is migrate-then-modernize (Section V).

IIThe 7 Rs in depth (1–4): Retire, Retain, Rehost, Relocate

The first four Rs cover everything from "do nothing but turn it off" to "move it as-is." These dispositions carry the lowest effort and the lowest risk, and they apply to a surprisingly large share of most estates — run the assessment honestly and the discovery tooling routinely surfaces 10–20% of servers as Retire candidates that are not worth migrating at all.

IIIThe 7 Rs in depth (5–7): Repurchase, Replatform, Refactor

The last three Rs change the application itself — its hosting model, its managed services, or its architecture. They carry more effort and risk, but they are where the durable savings and operational wins come from.

IVPortfolio analysis: how you actually assign the 7 Rs

You do not guess the disposition. You run a discovery + portfolio analysis that gives you the data to assign an R to each application on evidence, not opinion. This is the core of the Assess phase and the first thing a migration partner does.

Discovery comes first. AWS Application Discovery Service (agent-based or agentless via the OVA collector) inventories your servers, captures utilization (CPU, memory, disk, network), and — critically — maps the connections between servers so you can see which machines actually talk to each other. AWS Migration Hub aggregates this into one view and tracks the migration once it starts; for larger estates, partners layer in tooling like Migration Evaluator to model right-sized AWS costs.

With the inventory in hand, each application is scored on a few axes that map cleanly onto a disposition:

• Utilization — Near-zero → Retire. Low and steady → Rehost with aggressive right-sizing. Spiky/elastic → Replatform or Refactor where auto-scaling pays off.
• Business criticality + change appetite — Mission-critical but stable and untouchable → Rehost (do not risk it). Mission-critical and strategic → a Refactor candidate if the architecture is the bottleneck.
• Technical complexity + coupling — Tightly coupled clusters move together as a wave. Heavy interdependence with a system staying behind → Retain until that dependency moves.
• Licensing — Expensive per-core licenses (Oracle, SQL Server) flip the math toward Replatform/Refactor onto Aurora or open-source engines to shed license cost — a major TCO lever.
• Commodity vs differentiator — Commodity function with a SaaS equivalent → Repurchase. Core differentiator → keep it and decide Rehost vs Replatform vs Refactor on the other axes.
• Remaining lifespan — App being sunset within ~12 months → Retain; do not spend migration effort on something you are about to switch off.

The output is a disposition map: every application tagged with one of the 7 Rs, a rough effort estimate, and a dependency-aware grouping. That map drives the wave plan and the business case. A partner produces it in the 2–6 week Assess phase — and under the AWS Migration Acceleration Program, that Assess phase (MAP Assess) is frequently AWS-funded, which is why it often costs you nothing.

VSequencing: migrate-then-modernize, then plan the waves

Once every app has a disposition, two sequencing decisions remain: when to modernize (almost always after the move, not during), and what order to move things in (the wave plan).

Migrate-then-modernize is the sequencing that works. The longer you run in two places, the longer you pay two bills and carry cutover risk — so the priority is exiting the source environment. Rehost or Replatform to get there, capture the savings, then Refactor the high-value apps as scoped, separately-funded projects once real AWS usage data shows where the spend and the bottlenecks actually are. Modernizing during the migration couples two hard problems — moving and rewriting — and is the single most common reason migrations slip by quarters.

Wave planning sequences the actual moves. You do not migrate 200 apps at once; you move them in waves of related applications. The standard shape:

VIBuilding the business case and the TCO model

A migration strategy that cannot be justified financially does not get funded. The Assess phase produces a TCO model and a business case — and this is also where the MAP funding hook does the heavy lifting.

A credible TCO model compares the fully-loaded current cost against the projected AWS cost over a 3-year horizon, and is honest about both sides:

• Current-state cost (often understated) — Not just hardware — data-center space, power, cooling, network, hardware refresh cycles, hypervisor/OS/database licensing, backup/DR infrastructure, and the staff hours spent racking, patching, and babysitting it all. Most teams under-count this badly.
• Future-state AWS cost (model it right-sized) — Right-sized compute (not on-prem-sized VMs), the correct purchase model (Savings Plans/Reserved Instances for steady workloads, On-Demand/Spot for elastic), managed-service costs (RDS/Aurora vs self-managed), data-transfer, and storage tiering. This is where Replatform/Refactor dispositions out-save a flat Rehost.
• One-time migration cost — Assessment, landing-zone build, the migration labor, dual-running overlap (you pay both environments during cutover), and any refactoring projects. This is the number MAP funding is designed to offset.
• Risk + agility (the part finance forgets) — Faster release cycles, elasticity instead of over-provisioning, better resilience/DR, and the avoided cost of the next hardware refresh. Harder to quantify, but often the real reason to migrate.

Realistic outcome: well-executed migrations with right-sizing and selective Replatforming typically land a 20–40% steady-state TCO reduction versus the fully-loaded on-prem cost — more when expensive databases move off per-core licensing. Honest framing: a naive lift-and-shift with no right-sizing can be cost-neutral or even more expensive in month one; the savings come from right-sizing, purchase commitments, and managed services, not the move alone.

Then the funding hook. The AWS Migration Acceleration Program (MAP) is built to de-risk exactly this business case: AWS funds the Assess phase (often free), funds Mobilize (pilot + landing zone), and credits a large share of the Migrate & Modernize cost, with the partner paid through MAP. For qualifying migrations — typically those carrying a meaningful post-migration AWS-spend commitment — this brings the customer's net migration cost to little-or-nothing. Where a migration does not qualify, the value is a vetted partner who de-risks the cutover. CloudRoute tells you which of the two you are looking at, up front.

VIIThe 7 Rs compared — effort, cost, benefit, and when to use each

VIIIThe strategy mistakes that sink migrations

Most failed migrations do not fail on technology — the tools are mature. They fail on strategy decisions made, or skipped, in the Assess phase. The recurring ones:

• Skipping discovery and guessing the dispositions — Assigning Rs from a hand-maintained spreadsheet instead of real utilization + dependency data — then discovering the missing dependencies at cutover, the worst possible time. Run Application Discovery Service first, always.
• Trying to Refactor everything during the migration — The single most common timeline killer. Coupling "move it" with "rewrite it" turns a 6-month migration into an 18-month one. Migrate-then-modernize: move first, refactor high-value apps as funded follow-ons.
• Lift-and-shift with no right-sizing — Rehosting on-prem-sized VMs onto equivalently-sized EC2, then being surprised the AWS bill beats the data center. The savings are in right-sizing and purchase commitments, not the move itself.
• Forgetting to Retire — Migrating dead workloads because nobody checked usage — paying to assess, move, test, and run servers that serve nobody. 10–20% of a typical estate is Retire-able; find it before you move it.
• No wave plan — big-bang cutover — Moving everything in one weekend, with no rollback path that works at that scale. Move in dependency-aware waves behind a pilot-validated runbook.
• Building the business case without the funding — Modelling the migration as a pure self-funded cost, when MAP could fund the Assess phase and credit much of the rest. Many migrations that look "not worth it" on a self-funded TCO clearly are once MAP funding is in the model.
• Treating Retain as forever — Letting "we will do it later" apps sit in a permanent hybrid state, paying for both environments and the connectivity between them indefinitely. Every Retain decision needs a documented revisit date.