CONSULT CIRCLE | CLOUD MIGRATION
Rehost, replatform, refactor, repurchase, retire or retain - and how to tell which one a given application actually needs.
The six migration strategies are well known. Choosing between them is where organisations struggle, because the decision is usually made by whoever is loudest rather than by the characteristics of the application.
The cost of choosing wrongly is asymmetric. Rehosting something that should have been retired wastes a modest amount of effort. Refactoring something that should have been rehosted can consume a year and still not deliver.
What this guide covers
- The six strategies and what each actually costs
- A decision sequence that works, in order
- Signals that a strategy has been chosen wrongly
The six strategies, and what each actually costs
| Strategy | What it involves | Effort | Choose it when |
|---|---|---|---|
| Retire | Decommission rather than migrate | Lowest | Nobody uses it, or its function is duplicated elsewhere. Every estate has more of these than expected |
| Retain | Leave where it is, for now | None | Constraints make migration impractical, or a refresh event is close enough to wait for |
| Rehost | Move as-is to cloud infrastructure | Low | The application works, the deadline is real, and there is no appetite to change it |
| Replatform | Minor changes to use managed services, such as a managed database | Moderate | Modest changes remove a disproportionate amount of operational burden |
| Repurchase | Replace with a SaaS product | Moderate to high | A commodity function where a mature product exists and customisation is low |
| Refactor | Re-architect for cloud-native patterns | Highest | The application is strategic, actively developed, and constrained by its current architecture |
Table 1 - The six migration strategies compared.
A decision sequence that works
Work through these in order. The first clear answer is usually the right one.
- Does anyone actually use it? Check real usage, not the asset register. If not, retire.
- Is its function duplicated by something else you already own? If so, retire or consolidate.
- Is there a hard constraint preventing migration - licensing, regulation, an unsupported dependency? If so, retain and record why, with a review date.
- Is there a mature SaaS product for this function, and is your usage close to standard? If so, evaluate repurchase.
- Is the application actively developed and is its architecture genuinely holding the business back? If so, refactor - but only if you have the time and the team.
- Would a modest change, such as moving to a managed database, remove significant operational burden? If so, replatform. The database side of that decision is covered in Migrating Legacy Databases to Cloud.
- Otherwise, rehost. It is the default for a reason.
Where the honest answer is "retain", the placement criteria in Hybrid Cloud Architecture Decisions will tell you whether that is a permanent position or one waiting on a refresh event.
Signals that a strategy has been chosen wrongly
| Signal | What it usually means |
|---|---|
| The refactor has no completion date anyone believes | It should have been a rehost, with modernisation as a separate initiative afterwards |
| A rehosted application costs more in cloud than it did on-premises | It was not right-sized, or it is steady-state and should have been retained or reserved |
| A SaaS replacement is being heavily customised | The function was not as standard as assumed; repurchase was the wrong call |
| Nobody can name the business owner | Strong candidate for retire, and worth confirming before spending anything on it |
| The dependency list keeps growing during the build | Discovery was too shallow; pause and complete it rather than continuing to find out |
Table 2 - Warning signs of a wrong strategy choice.
Where to go next
- Practical Cloud Migration Checklist: 10 Steps to Reduce Risk and Cost
- 3 Quick Signs Your Business Is Ready to Move Non-Critical Workloads to the Cloud
- How to migrate to VCF using HCX for rehosting VMware estates, delivered through VCF Migration Services
Frequently Asked Questions
What are the 6 Rs of cloud migration?
Retire, retain, rehost, replatform, repurchase and refactor. They describe what you do with each application, ranging from decommissioning it to re-architecting it for cloud-native patterns.
Is lift and shift a bad strategy?
No. Rehosting is the right answer for a large share of applications, particularly under deadline pressure. It becomes a problem only when workloads are never right-sized afterwards and the cost of the old architecture carries forward indefinitely.
Should we modernise applications before or after migrating?
Usually after. Modernising and relocating at the same time couples two hard problems and doubles the risk. Move first, stabilise, then modernise from a consistent platform.
How do we identify applications to retire?
Check actual usage rather than the asset register, look for duplicated functions, and identify applications with no named owner. Most estates find a meaningful percentage that can simply be switched off.
How long does it take to decide a migration strategy per application?
With good dependency data, a working session can classify dozens of applications in a day. Without it, each one becomes an investigation. The discovery work is what determines the pace.
Talk to Consult Circle
Our fixed-fee assessment produces a per-application disposition with a costed roadmap, so the strategy decision is made on evidence rather than assumption. Book a free 30-minute call - 0203 916 5593 - info@consultcircle.com