The 6 Rs of Legacy System Modernization
A comprehensive guide to choosing the right migration strategy for each workload, from simple lift-and-shift to complete re-architecture.
Not every legacy system needs the same treatment. The 6 Rs framework (originally from AWS, now industry standard) helps you categorize workloads and choose the right modernization approach for each. The right strategy balances cost, risk, speed, and long-term maintainability.
1. Rehost (Lift and Shift)
Rehosting means moving applications to the cloud without modification. You're essentially running the same application on cloud infrastructure instead of on-premise servers.
When to Rehost
Rehosting is ideal when: you need to migrate quickly (data center exit), the application is stable and doesn't need changes, you want to reduce infrastructure costs first and optimize later, or the business case for modernization isn't clear yet.
Pros & Cons
Pros: Fastest migration path (weeks vs. months), lowest risk, minimal skills required. Cons: Doesn't optimize for cloud, may have higher ongoing costs, technical debt remains, limited cloud-native benefits.
2. Replatform (Lift and Optimize)
Replatforming makes some cloud optimizations without changing the core architecture. Common examples include moving to managed databases, containerizing applications, or enabling auto-scaling.
When to Replatform
Choose replatforming when: you want cloud benefits (managed services, scaling) without full re-architecture, the application will run for 3-5+ more years, you have time and budget for some optimization, or specific pain points (database management, scaling) can be addressed.
Common Replatform Moves
Moving databases to managed services (RDS, Cloud SQL), containerizing applications with Docker/Kubernetes, implementing auto-scaling, switching to managed messaging/caching, enabling cloud-native monitoring.
3. Repurchase (Drop and Shop)
Repurchasing means replacing your custom or legacy application with a commercial SaaS solution. Instead of migrating, you buy an existing product that solves the same problem.
When to Repurchase
Repurchasing makes sense when: the functionality isn't a competitive differentiator (HR, CRM, ERP), maintaining the system costs more than SaaS licensing, modern SaaS solutions are significantly better, or you lack the team to maintain the current system.
Considerations
Data migration and integration are still significant efforts. Evaluate total cost of ownership, not just licensing. Plan for change management—users will need to learn new systems. Consider customization limits of SaaS platforms.
4. Refactor (Re-architect)
Refactoring means re-architecting applications to be cloud-native—typically breaking monoliths into microservices, adopting serverless, or rewriting significant portions.
When to Refactor
Refactoring is worth the investment when: the application is strategic and will be used for 5-10+ years, you need scalability/performance that current architecture can't provide, you want to accelerate feature development, or the cost of maintaining the current system exceeds refactoring cost.
Approaches to Refactoring
Strangler pattern: Gradually replace pieces of the monolith while keeping the system running. Microservices extraction: Pull out bounded contexts into independent services. Serverless transformation: Replace components with functions-as-a-service.
5. Retire (Decommission)
Retiring means shutting down applications that are no longer needed. This is often overlooked but can provide significant savings and reduce complexity.
Identifying Retirement Candidates
Look for applications with: few or no active users, functionality duplicated elsewhere, data that can be archived, unsupported technology with high risk, or costs that exceed value delivered.
Retirement Process
Confirm the application is truly unused (monitor traffic), extract and archive any valuable data, communicate with stakeholders, plan for data retention requirements, and sunset gracefully with proper documentation.
6. Retain (Revisit Later)
Retaining means keeping applications on-premise or in their current state, at least for now. This is a deliberate decision to defer migration.
When to Retain
Retain applications when: they have compliance requirements that prevent cloud migration, the cost of migration exceeds benefits, they're scheduled for retirement within 1-2 years, or dependencies on other systems haven't been migrated yet.
Retain ≠ Ignore
Retained applications still need maintenance and security updates. Set a revisit date to reassess the decision. Document why the application was retained and what would need to change.
Choosing the Right Strategy
For most organizations, the portfolio will include a mix of strategies. Use a decision framework that considers: business value and strategic importance, technical complexity, dependencies, required skills, timeline, and risk tolerance.
Key Takeaways
No One-Size-Fits-All
Different applications need different strategies. Assess each workload individually.
Start with Rehost
Rehosting is often a good first step—get to cloud quickly, optimize later.
Don't Forget Retire
Up to 20% of applications can often be retired, providing immediate savings.
Business Value Drives Decisions
Invest in refactoring for strategic applications; rehost or retire the rest.
Frequently Asked Questions
How do I decide between replatform and refactor?
Consider the application's expected lifespan and strategic importance. If it will run for 3-5+ years and is moderately important, replatform. If it's a core system that will run 5-10+ years and needs significant capability improvements, refactor. Also consider your team's skills and timeline.
What percentage of applications typically go to each R?
A typical distribution might be: Rehost 30-40%, Replatform 20-30%, Refactor 10-20%, Repurchase 5-10%, Retire 10-20%, Retain 5-15%. This varies significantly by organization maturity and strategic priorities.
How long does each strategy take?
Rough timelines: Rehost (2-4 weeks per application), Replatform (1-3 months), Refactor (6-18 months for significant systems), Repurchase (3-6 months including data migration), Retire (1-2 months for proper decommission).
What skills do we need for each approach?
Rehost: Infrastructure/ops skills. Replatform: Platform engineering, containers. Refactor: Strong software engineering, architecture, DevOps. Repurchase: Integration, data migration, change management. The more ambitious the strategy, the more specialized skills required.
Need Help Choosing Your Strategy?
Our team can assess your application portfolio and recommend the right modernization approach for each workload.
Request Assessment