Most application migration projects fail the same way: someone picks a single strategy for the entire portfolio, then tries to force every workload into it. Lift-and-shift everything to meet a data centre exit deadline. Refactor everything because someone read a cloud-native manifesto. Retire nothing because no one wants to make the decision.
AWS’s 7 Rs framework exists to prevent that. It recognises that a 20-application portfolio probably needs three or four different migration approaches, and gives you a structured way to decide which applies where.
The framework has taken on new relevance in 2026. The cloud migration market is projected to grow from $232.51 billion in 2024 to $806.41 billion by 2029, a CAGR of over 28%, and AWS reports that TCO reductions of up to 40% are achievable when migrations are planned well. The “planned well” part is where the 7 Rs earn their keep.
The Seven Options
1. Rehost (lift and shift). Move the application to AWS with minimal changes. The workload runs on EC2 largely as it did on-premises. This is the fastest path and the lowest risk, and it’s often the right choice for applications that work fine as they are, need to move quickly, or aren’t worth investing engineering effort into. The trade-off is that you don’t capture most of the cloud-native benefits — scalability, managed services, cost optimisation — until a subsequent modernization pass.
2. Replatform (lift and reshape). Move the application to AWS and make targeted changes to take advantage of cloud capabilities, without rewriting the core. Common examples include moving a self-managed SQL Server database to Amazon RDS, or containerising an application to run on ECS. You get meaningful operational improvements without the cost of a full refactor.
3. Refactor (re-architect). Rewrite the application to be cloud-native. This might mean breaking a monolith into microservices, moving from virtual machines to serverless, or adopting managed services like Aurora or DynamoDB. It’s the most expensive and time-consuming option, but it’s the right call when the application is strategically important and the current architecture is genuinely holding the business back.
4. Repurchase (drop and shop). Replace the application with a SaaS equivalent. If you’re running a self-hosted CRM, email platform, or HR system, the commercial logic for maintaining that infrastructure has usually collapsed. Repurchasing removes the workload from your migration scope entirely.
5. Relocate. Move workloads to AWS without changing anything about them — typically relevant for VMware environments moving to VMware Cloud on AWS or, increasingly, to EC2 via migration services. This is a specialist case, but a highly relevant one in 2026 given the ongoing VMware licensing changes.
6. Retain. Keep the application where it is, for now. Not every workload should move. Applications that are near end-of-life, subject to specific compliance constraints, or tightly coupled to on-premises hardware may not be migration candidates at all. Retaining is an active decision, not a default.
7. Retire. Switch it off. Most application portfolios include systems that no one actually uses, or whose functionality has been absorbed elsewhere. Migration projects are a good forcing function for honest retirement decisions — every workload you don’t migrate is time and money saved.
How to Decide Which R Applies Where
The decision isn’t about the application in isolation — it’s about the intersection of the application, the business context, and the team’s capacity. A workload that technically justifies a refactor might still be a rehost candidate if your engineering team is already stretched and the business needs the move completed this quarter.
A practical assessment considers four dimensions.
Business criticality. How central is this application to revenue and operations? High-criticality applications justify more investment in modernization; low-criticality applications are often better candidates for rehost or retire.
Technical health. Is the codebase maintainable? Are dependencies current? Applications with significant technical debt may benefit more from refactor than rehost — though AI-assisted modernization tooling is changing this calculation, with AWS Transform reportedly accelerating full-stack Windows modernization by up to 5x.
Operational fit. What does the application need that’s easier to deliver in AWS? Scalability, geographic distribution, managed database services, and integration with AI/ML tooling are all reasons to replatform or refactor rather than rehost.
Commercial drivers. Data centre exit deadlines, licensing costs, and M&A timelines all shape what’s realistic. A two-year refactor is not the right answer if your VMware renewal is in four months.
Most portfolios end up with a mix. A typical 50-application assessment might land on roughly 50% rehost, 25% replatform, 10% refactor, 5% repurchase, and 10% retire — though the exact split varies significantly by industry and starting position.
Why Sequencing Matters as Much as Strategy
Even with the right strategy selected per workload, migration order matters. Dependencies between applications mean the sequence affects risk, cost, and user experience. Moving a database before the applications that depend on it creates latency problems. Moving a customer-facing application before its supporting services creates outages.
AWS’s recommended approach is to plan migrations in waves, grouping applications by dependency relationships and business risk tolerance. Low-risk, low-dependency workloads move first to prove the process. Higher-complexity workloads follow once the operational model is established. This is also where agentic AI tooling has started to meaningfully help — AWS reports that automated dependency mapping now achieves up to 99% accuracy on complex application portfolios, removing one of the largest sources of migration risk.
Plan Your Migration With Expert Guidance
As an AWS Premier Tier Services Partner, Opti9 helps organisations assess their application portfolios, apply the 7 Rs framework to each workload, and execute migrations in the right sequence. We bring more than a decade of AWS expertise to the strategic decisions — and the operational capability to run what lands on the other side.
Get in touch today to schedule an AWS migration assessment.
