What are the common cloud migration strategies, often referred to as the 6 Rs, and how do you determine which strategy is best for a given workload?

Question

Accepted Answer

The 6 Rs framework, originally introduced by Gartner and popularized by AWS, provides a structured way to categorize the migration approach for each workload. Not every application should be migrated the same way, and choosing the right strategy for each workload is one of the most important decisions in a cloud migration project.

Rehost, commonly called lift-and-shift, means moving an application to the cloud with minimal or no changes. You take the existing server, convert it to a cloud virtual machine, and run it as-is. This is the fastest migration method and is appropriate for applications where the priority is getting out of the on-premises data center quickly. Tools like Azure Migrate, AWS Application Migration Service, and Zerto automate much of this process. The limitation is that you do not take advantage of cloud-native services, so the operational model remains similar to on-premises.

Replatform, sometimes called lift-tinker-and-shift, involves making a few optimizations during the migration without changing the core architecture. For example, migrating a database from a self-managed SQL Server on a VM to Azure SQL Managed Instance, which handles patching, backups, and high availability automatically. You gain some cloud benefits without a full redesign.

Refactor, also called re-architect, means significantly redesigning the application to take full advantage of cloud-native features. This might involve breaking a monolithic application into microservices, adopting serverless computing with AWS Lambda or Azure Functions, or rebuilding the application to use managed services like cloud-native databases and message queues. Refactoring delivers the most long-term benefit but requires the most time, effort, and development expertise.

Repurchase means replacing the existing application with a different product, typically a SaaS solution. For example, migrating from an on-premises Exchange server to Microsoft 365, or replacing a self-hosted CRM with Salesforce. This eliminates the need to manage the application entirely but may require data migration and user retraining.

Retire means identifying applications that are no longer needed and simply turning them off. During the assessment phase of a migration, it is common to discover servers and applications that are no longer used or that duplicate functionality provided by other systems. Retiring these reduces the migration scope and eliminates unnecessary costs.

Retain means deciding to keep certain applications on-premises, at least for now. Some workloads may not be suitable for the cloud due to latency requirements, regulatory restrictions, hardware dependencies, or licensing constraints. The decision to retain should be revisited periodically as these constraints evolve.

To determine the best strategy for each workload, I evaluate several factors. Technical compatibility asks whether the application can run in the cloud without modification. Business value asks how critical the application is and whether investing in refactoring is justified by the long-term savings. Time constraints matter because if the data center lease expires in six months, rehosting is the pragmatic choice even if refactoring would be ideal. Dependencies need consideration because applications with tight dependencies on other systems need to move together, which may constrain the strategy. And cost analysis compares the ongoing cloud cost of each approach against the current on-premises cost.

In practice, most enterprise migrations use a mix of strategies. Quick wins are rehosted, high-value applications are refactored over time, commodity software is repurchased as SaaS, and obsolete systems are retired.