Retire, retain, rehost, replatform, refactor, repurchase. Most workloads are an easy call. Save your energy for the few that are not.
The 6R framework for cloud migration is genuinely useful, but teams routinely turn it into a months-long analysis exercise. In practice, most workloads sort themselves quickly.
The quick sort
- Retire. Nobody owns it, nobody uses it, and turning it off for a week produces no complaints. A surprising share of an old estate lands here. Every workload retired is one you never have to migrate, secure, or pay for.
- Retain. It cannot move yet: a hardware dependency, a compliance blocker, a vendor end-of-life next year. Park it with a date to revisit.
- Rehost. It runs fine, it is not strategic, and lift-and-shift is cheap. This is the right answer for the long tail. Do not gold-plate it.
- Repurchase. There is a mature SaaS product that does the job and your customization is not a real differentiator. Moving to it removes the workload entirely.
That usually accounts for 80% of an estate in a couple of weeks.
Where to actually spend time
- Replatform. Small changes for a real payoff: managed database instead of self-hosted, containers instead of VMs. Worth it when the operational saving is ongoing.
- Refactor. Expensive and slow. Reserve it for the handful of applications that are genuinely strategic, actively developed, and constrained by their current architecture. If you are refactoring more than a few systems in one programme, question it.
The trap
The trap is treating every workload as a refactor candidate "while we are in there." You are not in there. You are trying to exit a data centre or reduce risk. Move the long tail fast, prove the landing zone, and come back for the strategic systems with a clear head and a separate budget.