Cloud migration is often talked about as if it is a single decision, you move to the cloud, and everything gets better. In reality, most organisations get the best results when they treat migration as a portfolio of decisions across applications, data, and ways of working. For business leaders, that is good news, because it means you can balance speed, cost, and risk, rather than forcing every system down the same path.
In this blog, we break down the six main strategies you will hear described in cloud migration planning: Rehost, Replatform, Refactor, Repurpose, Retain, and Retire. Each approach has a place, and many modernisation programmes use a mix of all six. By the end, you should be able to look at your environment and have a clearer view of what is worth moving quickly, what should be improved as it moves, and what should be left alone or switched off entirely.
Why Cloud Migration Isn’t a Single Strategy
Every system exists for a reason, but they do not all carry the same business importance, risk, or complexity. Some applications are stable and predictable, and the main goal is to keep them supported and resilient. Others are customer facing, change frequently, and need to scale during busy periods. Some are nearing end of life, or are only used by a handful of people, but still create cost and risk because they must be patched, backed up, and supported.
That is why cloud migration is rarely a one size fits all exercise. A sensible plan considers a few business led questions for each workload:
- How critical is it to day to day operations, revenue, or customer experience?
- How quickly do we need results? Is this a strategic programme, or a time sensitive risk reduction?
- What is the acceptable level of disruption while we change it?
- Are we trying to reduce cost, improve resilience, increase speed of change, or a mix of these?
- What level of governance, security, and compliance does it require?
Once you look at migration through that lens, the six strategies make more sense. Many organisations start with the least disruptive option, Rehost, to create momentum and reduce reliance on ageing infrastructure.
Rehost (Lift and Shift)
Rehost, often called “lift and shift”, moves an existing application from on premises infrastructure to the cloud with minimal change. In plain terms, it changes where the system runs, not how it works.
Rehosting is often appropriate when time is the priority, for example a data centre exit, an urgent hardware refresh, or a need to improve resilience quickly. It can also help reduce capital expenditure by shifting away from owning and maintaining physical infrastructure.
The trade off is that you may bring inefficiencies with you. If an application is costly to run and hard to maintain today, it may remain costly in Azure unless you take a second step to optimise it. Rehost is often best viewed as a starting point, a way to move safely, stabilise, then decide where modernisation will pay back.
Replatform and Refactor
If rehosting is “move it as it is”, then replatform and refactor are about improving the system as part of the move. They tend to deliver more long term value, but they require more planning, testing, and change management.
Replatform
Replatforming involves targeted changes so the workload can use more managed Azure services and run more efficiently, without redesigning the application from scratch. The goal is to reduce operational overhead and improve reliability while keeping risk controlled.
This approach often suits workloads that matter to the business but do not justify a full rebuild. You typically get better resilience and simpler ongoing management than lift and shift, but you still need to plan for compatibility and performance testing.
Refactor
Refactoring is a deeper change. It involves redesigning and rebuilding parts of an application so it takes advantage of cloud native capabilities such as scaling, resilience, automation, and modern development practices.
Refactoring can make sense when an application is central to growth, customer experience, or security requirements, and when you need long term agility rather than a quick move. The trade off is higher upfront cost and longer delivery times, which is why it is usually best reserved for a small number of high impact systems.
These options matter because they highlight a key point, cloud migration is not only about moving workloads, it is also about deciding where improvement will deliver a return.
Repurpose, Retain, and Retire
Not every workload should be moved, rebuilt, or even kept. Repurpose, retain, and retire can deliver some of the biggest gains in simplification, cost control, and risk reduction.
Repurpose
Repurposing means changing the approach, rather than migrating the legacy system as it is. You might replace a bespoke application with a modern alternative, or shift to a different service that meets the same business need more effectively. These decisions are as much about process and stakeholders as they are about technology.
Retain
Retain means keeping a workload where it is for now, on premises or in a hosting environment, while you migrate other parts of the estate. This is a valid choice when there are constraints such as vendor limitations, specialist hardware dependencies, latency requirements, or when the cost and risk of change outweigh the benefit today.
The key is to treat retention as a managed decision, with a clear plan for patching, backup, resilience, and a review date.
Retire
Retire is switching off what you no longer need. Many organisations have systems still running simply because they always have been, even if usage is low or the original purpose has faded.
A common example is legacy file storage. If you have a NAS or a traditional file share that has become hard to manage and risky to keep, you may decide to retire that approach and move collaboration to OneDrive and SharePoint, where it fits your governance and user needs. Retirement should always be handled carefully, with confirmed data ownership, retention requirements, and a plan for archiving and audit, but it can remove cost and complexity permanently.
Choosing the Right Mix
The simplest way to approach the six strategies is to decide workload by workload, rather than trying to pick a single “best” option for the whole business. Start with a lightweight inventory of key applications and data sets, then group them by business importance and urgency.
From there, assign an initial strategy:
- Rehost what needs to move quickly and can be stabilised first.
- Replatform where small improvements will reduce operational effort.
- Refactor the few workloads where agility and long term value justify it.
- Repurpose where a different solution would serve the business better.
- Retain what must stay for now, but manage the risk properly.
- Retire what is no longer needed.
Sequencing matters. Many SMBs do well by starting with foundations and quick wins, then moving to more complex modernisation. That usually means putting the basics in place early, security baselines, identity and access controls, backup and recovery, monitoring, and cost governance, so the Azure environment stays predictable after the initial move.
How We Can Help
Choosing the right migration strategy is often less about technology and more about making clear, practical decisions that fit the business. We can help you assess your environment, map systems to the right approach, and build a phased plan for Azure that balances speed with long term value. That support can include everything from planning and foundations through to delivery, optimisation, and ongoing management, depending on what you need and how much change you want to take on at once.
If you want to understand which workloads should be moved quickly, which should be modernised, and which should be switched off entirely, contact us to find out more, and we will help you shape a cloud migration plan that is realistic, secure, and aligned to your business priorities.