The 7 Rs of Cloud Migration: Choosing the Right Strategy for Your Legacy Apps

Migrating a legacy application to the cloud is not a single technical decision.

The first question is usually, “Which cloud should we move to?”

But the more important question is:

What should we do with the application before we move it?

Some legacy applications can be moved with minimal changes. Others need modernization. Some should be replaced entirely, while others should not be migrated at all.

This is where the 7 Rs of cloud migration provide a useful framework.

The 7 Rs help organizations evaluate each application and choose the migration strategy that makes the most sense based on cost, complexity, business value, and long-term goals.

Two strategies are often confused: Rehosting and Refactoring.

One focuses on moving quickly. The other focuses on redesigning for the cloud.

Understanding the difference is critical because choosing the wrong approach can increase migration costs and create unnecessary technical debt.

What Are the 7 Rs of Cloud Migration?

The 7 Rs provide a framework for deciding how each application should be handled during a cloud migration.

The strategies are:

1. Rehost
2. Replatform
3. Repurchase
4. Refactor or Re-architect
5. Retire
6. Retain
7. Relocate

Not every application should follow the same path.

A large migration program may involve several strategies running at the same time. One application may be rehosted to meet a tight migration deadline, while another may be refactored to improve scalability and performance.

The right strategy depends on the application.

1. Rehost: Move the Application With Minimal Changes

Rehosting is often called lift and shift.

The application is moved from its existing environment to the cloud with minimal changes to its architecture.

For example, a virtual machine running an application in a data center may be migrated to a cloud virtual machine with the same basic operating model.

When Rehosting Makes Sense

Rehosting may be suitable when:

• The organization needs to migrate quickly
• The application is stable
• Major changes are not currently required
• Data center exit timelines are approaching
• The application needs further assessment before modernization

The biggest advantage of rehosting is speed.

Organizations can move workloads to the cloud without spending months redesigning every application.

The Limitation of Rehosting

Rehosting does not automatically make an application cloud-native.

The same architecture, operational limitations, and inefficiencies may continue in the new environment.

For example, an oversized legacy application moved directly to the cloud may continue consuming more infrastructure than necessary.

Rehosting should therefore often be viewed as a migration strategy, not necessarily a final modernization strategy.

2. Replatform: Make Targeted Changes for the Cloud

Replatforming sits between rehosting and refactoring.

The application is moved to the cloud, but selected components are modified to take advantage of cloud services.

For example, an organization may move an application to the cloud while replacing a self-managed database with a managed database service.

The core application may remain largely unchanged.

When Replatforming Makes Sense

Replatforming can work well when:

• The organization wants some cloud benefits without a complete redesign
• Specific infrastructure components create operational overhead
• Managed services can improve efficiency
• The application does not justify a major refactoring effort

It provides a middle ground between speed and modernization.

3. Repurchase: Replace the Existing Application

Repurchasing means replacing an existing application with a SaaS or cloud-based alternative.

Instead of migrating and maintaining a legacy system, the organization adopts a new product.

For example, an on-premises business application may be replaced with a SaaS platform.

When Repurchasing Makes Sense

Consider repurchasing when:

• The existing application has limited business value
• Maintaining it has become expensive
• A suitable SaaS alternative already exists
• The organization wants to reduce operational responsibility

The main consideration is not whether the application can be migrated.

It is whether it should continue to exist in its current form.

4. Refactor: Redesign the Application for the Cloud

Refactoring, also called re-architecting, involves making significant changes to the application so it can take better advantage of cloud capabilities.

This may involve redesigning components for scalability, resilience, automation, or managed cloud services.

For example, a monolithic application may gradually be redesigned into more modular services.

When Refactoring Makes Sense

Refactoring may be appropriate when:

• The application is strategically important
• Scalability requirements are increasing
• The existing architecture limits growth
• Performance or reliability issues need to be addressed
• The organization expects long-term cloud usage

Refactoring can deliver greater long-term benefits, but it also requires more time, investment, and planning.

This is why it should not be the default strategy for every application.

Rehosting vs. Refactoring: The Key Difference

The difference comes down to the amount of change.

Rehosting	Refactoring
Minimal application changes	Significant architectural changes
Faster migration	Longer migration process
Lower upfront migration effort	Higher upfront engineering effort
Useful for data center exits	Useful for long-term modernization
Existing architecture largely remains	Architecture is redesigned for cloud capabilities
May carry existing technical debt	Can address architectural limitations

Neither approach is automatically better.

A business with an urgent deadline may benefit from rehosting first and modernizing later.

A business planning to run a strategic application in the cloud for many years may justify the investment required for refactoring.

The decision should be based on business value and long-term requirements.

5. Retire: Remove What Is No Longer Needed

Cloud migration often reveals applications that are no longer actively used.

Some systems may have been retained for historical reasons. Others may have been replaced without being formally decommissioned.

Migrating these workloads simply transfers unnecessary cost into the cloud.

Before migration, identify applications that can be retired.

This can reduce:

• Migration effort
• Infrastructure costs
• Licensing costs
• Security exposure
• Operational complexity

Retirement is often one of the simplest ways to reduce the overall scope of a cloud migration.

6. Retain: Keep the Application Where It Is

Not every application needs to move immediately.

Some workloads may need to remain in their existing environment because of:

• Technical dependencies
• Compliance requirements
• Licensing restrictions
• Hardware requirements
• High migration risk
• Upcoming application replacement

Retaining an application does not mean ignoring it.

It means deliberately deciding that migration should not happen yet.

This is different from an application simply being left behind because it was difficult to migrate.

7. Relocate: Move the Environment With Minimal Application Changes

Relocation involves moving servers or workloads to a different infrastructure environment with limited changes to the application.

This approach can be relevant when an organization needs to move workloads between compatible environments without redesigning the applications.

The focus is on moving the infrastructure environment rather than changing the application itself.

Relocation can support faster migration in specific scenarios, particularly where existing infrastructure dependencies need to be preserved.

How to Choose the Right Migration Strategy

The 7 Rs should be applied at the application level.

Do not select one strategy for the entire migration program.

Start by assessing each application against a few key questions:

What Is the Business Value?

A strategically important application may justify modernization.

A low-value application may be better suited for retirement or replacement.

How Complex Is the Application?

Highly interconnected applications may require more planning.

Migration complexity should be understood before deciding whether to rehost, replatform, or refactor.

How Urgent Is the Migration?

A data center exit deadline may make rehosting the practical first step.

Longer timelines may allow more extensive modernization.

What Is the Current Technical Debt?

Applications with significant architectural limitations may continue carrying those problems into the cloud if they are simply rehosted.

What Are the Long-Term Requirements?

If the application needs to support significant growth, global availability, or rapid feature development, refactoring may provide stronger long-term value.

A Practical Approach for Legacy Application Migration

A successful migration strategy usually begins with an application portfolio assessment.

For every application, document:

• Business value
• Technical complexity
• Dependencies
• Infrastructure requirements
• Security and compliance requirements
• Current operating costs
• Future business plans

Then map each application to one of the 7 Rs.

A typical migration portfolio may look like this:

Low-complexity applications with short timelines: Rehost

Applications that can benefit from managed services: Replatform

Applications with suitable SaaS alternatives: Repurchase

Strategic applications with long-term growth requirements: Refactor

Unused applications: Retire

Applications that cannot move yet: Retain

Compatible workloads requiring infrastructure relocation: Relocate

This approach helps organizations avoid spending the same amount of effort on every application.

Final Thoughts

The 7 Rs of cloud migration are not seven steps that every application must follow.

They are seven strategic options.

The goal is to select the approach that delivers the right balance between migration speed, cost, risk, and long-term value.

The biggest mistake is assuming every legacy application should be modernized before migration.

In many cases, rehosting is the right short-term decision. It helps organizations move quickly and reduce immediate infrastructure constraints.

But rehosting and refactoring serve different purposes.

Rehost when speed and minimal change are the priority.

Refactor when long-term scalability, resilience, and modernization justify the additional investment.

The right cloud migration strategy starts by evaluating the application—not by deciding in advance how every workload should be moved.