Why a binary frame fails
Most legacy estates contain dozens to hundreds of distinct workloads. Treating modernisation as "we are moving to cloud" or "we are rewriting our platform" is a category error — different workloads in the same estate deserve different answers. The 7 Rs framework gives you a vocabulary for those different answers, and a sequence for applying them.
The seven options, in plain terms
- Retain. Leave it alone. Some workloads are stable, low-risk, and not worth the modernisation effort. Naming "retain" explicitly stops it from being a hidden default.
- Retire. Decommission it. Often the highest-leverage modernisation move — the work that does not get done anymore is the cheapest work.
- Rehost. Lift-and-shift to cloud infrastructure with minimal change. Useful when the application is stable and the goal is data centre exit or cost reduction.
- Relocate. Move with minimal change to different infrastructure — e.g. VMware migration to a cloud-native VMware service. Cousin of rehost; specific use cases.
- Replatform. Lift-and-improve. Move to cloud and adopt managed services for clearly-beneficial pieces — managed database, managed identity. Most workloads land here in practice.
- Refactor / rearchitect. Restructure the application — sometimes modest, sometimes substantial. The right call when the current architecture is the bottleneck.
- Rebuild. Replace from scratch. The right call when the existing system fundamentally cannot support the next three to five years of strategy.
Choosing the right R per workload
Four questions sort most workloads into the right R:
- Is this workload contributing differentiated business value? If no, lean toward retain or retire. If yes, it deserves more attention.
- How big is the gap between current and desired capability? Small gaps lean replatform. Large gaps lean rearchitect or rebuild.
- What is the operational risk of change? High-risk workloads lean toward incremental Rs (replatform, refactor) over big-bang ones (rebuild).
- What does the data flow look like? A workload that is mostly a thin shell over a large dataset deserves data-first treatment, regardless of which R you apply to the application layer.
Sequencing — what to do first
The order matters. Modernisation programmes that lead with the most ambitious R typically stall. The sequence that holds up:
- Inventory and assess — sort workloads into Rs explicitly.
- Retire what can be retired. It is free velocity for everything that follows.
- Replatform the high-value, low-risk pieces. They build confidence and capability.
- Rearchitect or rebuild the strategically-important pieces with the capability you have just built.
- Retain the rest with a clear review schedule — not forever, just until it earns the attention.
Where teams most often get it wrong
Two failure modes recur. One is over-ambition — treating the whole estate as a candidate for rebuild, then discovering you cannot rebuild a hundred applications in parallel. The other is over-caution — defaulting every workload to retain and ending up with a cloud strategy that did not actually modernise anything.
The right rhythm is honest. Most workloads deserve replatform. A small number deserve rebuild. A larger number than teams expect deserve retire. The work of modernisation is sorting, not avoiding the sorting.