Legacy system modernisation is the work of updating ageing software so it costs less to run, carries less risk, and stops slowing the business down. Done well, it is rarely a single dramatic rewrite. It is a sequence of deliberate changes that keep the lights on while the old system is replaced piece by piece, with value arriving along the way rather than at the end.
This page is the hub for our modernisation writing. It covers why legacy systems hold organisations back, how to assess and prioritise what you have, the realistic options for each system (the 6 Rs), the strangler fig pattern for replacing a system without a risky big-bang, how to keep trading while you change things, and how to build a business case that survives a budget review. Where it helps, it links out to deeper pieces on architecture and strategy.
Why legacy systems hold organisations back
A legacy system is not just old software. It is software that has become hard to change, expensive to keep alive, or risky to depend on, regardless of when it was built. The cost shows up in four places.
- Cost. Old platforms carry licence fees, ageing infrastructure, and a maintenance tax that grows as the code accretes workarounds. A large share of the IT budget goes on keeping things running rather than improving them.
- Risk. Unsupported components, unpatched dependencies, and undocumented behaviour create security and compliance exposure. The more the business relies on a system nobody fully understands, the more fragile the operation becomes.
- Slow delivery. Brittle, tightly coupled code makes every change slow and frightening. A small feature request turns into a regression-test marathon, and the lead time from idea to live stretches into months.
- Talent. Few engineers want to spend their careers on a dying stack, and the people who know it best are often close to retirement. Hiring gets harder and key-person risk climbs.
These pressures compound. The harder a system is to change, the more workarounds it accumulates, which makes it harder still. Modernisation is how you break that loop.
How to assess and prioritise
You cannot modernise everything at once, and you should not try. Start by mapping the estate against two questions: how much business value does this system carry, and how healthy is it technically. Plotting systems against those two axes tells you where to act first.
High value and poor health is where modernisation pays off most, so it goes to the front of the queue. High value and good health can be left alone for now. Low value and poor health is often a candidate for retirement rather than investment. Low value and good health rarely justifies the disruption. The point is to spend effort where it returns the most, not to treat the whole estate as one undifferentiated rewrite.
- Map the estate. List the systems, what each one does for the business, and what depends on it. Verify: a shared inventory that names every system, its owner, and its critical dependencies.
- Score value and health. Rate each system on business value and technical health. Verify: every system has a position on the value-health grid that owners agree with.
- Pick the first slice. Choose a high-value, poor-health area where a contained change can prove the approach. Verify: a slice small enough to ship in weeks, with a measurable outcome.
- Sequence the rest. Order the remaining work so each phase funds or de-risks the next. Verify: a roadmap where early slices return value, not a plan that pays out only at the end.
The modernisation options: the 6 Rs
Once you know which systems to act on, you need to decide what to do with each one. The 6 Rs are a practical set of options. Most estates end up with a mix, because the right answer for a payroll system is rarely the right answer for a public-facing product.
- Retain. Leave the system as it is, for now. Right when it works, carries little risk, and a change would cost more than it returns. Retaining is a decision, not neglect, so it should be reviewed.
- Retire. Switch the system off. Right when it is low value, duplicated elsewhere, or no longer used. Retiring removes cost and risk for almost no effort, and is often the cheapest win in the estate.
- Rehost. Move the application onto modern infrastructure with no real code change, often called lift and shift. Right for a quick exit from end-of-life hardware or a data centre, when speed matters more than improving the application itself.
- Replatform. Move with light, targeted changes, such as swapping a self-managed database for a managed service. Right when small adjustments unlock a meaningful cost or operability gain without a full rebuild.
- Refactor. Improve the internals while keeping behaviour the same. Right when the system is worth keeping but the code has become hard to change, and cleaner structure will speed up future work.
- Rearchitect or replace. Rebuild the system around a new architecture, or replace it with new software. Right when the current design cannot support what the business needs, and incremental changes will not get it there.
The deeper architecture choices sit underneath the last R. Whether to break a system into services or keep it as one deployable unit is a decision in its own right, covered in microservices vs monolith. For platforms built around composable, API-first, cloud-native and headless components, our guide to MACH architecture goes into how that pattern works in practice.
The short version
Modernisation is not one decision. Assess each system on business value and technical health, assign it one of the 6 Rs, and replace the systems you keep incrementally using the strangler fig pattern. Ship value in slices, keep trading on the old system until each replacement is proven, and let evidence drive the sequence rather than a fixed upfront plan.
The strangler fig pattern: replacing without a big-bang
The riskiest way to modernise is the big-bang rewrite: build a complete replacement in parallel, then cut over to it in one go. The trouble is that all the value is locked behind a single launch, the new system has to match years of accumulated behaviour before it can go live, and if the cutover fails there is no gentle way back. Plenty of large rewrites have failed exactly here.
The strangler fig pattern avoids that. The name comes from the fig that grows around a host tree and gradually takes its place. In software, you build new services around the legacy system and route functions to them one slice at a time. A façade sits in front of both, sending each request to either the old system or its replacement. As each slice moves across and proves itself in production, the legacy system carries less and less, until it can be switched off.
This keeps risk small and contained. Each slice is a real, reversible change rather than a leap of faith. The business runs on the old system for everything not yet migrated, so there is no moment where the whole operation depends on untested code. And because slices ship continuously, value arrives throughout the programme instead of at a distant end date. It is the same incremental, value-first delivery our squads use on every modernisation: a cross-functional team owning an outcome, shipping working software in short cycles, and adjusting on evidence.
Keeping the business running during change
Modernisation usually happens on systems that cannot stop. The skill is changing the engine while the vehicle keeps moving. A few practices make that possible: route traffic through a façade so you can shift functions gradually and roll back a slice without touching the rest; keep the old and new systems in sync on shared data until a slice is fully migrated; and put monitoring in place before you cut over, so you see problems in minutes rather than from a customer complaint.
This is the heart of our digital platforms work. For Bauer Media, we moved 34 media sites off a monolithic WordPress estate to a headless architecture on Next.js and GraphQL, migrating sites incrementally rather than risking the whole portfolio in one cutover. For Motive Partners, we re-architected a FinTech platform to event-driven microservices and readied it for acquisition and its first bank client, work where the platform had to stay dependable throughout.
Modernisation also covers the internal systems that run an operation, not just public products. At Darktrace, we modernised internal CRM and analytics so the teams relying on them had tools that kept pace with the business. And in government, the DEFRA DxT programme replaced paper forms with accessible online services now handling more than 14 million transactions a year, a public-facing example of moving a process to modern, maintainable software without breaking the service while doing it. We do similar work across the public sector, where accessibility and reliability are not optional.
How to build the business case
Modernisation competes for budget against features that are easier to sell, so the case has to be made carefully. The strongest framing starts with the cost of doing nothing, because that cost is real and growing even if nobody has written it down.
Start with the cost of doing nothing
Add up what the legacy system already costs: licence and infrastructure spend, the share of engineering time absorbed by maintenance and firefighting, the security and compliance exposure, and the delivery speed lost to brittle code. Most organisations underestimate this, because the cost is spread across many budgets and never totalled. Putting one number on it changes the conversation.
Phase the investment
Set that cost against what modernisation unlocks: lower run costs, lower risk, faster delivery, and the ability to build things the old system blocked. Then phase the spend. Rather than asking for the whole budget against a payoff years away, sequence the work so early slices return value and help justify the next stage. That is the practical advantage of incremental delivery for the business case as much as the technology: it lets sponsors see results before they commit the full investment.
Modernisation rarely sits on its own. It is usually one strand of a wider change in how an organisation builds and runs software, which is the subject of our digital transformation strategy guide.
Next steps
If a legacy system is holding back what you need to ship, start by naming the cost it imposes and the outcome you want, then pick a first slice small enough to prove the approach in weeks. From there, read more about our digital platforms service, or see how incremental modernisation played out on Bauer Media and Motive Partners.