Every organisation with ageing core systems eventually faces the same temptation: replace the lot in one go. A new platform, a clean slate, everything modern by a single go-live date.

Sometimes that’s the right call. More often, the big bang turns into a long wait: years of investment before any benefit, a business that has to freeze change while it happens, and a go-live that concentrates every risk into a single weekend.

There’s another route to legacy system modernisation. It’s less dramatic and, in our experience, far more often successful.

Why big-bang replacements struggle

Big-bang programmes rest on a series of optimistic assumptions: that requirements can be fully known up front, that the business can pause its own change while the programme runs, that data will migrate cleanly, and that everyone will be ready on the same day.

Each assumption is reasonable on its own. Together, they compound. And because value only arrives at the end, confidence has to survive years of spending with nothing to show for it. When the inevitable delay comes, there’s no partial benefit to point to – only a revised date.

“In a big bang, value arrives last and risk arrives all at once.”

5 principles for incremental modernisation

1. Decouple before you replace

The legacy system usually isn’t the real problem. The problem is that everything new has to go through it. Every change request joins the same queue, waits on the same specialists, and is constrained by the same old architecture.

So break the dependency first. Put a layer between the legacy platform and the services that need its data – an API layer, for example – so new applications can be built at the pace the business needs, without waiting for the core to be replaced. For one housing association constrained by its legacy housing system, that approach unblocked the delivery roadmap and made rapid prototyping of a tenant self-service app possible.

2. Organise around capabilities, not systems

Big-bang programmes are usually organised around the technology being replaced. Incremental modernisation works better when it’s organised around business capabilities – customer contact, billing, field operations – each with a team that owns its improvement.

That shifts the question from “when will the new system be live?” to “what can we improve for customers this quarter?”

3. Bring critical capability back in-house

Many organisations that rely heavily on large system integrators find they’ve outsourced not just the work but the knowledge of how their own technology works. Modernising incrementally is a chance to rebuild that – insourcing the roles that matter most to the business and using partners for genuine specialism rather than for everything.

4. Show value early

The great advantage of the incremental route is that value arrives in weeks rather than years. Early, visible results do more than any business case to keep a modernisation funded and supported.

5. Keep the big decisions for when you know more

Incremental modernisation doesn’t mean never replacing the core. It means making that decision later, with far better information – about what the business needs, what the legacy system genuinely constrains, and what can simply be built around it.

Sometimes, by the time you get there, the big bang has become a small one.

When a big bang is still the right answer

Incremental isn’t always right. A full replacement may be the better option when the legacy platform is out of support and carries unacceptable security risk, when a regulatory deadline leaves no time for a phased route, or when the cost of running old and new side by side outweighs the risk of a single cutover.

Even then, the principles above still help: decouple what you can first, organise around capabilities, and find ways to release value before the final switch.

How to plan an incremental modernisation

An incremental approach still needs a plan – just a different kind. 4 steps give it shape.

1. Map capabilities and pain. List the business capabilities the legacy platform supports and score each on how much the current technology constrains it. That tells you where modernisation will create value first.

2. Choose your decoupling points. Decide where to put the layer between legacy and new: usually around the data and functions that the most valuable new services depend on.

3. Sequence by value and risk. Move the capabilities that create early, visible value and carry manageable risk first. Leave the most tangled, least valuable areas until you know more.

4. Plan the retirement as well as the build. Running old and new side by side has a cost. Every increment should say what legacy functionality it will switch off, and when.

Signs your incremental plan is drifting into a big bang

• each increment keeps growing because “it makes sense to do it all together”
• nothing legacy has actually been switched off
• go-live dates for several capabilities have started to converge
• the business has been asked to pause its own change until the programme is done

If you see these, stop and re-slice. The value of the incremental route comes from keeping each step small enough to land.

Common questions

What is legacy system modernisation?

Updating or replacing ageing core technology so it supports current business needs. It can be done through full replacement, through incremental approaches such as decoupling and gradual migration, or through a combination.

What’s the difference between big-bang and phased migration?

A big-bang migration moves everything to the new system at once, concentrating risk and delaying value until go-live. A phased approach moves capabilities incrementally, releasing value earlier and spreading risk.

How does an API layer help with legacy systems?

It sits between the legacy platform and newer applications, exposing data and functions in a modern way. New services can then be built without changing the legacy core, reducing dependency on it over time.

What this looks like in practice

A UK gas distribution network moved from total reliance on large system integrators to an adaptive, in-house delivery model without a big-bang transformation. A new customer engagement platform went live in 12 weeks, and IT operating costs fell by around half over the course of the change. Read the case study →