Every organization eventually reaches the same crossroads: a portfolio of applications, some running on aging on-premises hardware, some half-modernized already, and a mandate to "move to the cloud." The trouble is that "move to the cloud" is not one decision — it's dozens of smaller ones, made application by application.
That's where the 6 Rs framework comes in. Originally popularized by AWS and later adopted across Azure, Google Cloud, and most enterprise architecture practices, the 6 Rs give you a shared vocabulary for deciding what to do with each workload. Instead of treating migration as an all-or-nothing lift, you evaluate each application against six possible paths and pick the one that fits its business value, technical condition, and urgency.
Here's a practical walkthrough of each strategy, when to use it, and how to think about the trade-offs.
1. Rehost — lift and shift
Rehosting means moving an application to the cloud with little or no code change — essentially picking up a virtual machine and setting it down on cloud infrastructure. Tools like AWS Application Migration Service or Azure Migrate automate much of this.
Best for: Applications under time pressure (a data center lease expiring, hardware nearing end-of-life), workloads with unclear long-term value, or a first step in a larger modernization roadmap.
Trade-off: Fast and low-risk, but you carry over any existing inefficiencies — you're not reducing technical debt, just relocating it. Cost savings are often modest until you optimize afterward.
2. Replatform — lift, tinker, and shift
Replatforming makes a few targeted optimizations during the move without changing the core architecture. A common example: migrating a self-managed database to a managed service like Amazon RDS or Azure SQL Database, while leaving the application logic untouched.
Best for: Teams that want quick operational wins — reduced patching burden, better backups, managed scaling — without committing to a full rewrite.
Trade-off: More benefit than rehosting for a similar level of effort, but it requires some testing and validation since you are changing part of the stack.
3. Repurchase — move to a SaaS product
Sometimes the right move isn't migrating your application at all — it's replacing it. Repurchasing means retiring a self-hosted system in favor of a commercial SaaS equivalent, such as swapping a homegrown CRM for Salesforce, or an on-prem email server for Microsoft 365.
Best for: Commodity functions where custom code adds little competitive value — HR systems, CRM, email, ticketing.
Trade-off: Eliminates infrastructure and maintenance overhead, but introduces licensing costs, data migration work, and potential process changes for end users.
4. Refactor / Re-architect — redesign for the cloud
Refactoring is the deepest transformation: rebuilding the application to take advantage of cloud-native capabilities — breaking a monolith into microservices, adopting containers and serverless functions, or redesigning for auto-scaling and resilience.
Best for: Business-critical applications where scalability, agility, or feature velocity genuinely matter, and where the current architecture is holding the business back.
Trade-off: The highest potential payoff — better performance, lower long-term cost, faster development cycles — but also the highest cost, time investment, and risk. Refactoring is usually reserved for applications with a clear strategic reason to justify it.
5. Retire — decommission what you don't need
Not every application deserves a ticket in the migration plan. A cloud migration is a natural moment to audit your portfolio and find applications that are redundant, unused, or replaced by something else already in place.
Best for: Legacy systems with low usage, duplicate tools that emerged from mergers or shadow IT, or anything kept alive "just in case."
Trade-off: Pure upside if done carefully — reduced cost and complexity — but it requires confirming there are no hidden dependencies or compliance reasons the system still needs to exist.
6. Retain — keep it where it is
Some applications simply aren't ready to move, and that's a legitimate strategic choice, not a failure to migrate. Common reasons include regulatory constraints, recent on-premises investment, tight hardware dependencies, or planned retirement in the near future.
Best for: Systems facing imminent replacement, workloads with strict data residency requirements, or applications where the migration cost clearly outweighs the benefit right now.
Trade-off: Avoids unnecessary migration effort but means the application continues to carry on-premises overhead and won't benefit from cloud elasticity or managed services.
How to actually choose
For each application, a useful exercise is to score it against a few dimensions:
- Business criticality — how central is this to revenue or operations?
- Technical condition — is the codebase healthy, or fragile and hard to change?
- Compliance and data constraints — are there residency or regulatory limits?
- Cost of inaction — what does it cost to leave this exactly as it is?
- Migration effort and risk — what would it actually take to move or transform it?
Applications with high business value and poor technical health are your refactor candidates. Applications with low business value and low usage are retire candidates. Everything in between usually falls to rehost or replatform as a pragmatic middle path, while commodity functions are prime repurchase targets.
Most organizations end up using all six strategies across their portfolio simultaneously — migration is rarely a single strategy applied uniformly, but a mix tailored application by application.
Closing thought
The 6 Rs framework isn't about picking the "best" strategy in the abstract — there isn't one. It's a structured way to match each application's realistic constraints to the migration approach that serves it best, so that a cloud migration becomes a series of deliberate, well-reasoned decisions rather than a one-size-fits-all mandate.
Frequently Asked Questions
1. Do I have to use all 6 Rs, or can I pick just one strategy for my whole migration?
You can use just one, but most organizations end up using a mix. A large portfolio typically has some applications suited to rehosting, some to repurchasing, and a smaller set worth refactoring. Applying a single strategy across the board usually means over-investing in low-value apps or under-investing in critical ones.
2. What's the difference between rehost and replatform?
Rehosting moves an application as-is, with no architecture changes. Replatforming makes small, targeted optimizations during the move — like switching to a managed database — without a full redesign. Replatforming takes slightly more effort but usually delivers more operational benefit.
3. How do I decide between refactoring and repurchasing?
Refactor when the application is strategically important and the current architecture limits the business — you need the custom functionality, just built better. Repurchase when the function is a commodity capability (email, CRM, ticketing) that a SaaS product already handles well, so building or maintaining custom code isn't adding real value.
4. Is retaining an application the same as failing to migrate it?
No. Retain is a deliberate decision, usually driven by compliance requirements, recent infrastructure investment, or a planned retirement date. A good migration strategy explicitly accounts for retained systems rather than treating them as leftovers.
5. Which strategy is cheapest, and which delivers the most long-term value?
Rehosting is typically the fastest and cheapest in the short term, but it doesn't reduce technical debt. Refactoring costs the most upfront but tends to deliver the greatest long-term value through lower operating costs, better scalability, and faster feature delivery — which is why it's usually reserved for your most business-critical applications.
Work with eSparks IT Solutions
Planning a project around this? We help businesses across the USA, UK, Canada, Australia and the GCC ship it. Explore our Cloud Computing services and portfolio, estimate your project cost, or book a free call.
Top comments (0)