Introduction
Moving an existing application to the cloud is rarely a single decision — different applications in a portfolio warrant different approaches depending on their business value, technical condition, and urgency. The '6 Rs' is the widely used framework for categorizing these approaches: Rehost, Replatform, Repurchase, Refactor, Retire, and Retain.
Cricket analogy: Just as a franchise doesn't use the same strategy for every player in an IPL auction, some retained, some traded, some released, an enterprise's portfolio of applications each needs its own migration approach based on value and urgency, captured by the 6 Rs framework.
Explanation
Rehost ('lift-and-shift') moves an application to the cloud with minimal or no code changes — typically just moving virtual machines as-is onto cloud infrastructure. It's the fastest strategy but captures the fewest cloud-native benefits, since the application still runs the same way it did on-premises.
Cricket analogy: Rehost is like fielding the exact same playing XI from a domestic league straight into an IPL match with zero tactical changes; it's the fastest way to get on the field but captures none of the tactical advantages a proper IPL-specific game plan would unlock.
Replatform makes a small number of targeted optimizations during the move without changing the application's core architecture — for example, moving a self-managed database to a managed database service while leaving the application code largely untouched. Repurchase means replacing the existing application with a different product, typically a SaaS offering, instead of migrating the old codebase at all (e.g. moving from a self-hosted CRM to a cloud CRM subscription). Refactor (also called re-architect) involves substantially redesigning the application to be cloud-native, such as breaking a monolith into microservices or adopting serverless — it requires the most effort but unlocks the most benefit in scalability and agility. Retire means decommissioning an application that is no longer needed, removing it from the portfolio entirely rather than migrating it. Retain means deliberately keeping an application where it is for now (on-premises), because migrating it isn't yet justified — due to compliance constraints, recent investment, or low priority — while other applications move forward.
Cricket analogy: Replatform is swapping a club's old scoreboard for an electronic one while keeping the same ground and team; Repurchase is switching from a homegrown scoring app to a licensed CricViz subscription; Refactor is rebuilding a team from a Test format into a T20 franchise; Retire is disbanding a defunct club; Retain is keeping a heritage ground unchanged for now.
Example
Portfolio migration plan (the '6 Rs'):
App Strategy Reasoning
---------------------------------------------------------------
Legacy file server -> Rehost Fast lift-and-shift, low value
Order DB (self-hosted)-> Replatform Move to managed DB service
Internal email tool -> Repurchase Switch to SaaS email provider
Core checkout monolith-> Refactor Redesign as microservices
Unused reporting tool -> Retire No longer used, decommission
Finance system -> Retain Compliance blocks migration nowAnalysis
The 6 Rs framework is useful precisely because it discourages a one-size-fits-all migration. Rehost and Replatform prioritize speed and low risk, making them common first steps for large portfolios under time pressure, but they leave cloud-native benefits (elastic scaling, managed services, pay-per-use) largely on the table. Refactor delivers the deepest benefits but is the most expensive and time-consuming, so it's typically reserved for high-value, high-traffic applications where the investment pays off. Retire and Retain are equally important decisions even though neither involves actually moving anything — Retire avoids wasting migration effort on something that should be shut down, and Retain acknowledges that not everything needs to move immediately, or ever. A realistic migration plan applies different Rs to different applications rather than forcing every workload through the same strategy.
Cricket analogy: Rehost and Replatform, like a quick lineup tweak, prioritize getting onto the field fast, leaving deeper tactical upgrades untouched, while Refactor, like fully rebuilding a squad for T20 franchise cricket, suits high-value teams; Retire drops a defunct club and Retain keeps a heritage ground as-is.
Key Takeaways
- The 6 Rs are: Rehost (lift-and-shift), Replatform (small optimizations), Repurchase (switch to SaaS), Refactor/re-architect (redesign as cloud-native), Retire (decommission), and Retain (keep on-prem for now).
- Rehost is fastest but captures the least cloud-native benefit; Refactor captures the most benefit but costs the most effort.
- Retire and Retain are valid migration decisions even though they don't move an application to the cloud.
- A realistic migration plan applies different Rs to different applications based on business value and technical condition, rather than one strategy for the whole portfolio.
Practice what you learned
1. What does the 'Rehost' migration strategy involve?
2. Which migration strategy involves substantially redesigning an application to be cloud-native, such as breaking a monolith into microservices?
3. What does 'Repurchase' mean in the 6 Rs migration framework?
4. In the 6 Rs framework, what does 'Retain' mean?
Was this page helpful?
You May Also Like
Multi-Cloud and Hybrid Cloud
Distinguish using multiple public cloud providers (multi-cloud) from mixing private/on-prem infrastructure with public cloud (hybrid cloud), and why teams choose each.
Cloud Deployment Models
The differences between public, private, hybrid, and community cloud, and the cost, control, and compliance tradeoffs of each.
Virtual Machines in the Cloud
Learn how cloud virtual machines work, how to size them, and how on-demand, reserved, and spot pricing models trade off cost against reliability.
Cost Optimization Basics
Learn concrete cloud cost-optimization levers such as right-sizing, reserved and spot instances, storage tiering, and auto-scaling.