Types of cloud migration: choosing an approach for each workload
Cloud migration guides don’t always agree. One lists four types, another five, and another seven. Even when they use the same terms, the definitions can differ. That makes planning harder. You need to know what each approach involves, how much work it requires, and what the application will cost to run afterwards. Moving it unchanged might be the quickest option, but any problems it has today may still need fixing once it’s in the cloud.
This guide explains the different types and their trade-offs to help you choose an approach for each application.
What does “type of cloud migration” mean?
When people talk about cloud migration types, they usually mean one of two things:
- Strategy types describe how you move an application and how much you change it along the way. They’re known as the 7 Rs.
- Scope types describe what you move and where it goes: from on-premises to the cloud, between providers, into a hybrid set-up, or back again.
A single project can involve both. If you’re leaving a data centre, for example, you might rehost some applications and modify others. The scope defines the overall move, while the strategy reflects each application’s infrastructure and requirements.
The migration process is the work involved in carrying out that move, from assessment and planning to execution and optimisation. For a breakdown of these stages, see our guide to the cloud migration process.
The 7 Rs of cloud migration
The 7 Rs started life as a shorter list, Gartner’s five Rs from 2010. AWS later expanded it, and its Prescriptive Guidance now lists seven strategies. Other providers use slightly different labels for the same ideas, which accounts for most of the confusion.
Rehost (lift and shift)
Rehosting moves an application to the cloud with minimal or no changes. The code and operating system stay the same; only the infrastructure underneath is new. It’s fast, so it’s popular for data centre exits and for setting up disaster recovery quickly. In a well-planned lift and shift, applications keep serving users throughout, and disruption stays low. The downside is that every inefficiency comes along, and you use very little of the cloud native functionality you’re paying for.
Relocate
Relocating moves workloads at the hypervisor level, for example VMware-based servers to a VMware service on a public cloud. Neither the application nor the operating system changes, and you don’t buy new hardware. AWS describes it as the quickest way to get a workload running in the cloud. In exchange, you stay on the same virtualisation platform and under its licensing.
Replatform (lift, tinker, and shift)
Replatforming adds a few targeted improvements during the move. You might shift a SQL Server database to a managed database service, or package virtual machines into containers, while leaving the core architecture alone. Some maintenance work moves to the provider, application performance often improves, and you gain cloud services that earn back their cost. It sits between a plain rehost and a full rebuild.
Refactor or re-architect
Refactoring changes the application so it can use cloud native features such as microservices, containers, managed messaging, or serverless computing. It demands the most effort and money up front, and it pays off most for applications that are central to how you compete, with the best long-term scalability and cost efficiency. Even so, AWS advises against refactoring during large migrations and recommends moving first and modernising afterwards.
Repurchase (drop and shop)
Repurchasing replaces an on-premises application with cloud based software, usually SaaS. CRM, HR and collaboration tools are the usual candidates. You stop maintaining infrastructure for them and get vendor-managed features in return. You will still have to migrate data and retrain users, and you’ll have less room for customisation than your legacy systems gave you.
Retain
Retaining keeps certain workloads where they are, for now. Common reasons are compliance requirements such as data residency, dependencies on systems that have to move first, specialised hardware with no cloud equivalent, or a recent upgrade you’d rather not write off. Retained workloads often leave you with a hybrid cloud as the target state.
Retire
Retiring means switching off applications nobody needs. Removing them before the move simplifies the migration, reduces risk, and cuts future cloud costs. A good place to look is what AWS calls “zombie” applications, those averaging below 5% CPU and memory use.
Refactor, re-architect, or rebuild?
These three terms get mixed up more than any others.
- Refactor: restructure the code so it runs better in the cloud, without changing what users see on the front end.
- Re-architect: redesign the architecture itself, for instance by splitting a monolith into microservices, to unlock cloud native capabilities.
- Rebuild: rewrite the application from scratch for the cloud environment.
AWS groups all three under “refactor or re-architect”. Microsoft’s Cloud Adoption Framework lists them separately, next to retire, retain, rehost, replatform, and replace, which is why some sources count eight Rs instead of seven.
How the types of cloud migration compare
No option is best for everything. Choosing the right cloud migration approach comes down to three things: how fast you need to move, what you can spend now versus later, and how much change each application can tolerate. Here’s how the strategies stack up in relative terms.
| Type | Effort | Speed to cloud | Migration risk | Upfront cost | Long-term cost efficiency | Cloud native benefit |
| Retire | Very low | n/a | Very low | Very low | High | n/a |
| Retain | None | n/a | Low | None | Unchanged | None |
| Rehost | Low | Fast | Low to medium | Low | Low to medium | Low |
| Relocate | Low | Fastest | Low | Low | Low to medium | Low |
| Replatform | Medium | Medium | Medium | Medium | Medium | Medium |
| Repurchase | Medium | Medium | Medium | Medium (licences) | Medium to high | High (vendor-managed) |
| Refactor or re-architect | High | Slow | High | High | High | High |
Approaches with lower migration costs can have higher running costs. Making greater use of cloud capabilities generally requires more work from your team.
Most portfolios therefore combine several strategies. Teams may rehost most applications and refactor those that differentiate the business, with migration carried out in waves.
Scope types: what you move and where it goes
You choose a strategy for each application. Scope describes the wider move: which systems are involved and where they’re going.
- On-premises to cloud: moving workloads from your own servers to a cloud provider.
- Cloud-to-cloud: moving between platforms, such as AWS and Microsoft Azure or Google Cloud. This might follow an acquisition or a decision to change providers because of costs or available services.
- Hybrid cloud: moving some workloads while keeping others on-premises. Networking, identity, and monitoring need to work across both environments.
- Cloud to on-premises (repatriation): bringing workloads back, usually for cost predictability, performance, or control. If data location is driving the decision, digital sovereignty options are worth a look.
- By asset: terms such as database, application, and data centre migration describe what you’re moving.
Scope also depends on which of the three broad types of cloud you’re moving to: public, private, or hybrid.
Let’s plan your cloud migration
Learn more
Security, cost, and risk trade-offs by migration type
The approach you choose also changes what your team needs to secure and maintain.
Security and compliance
You and your cloud provider share responsibility for security, and how that works in practice depends on the path you take:
- Rehost and relocate: review the network rules, encryption, and identity and access management (IAM) settings you bring across. Some may need changing for the new environment.
- Replatform and refactor: you can add managed identities, secrets management, or policy as code as part of the application changes.
- Repurchase: check where the vendor stores your data and how access is controlled before signing.
- Retain: keeping a workload on-premises may be necessary if the proposed cloud environment doesn’t meet compliance requirements.
Cloud providers offer strong security tools, but they only protect you once they’re configured correctly.
Costs and common risks
Migration costs don’t end at cutover. Some issues show up once you start using the new environment.
- Cost creep: A rehosted workload that’s oversized or running around the clock can cost more than it did on-premises. Surprise bills almost always come from poor resource allocation, so right-size once you’re in.
- Downtime: It’s the first thing most teams worry about. Rehearse the cutover, have a rollback plan ready, and test properly so the switch is as uneventful as possible.
- Legacy compatibility: Some older applications just don’t work well in the cloud. When that happens, it’s time to replatform, refactor, or retire them.
- Skills gaps: Cloud tech changes fast. Without enough experience on the team, even a straightforward rehost can go sideways.
Get these right and you’ll see the benefits: better performance and reliability, resources you can flex as needed, easier scaling, and a firmer grip on costs.
Choosing the right cloud migration approach
Start with three questions for every application:
- How quickly does it need to move?
- How much can you invest now, and how much later?
- How much change can the application, and the team behind it, absorb?
Then assess your existing infrastructure and classify each workload before committing.
AWS’s readiness assessment covers six perspectives, and its migration programme AWS MAP splits the work into assess, mobilise, and migrate phases. Building automation plans early speeds things up considerably. For the bigger picture, see our guide to building a cloud migration strategy.
The type you choose for each application shapes the whole migration and the digital transformation it supports. Most successful migrations use several types, each matched to the application it suits.
If you’re unsure which type fits which workload, talk to our cloud team. We’ll map your portfolio and give you a plan for each application before you commit budget.
FAQ: cloud migration
You can look at cloud migration in two ways. The 7 Rs describe what you do with each application: rehost, relocate, replatform, refactor, repurchase, retain, or retire. You can also describe a migration by what moves and where it goes, such as from on-premises to cloud, between cloud providers, into a hybrid setup, or back on-premises.
You’ll often see four listed: rehost, replatform, refactor, and repurchase. The list varies between guides, with some using re-architect instead of repurchase. The 7 Rs give a fuller picture by including relocate, retain, and retire.
Rehosting moves an application to the cloud with little or no change. Replatforming makes a few improvements along the way, such as moving to a managed database or putting the application into containers, while keeping its core architecture. It takes more work, but can leave you with less to maintain and lower running costs.
Refactoring changes the code while keeping the application’s behaviour the same. Re-architecting changes how the application is built, for example by breaking a monolith into microservices. AWS groups the two under one strategy; Microsoft lists them separately.
It depends on whether you mean the cost of the move or the cost of running the application afterwards. Rehosting is usually cheaper upfront, but existing inefficiencies can keep running costs high. Refactoring costs more initially and may save money over time. Retiring an unused application removes its future running costs, though you may still need to pay for decommissioning and archiving.
A common list includes storage, database, application, and cloud migration. These often overlap: moving an application to the cloud may also mean moving its database and storage.
Start with three questions: how soon does the application need to move, what can you spend, and how much change can the application and your team handle? Then check dependencies and compliance requirements, and make sure the choice supports your business goals. You’ll probably use different strategies for different applications.
arrow_circle_rightCONTACT US
Let’s discuss your cloud migration
Marcin Waleczko
Vice President of Client Services
arrow_circle_right OUR ARTICLES
