Cloud Migration Strategy: The 6 Rs

A cloud migration strategy is a decision per workload, not a verdict on the whole estate. The 6 Rs are the six decisions available: rehost (move it as is), replatform (move it onto a managed service with small changes), refactor (change the code to use the cloud properly), repurchase (replace it with a SaaS product), retire (switch it off) and retain (leave it where it is for now). Most migrations use all six. This guide explains each with examples, gives a decision matrix for choosing, and shows how to sequence the results into waves.

What cloud migration is

Cloud migration is the move of servers, applications, databases, data and the identity and network services around them from on-premises hardware or a hosting provider into a public cloud such as Azure, AWS or Google Cloud. It can also mean a move from one cloud to another, or from a cloud VM estate into managed services on the same cloud. What is cloud migration for, in business terms: fewer servers to own and patch, capacity that follows demand, managed backup and recovery, and a platform that newer work (analytics, integration, AI) can build on.

The strategy exists because “move everything” is rarely right. Some systems are duplicates or unused, some cost less as a subscription, some would cost more in the cloud than on paid-off hardware, and some need re-engineering to benefit. Gartner originally described five migration options (rehost, refactor, revise, rebuild, replace); AWS later popularized a six-R version that added retire and retain and merged the middle options, and later still added a seventh, relocate, for moving VMware estates at the hypervisor level. The six-R form below is the one most teams use when they build a cloud migration plan.

The 6 Rs with examples

1. Rehost (lift and shift)

Move the server to a cloud virtual machine without changing the application. Replication tools such as Azure Migrate, AWS Application Migration Service and Google’s Migrate to Virtual Machines copy the disks continuously, so cutover is a short switch.

Example: a vendor-supplied warehouse management application on two Windows servers with a SQL Server database. The vendor supports it on a cloud VM but not on a managed database, so it rehosts as is, on a VM family sized from the discovery utilization data.

When it fits: hardware or data-center deadlines, vendor products with narrow support statements, and estates where speed matters more than optimization. Watch for: cost. A rehosted server costs what a server costs; the savings come later from right-sizing, reservations and shutdown schedules, or from a second step onto managed services.

2. Replatform (lift, tinker and shift)

Move the application onto a managed service with limited changes to configuration and code. The application logic stays the same; the platform underneath changes.

Example: an in-house ASP.NET web application and its SQL Server database. The web tier goes to Azure App Service instead of an IIS virtual machine, and the database goes to Azure SQL Managed Instance, which keeps SQL Agent jobs and cross-database queries working. On AWS the equivalents are Elastic Beanstalk or a container service and Amazon RDS. Packaging an application into a container without changing its code is also a replatform.

When it fits: applications you maintain yourself, where patching, backups and scaling are the pain and the code is fine. Watch for: compatibility details: SQL CLR, linked servers, file-system access, Windows authentication and connection strings all need checking before you commit.

3. Refactor or re-architect

Change the application’s code or structure so it uses cloud services directly: managed queues instead of a polling table, functions for scheduled jobs, managed identity instead of stored passwords, a modular structure that lets parts scale and deploy separately.

Example: an order-processing monolith whose nightly batch and web traffic compete for the same server. The batch work moves to a queue (Azure Service Bus or Amazon SQS) with workers that scale out, the web tier runs on a container platform, and the database moves to a managed tier. The code changes; the business rules do not.

When it fits: systems that change often, need to scale, or are the reason a migration is happening at all. It is the most expensive R and the only one that changes what the application can do. Our guide on moving from a monolith to microservices covers the limits of this option, and the case for a modular monolith first.

4. Repurchase (replace with SaaS)

Retire the application in favor of a subscription product and migrate the data into it.

Example: an on-premises email server replaced by Microsoft 365; a custom-built CRM replaced by a commercial one; an aging HR or expense system replaced by a SaaS product with the integrations you need. The migration work becomes data mapping, user setup and integration rather than servers.

When it fits: commodity functions where your customizations no longer differentiate you. Watch for: the customizations people depend on, data that does not fit the new model, contract terms, and the integrations that quietly pointed at the old system.

5. Retire

Switch the system off. Every inventory contains servers nobody uses, duplicate reporting tools, a pilot that never ended, and applications whose last user left.

Example: two document-management systems from an acquisition, one of which holds nothing created in the last three years, consolidated into the other with the old one archived and decommissioned.

When it fits: whenever discovery shows no owner, no traffic or a duplicate. Watch for: retention obligations and hidden consumers, such as a report or an integration that still reads the old database. Retiring early shrinks everything that follows, so this decision comes first.

6. Retain

Leave the system where it is, with a reason and a review date. Retain is a decision, not a failure to decide.

Example: a production-line control system that needs millisecond latency to equipment on the factory floor; a system whose vendor will not support cloud hosting; a workload with a data-residency requirement the chosen region cannot meet; a fully depreciated system scheduled for replacement next year.

When it fits: when latency, licensing, compliance or timing make a move pointless or impossible today. Watch for: the hybrid connectivity and identity integration the retained system needs once everything around it has moved.

The seventh R, relocate, moves an entire VMware environment to Azure VMware Solution, VMware Cloud on AWS or Google Cloud VMware Engine without converting the virtual machines. It is fast and keeps existing tooling, and it is usually a bridge to a later replatform rather than an end state.

Cloud migration strategy decision matrix

Two questions settle most workloads: how much business value the system still carries, and how technically fit it is (supported platform, maintainable code, acceptable security). Score each from low to high and read the quadrant.

Business value	Technical fitness	Likely decision	Reasoning
High	High	Rehost or replatform	It works and it matters; move it with minimal risk, then optimize
High	Low	Refactor, or replatform now and refactor later	The business depends on it and the platform is holding it back; invest
Low	High	Rehost cheaply, or retain until replacement	Not worth engineering effort; keep the cost down
Low	Low	Retire or repurchase	Neither valuable nor sound; switch it off or buy the function

Then apply the overrides that trump the quadrant:

• Vendor support statement. If the vendor supports only a VM, the answer is rehost regardless of fitness.
• Licensing. Where Azure Hybrid Benefit or license mobility applies, a replatform onto a managed SQL service may cost less than a rehost; where it does not, the reverse can be true. Model both.
• Compliance and residency. A control you cannot meet in the target region means retain, or a different region.
• Deadline. A data-center exit in six months pushes high-value workloads toward rehost now and refactor later; the strategy records both steps.
• Dependencies. Tightly coupled systems usually share a decision and a wave, because a chatty application split across two locations generates latency and data-transfer charges.

Record each decision with its reason and its owner. The register becomes the backbone of the cloud migration plan and the first thing a new team member reads.

Sequencing waves

Once every workload has an R, the strategy turns into a sequence. The order that works in most programs:

1. Retire first. Decommissioning before migration removes workloads from every later estimate, and it needs no cloud at all.
2. Build the landing zone. Identity, network, policy, logging, backup and tagging as code, before anything moves.
3. Wave one: a low-risk rehost. A test environment or an internal tool proves the runbook, the replication tooling and the cutover process.
4. Rehost and replatform the dependent groups. Move tightly coupled systems together; a database and the applications that use it belong in one wave.
5. Repurchase in parallel. SaaS replacements run as separate projects with their own data migration, often led by the business rather than IT.
6. Refactor last, or as a second pass. Refactoring a system that is already in the cloud is safer and better measured than refactoring during the move.
7. Revisit the retained systems. Each one has a review date; some become migrations when the vendor’s support policy or the business’s plans change.

Our cloud migration checklist lists the 45 steps inside those waves, and our guide to cloud cost optimization covers what to do once the waves are done, because a rehosted estate that is never right-sized costs more than the hardware it replaced.

Where PS3G fits

PS3G builds the strategy and then executes it. Our cloud migration services start with discovery and a per-workload decision register, model the run cost for each option in the vendor’s calculators, and deliver the landing zone, the waves and the optimization afterwards. Our wider cloud consulting practice covers the architecture, security and managed cloud around it. We work on Azure, AWS and Google Cloud, we are not tied to any vendor’s resale program, and we scope the work for organizations of every size, from a founder with a handful of servers to a department inside a larger group with its own procurement and security rules.

Related reading

• Cloud Migration Checklist: 45 Steps from Inventory to Decommission
• Monolith to Microservices: When It’s Worth It and How to Do It
• Cloud Cost Optimization: 20 Ways to Cut Azure and AWS Bills
• Cloud migration services from PS3G

Frequently asked questions

What are the 6 Rs of cloud migration?

Rehost (move the server as is), replatform (move onto a managed service with small changes), refactor (change the code to use cloud services), repurchase (replace with a SaaS product), retire (switch it off) and retain (leave it in place for now). Each workload in an inventory gets one of the six, with a reason recorded. Some frameworks add a seventh, relocate, for moving VMware estates without converting them.

What is the difference between rehost and replatform?

Rehost copies the server into a cloud virtual machine with no change to the application; replatform moves the application onto a managed service such as App Service or a managed database, with small changes to configuration and sometimes code. Rehost is faster and lower risk; replatform removes patching, backup and scaling work and usually costs less to run. Many workloads rehost first and replatform in a second pass.

Which cloud migration strategy is cheapest?

Retire costs the least, because the workload disappears. Among the moves, rehost has the lowest one-time cost but often the highest run cost, replatform costs more up front and less to run, and refactor costs the most up front and pays back only where the application needs to scale or change often. A fair comparison models one-time and run cost together over a few years, per workload.

Can one application use more than one of the Rs?

Yes, and larger applications usually do. A typical pattern is to rehost the web servers, replatform the database onto a managed service, retire a reporting copy nobody uses, and plan a later refactor of the batch jobs. The decision register records one R per component rather than per application, and the wave plan keeps the coupled components together.

How do we choose between refactor and repurchase?

Ask whether the customization is a differentiator. If the application does something competitors cannot buy, refactor it and keep the advantage. If it does a standard job (email, CRM, HR, accounting) in a custom way, a SaaS product with good integration usually costs less and is better maintained than a rebuild. Data migration and the integrations that point at the old system decide most of the effort either way.