AWS migration strategy: the 7 Rs, decided per application.
There is no single migration strategy. There are seven choices (the 7 Rs: Retire, Retain, Rehost, Relocate, Repurchase, Replatform, Refactor), and the work is picking the right one for each application. The pattern that works: move first with Rehost or Replatform, then Refactor the few apps where it pays back.
- The 7 Rs are per-application choices: Retire (turn it off), Retain (leave it for now), Rehost (lift-and-shift), Relocate (move a whole platform layer, such as VMware), Repurchase (switch to SaaS), Replatform (move and swap in managed services), Refactor (re-architect). Most estates are mostly Rehost and Replatform, with Refactor for the few apps where it pays back.
- Migrate, then modernize: Rehost or Replatform first to leave the old environment and stop paying twice, then Refactor selectively once you have real AWS usage data. Refactoring everything during the move is the most common way migrations blow their timeline.
- A partner can run the assessment that assigns the Rs and then run the migration. If the migration qualifies, your matched partner can file MAP funding: typically $50K to $150K for startups. Depends on the workload; AWS approves.
IA migration strategy is a set of per-application decisions
A real strategy is a portfolio of decisions (one R per application), the sequence that turns them into waves, and the business case that justifies the spend.
AWS runs larger migrations through the Migration Acceleration Program (MAP) in three phases: Assess, Mobilize, and Migrate and Modernize. The 7 Rs belong to Assess: they are how you classify each application before anything moves.
A large estate does not get one strategy, it gets a mix: some apps retired, a few retained, most rehosted or replatformed, a handful refactored. The skill is matching each app to the right R, not forcing everything into a favourite.
IIThe 7 Rs, from lowest to highest effort
The first four change little or nothing about the application. The last three change its hosting, its managed services or its architecture, which is where the lasting savings come from.
1. Retire: turn it off
Nobody uses it, or another system replaced it. Decommission it instead of migrating it. Every retired server is one you never assess, move, test or run. Usage and dependency data give you the confidence to switch it off.
2. Retain: leave it where it is, for now
Choose it for a hard residency or compliance constraint, a system with no clean cloud path, an app being sunset soon, or a dependency that must move first. Always set a revisit date, or "temporary" hybrid becomes permanent.
3. Rehost: lift and shift
Move the app unchanged onto EC2, usually with AWS Application Migration Service (MGN), which replicates servers continuously and lets you cut over in a short window. It is the fastest way out of a data centre or another cloud. The catch: if you do not right-size, cloud VMs sized like old hardware can cost more than the source.
4. Relocate: move the platform layer as it is
Move a whole virtualised or containerised layer without converting each workload, for example a VMware estate or a Kubernetes cluster moved to EKS with minimal changes. Fast, but plan the next step or you keep paying for the old layer.
5. Repurchase: switch to a SaaS product
Replace a self-hosted commodity tool (CRM, ticketing, email) with SaaS and move the data. It removes the workload from your bill and your ops load. The risks are data fidelity and integration gaps.
6. Replatform: lift, tinker and shift
Keep the code, but swap parts for managed services: self-managed databases to Amazon RDS or Aurora, VMs to containers on ECS (ECS Express Mode for simple web services; App Runner closed to new customers on April 30, 2026), a load balancer instead of a hand-built one. You stop doing patching, backups and failover yourself. Same-engine database moves stay Replatform; an engine change (Oracle to Aurora PostgreSQL) needs the Schema Conversion Tool and is closer to Refactor in effort.
7. Refactor: re-architect for the cloud
Split a monolith, move to serverless (Lambda, API Gateway, EventBridge, DynamoDB) or adopt EKS. Highest effort and risk, with the biggest possible payoff in scale, speed and running cost. Only worth it when the architecture is the bottleneck. Refactoring an app that works and is cheap to run wastes money.
IIIPortfolio analysis: assigning an R to each application
Do not guess. Collect usage and dependency data, then score each application.
Start with discovery: an inventory of servers, their real utilisation, and which machines talk to each other. AWS Migration Hub and Application Discovery Service closed to new customers on November 7, 2025; AWS now points new users to AWS Transform for discovery and planning, and Migration Evaluator builds a business case at no cost.
- Utilisation: Near zero: Retire. Low and steady: Rehost with right-sizing. Spiky: Replatform or Refactor where autoscaling pays.
- Criticality and appetite for change: Critical but stable: Rehost, do not risk it. Critical and strategic with an architectural bottleneck: a Refactor candidate.
- Coupling: Tightly coupled apps move together in one wave. Heavy dependence on something staying behind: Retain until it moves.
- Licensing: Expensive per-core licences (Oracle, SQL Server) push toward Replatform or Refactor onto Aurora or open-source engines.
- Commodity or differentiator: Commodity with a SaaS equivalent: Repurchase. Differentiator: decide between Rehost, Replatform and Refactor on the other axes.
- Remaining lifespan: Being sunset soon: Retain. Do not spend migration effort on something you are about to switch off.
IVSequencing: migrate first, then modernize, in waves
Once each app has an R, two decisions remain: when to modernize (after the move) and in what order to move things (waves).
Migrate, then modernize. Every month you run in two places you pay two bills and carry cutover risk. Rehost or Replatform to get out, then Refactor high-value apps as scoped follow-on projects once real AWS usage shows where the cost and bottlenecks are.
Waves. First the foundation (a multi-account landing zone, identity, networking, logging, security baseline). Then a small, representative pilot that proves the runbook end to end. Then production waves grouped by dependency, easier ones first, tightly coupled systems and cross-engine database moves later.
VThe business case: be honest on both sides
A strategy that cannot be justified financially does not get funded. Compare fully loaded current cost with right-sized AWS cost.
- Current cost (usually understated): Hardware, space, power, network, refresh cycles, licences, backup and DR, and the staff hours spent running it all.
- Future AWS cost (model it right-sized): Right-sized compute, the right purchase model (Savings Plans for steady workloads), managed services, data transfer and storage tiers.
- One-time migration cost: Assessment, landing zone, migration labor, the period you pay for both environments, and any refactoring.
- Speed and resilience: Faster releases, elasticity instead of over-provisioning, better recovery, and the hardware refresh you no longer buy.
AWS reports on its MAP page that customers migrating legacy applications achieve an average of 31% infrastructure savings. Treat that as AWS's average, not your forecast: savings come from right-sizing, commitments and managed services, not from the move alone.
VIWho files the funding
MAP is filed by an AWS partner, not by you. Activate is the other way round.
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. Small moves may not qualify; the partner tells you before you commit.
CloudRoute matches you with one vetted partner who can run the assessment and the migration. Startups pay CloudRoute nothing; partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.
| Funding | Who files it | Amount | When it fits |
|---|---|---|---|
| Migration Acceleration Program (MAP) | Your matched AWS partner | $50K to $150K for startups. Depends on the workload; AWS approves. | You are not on AWS yet and want to migrate. |
| Proof of concept (POC) funding | Your matched AWS partner | $50K to $150K for startups. Depends on the workload; AWS approves. | You want to test something, whether or not you are on AWS today. |
| Incremental workload (IW) funding | Your matched AWS partner | $50K to $150K for startups. Depends on the workload; AWS approves. | You are already on AWS and are launching new work: a new AI feature, a new customer or a new contract. |
| AWS Activate Founders | Founder applies | $1,000 to start, up to $5,000 | Self-funded startups with no investor or accelerator behind them. |
| AWS Activate Portfolio | Founder applies | up to $200,000 | Startups backed by a VC firm, accelerator or angel investor that is an AWS Activate Provider. |
| AWS Credits for AI Startups | Invite only (AWS account manager) | $200,000 or more, by invitation | AI startups ready to scale after Activate Portfolio, invited by AWS. |
VIIThe 7 Rs compared
| R | What changes | Effort | Migration cost | Cloud-native benefit | Choose when |
|---|---|---|---|---|---|
| Retire | Nothing; you switch it off | Lowest | You save | n/a | No real usage |
| Retain | Nothing yet | None now | None now | None yet | Compliance, dependency or sunset soon |
| Rehost | Host only (VM to EC2 via MGN) | Low | Lowest | Low until right-sized | Fast exit; stable app |
| Relocate | Platform layer moved as is | Low | Low | Low | Large virtualised or containerised estate |
| Repurchase | The product (to SaaS) | Moderate | Data and integration work | Off your bill | Commodity app with mature SaaS |
| Replatform | Some components (database to RDS or Aurora, VM to ECS) | Moderate | Moderate | Real ops savings without a rewrite | Most web and app workloads |
| Refactor | The architecture | Highest | Highest up front | Highest | Architecture is the bottleneck |
VIIIThe strategy mistakes that sink migrations
Migrations rarely fail on tooling. They fail on decisions made, or skipped, during assessment.
- Guessing the Rs: Assigning dispositions from a spreadsheet instead of real usage and dependency data, then finding the missing dependency at cutover.
- Refactoring everything during the move: Coupling "move it" with "rewrite it" turns months into quarters. Move first, refactor high-value apps afterwards.
- Lift-and-shift without right-sizing: Copying old-hardware sizes onto EC2 and then being surprised by the bill.
- Forgetting to Retire: Paying to move and run servers nobody uses. Check usage first.
- Big-bang cutover: Moving everything in one weekend with no rollback that works at that scale. Use dependency-aware waves behind a proven pilot.
- Retain forever: Every Retain decision needs a revisit date, or you pay for both environments and the link between them indefinitely.
Rehost vs Replatform vs Refactor
Retire, Retain, Relocate and Repurchase are usually obvious after discovery. For most of your estate the real choice is among these three.
| Variable | Rehost (lift-and-shift) | Replatform (lift, tinker, shift) | Refactor (re-architect) |
|---|---|---|---|
| Code changes | None | Minimal (config and managed-service swaps) | Significant |
| Primary tools | MGN | MGN, RDS or Aurora, ECS | Lambda, EKS, DynamoDB, API Gateway |
| Steady-state cost | Like the source (lower if right-sized) | Lower (managed services, right-sizing) | Potentially lowest |
| Operational burden | Same as before | Lower (AWS runs the database and load balancer) | Lowest |
| Risk | Low (roll back to source) | Moderate (database and connection changes) | High (it is a software project) |
| Best for | Fast exit; stable apps | Most web and app workloads | Apps where the architecture is the bottleneck |
How a match works (example)
- You tell us about the work
You fill in a short form: what you run today, what you want to move, test or build, your stage and your region.
- We pick one partner
We read your answers and pick one vetted AWS consulting partner that fits the work, the stack and the region. We reply within 24 hours; your matched partner reaches out within 5 business days.
- The partner checks MAP funding
Your matched partner scopes the migration with you. Then it checks whether the move qualifies for MAP (Migration Acceleration Program) funding. MAP is for teams that are not on AWS yet.
- The partner files, AWS decides
If the work qualifies, the partner files the funding request with AWS. AWS reviews it and decides. The amount depends on the workload.
- You pay nothing
CloudRoute is free for startups. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.
AWS Activate credits are separate, and you apply for them yourself. Use Activate Founders if no investor backs you. Use Activate Portfolio with the Org ID or invite from your VC, accelerator, incubator or angel group if it is an Activate Provider. A consulting partner cannot apply for Activate on your behalf.
Common questions
What are the 7 Rs of cloud migration?
Which of the 7 Rs should I use?
What is the difference between Rehost, Replatform and Refactor?
What does migrate-then-modernize mean?
How much can an AWS migration save?
Does AWS pay for the migration through MAP?
Can we build the strategy ourselves?
Get the 7 Rs assigned to your estate by a partner who can run the move
CloudRoute matches you with one vetted AWS partner who runs the assessment (discovery, portfolio analysis, cost model, wave plan), then the migration, and files MAP funding when the migration qualifies and AWS approves. CloudRoute is free for startups.