The 6 Rs of Cloud Migration: A Plain-English Guide to Every Strategy
“`html
The 6 Rs of cloud migration are six strategies for moving applications to the cloud: Rehost, Replatform, Refactor, Repurchase, Retire, and Retain. AWS popularized the model, and Azure, Google Cloud, and IBM Cloud have since adopted it in their own migration documentation. The framework gives IT teams a decision model for treating each application differently, because not every workload belongs on the same migration path.
Key Takeaways
- Rehosting moves applications to the cloud with zero code changes, making it the fastest migration path.
- Refactoring redesigns applications to be cloud-native using containers, microservices, or serverless functions.
- Retiring unused applications reduces migration scope and lowers ongoing infrastructure costs.
- Most organizations apply several of the 6 Rs across their portfolio, not just one strategy for everything.
- 75% of organizations plan to rearchitect custom-built applications for the cloud (Gartner, cited in Okta Identity Accelerator white paper).
What is the 6R cloud migration strategy and why does it matter for your business?
The 6 Rs give your business a structured way to make migration decisions application by application. Without this kind of model, organizations tend to apply one blanket approach to every workload, which wastes money on over-engineered migrations or leaves technical debt untouched.
AWS originally developed the framework to help enterprise teams categorize workloads before committing to a migration path. Microsoft Azure and Google Cloud have since adopted similar models in their migration documentation. The six strategies are:
- Rehost — move the application as-is (lift and shift)
- Replatform — move with minor infrastructure adjustments
- Refactor — redesign the application for cloud-native architecture
- Repurchase — replace the application with a SaaS product
- Retire — decommission the application entirely
- Retain — keep the application where it is for now
The right choice depends on your timeline, budget, and how important each application is to your business long term.
What is rehosting in cloud migration and when should you use it?
Rehosting, commonly called lift and shift, moves an application to the cloud without changing its code, architecture, or how it behaves. Rehosting is the fastest migration path available and the lowest risk in terms of application behavior after the move.
Rehosting is the right choice when your team is working against a tight deadline, when your application portfolio is large and you need to move fast, or when cloud cost savings from infrastructure consolidation alone justify the migration. A retail business moving its inventory management system to AWS EC2 to exit a data center lease within 90 days is a practical example of where rehosting delivers real value.
Rehosting doesn’t reduce technical debt or unlock cloud-native performance benefits. An application that ran inefficiently on-premises will likely run inefficiently in the cloud, just on rented hardware. Many teams use rehosting as a first step, planning to optimize later once the workload is in the cloud environment.
📌 Key Fact: Rehosting moves individual workloads to the cloud in days to weeks.
When should I use the Rehost strategy?
Rehosting works best when speed matters more than optimization. Use it for stable, low-complexity applications that don’t need to scale dramatically or integrate deeply with cloud-native services. Rehosting is also a practical choice when your team lacks cloud architecture expertise but needs to exit on-premises infrastructure quickly.
Replatforming: Migrate with Targeted Improvements
Replatforming, sometimes called lift-tinker-and-shift, moves an application with small but meaningful infrastructure adjustments. The core application code doesn’t change, but the environment it runs in gets upgraded to take advantage of cloud services.
A database migration is the clearest example. Instead of rehosting a self-managed MySQL server on a cloud virtual machine, your team migrates it to AWS RDS or Azure SQL Database, a managed service that handles patching, backups, and scaling automatically. The application still connects to a database the same way, but your team stops spending time on database administration.
📌 Key Fact: Replatforming to a managed database service eliminates patching, backups, and manual scaling tasks.
Unlike refactoring, replatforming doesn’t require redesigning how the application is built. It’s purely an infrastructure-level change. The business benefit is moderate effort for meaningful gains in performance, cost efficiency, or manageability. Replatforming is the right middle path for applications that are still actively used and worth improving, but don’t justify a full rebuild.
What is refactoring in cloud migration and what does it involve?
Refactoring, also called re-architecting or rearchitecting, involves redesigning an application’s code and underlying architecture to be cloud-native. It’s the most complex migration strategy, and the one with the highest long-term payoff.
Cloud-native means the application is built to take full advantage of how cloud platforms work. In practice, that often means breaking a monolithic application into microservices, adopting containers managed by AWS Elastic Kubernetes Service or Azure Kubernetes Service, or converting processing jobs to serverless functions on AWS Lambda or Google Cloud Run.
The business case for refactoring is strongest for applications with high scalability demands, persistent performance bottlenecks, or long-term strategic importance. A customer-facing e-commerce platform that needs to handle unpredictable traffic spikes is a good candidate.
📌 Key Fact: Refactoring complex applications into microservices takes three to twelve months.
75% of organizations plan to rearchitect their custom-built applications for the cloud (Gartner, cited in Okta Identity Accelerator white paper). That number signals a real shift in how businesses think about cloud migration. Organizations are moving away from treating migration as a one-time move and toward treating it as an architectural investment.
Refactoring carries the highest upfront cost and requires the most skilled engineering effort. It’s not the right choice for every application, and it’s rarely a good fit for small businesses without dedicated development teams.
Repurchase, Retire, and Retain: The Three Remaining Strategies
These three strategies are frequently underestimated in migration planning, but they can reduce your migration scope and cost significantly before you’ve moved a single workload.
Repurchase means replacing an existing application with a cloud-based SaaS product. SaaS, or Software as a Service, refers to software delivered over the internet and managed entirely by the vendor, without any infrastructure for your team to maintain. If your business runs a self-hosted CRM, replacing it with Salesforce is a repurchase decision. Repurchase trades migration complexity for a subscription cost and removes the burden of maintaining legacy software entirely.
📌 Key Fact: Repurchase eliminates all infrastructure maintenance by replacing legacy software with a vendor-managed SaaS product.
Retire means decommissioning applications that are no longer serving a business need. A legacy reporting tool that three people used five years ago, a duplicate system left over from an acquisition, or an internal portal that’s been replaced by a newer platform are all candidates. Retiring even a handful of applications meaningfully reduces what your team needs to migrate, test, and support.
Retain means keeping an application in its current environment, at least for now. Common reasons include regulatory compliance requirements, low latency needs that cloud connectivity can’t meet, or a recent capital investment in on-premises infrastructure. Retain isn’t failure. It’s a deliberate choice backed by specific business criteria.
What is the cloud migration strategy 6 Rs framework and how do the strategies compare to each other?
Across the six strategies, effort and cloud benefit move in opposite directions at the extremes. Rehosting is fast and low-effort but delivers the least cloud optimization. Refactoring delivers the most long-term value but demands the most time, skill, and budget. Here’s how they compare:
| Strategy | Migration Effort | Time to Migrate | Cloud Benefit Realized |
|---|---|---|---|
| Rehost (Lift and Shift) | Low | Fast (days to weeks) | Low |
| Replatform (Lift and Optimize) | Medium | Moderate (weeks) | Medium |
| Refactor (Re-architect) | High | Slow (months) | High |
| Repurchase (Replace with SaaS) | Medium | Moderate (weeks) | Medium-High |
| Retire / Retain | Low | Immediate | Indirect (scope reduction) |
Most organizations apply all six strategies across their portfolio rather than picking one approach for everything. A realistic migration plan for a business with 30 applications might retire 8, retain 4, rehost 10, replatform 5, repurchase 2, and refactor only 1 or 2 high-priority systems.
📌 Key Fact: Most enterprise cloud migrations run six to eighteen months across planned waves.
How do the 6 Rs of cloud migration differ from the 5 Rs and 7 Rs frameworks?
The 5 Rs is the earlier version of this framework, predating the addition of Retain as a formal strategy. Many organizations still reference it, but the 6 Rs is now the more widely used planning baseline across AWS, Azure, and independent cloud consultancies.
The 7 Rs framework, used in some AWS documentation, adds Relocate as a seventh option. Relocate moves workloads using VMware Cloud on AWS without changing the hypervisor layer, making it useful for organizations with large VMware environments that want to migrate infrastructure without retraining their operations teams.
For most businesses, the 6 Rs is the right starting point. It covers every realistic decision a migration team will face and maps cleanly to the tooling available on major cloud platforms.
How do you choose the right R for each application in your migration plan?
Start your decision process by auditing your application portfolio before committing to any migration strategy. AWS Migration Hub and Azure Migrate both offer tools to assess and categorize applications based on their dependencies, usage patterns, and infrastructure requirements.
Apply these questions to each application:
- Is this application still actively used by your team or customers?
- Does it need to scale significantly in the next two to three years?
- Is there a mature SaaS product that replaces its function?
- Does it carry compliance or data residency requirements?
- How much technical debt does it carry, and how much does that debt cost your team?
Start with Retire and Retain decisions. Removing applications from scope before you plan migration waves reduces complexity, lowers total cost of ownership, and lets your team focus engineering effort where it delivers the most value. Then sequence Rehost and Replatform work to move the bulk of your portfolio efficiently, reserving Refactor for the applications where cloud-native architecture genuinely changes what your business can do.
Frequently Asked Questions About the 6 Rs of Cloud Migration
What is the difference between rehosting and replatforming?
Rehosting moves an application to the cloud exactly as it is, with no changes to code or infrastructure configuration. Replatforming makes targeted infrastructure-level adjustments, like switching a self-managed database to a managed cloud service, without modifying the core application code. Replatforming delivers more operational benefit than rehosting with relatively modest additional effort.
Which cloud migration strategy is best for small businesses?
Rehosting and Repurchase tend to be the most practical strategies for small businesses. Rehosting moves applications quickly without requiring cloud architecture expertise. Repurchase replaces on-premises tools with SaaS products and eliminates infrastructure management entirely. Refactoring typically requires a dedicated engineering team and is better suited to businesses with complex, custom-built applications and long-term scalability goals.
How long does a cloud migration using the 6 Rs take?
Timeline depends on which strategies you apply and how many applications you’re moving. Rehosting individual workloads can take days to a few weeks. Replatforming a database or middleware layer typically takes several weeks. Refactoring a complex application into microservices can take three to twelve months. Most enterprise migrations run in phases over six to eighteen months, applying different Rs to different application groups in planned waves.
Is the Retain strategy a sign that cloud migration failed?
Retain is a deliberate, legitimate business decision, not a fallback. Applications with strict data residency requirements, very recent infrastructure investment, or latency constraints that cloud connectivity can’t meet may be better left on-premises for now. Treating Retain as a planned outcome rather than a missed opportunity keeps your migration budget focused on workloads that actually benefit from moving.
When is refactoring worth the cost and effort?
Refactoring pays off when an application is business-critical, needs to scale unpredictably, or when its current architecture actively limits what your development team can build or how fast they can release updates. For applications that are stable, low-traffic, or approaching end-of-life, the upfront investment in rearchitecting rarely delivers a return that justifies the effort.
“`