Rehost when speed matters more than efficiency, replatform when a managed service removes meaningful operational burden, and rebuild only where the architecture is the constraint. Sequence migrations by business value and technical risk rather than by ease, and model run cost after migration as carefully as migration cost.
The six migration strategies
Every application lands in one of a small number of strategies: rehost with minimal change, replatform onto managed services, repurchase with a SaaS replacement, refactor or rebuild for cloud-native architecture, retain because migration is not justified, or retire because the system is no longer needed.
The mistake is applying one strategy across a portfolio. A monolithic reporting database and an internal approval tool have almost nothing in common, and treating them identically produces either wasted effort or unnecessary cost.
Retire and retain are frequently the highest-return choices and the most neglected. A migration programme that begins with a decommissioning exercise usually removes a meaningful fraction of the portfolio before any migration work starts.
Choosing per application
Score each application on four factors: business criticality, architectural coupling, operational pain and remaining lifespan. High criticality with heavy coupling and a long lifespan justifies rebuilding. Low criticality with a short remaining lifespan justifies retaining or retiring.
Two questions sharpen the decision. First, does a managed service remove operational burden you currently carry, such as patching, backups or failover? If so, replatforming pays quickly. Second, is the architecture itself the constraint on scaling or release frequency? If not, refactoring is usually unjustified.
Portability deserves an honest assessment. If the target platform's managed services are materially better but proprietary, accept the coupling deliberately rather than accidentally.
| Strategy | Effort | Choose when |
|---|---|---|
| Rehost | Low | Speed is the priority; architecture is acceptable |
| Replatform | Medium | Managed service removes real operational burden |
| Repurchase | Medium | A SaaS product covers the need better |
| Refactor or rebuild | High | Architecture blocks scaling or delivery |
| Retain | None | Cost or risk of moving exceeds the benefit |
| Retire | Low | The system is no longer needed |
Sequencing the programme
Sequence migrations to build capability and credibility. Start with a small number of genuinely useful workloads that exercise the target platform's core capabilities, have a real business benefit, and are not so critical that failure is unacceptable.
Then migrate in waves grouped by shared characteristics, such as applications sharing a database, a network zone or a compliance boundary. Grouping reduces rework and avoids temporary hybrid networking that must later be unpicked.
Keep dependency mapping explicit. Migrating a service before the systems it depends on forces temporary bridges and dual running costs, and those bridges have a habit of becoming permanent.
- Start with low-risk workloads that still deliver real benefit.
- Group waves by shared dependencies and compliance boundaries.
- Map dependencies before cutover to avoid permanent temporary bridges.
- Reserve the hardest workloads for when capability is established.
Cost modelling and cutover
Migration cost is one-off; run cost is forever. Model compute, storage, database, networking and especially egress, plus support tiers, licensing portability and the cost of the new operational tooling the platform requires. Many rehosted estates cost more to run than the data centre they left.
Licensing is a frequent trap. Per-core licensing models, virtualisation restrictions and support contract terms can make a platform change unexpectedly expensive, so confirm portability with the vendor before designing the target.
For cutover, prefer a phased approach with reversible steps. Where a hard switch is unavoidable, rehearse it, define the rollback trigger in advance, and keep the source environment intact until the target has run through at least one full business cycle.
- Model run cost including egress, support tiers and tooling.
- Confirm licence portability with vendors before designing the target.
- Prefer phased cutover with reversible steps.
- Define the rollback trigger before the cutover, not during it.
Frequently asked questions
Is lift-and-shift ever the right cloud migration strategy?
Yes, when speed or a data centre exit deadline dominates and the application architecture is acceptable. It is a valid first step, but without a follow-up optimisation plan it often results in higher run cost than the original environment.
How should migration order be decided?
By business value and technical risk grouped into waves with shared dependencies, not by ease of migration. Starting with trivial workloads consumes budget without proving the platform handles what matters.
What is most commonly missed in cloud migration business cases?
Ongoing run cost, network egress, support tiers, licensing portability and the tooling the new platform requires. Migration cost is usually modelled; the permanent cost line frequently is not.
References
Engineer your next strategic platform
Estimate your project investment and delivery timeline instantly, or schedule an architectural discovery call with our engineering leadership.