The 7 R's of Cloud Modernization: A Practical Guide

Ask three different consultants how to modernise a legacy system and you'll get three different frameworks, each with its own acronym, each presented like it's the first time anyone's thought about this. Underneath the branding, almost all of them collapse into some version of the same seven decisions, usually called the 7 R's. It's a genuinely useful framework. It's also routinely taught as a checklist, which misses the point entirely.

The 7 R's aren't a menu you pick from once. They're a set of trade-offs, and the company that gets modernisation right isn't the one with the cleverest framework — it's the one honest enough to admit which R they're choosing for the wrong reasons.

So here's the practitioner's version. What each one actually means, when it's right, and — more usefully — when people pick it because it's comfortable rather than because it's correct.

Retire

Turn it off. Stop paying for it, stop maintaining it, stop worrying about it.

This is the R nobody wants to pick and almost everybody should pick more often. Every estate we've looked at has systems running that nobody uses, reports nobody reads, integrations that exist because someone was afraid to ask if they still mattered. Retiring them costs nothing technical and saves real money — license fees, server costs, the cognitive load of "we have to remember that thing exists when we plan anything."

The reason it gets skipped isn't technical, it's organisational. Nobody wants to be the person who turned off a system that turned out to matter to someone in finance who never spoke up in the meeting. So the safe move, organisationally, is to leave it running forever rather than ask the question. That's how companies end up paying for infrastructure nobody can explain.

Pick this when: usage data — actual usage data, not a guess — shows nobody's touching it, or the business function it served doesn't exist anymore.

Don't pick this when: you haven't actually checked. "I think nobody uses this" is not the same as "nobody uses this," and the difference matters when you've already deleted it.

Retain

Leave it exactly where it is. Don't touch it.

The most underrated R, and the one most likely to be the right call for a system that's old, ugly, and working fine. Not everything needs modernising. A lot of advice in this space implicitly assumes that legacy equals bad, and it doesn't — legacy means old, and old systems that nobody's had to think about in five years because they just work are, in a real sense, a success story, not a problem to solve.

The honest reason companies retain things they shouldn't is fear of touching something they don't understand. The honest reason companies modernise things they shouldn't is a desire to look busy on a roadmap. Both are wrong for the same reason: the decision should be driven by risk and cost, not by how the system makes anyone feel.

Pick this when: the system is stable, the risk of touching it outweighs the benefit, and nobody's actively blocked by it.

Don't pick this when: "stable" is doing a lot of work to disguise "nobody understands it enough to be confident changing it" — that's not stability, that's risk you haven't priced yet.

Rehost

Move it to the cloud as-is. Same software, same architecture, just on different infrastructure — sometimes literally just picking up a virtual machine and putting it somewhere else. Often called lift-and-shift, usually said with a slight sneer, as if it's the unsophisticated option.

It's not unsophisticated. It's often exactly right, and the sneer is doing real damage to companies that get talked out of it by people who want to sell something more elaborate. Rehosting is fast, comparatively cheap, low-risk, and gets you out of a data centre contract or off ageing hardware quickly. It doesn't fix any underlying architectural problems — but sometimes you don't need to fix them yet, you just need to stop the data centre bleeding you dry on a renewal.

Pick this when: the urgency is real (a contract's ending, hardware's failing, a data centre's closing) and you need to move now, with the deeper rework planned as a second phase rather than skipped entirely.

Don't pick this when: it becomes the destination instead of a step. We've seen companies rehost and then never come back to do the actual modernisation work, because the pressure that forced the move is gone and nothing else creates the same urgency. If you rehost, put a real date on the next phase, or it won't happen.

Replatform

Move it to the cloud with some changes — usually swapping out a piece of infrastructure for a cloud-native equivalent without rewriting the application itself. Migrating a self-managed database to a managed cloud database service is the classic example: same application code, but now someone else handles patching, backups, and scaling.

This is the most genuinely underused R, in our experience, because it sits in an awkward middle ground that's harder to pitch than the other options. It's not as simple a story as "lift and shift," and it's not as dramatic a story as "we rebuilt it properly." But it often delivers the best ratio of effort to benefit — meaningful operational improvement (someone else managing your database infrastructure is a real win) without the cost and risk of a full rewrite.

Pick this when: there's a clear, contained piece of infrastructure causing real operational pain — usually a database or a messaging layer — that has a mature managed equivalent in the cloud.

Don't pick this when: the application itself is the actual problem. Swapping the database underneath a badly designed application doesn't fix the application; it just moves the same problems onto newer infrastructure.

Refactor

Restructure the existing code without changing what it does from the outside — cleaning up the internals, breaking apart tangled logic, removing duplication, making it testable. The system behaves the same; the inside is less of a horror to work in.

This is the seductive middle ground, and it's where most modernisation efforts quietly stall. It feels responsible — you're not throwing anything away, you're improving it — and that feeling is exactly the trap. Refactoring without a clear, bounded goal turns into an open-ended project that never quite finishes, because there's always one more thing that could be cleaner. We've watched refactoring efforts run for over a year with no shipped business value, because "improve the code" doesn't have a finish line unless someone draws one.

Pick this when: you can name the specific thing the refactor unlocks — faster releases, the ability to add a feature that's currently too risky to attempt, fewer production incidents — and you can put a boundary around the work.

Don't pick this when: the goal is just "make it better" with no specific business outcome attached. That's not a modernisation plan, that's an open invitation to spend a year polishing something nobody asked you to polish.

Rearchitect

Change the fundamental structure of the system — splitting a monolith into services, moving from a request-response model to an event-driven one, redesigning how data flows through the business. This is real engineering, takes real time, and is usually the option people reach for when they actually mean "refactor" but want it to sound more impressive in a steering committee deck.

Done for the right reason, rearchitecting is how a system that's hit a genuine structural ceiling — it can't scale, can't be split across teams, can't support a new business model — gets the redesign it actually needs. Done for the wrong reason, it's an extremely expensive way to rebuild something that was working fine, driven by an engineer's understandable but commercially irrelevant desire to use a more interesting pattern.

Pick this when: there's a structural limitation actively blocking the business — teams can't deploy independently, the system can't handle the next order of magnitude of load, a new business line genuinely can't be supported by the current shape of the system.

Don't pick this when: the justification is mostly aesthetic. "This would be architecturally cleaner" is true of almost every system ever built and is not, by itself, a business case.

Replace

Throw it out, buy or build something new. The most dramatic option, and the one with the widest range of outcomes — from "this transformed the business" to "this is the most expensive mistake the company made that decade," sometimes for the same kind of project at different companies.

Replace is right when the existing system genuinely cannot do what the business now needs and no amount of incremental change gets it there — the underlying model is wrong, not just the implementation. It's wrong when it's chosen because rewriting feels more satisfying than untangling what exists, which is a more common motivation than anyone likes to admit, especially among engineers who didn't build the original system and don't enjoy maintaining someone else's decisions.

Pick this when: the gap between what the system does and what the business needs is fundamental, not incremental — and you've actually tested that assumption against the other six options first.

Don't pick this when: it's the first option considered rather than the last one standing. Replace should be what you arrive at after ruling out the others, not where you start because starting fresh sounds more appealing than reading someone else's code.

The part everyone skips: this is a portfolio decision, not one decision

Here's the thing the framework doesn't say loudly enough: you don't pick one R for your whole estate. A real modernisation programme runs all seven, simultaneously, against different parts of the same business — retire the three reporting tools nobody opens, retain the billing system that's ugly but rock solid, rehost the thing on a dying contract, replatform the database that's caused four outages this year, refactor the checkout flow before it gets a new feature, rearchitect the order system that can't handle Black Friday anymore, replace the CRM that was wrong for the business five years ago and has only gotten more wrong since.

Treating modernisation as one big decision — "are we doing cloud migration or not" — is how programmes balloon into multi-year, multi-million-pound efforts that lose executive patience before they deliver anything. Treating it as a portfolio of dozens of smaller decisions, each with its own R, its own cost, its own timeline, is how it actually gets done. This is also, not coincidentally, why we start every assessment by mapping the whole estate before recommending anything — you can't make good portfolio decisions about parts you haven't looked at yet.

The one honest test, across all seven

Before committing to any of them, ask the same question: what business outcome does this actually unlock, and how would we know if it worked? If the honest answer is "the architecture would be nicer" or "it would feel more modern," that's a signal to slow down, not speed up. The R you should pick is the one that's attached to a number someone in the business actually cares about — not the one that's most interesting to build.

---

Plexa Solutions runs a fixed-scope Cloud + AI Modernization Assessment that maps an estate against exactly this framework — and gives you a costed, prioritised plan before anyone commits to a direction. plexasolutions.ie