The AWS 7R Migration Framework Explained — Which Strategy Is Right for Your SaaS Workloads?

The biggest mistake in cloud migration is not choosing the wrong cloud provider. It’s applying the same migration strategy to every workload, regardless of what each workload actually needs.

When Amazon Web Services formalized the cloud migration strategy 7R framework, it was acknowledging something that experienced cloud architects had known for years: there is no single right way to migrate to the cloud. A legacy CRM that hasn’t been touched in five years needs a fundamentally different approach than a microservices-based order management system that your engineering team deploys to 30 times per week.

For SaaS companies in the growth stage — particularly those in FinTech, HealthTech, and E-commerce — migration decisions carry real commercial risk. Getting the strategy wrong for a mission-critical workload means downtime, data migration failures, performance degradation, or a post-migration bill that’s higher than what you were paying on-premises. None of these outcomes is acceptable when you’re trying to scale.

This guide explains all seven strategies in plain language, tells you which workloads each applies to, and gives you the decision framework to assign the right migration path to every application in your portfolio.

---

Why the Migration Strategy You Choose Matters More Than You Think

Most cloud migration horror stories share a common root cause: the team applied a lift-and-shift approach (taking an application and moving it to cloud with minimal changes) to workloads that were fundamentally incompatible with that approach. They moved the application, but they also moved all of its architectural problems — and then paid cloud prices for on-premises performance.

The cloud migration strategy 7R framework exists to prevent exactly this outcome. By forcing a deliberate, workload-by-workload strategy decision before migration begins, the 7R framework ensures that each application is migrated in the way that maximizes its value on AWS — whether that means moving it unchanged, modernizing it, replacing it, or retiring it entirely.

---

The 7 Strategies — Explained

1. Retire

The most underrated strategy in the framework. Before migrating anything, ask: does this application still need to exist? A surprising percentage of enterprise application portfolios — often 10–20% — contain applications that are no longer actively used, have been replaced by other systems, or are being maintained purely because nobody has made the decision to shut them down.

Retiring applications before migration reduces migration scope, eliminates ongoing cloud costs for those workloads, and simplifies the architecture of the environment you’re building on AWS.

Action: Before scoping your migration, run an application usage audit. Any application with fewer than 10 active users per month or no active business process dependency is a retirement candidate.

2. Retain

Some applications genuinely should not move to cloud yet — or ever. Applications with regulatory requirements that mandate on-premises data residency, applications mid-way through a replacement cycle, or applications where the migration cost exceeds the benefit are candidates for retention. Retain means leaving them where they are, intentionally, with a documented rationale and a defined review date.

The key word is intentional. Retain is not ‘we’ll get to this later.’ It is a deliberate strategic decision with a documented reason.

3. Rehost (Lift and Shift)

Rehosting moves an application to AWS with no changes to the application architecture. The application runs on EC2 instances that mirror its on-premises configuration as closely as possible. This is the fastest migration path and the lowest-risk approach for applications that need to move quickly.

Best for: applications with near-term decommission plans for on-premises infrastructure, applications where the business cannot tolerate extended migration timelines, and applications that will be modernized in a second phase after initial migration.

Not for: applications where the performance problems or architectural limitations are inherent — rehosting them moves the problems to cloud without solving them.

4. Relocate

Relocate is a variant of rehost specific to VMware workloads. It migrates VMs from on-premises VMware infrastructure to VMware Cloud on AWS — preserving the VMware tooling, skills, and operational processes your team already has while gaining the scalability and global reach of AWS infrastructure.

Best for: organizations with large VMware estates, significant VMware expertise, and a need to migrate quickly without re-platforming.

5. Repurchase

Repurchase means replacing your current application with a SaaS alternative. Instead of migrating your on-premises CRM to AWS, you move to Salesforce. Instead of migrating your on-premises HR system, you move to Workday. The application infrastructure moves off your responsibility entirely.

Best for: commodity business applications (CRM, ERP, ITSM, HR) where a well-established SaaS alternative exists and the migration effort for the existing application exceeds the switching cost.

For SaaS companies specifically: be careful about repurchasing tools that integrate deeply with your product. The operational simplicity of a SaaS alternative can be offset by integration complexity and data portability limitations.

6. Replatform (Lift, Tinker, and Shift)

Replatforming makes targeted optimizations to an application during migration — without fundamentally changing the application architecture. Classic examples: migrating a self-managed MySQL database to Amazon RDS (moving to a managed service without changing the application), or moving a Java application to AWS Elastic Beanstalk for managed deployment without rewriting the application logic.

Best for: applications where specific components (database, deployment, scaling) can be improved with managed services without requiring full re-architecture, and where the operational benefit justifies the additional migration complexity.

7. Refactor / Re-architect

Refactoring involves re-imagining and re-building an application to be cloud-native — decomposing monoliths into microservices, adopting serverless architectures, containerizing with ECS or EKS, and building CI/CD pipelines for automated deployment. This is the most complex and time-intensive migration strategy — and it delivers the highest long-term return.

Best for: applications that are central to your competitive differentiation, applications where architectural limitations are actively slowing your development velocity, and applications where the performance, scalability, or cost profile of the current architecture is becoming a strategic problem.

Not for: every application. Refactoring every workload is expensive, slow, and risky. Apply it selectively to the applications where cloud-native architecture creates genuine business value.

---

The Decision Framework — Which Strategy for Which Workload?

Apply this decision tree to every application in your portfolio before scoping migration:

1. Is this application still actively used and needed? → No: Retire. Yes: Continue.
2. Does this application have regulatory, technical, or contractual reasons to stay on-premises? → Yes: Retain with review date. No: Continue.
3. Is this application a commodity business function with a strong SaaS alternative? → Yes: Evaluate Repurchase. No: Continue.
4. Is the application VMware-based and your team has strong VMware expertise? → Yes: Consider Relocate. No: Continue.
5. Is this application central to your product or competitive differentiation? → Yes: Evaluate Refactor. No: Continue.
6. Can specific components (database, deployment) be improved with managed services without re-architecture? → Yes: Replatform. No: Rehost and modernize in phase two.

---

Common Mistakes When Applying the 7R Framework

Applying Rehost to everything. Speed is not the only migration objective. Rehosting an application with fundamental architectural problems moves those problems to cloud — it doesn’t solve them.

Under-investing in the Retire step. Every application you don’t retire before migration is an application you’ll pay cloud costs for indefinitely. The Retire audit is the highest-ROI hour of your migration planning process.

Refactoring too much too fast. Refactoring is high-value but high-cost. Trying to refactor your entire application portfolio simultaneously creates migration risk, developer burnout, and scope creep. Prioritize ruthlessly.

Skipping the Migration Readiness Assessment. Applying the 7R framework without first mapping application dependencies, data flows, and integration points produces a strategy on paper that can’t be executed in practice.

---

Sequencing Your Migration Waves

Once every application has a 7R strategy assigned, sequence the migration into waves based on complexity, business criticality, and dependency mapping:

• Wave 1 — Retire and Repurchase: decommission and replace before any migration work begins. Reduces scope and complexity.
• Wave 2 — Rehost and Relocate: low-complexity migrations first. Build team confidence, tooling, and process before tackling complex workloads.
• Wave 3 — Replatform: moderate complexity. Managed service adoptions that improve operations without full re-architecture.
• Wave 4 — Refactor: highest complexity. Reserve for last — after your team has migration experience, your cloud environment is governed, and your architecture decisions are informed by real usage data