Legacy modernization

Your business keeps running. The system changes underneath.

Replacing a part is the smaller half. Keeping the old one answering correctly until the new one has earned the switch is where the schedule and the budget go.

Book a working sessionSee how the order is decided

The system did not change. What it is asked to do did.

Your system does what it was built to do, most days. It was extended over years by people who are no longer there, under deadlines that were real at the time, and each of those decisions made sense on the day it was made.

What is asked of it now is not what was asked then. New channels to serve, new reporting to produce, new rules to comply with, and people who expect an answer in the moment rather than at the end of the day.

Each of those arrives as a request for a change, and each one is estimated by people who cannot fully establish what else it will reach. The documentation describes a version that no longer exists, and whoever could have answered from memory has moved on.

So every estimate carries a margin for the unknown, and that margin grows every year whether or not anything is done. That is what the gap costs, and it is not downtime. It is the speed at which the business is still able to change its mind.

AI agents can only act on what they can read.

What is being asked of these systems is new: that an agent can find out what they hold and act on it, without a person in the middle translating.

Most systems that have been running for years cannot answer that, and the reason is not their age. It is that what they know is spread across code, stored procedures, scheduled jobs and conventions nobody wrote down, the same reason they are hard to explain to a new engineer.

That overlap is the useful part. A description of what the system holds, where its boundaries are and which operations are safe to call is most of the work in both cases, which means it does not have to be a separate programme with its own budget.

It is worth settling before the modernization plan is fixed, because it changes what finished means.

Writing the replacement is no longer the slow part.

Models read unfamiliar code well, and they produce something that looks equivalent quickly. That part of the work has genuinely got cheaper, and there is no reason to expect it to get more expensive.

The proof has not got cheaper. Before the old component can be switched off, somebody has to establish that the new one behaves the same way, including in the cases nobody wrote down, the ones that exist because a customer complained once and a rule was quietly added.

That evidence is not generated. It is built, out of the system’s own behaviour: the data it has already processed, the exceptions it already handles, the outputs it has already produced and that somebody downstream already trusts.

A programme that produces new code quickly and evidence slowly has not become faster. It has moved the risk to the end, which is the most expensive place to find it. Most of our effort goes into the second half.

Which part to change first, and why that one.

The order is not a matter of taste, and it does not come from the technology. It comes from three things that are true about every part of your system.

How often it has to change

The parts the business keeps asking to change are where the cost of the current system is actually being paid. A part nobody has needed to touch in years is cheap to leave alone, however old it looks from the outside.

What stops if it stops

A component that can fail for an hour without anyone outside noticing carries a different risk from one that stops invoicing. That does not automatically put it later in the order, it puts it in a different kind of work, with different evidence required before it moves.

Whether anyone can still explain it

Where nobody can say what a part does, no estimate for changing it is real. Those parts get read before they get scheduled, and that reading is what turns a plan into something the business can commit to.

What gets measured is agreed before anything is changed

Those are the baselines, and they are taken while the system is still untouched, because afterwards they cannot be recovered.

A percentage carries four things: what was measuredwhat it was beforewhat it is nowwho measured it. Without those, it is a number that reads like evidence and is not.

Four questions this page expects to get.

  1. How do you start if nobody here can fully explain the system?

    That is the normal case, and it is the reason the first deliverable is the explanation rather than a plan. It is built from what the system does, its behaviour, its data, its interfaces, rather than from interviews alone, because the interviews are exactly where the gaps are.

  2. Can this happen while the system stays in production?

    Usually yes, and that constraint is what decides how the work can be sequenced at all. Where it cannot, that is worth establishing before the budget is set rather than after.

  3. How long before anything is visible?

    The reading of the system exists before any code changes, so there is something to review early. After that, which part moves first is decided by the criteria above, and one of the things those criteria weigh is how soon the business can see the difference.

  4. What happens to the team that maintains the system today?

    They are the main source for everything that cannot be read out of the code, and they are who the explanation is written for. A modernization that leaves the team unable to change the result has moved the problem rather than solved it.

Start with the explanation, Book a working session not with the plan.

A reading of your system, delivered as a document: what it does today, which parts carry the cost of change, and the order we would work in. It is yours whether or not anything else follows.