The 6 Rs of Cloud Migration
Decision framework per application.
The 6 Rs of Cloud Migration
AWS defines six migration strategies — the "6 Rs" — that categorize how applications move to the cloud. Understanding which strategy fits each application is the first and most important decision in any cloud migration program.
The Six Strategies
| Strategy | Effort | Timeline | Cloud Optimization |
|---|---|---|---|
| Rehost (Lift & Shift) | Low | Weeks | Low |
| Replatform (Lift & Reshape) | Medium | Weeks-Months | Medium |
| Repurchase (Replace) | Low-Medium | Weeks-Months | High |
| Refactor (Re-architect) | High | Months | High |
| Retire | None | Immediate | N/A |
| Retain | None | N/A | N/A |
1. Rehost (Lift and Shift)
Move applications to the cloud with minimal changes — essentially running the same OS, middleware, and application on cloud infrastructure.
- When: Legacy applications, tight timeline, low risk tolerance
- Tools: AWS Application Migration Service, CloudEndure
- Example: Move a Windows Server IIS application to EC2
- Savings: 10-20% from right-sizing and reserved instances
2. Replatform (Lift and Reshape)
Make targeted optimizations during migration without changing the core application architecture.
- When: Databases, middleware that have managed equivalents
- Examples: Self-managed MySQL → RDS MySQL, Self-managed Redis → ElastiCache
- Savings: 20-40% from reduced operational overhead
3. Repurchase (Replace)
Replace existing applications with SaaS alternatives.
- When: COTS software with cloud-native alternatives
- Examples: On-prem email → Microsoft 365, On-prem CRM → Salesforce
- Consideration: Data migration, user retraining, integration changes
4. Refactor (Re-architect)
Re-architect applications to take full advantage of cloud-native capabilities.
- When: Strategic applications that need scalability, business agility
- Examples: Monolith → microservices on ECS/EKS, Batch processing → Lambda
- Savings: 40-70% from elasticity, serverless, and managed services
5. Retire
Identify applications that can be decommissioned.
- When: Duplicate functionality, unused applications, end-of-life
- Savings: 100% — eliminate infrastructure and license costs
- Typical finding: 10-20% of applications in a portfolio are candidates for retirement
6. Retain
Keep applications on-premises for now.
- When: Regulatory requirements, deep hardware dependencies, recently purchased licenses
- Plan: Revisit in 1-2 years as requirements change
Decision Framework
For each application, evaluate:
1. Business criticality? (High → consider Refactor)
2. Time constraint? (Tight → Rehost)
3. Managed service available? (Yes → Replatform)
4. SaaS replacement? (Yes, good fit → Repurchase)
5. Still needed? (No → Retire)
6. Migration blocked? (Yes → Retain)Typical Migration Portfolio
- Rehost: 40% of applications (quick wins, bulk of the estate)
- Replatform: 20% (databases, middleware)
- Refactor: 10% (strategic, revenue-generating apps)
- Repurchase: 10% (COTS replacements)
- Retire: 15% (unused or duplicate)
- Retain: 5% (migration blockers)
Eazy SaaS Tip: We start every migration with a portfolio assessment, categorizing each application into one of the 6 Rs. This prevents the common mistake of trying to refactor everything (too slow) or rehosting everything (missed optimization). The right mix typically completes migration 40% faster.