Quick answer: The 7 Rs of cloud migration are seven strategies for deciding what to do with each workload when moving to the cloud: retire, retain, rehost, relocate, repurchase, replatform and refactor. Each workload gets its own strategy based on business value, technical fit, cost and risk. Most small-business migrations combine several, typically rehosting quickly and replatforming or replacing where it clearly pays off.
Key takeaways
- Assign a strategy per workload; a single approach for everything rarely gives the best result.
- Retiring unused applications is the cheapest migration of all and should be considered first.
- Rehost (lift and shift) is fastest but needs right-sizing afterward to avoid overspending.
- Replatforming to managed databases and app services often gives the best value for small teams.
- Refactor only where the business benefit justifies the engineering effort.
Every cloud migration eventually comes down to a set of individual decisions: what should happen to this server, this application, this database? The 7 Rs provide a shared vocabulary for making those decisions consistently. This guide explains each strategy with examples relevant to small businesses and nonprofits. It is part of our cloud migration services guidance.
What are the 7 Rs of cloud migration?
The 7 Rs are seven strategies for handling each workload in a migration: retire, retain, rehost, relocate, repurchase, replatform and refactor. They range from "switch it off" to "rebuild it for the cloud."
| Strategy | Also called | What happens | Effort | Typical SMB example |
|---|---|---|---|---|
| Retire | Decommission | Switch off applications no longer needed | Very low | Old intranet, unused reporting server |
| Retain | Revisit | Keep on-premises for now | None now | Machine-control software tied to local hardware |
| Rehost | Lift and shift | Move virtual machines unchanged | Low | Line-of-business app server |
| Relocate | Hypervisor-level lift and shift | Move a whole virtualized environment as-is | Low to medium | VMware cluster moved to a cloud VMware service |
| Repurchase | Replace, drop and shop | Switch to a SaaS product | Variable | On-premises Exchange to Microsoft 365 |
| Replatform | Lift, tinker and shift | Small changes to use managed services | Medium | SQL Server VM to a managed SQL database |
| Refactor | Re-architect | Redesign the application as cloud-native | High | Monolithic portal rebuilt with managed services |
What does each strategy involve?
Retire
Retiring means decommissioning workloads that no longer deliver value. Discovery commonly turns up servers that nobody uses, duplicated applications or test machines left running for years.
Retiring is the cheapest migration available: no move, no cloud bill, and a smaller attack surface. Confirm data retention requirements before switching anything off.
Retain
Retaining means deliberately leaving a workload where it is, at least for now. Valid reasons include specialized hardware dependencies, a pending replacement, recent investment or regulatory constraints.
Retain is a decision, not avoidance. Record why, and set a date to revisit it.
Rehost
Rehosting moves servers to cloud virtual machines with no application changes. Native tools such as Azure Migrate, AWS Application Migration Service and Google Cloud Migrate to Virtual Machines replicate servers continuously and allow a short cutover window.
Rehost is the fastest path when deadlines are tight, such as a hardware failure or contract end. Its weakness is that it carries over every inefficiency, so plan to right-size afterward. See post-migration optimization.
Relocate
Relocating moves an entire virtualized environment, typically VMware, to a cloud-hosted equivalent without converting each virtual machine. Options include Azure VMware Solution, VMware Cloud on AWS and Google Cloud VMware Engine, subject to current availability and licensing terms.
Relocate suits organizations with substantial VMware estates and skills. For most small businesses with a handful of servers, rehosting individual machines is simpler and cheaper.
Repurchase
Repurchasing replaces an application with a SaaS product. Classic examples are moving on-premises email to Microsoft 365 or Google Workspace, file servers to SharePoint or Google Drive, or an aging CRM to a cloud CRM.
For small organizations, repurchase is often the highest-value move because it removes infrastructure entirely. The real work is data migration, configuration and user adoption.
Replatform
Replatforming makes targeted changes to take advantage of managed services without rewriting the application. Common examples include moving a self-managed database to Azure SQL Database, Amazon RDS or Cloud SQL, or running a web application on a managed app platform or in containers.
Replatforming frequently offers the best balance for small teams: modest effort, lower operational burden and lower ongoing cost than running virtual machines.
Refactor
Refactoring redesigns an application to be cloud-native, using managed services, serverless functions, containers and automation. It delivers the most long-term flexibility and can reduce running costs significantly, but it is a software development project with matching effort and risk.
Refactor when the application is a strategic differentiator, needs to scale, or cannot move otherwise. Our guides on legacy application modernization and cloud-native application architecture cover the approach.
How do you choose the right R for each workload?
Choose by working through a short sequence of questions for every workload discovered during a cloud readiness assessment.
- Is it still used and needed? If not, retire it.
- Is there a hard reason it cannot move now? If yes, retain and set a review date.
- Does a SaaS product meet the need well? If yes, repurchase.
- Is it a large VMware environment that must move quickly? Consider relocate.
- Can a managed service replace part of the stack with modest change? If yes, replatform.
- Is it strategic and worth re-engineering? If yes, refactor, possibly after an initial rehost.
- Otherwise, rehost now and optimize later.
What does a typical small-business migration look like?
A typical small-business migration uses four or five of the Rs together. For example, a 40-person professional services firm with seven servers might:
| Workload | Strategy |
|---|---|
| Old reporting server and two test VMs | Retire |
| Exchange server | Repurchase (Microsoft 365) |
| File server | Repurchase (SharePoint and OneDrive) |
| Line-of-business application server | Rehost |
| SQL Server database | Replatform (managed database) |
| Scanner and plotter print server | Retain, revisit next year |
This illustrative mix shows how a migration can end with fewer servers than it started with.
How do the Rs affect cost and timeline?
Strategy choice has the biggest effect on both project effort and the ongoing cloud bill. Rehost minimizes project effort but may increase run cost; replatform and refactor shift spending into the project to lower run cost later.
For estimating guidance, see cloud migration cost estimation. Platform-specific steps are covered in the Azure migration checklist and the AWS migration checklist.
How Desai InfoTech applies the 7 Rs
Desai InfoTech assigns a strategy to every workload during assessment and documents the reasoning, so decisions are transparent and revisitable. Recommendations stay vendor-neutral across Azure, AWS and Google Cloud. To see how your environment maps to the 7 Rs, request a free cloud assessment.
Frequently asked questions
What is the difference between rehost, replatform and refactor?
Rehost moves a server to the cloud essentially unchanged, often called lift and shift. Replatform makes targeted changes to use managed services, such as moving a database to a managed database service, without rewriting the application. Refactor changes the application's code and architecture to become cloud-native. Effort, cost and long-term benefit generally increase in that order.
Why are there 6 Rs in some sources and 7 Rs in others?
The framework has evolved. Gartner published an early five-strategy model, AWS expanded it to six Rs, and AWS later added relocate as a seventh, covering moves of entire virtualized environments such as VMware without converting individual servers. The core ideas are the same; the seventh R simply recognizes hypervisor-level migrations as a distinct option.
Which migration strategy is best for a small business?
There is no single best strategy, but a common pattern works well. Retire unused systems, replace commodity servers such as email or file shares with SaaS, rehost applications that need to move quickly, and replatform databases to managed services. Refactoring is usually reserved for one or two applications where the business case is strong.
Is lift and shift a bad idea?
Not necessarily. Lift and shift is the fastest, lowest-risk way to exit a data center or failing hardware, and it gives immediate benefits such as better backup and resilience. It becomes a problem when servers are moved without right-sizing, governance or a plan to optimize later, which can make cloud costs higher than expected.
Part of the Cloud Migration Services hub.