Migration Strategies: The 6 Rs
Learn the six common migration strategies (the 6 Rs) that organizations use when moving workloads to the cloud, from lift-and-shift to full re-architecture.
By the end of this lesson, you will be able to:
- Name all six migration strategies (the 6 Rs).
- Define each strategy in one sentence and give an example.
- Explain when to choose one strategy over another.
- Identify AWS services that support migration planning.
Why Migration Strategies Matter
Not every application should be migrated the same way. Some can be moved as-is, some need rethinking, some should be replaced, and some should be turned off entirely. The 6 Rs give you a decision framework for each workload in your portfolio.
What to focus on
The key skill is matching a migration scenario to the correct strategy. Focus on the definition and a one-line example for each R.
The 6 Rs
1. Rehost ("Lift and Shift")
Move the application as-is to the cloud with no code changes.
- Fastest migration path.
- Good for: large legacy portfolios where speed matters more than optimization.
- Example: Move an on-premises VM to an EC2 instance with identical configuration.
2. Replatform ("Lift, Tinker, and Shift")
Make a few cloud optimizations without changing the core architecture.
- Slightly more effort than rehost, but captures some cloud benefits.
- Good for: workloads that benefit from managed services without a full rewrite.
- Example: Migrate a self-managed MySQL database to Amazon RDS (managed database), keeping the same schema with no application code changes.
3. Repurchase ("Drop and Shop")
Replace the existing application with a different product, typically SaaS.
- Involves switching to a completely different solution.
- Good for: legacy applications where a modern SaaS product does the job better.
- Example: Replace a self-hosted CRM with Salesforce, or switch a self-managed email server to Microsoft 365.
4. Refactor / Re-architect
Redesign and rewrite the application to be cloud-native.
- Most effort, but captures the most cloud benefits.
- Good for: applications that need to scale massively, adopt microservices, or use serverless.
- Example: Break a monolithic Java application into microservices running on Lambda and DynamoDB.
5. Retire
Decommission the application entirely; turn it off.
- After analyzing your portfolio, some applications are no longer needed.
- Good for: duplicate, end-of-life, or unused applications.
- Example: Shut down a legacy reporting tool that no one uses anymore.
6. Retain ("Revisit Later")
Keep the application as-is in the current environment for now.
- Some applications aren't ready to migrate due to compliance, recent upgrades, or complexity.
- Good for: applications with unresolved dependencies or recent on-premises investments.
- Example: A mainframe application with deep integrations that will be evaluated for migration next year.
Strategy Comparison
| Strategy | Effort | Cloud benefit | When to use |
|---|---|---|---|
| Rehost | Low | Low | Speed matters, migrate fast |
| Replatform | Low–Medium | Medium | Quick wins with managed services |
| Repurchase | Medium | High | Better SaaS product exists |
| Refactor | High | Highest | Need cloud-native scale/features |
| Retire | None | N/A | Application is no longer needed |
| Retain | None | None (yet) | Not ready to migrate now |
No single right answer
Most organizations use a mix of strategies across their application portfolio. The right strategy depends on each application's business value, complexity, and technical constraints.
AWS Migration Services
Two services help with migration planning:
AWS Migration Hub; A single place to track the progress of application migrations across multiple AWS tools. It provides a central dashboard showing which applications have been discovered, planned, and migrated.
AWS Application Discovery Service; Helps you discover on-premises servers, gather configuration data, and understand dependencies between applications. This data feeds into migration planning.
Quick distinction
"Which service helps you track migration progress?" → Migration Hub. "Which service helps you discover on-premises infrastructure?" → Application Discovery Service.
Physical Data Migration: When the Network Isn't Enough
The 6 Rs describe what to do with an application. But they do not address how to move the data itself. When network transfer would take weeks or months, or when the migration window is fixed and non-negotiable, offline physical transfer becomes the right tool. It is not a migration strategy itself — it is the transfer mechanism that enables whichever R you have chosen.
Snowball Edge import lifecycle — the canonical offline migration flow
Online vs Offline data transfer
Use Snowball when…
- Network would take weeks or months for petabyte-scale data
- Migration window is fixed and cannot slip
- Operational risk of long network transfer is unacceptable
- Large-scale planned migration (500 TB+, consider LDMM)
Use online transfer (DataSync / DMS) when…
- Continuous or ongoing replication is needed
- Data volume fits a reasonable network window
- Changes are incremental rather than a one-time bulk move
- Real-time sync between on-prem and cloud is required
Object overwrite pitfall
Importing to an existing S3 bucket can overwrite objects with the same key name. Use a staging bucket or prefix, validate the data before promoting it, and only then unblock downstream workloads that depend on it.
Micro-activity: Match the Migration Strategy
Match each scenario to the correct migration strategy
Examples
Choose one, then match it on the right
Characteristics
Select an example first
0 of 6 matched so far.
Decision Framework
When evaluating a workload, ask these questions in order:
- Is it still needed? → If no, Retire it.
- Is there a better SaaS product? → If yes, Repurchase.
- Does it need major redesign for cloud-native benefits? → If yes, Refactor.
- Can we get quick wins from managed services? → If yes, Replatform.
- Do we just need to move it fast? → Rehost.
- Is it not ready to move at all? → Retain.
Summary
The 6 Rs provide a structured way to decide how to migrate each application. Know each strategy's name, one-sentence definition, and a simple example. Remember that most migrations use a mix of strategies, and AWS Migration Hub + Application Discovery Service support the planning process.