Revisiting the 7 Rs of Cloud Migration with Real-World Examples

With the rapid growth of cloud technologies and data centres, it is no longer a matter of if organizations should move to the cloud — it is a matter of when and how. Cloud migrations become critical in this context, with the need to balance key levers such as speed, cost, risk, and value. Originally popularized by Gartner and AWS, this article takes a look at the 6 Rs of Cloud Migration (with an additional R added to the traditional model), along with illustrative real-world examples, to help teams make informed cloud migration decisions.

The 7 Rs — Rehost, Replatform, Refactor, Repurchase, Retire, Retain, and Relocate — provide a structured way to analyze each application in an organization’s portfolio. Rather than taking a one-size-fits-all approach, this framework focuses on the notion that different applications and services require different migration strategies depending on business criticality, technical complexity, compliance constraints, and digital transformation goals.

Rehost (Lift and Shift)

One of the simplest and most straightforward cloud migration approaches is rehosting, also known as lift and shift. This approach is ideal for quick migrations with minimal disruption and is often preferred by teams with a low tolerance for risk during the initial migration phase.

For example, a retail company using legacy Java applications on VMware can migrate to Amazon EC2 using AWS Application Migration Service (MGN). In this context, there would be no noticeable change, as the application continues to operate exactly as it did on-premises. However, scalability and availability would be improved.

Replatform (Lift, Tinker, and Shift)

This approach aims to strike a balance between speed and optimization. The core application architecture remains unchanged; however, small, incremental, and often targeted improvements are made while moving the application to the cloud. Replatforming is useful when teams want performance benefits without significant re-architecting.

For example, an e-commerce platform might migrate from an on-premises MySQL database to Amazon RDS while keeping the application code unchanged. This reduces the operational overhead of database backups and patching.

Refactor (Re-Architect)

Refactoring involves making significant changes to an application’s architecture to take advantage of cloud-native capabilities such as microservices, serverless computing, and managed services. High-value and business-critical applications are typically candidates for this approach. Organizations often choose refactoring when existing systems struggle with demand, slow deployments, or reliability issues.

For instance, a fintech company may choose to break down a monolithic architecture into microservices. By using managed databases, API gateways, and serverless functions, each service can scale independently and support continuous deployments. While this approach can be costly and time-consuming, it offers long-term benefits such as increased scalability and innovation capabilities.

Repurchase (Drop and Shop)

Repurchasing involves replacing existing applications with vendor-managed platforms that deliver functionality out of the box, most commonly through SaaS solutions. Run-of-the-mill applications for CRM, HR, finance, and ERP are common candidates. Organizations often adopt this approach to leverage trusted vendors and reduce operational complexity.

For example, an organization may decide to replace its existing CRM with Salesforce. Customer data is migrated, and third-party integrations are rebuilt to minimize disruption to daily operations. Some drawbacks include higher licensing costs and limited customization options.

Retire

In this approach, systems that are no longer required are sunset and decommissioned. These may be redundant applications or systems that no longer meet business objectives.

For example, during a cloud migration assessment, an organization may discover multiple overlapping point solutions. After validating requirements with business stakeholders, some of these systems can be retired, resulting in a more consolidated architecture and a single source of truth.

Key benefits include immediate cost savings, reduced attack surface area, and lower technical complexity.

Retain (Revisit Later)

This approach recognizes that certain applications may not yet be suitable for cloud migration. As a result, these systems remain on-premises while other services move to the cloud. Retention is common when technical constraints or regulatory requirements make migration impractical.

For instance, a healthcare organization might decide to keep its patient records on-premises due to HIPPA compliance and other data-specific regulations. However, there can be several integrations that keep both the cloud and on-premises services in sync with each other.

Drawbacks include increased on-premises operational costs and added complexity in managing hybrid integrations with cloud services — if present.

Relocate (Hypervisor-Level Migration)

Relocation focuses on moving applications at the virtual machine or hypervisor level from on-premises environments to the cloud without changing application code or VM configurations. This approach is ideal for organizations with large VMware estates that require a rapid data centre exit with minimal refactoring and downtime.

For example, an enterprise running hundreds of workloads on VMware vSphere can migrate them to VMware Cloud on AWS with minimal disruption. Teams can continue using familiar tools such as vCenter while gradually adopting native cloud services.

Relocation enables fast migrations, preserves existing operational models, and supports phased modernization. However, it often involves continued licensing costs, provides limited immediate cloud-native benefits, and may prolong legacy architectures if modernization is delayed.