Cloud migration strategies: rehost, replatform, refactor or retire

"Move to the cloud" is not a plan. It hides a dozen different decisions, and treating every workload the same is how migrations run late and over budget.

Start with why

Be specific about the goal, because it changes the approach. Typical reasons include reducing data-centre cost or risk, improving reliability, scaling for growth, speeding up delivery, or exiting hardware that is reaching end of life. A migration driven by a hardware deadline looks very different from one driven by a desire to ship faster.

The common approaches

Rehost ("lift and shift"). Move the application as it is, onto virtual machines in the cloud. It is the fastest route and the least disruptive, and a sensible choice when a deadline is tight. The trade-off is that you carry over existing inefficiencies and gain few cloud benefits.

Replatform. Move with small, targeted changes, such as replacing a self-managed database with a managed one, or containerising the application. You gain operational improvements without rewriting the application.

Refactor or re-architect. Change the application's design to use cloud capabilities such as managed services, autoscaling and event-driven components. It offers the most long-term benefit and carries the most cost and risk. Reserve it for systems where those benefits clearly matter.

Repurchase. Replace the system with a software-as-a-service product. Often the right answer for commodity functions like email, HR or basic CRM.

Retire. Switch off what is no longer needed. Discovery frequently finds applications nobody uses, and retiring them is the cheapest migration of all.

Retain. Leave some workloads where they are for now, for regulatory, latency or economic reasons.

Assess before you commit

Build an inventory: what exists, who owns it, what it depends on, how critical it is, and how it is used. Then, for each application, consider:

• Dependencies. Applications rarely move alone. Databases, file shares, authentication and integrations often dictate move groups.
• Data. Volume, sensitivity and the time needed to transfer it. Large datasets may need a transfer strategy of their own.
• Compliance and data residency. Where data is allowed to live, and which controls must be demonstrable.
• Licensing. Some software is licensed in ways that change cost significantly in the cloud.
• Performance and latency. Chatty connections between a cloud-hosted app and an on-premises database can be slow and costly.

Migrate in waves

Start with a low-risk, representative workload to build the landing zone — accounts, networking, identity, logging, security baselines — and to learn. Then move in waves, grouped by dependency, with a tested rollback plan for each cutover. Run old and new in parallel where you can, and verify with real traffic or realistic tests before decommissioning.

Plan for after the move

Migration is not the finish line. Budget for cost monitoring, right-sizing, security configuration, backup and disaster-recovery testing, and training the team that will operate it. A migrated system nobody understands is a new kind of legacy.

What to take away

Sort workloads by value and effort, choose the lightest approach that meets the goal, and migrate in tested waves. Retire what you can, rehost where speed matters, and spend refactoring effort only where the cloud's strengths will pay it back.