Replacing a system people depend on

Nobody sets out to keep a system running for twenty-five years. It happens because every year the case for replacing it loses to something more urgent, and every year it gets harder.

Then one day it becomes unavoidable, and you get handed the project.

Why I can’t give you a failure rate

I went looking for a number and I’m going to tell you why I’m not using one.

The figure you’ll see is that most modernisation projects fail. Depending on which page you land on, that’s 70%, or 70 to 79%, or 70 to 88%. Every one of those ranges comes from a firm that sells modernisation services, and none of them publishes a methodology or defines what counts as failure.

A range that wide isn’t a measurement. It’s a marketing input.

What I’ll say instead is what’s actually observable. The public failures are real, they’re documented, and they’re large. TSB’s 2018 banking migration is the one most people in Europe remember. Queensland Health turned a payroll upgrade into one of the most expensive public sector IT failures in Australian history. Southwest’s December 2022 meltdown, where decades-old crew scheduling software couldn’t cope with a winter storm, cancelled flights in the thousands.

Read the post-mortems on those and you notice something. Almost none of the root causes are about choosing the wrong technology.

What actually breaks

The system is the documentation. This is the one that gets underestimated every time. Twenty years of business rules are encoded in that system, and a meaningful share of them exist nowhere else: not in a spec, not in a process map, not in anyone’s head as a complete picture. When you replace it, you’re not migrating software. You’re trying to recover institutional knowledge from a codebase, and you’ll find rules nobody can explain and nobody is willing to remove.

The people who know it are leaving. McKinsey’s phrase for this is that the system is the documentation, and the risk arrives when the personnel do. This isn’t a hypothetical curve. The people who built it are retiring now, and every year you defer, more of the explanation walks out.

Users have muscle memory, and it’s worth more than your UX. Somebody who has used the same green screen for fifteen years is faster on it than they’ll be on anything you build, for at least six months. Your new system can be better in every measurable way and still be slower for the person using it on day one. If you haven’t planned for that gap, they’ll route around you, and in a lot of organisations they can.

Nobody agreed what "the same" means. Parity sounds like a technical question and it’s a political one. Does the new system have to do everything the old one did, including the things three people use twice a year? Whoever answers that determines your timeline, and if you never make them answer it, the answer defaults to yes.

The edge cases are the product. The boring middle migrates fine. The account that was set up wrong in 2011, the customer with two records, the manual override somebody added for a regulator — those are where the project actually lives.

The sequencing question, which is the only one that matters

There are two ways to do this and everyone knows the trade.

Big bang means one cutover, one date, everything moves. It’s cheaper if it works and it’s the version that produces the headlines when it doesn’t. Phased means running both systems for a while, which is expensive, tedious, and much harder to get wrong catastrophically.

I’d take phased almost every time, and not because of the risk profile. Because of what it does to information.

A phased migration gives you evidence while you can still act on it. You learn that the reconciliation logic is wrong in month three rather than on cutover night. You find the undocumented rule when one department moves rather than when all of them do. Big bang concentrates every discovery into the worst possible week.

The argument against is real: running two systems costs money and confuses people, and there’s a version of phased that never finishes and leaves you maintaining both forever. That’s a genuine failure mode. The defence is naming the end date and the retirement criteria at the start, and treating the old system’s shutdown as a deliverable with an owner rather than something that happens eventually.

What I do differently on these

Record the baseline before anything moves. How long does the current process take, how often does it fail, what does it cost. You’ll need it to prove the replacement worked, and more importantly you’ll need it when somebody claims the new system is slower. Sometimes they’re right. Without the baseline it’s your word against theirs.

Find the rules that exist only in the code. Budget real time for this. It’s an archaeology project and it’s the single most underestimated line in every plan I’ve seen.

Ask who loses. Somebody’s job gets harder, somebody’s workaround stops working, somebody’s team gets more visible. Those people aren’t obstacles, they’re information, and if you find them in month two they can help you. If you find them at cutover they can stop you.

Write the parity decision down. Which of the old system’s behaviours you’re deliberately not reproducing, and who signed that off. This is the document that saves you in month nine.

Treat the shutdown as a deliverable. With a date, an owner and a definition of done. Otherwise you have not replaced a system, you have added one.

The uncomfortable part

The organisations that handle this well tend to be the ones that never let it get this bad. McKinsey’s April 2026 work describes what it calls deliberate modernisers: organisations that put at least a third of their technology budget into change, keep run costs at least 20% lower than peers, and replace legacy systems rather than layering new capability on top.

That’s useful as a description of what good looks like and it isn’t much help if you’re already twenty-five years in. If you are, the honest position is that this will take longer than the plan says, the hard part is organisational, and the most valuable thing you can do in the first month is find out what the system does that nobody can explain.

Common questions

Why do legacy modernisation projects fail?

Overwhelmingly for organisational rather than technical reasons. The old system is usually the only complete record of how the business actually works, the people who understand it are retiring, users have years of muscle memory that no interface improvement offsets immediately, and nobody has agreed what parity with the old system means. Post-mortems of the well-known public failures rarely identify the wrong technology as a root cause.

Is it true that 70% of modernisation projects fail?

Treat that figure with suspicion. Published ranges run from 70% to 88%, every version comes from a firm selling modernisation services, and none defines what counts as failure or publishes a methodology. A range that wide is not a measurement. The documented individual failures are real and large, which is a better basis for planning than an unsourced percentage.

Should you do a big bang or a phased migration?

Phased, in most cases, and the strongest argument is not risk but information. A phased migration surfaces problems while you can still act on them: you learn the reconciliation logic is wrong in month three rather than on cutover night. Big bang concentrates every discovery into one week. The real danger with phased is never finishing, so name the end date and the retirement criteria at the start.

What is the most underestimated part of replacing a legacy system?

Recovering business rules that exist only in the code. Years of logic accumulate in these systems and a meaningful share is recorded nowhere else. Budget it as an archaeology project with real time attached, because you will find rules nobody can explain and nobody is willing to remove.

Why do users prefer the old system even when the new one is better?

Because they are genuinely faster on it. Someone who has used the same interface for fifteen years will outperform themselves on a better system for months. That gap is real and temporary, but if it is not planned for, people route around the new system and in many organisations they can.

What should you measure before a legacy replacement?

The current baseline: how long the process takes, how often it fails, what it costs. You need it to demonstrate the replacement worked, and you need it when someone claims the new system is slower. Occasionally they are right, and without a baseline it is one opinion against another.

How do you avoid running two systems forever?

Treat the old system's shutdown as a deliverable with a date, an owner and a definition of done, agreed at the start alongside the retirement criteria. A phased migration without a named end state does not replace a system, it adds one.