Cloud Migration Strategy: The 7 Rs Explained
Most cloud migrations that go over budget fail for the same reason: every application was treated the same way. A sound cloud migration strategy starts by deciding, application by application, whether to move it as-is, improve it on the way, replace it or switch it off. The “7 Rs” framework, popularized by AWS and echoed in Microsoft’s and Google’s migration guidance, gives you a shared vocabulary for those decisions.
This guide explains each R in plain terms, shows when it fits, and sets out the steps we follow when helping clients move workloads as part of our cloud-based application development services.
What Are the 7 Rs of Cloud Migration?
The 7 Rs are seven options for each workload in your portfolio: retire, retain, rehost, relocate, repurchase, replatform and refactor. They run roughly from least to most effort, and a typical migration uses several of them at once.
| Strategy | What it means | Effort | Best for |
|---|---|---|---|
| Retire | Switch the application off | Very low | Duplicate or unused systems |
| Retain | Leave it where it is for now | None now | Recently upgraded or hard-to-move systems |
| Rehost (“lift and shift”) | Move servers to cloud VMs unchanged | Low | Fast data-centre exits |
| Relocate | Move a virtualized platform (for example VMware) to the cloud provider’s hosted version | Low | Large VMware estates |
| Repurchase | Replace with a SaaS product | Medium | CRM, HR, email, ticketing |
| Replatform (“lift and reshape”) | Move with targeted changes, such as a managed database | Medium | Apps that gain from managed services |
| Refactor (re-architect) | Redesign for cloud-native services | High | Core products that must scale or change fast |
Each Strategy in More Detail
1. Retire
Discovery almost always turns up applications nobody uses: a reporting tool replaced years ago, a test server left running, a duplicate intranet. Retiring them before migration cuts scope, license cost and attack surface. Archive the data according to your retention policy first.
2. Retain
Some systems should stay put for now: a mainframe with years of support left, an application tied to on-premises hardware, or one facing strict data residency rules you cannot yet meet in the cloud. Retain is a legitimate decision as long as it has a review date.
3. Rehost
Rehosting copies servers to cloud virtual machines with minimal change. It is the fastest way to exit a data center before a lease ends, but it rarely cuts running costs much on its own, because oversized servers stay oversized. Treat it as step one, then optimize.
4. Relocate
Relocation moves an entire virtualization platform, typically VMware, onto the cloud provider’s hosted equivalent, so workloads move without conversion. It suits organizations with hundreds of virtual machines and teams skilled in that platform.
5. Repurchase
Replacing a self-hosted system with SaaS, such as moving an on-premises CRM to a hosted one, removes the infrastructure burden entirely. The real work lies in data migration, integrations and retraining staff. Our comparison of custom web applications vs off-the-shelf software helps decide when buying beats building.
6. Replatform
Replatforming makes a few targeted changes during the move: swapping a self-managed database for a managed one, moving the app into containers, or putting files in object storage. You gain automated backups, patching and scaling without rewriting business logic. For many business applications this is the best value option.
7. Refactor
Refactoring redesigns an application to use cloud-native patterns such as managed queues, serverless functions or a split into services. It costs the most but pays off for products that must scale, release frequently or support new features. Avoid refactoring everything at once; our guide to microservices vs monolith explains why a well-structured monolith is often enough.
A quick rule of thumb for choosing
Ask three questions of every workload. Does anyone still need it? If not, retire it. Is there a mature SaaS product that does the same job well? If so, consider repurchasing. Is the application a source of competitive advantage that must change often? If yes, it is a candidate for refactoring over time; if not, rehost or replatform it and spend your engineering effort elsewhere. In our experience, most business portfolios end up with a large block of rehosted and replatformed systems, a handful of refactored core products and a surprising number of retirements.
How to Build a Cloud Migration Strategy Step by Step
A practical migration runs in five phases: assess, decide, prepare the landing zone, migrate in waves, then optimize. Skipping the first two is the most common cause of overruns.
- Assess the portfolio. Inventory every application, its owners, dependencies, data volumes, licenses and compliance needs. Dependency mapping is critical: moving an app without the database it calls every second creates latency problems.
- Assign an R to each workload. Score by business value and technical difficulty. High-value, low-difficulty apps make good early candidates.
- Build a landing zone. Set up accounts or subscriptions, networking, identity, logging, backup policies and guardrails in infrastructure as code before any workload moves. Frameworks such as the Microsoft Cloud Adoption Framework and the AWS Well-Architected Framework provide checklists for this.
- Migrate in waves. Start with a low-risk pilot, then group related applications. Each wave should include testing, a cutover window and a tested rollback plan.
- Optimize after cutover. Right-size instances, add autoscaling, move to commitment discounts and schedule non-production environments to switch off overnight.
Costs and Timelines to Expect
Migration cost scales with the number of applications and the share you replatform or refactor. The indicative ranges below assume a professional services partner and exclude ongoing cloud fees.
| Scenario | Indicative cost (USD) | Typical timeline |
|---|---|---|
| Single web application rehosted or replatformed | $8,000 – $30,000 | 3 – 8 weeks |
| SMB portfolio of 5–15 applications, mostly replatform | $40,000 – $150,000 | 3 – 6 months |
| Core product refactored to cloud-native architecture | $80,000 – $300,000+ | 4 – 12 months |
Plan for a period of running both environments in parallel, which temporarily raises costs. After migration, follow the practices in our guide to cloud cost optimization so the cloud bill comes in below the old hosting cost rather than above it.
Common Migration Risks and How to Manage Them
The biggest risks are hidden dependencies, data transfer time, security gaps and skills shortfalls. Each one can be reduced with planning.
- Hidden dependencies: use network monitoring during discovery to see what actually talks to what.
- Large data sets: test transfer speed early; very large volumes may need offline transfer devices or continuous replication.
- Compliance: confirm region choice and data processing terms meet laws such as the GDPR before moving personal data.
- Security misconfiguration: enforce least-privilege access, encryption and logging through the landing zone, not by hand.
- Skills gaps: pair internal staff with experienced engineers so knowledge stays in-house after cutover.
Still choosing a destination? Our comparison of AWS vs Azure vs Google Cloud covers the trade-offs.
Frequently Asked Questions
What is the difference between rehost and replatform?
Rehosting moves servers unchanged to cloud virtual machines. Replatforming makes limited changes during the move, such as switching to a managed database, to gain cloud benefits without rewriting the application.
Is lift and shift a bad cloud migration strategy?
No, but it is rarely the end state. It is a fast way to leave a data center; savings usually come afterwards from right-sizing and replatforming key workloads.
How long does a cloud migration take?
A single application can move in a few weeks. A small business portfolio typically takes three to six months, and enterprise programs often run a year or more in waves.
Will moving to the cloud reduce our IT costs?
It can, but not automatically. Savings come from right-sizing, autoscaling, managed services and switching off idle resources. A straight lift and shift can cost more than on-premises hosting.
Plan Your Migration with Sigmato
Sigmato’s engineers in Bengaluru and the UK assess portfolios, build landing zones and modernize applications, from replatforming legacy web applications to refactoring core products. We will give you a clear R for each workload and a phased plan with indicative costs.
Sources and References
