Introduction

One of the most consequential decisions in any enterprise cloud migration is how to migrate each application. The wrong strategy consistently produces suboptimal results. Specifically, applications end up costing more in the cloud than on-premises, deliver inferior performance, or accumulate new technical debt that must be addressed later.

The 6 Rs framework provides a structured decision model for categorizing each application migration approach. It considers business value, technical complexity, and desired cloud outcomes. Furthermore, understanding the first three options — Rehost, Replatform, and Refactor — is essential for any enterprise cloud architect.

This guide explains each migration strategy clearly, identifies which application characteristics make each strategy appropriate, and compares the cost and effort trade-offs. Additionally, it provides a decision framework that enterprise architects can apply to their application portfolio during migration planning.

Rehosting: The Lift-and-Shift Approach

Rehosting moves an application from on-premises infrastructure to cloud infrastructure with minimal or no changes to the application itself. The application code, databases, and application architecture remain essentially unchanged. Consequently, only the underlying infrastructure shifts from on-premises servers to cloud virtual machines or managed infrastructure services.

Rehosting is the fastest migration approach and requires the least technical expertise per application. However, rehosted applications do not typically deliver the full range of cloud benefits. Specifically, they miss the scalability, resilience, and operational efficiency advantages that cloud-native architectures provide.

• Best for: Stable applications with clear infrastructure cost reduction opportunity, applications approaching end-of-life, or applications that will be replaced within 2–3 years.
• Not ideal for: Applications requiring significant performance improvement, applications with scalability challenges, or applications where agility and feature velocity are high business priorities.
• Typical migration timeline: 2–6 weeks per application depending on complexity.
• Cloud cost outcome: Typically 20–30% infrastructure cost reduction compared to on-premises; does not capture the full range of cloud cost optimization opportunities.

Replatforming: Targeted Cloud Optimization

Replatforming makes targeted cloud optimizations to an application without fundamentally rearchitecting its design. Common replatforming changes include moving from self-managed databases to managed database services such as Cloud SQL or Amazon RDS. Additionally, teams might adopt managed container services without changing the application architecture itself.

Replatforming delivers meaningfully better cloud outcomes than pure rehosting without requiring the significant time and cost investment of full refactoring. Consequently, it is particularly effective for applications that have clear, specific cloud optimization opportunities that can be addressed without touching core application business logic.

• Best for: Applications that benefit from specific managed service substitutions but do not require architectural redesign to deliver adequate cloud performance.
• Not ideal for: Applications requiring fundamental architectural improvements for scalability or resilience; these require a Refactor investment.
• Typical migration timeline: 4–12 weeks per application depending on optimization scope.
• Cloud cost outcome: Typically 30–50% total cost of ownership reduction through managed service efficiency gains.

Refactoring: Cloud-Native Rearchitecting

Refactoring redesigns applications to take full advantage of cloud-native architectural patterns. These include microservices, containerization, serverless compute, event-driven architecture, and managed cloud services. Consequently, refactoring delivers the maximum cloud benefits in terms of scalability, resilience, and developer agility.

However, refactoring also requires the greatest time and investment of the three primary migration strategies. Therefore, it is most appropriate for applications that are strategic business assets with high feature velocity requirements. Furthermore, applications with significant scalability or resilience limitations are also strong refactoring candidates.

• Best for: Strategic applications with high business priority, significant scalability requirements, or where cloud-native architecture enables new business capabilities.
• Not ideal for: Applications being retired, low-priority applications, or applications with insufficient business value to justify significant rearchitecting investment.
• Typical migration timeline: 3–12 months per application depending on architectural complexity.
• Cloud cost outcome: Typically 50–70% total cost of ownership reduction with significantly improved scalability and resilience compared to on-premises baseline.

How to Choose the Right Strategy for Each Application

Choosing the right migration strategy for each application requires assessing four factors. First, evaluate business priority — how important is this application to current and future business operations? Next, assess technical debt level — how much architectural work does the application need? Additionally, identify desired cloud outcomes and evaluate available time and budget.

Most enterprises apply a portfolio-level view. Typically, they retire 15–20% of applications (low-value or near-retirement workloads). Furthermore, they rehost 30–40% (stable, low-priority applications) and replatform 25–35% (applications with clear managed service substitution opportunities). Additionally, they refactor 10–20% (strategic applications with high business value). These percentages vary based on portfolio age and technical debt levels.

The Other 3 Rs: Repurchase, Retire, and Retain

The complete 6 Rs framework includes three additional strategies. First, Repurchase replaces an on-premises application with a SaaS equivalent — often the right choice for commodity capabilities. Consequently, HR, finance, or collaboration tools are often strong candidates for replacement with SaaS alternatives.

Additionally, Retire decommissions applications that have no active users or business value — typically 15–20% of enterprise portfolios. Finally, Retain keeps applications on-premises that are not yet ready for cloud migration due to technical, regulatory, or business constraints. Furthermore, retained applications should have a defined plan to address those constraints and migrate in a future wave.

Frequently Asked Questions (FAQs)

Q1: What is the difference between Rehost, Replatform, and Refactor?

A: Rehost (lift-and-shift) moves applications to cloud infrastructure with minimal changes. Replatform makes targeted cloud optimizations without full rearchitecting. Refactor redesigns applications using cloud-native patterns such as microservices and serverless for maximum cloud benefit. Consequently, investment, timeline, and cloud outcomes increase significantly from Rehost to Refactor.

Q2: When should you Rehost vs Refactor an application?

A: Rehost when an application is stable, has clear infrastructure cost reduction opportunity, and is not a strategic priority for architectural improvement. Refactor when an application is a strategic business asset with high feature velocity requirements or significant scalability limitations. Furthermore, refactor when cloud-native architecture enables critical new business capabilities that justify the higher investment.

Q3: What are the 6 Rs of cloud migration?

A: The 6 Rs cloud migration framework categorizes migration strategies as: Rehost (lift-and-shift), Replatform (optimize key components), Refactor (rearchitect for cloud-native), Repurchase (replace with SaaS), Retire (decommission unused applications), and Retain (keep on-premises for applications not yet ready for cloud migration with a defined future migration plan).

Q4: What is cloud-native architecture?

A: Cloud-native architecture designs applications to take full advantage of cloud capabilities. Specifically, it uses microservices that decompose monolithic applications into independently deployable services, containers for consistent packaging and deployment, managed cloud services that eliminate infrastructure management overhead, event-driven patterns for loose coupling, and auto-scaling that adjusts compute capacity automatically based on actual demand.

Q5: What percentage of applications should be refactored vs rehosted?

A: Typical enterprise cloud portfolios allocate roughly 10–20% of applications to Refactor (highest-value strategic applications) and 25–35% to Replatform (clear managed service opportunities). Additionally, 30–40% go to Rehost (stable, lower-priority applications) and 15–20% to Retire (unused or low-value applications). However, actual percentages vary based on portfolio age, technical debt levels, and business strategy.

Conclusion

Choosing the right cloud migration strategy for each application is the highest-leverage decision in enterprise cloud migration planning. Organizations that apply a portfolio-level strategy matrix consistently achieve better cloud outcomes than those applying a one-size-fits-all approach. Furthermore, proper strategy selection maximizes cloud ROI across the entire migration program.

SIDGS helps enterprise cloud programs evaluate their complete application portfolio and recommend the optimal migration strategy for each application. Our cloud architects combine technical assessment with business value analysis to deliver portfolio strategy recommendations that maximize cloud ROI. Contact us to start your migration strategy assessment today.