# Legacy systems are expensive because knowledge has decayed

> Legacy systems become expensive to change when the organisation loses reliable knowledge of how they actually work, where behaviour lives and what a change may affect.

Paper: 02.02
Published: 2026-09-10
Canonical: https://harten.io/papers/02-02-legacy-systems-are-expensive-because-knowledge-has-decayed/

Cover illustration: [View the title image](https://harten.io/media/papers/covers/v1/02-02-legacy-systems-are-expensive-because-knowledge-has-decayed.jpg?v=a7c2652ccd68). Illustrative cover artwork, not an application screenshot or a record of measured results.

When we talk about legacy, we tend to talk about technology first.

Old languages, old frameworks, unsupported platforms, ageing infrastructure.

All of that matters, but I don't think that is usually the hardest part.

The harder problem is that over time the organisation loses a reliable understanding of how the system actually works.

People leave. Documentation drifts. Business rules end up spread across application code, stored procedures, configuration, batch jobs and operational processes. Integrations change ownership. Workarounds become permanent. Exceptions become normal.

The system still works, but fewer people can explain why.

That is an important distinction, because most legacy systems are not difficult to change simply because the code is old.

They are difficult to change because the consequences of change are unclear.

An engineer may understand a function perfectly well and still not know what depends on it.

They may not know whether another application relies on the current behaviour, whether a nightly process expects a particular output, whether there is another version of the same rule somewhere else, or whether an operations team has built a manual process around an edge case that nobody documented.

This is where much of the cost appears.

Before the change can be made, someone has to reconstruct enough of the system to become comfortable that the change is safe.

That means tracing dependencies, reading code, checking database procedures, looking through tickets, comparing documentation with production behaviour, speaking to people who have been around long enough to remember why something exists.

A two day change becomes two weeks.

From the outside, that looks like poor engineering productivity.

Sometimes it is.

But often it is simply the cost of uncertainty.

The engineer is not spending ten days writing code. They are spending most of that time trying to work out whether the two days of code will break something else.

Organisations then compensate for this in a fairly predictable way.

They depend on people.

There is normally someone who knows that one service cannot be restarted at a certain time.

Someone who remembers why an apparently redundant table is still there.

Someone who knows that a field marked optional is actually required by a downstream process.

Someone who knows which bit of documentation can be trusted.

We call these people subject matter experts.

But in older systems they often become part of the system itself.

Not because the software calls them, obviously, but because the organisation cannot safely operate or change the software without them.

You only really see the problem when they leave.

The code has not changed.

The architecture has not changed.

But suddenly the system becomes much harder to reason about.

What disappeared was not technology.

It was knowledge.

I think this is an overlooked part of technical debt.

We normally think of debt as code quality, outdated libraries, unsupported infrastructure, architectural compromises.

But there is also knowledge debt.

The distance between what the system does and what the organisation can confidently explain about what it does.

That gap grows over time.

And it is one of the reasons modernisation can go wrong even when the migration itself appears successful.

You can move an application to a new platform.

You can rewrite it.

Containerise it.

Change the database.

Replace the user interface.

And still bring the same uncertainty with you.

The technology is now newer.

The understanding of the application is not necessarily any better.

In fact, if the modernisation is mostly translation, you can end up recreating behaviours that nobody properly understood in the first place.

That is why I think discovery has to come before transformation.

Before changing a consequential system, you need to build a sufficiently good account of what is there today.

What the application does.

Where the business rules live.

How the data moves.

What depends on what.

What interacts with it.

What happens outside the code.

What you know.

What you think you know.

And importantly, what you still do not know.

That last part matters more than it sounds.

Most documentation is written as though everything is known.

Real systems are not like that.

There will be gaps. Conflicting evidence. Dead code. Behaviour that cannot be explained from the repository alone. Things people believe are true but cannot prove.

I would rather have a system description that says "we do not know" than one that gives me a confident answer built on weak evidence.

At least then the uncertainty is visible.

And once it is visible, you can decide what to do with it.

This matters even more now that AI is entering software engineering.

AI can generate code quickly. It can analyse large volumes of code quickly. It can generate a very convincing explanation of an application quickly.

But a convincing explanation is not the same thing as understanding.

If the underlying evidence is incomplete, the answer can still look excellent.

That is probably the part we need to be most careful about.

The temptation will be to use AI to move directly to transformation because transformation is visible.

New code gets generated. Tests run. Applications appear.

But the harder and probably more valuable use of AI in legacy estates may come before that.

Use it to help reconstruct the system.

Trace relationships across thousands of artefacts.

Find where business rules are actually implemented.

Compare code against documentation.

Identify dependencies.

Surface contradictions.

Retain uncertainty instead of filling the gaps.

Build an evidence-backed description of the application that a human and a machine can both reason over.

Then transformation starts from a very different position.

The question is no longer simply whether we can generate the new system.

It is whether we understand the existing one well enough to know what we are changing.

I think that distinction is going to matter a lot.

Because legacy is not just old technology.

Quite often it is a system that still runs, but an organisation that has gradually forgotten how it works.

Modernisation has to recover that understanding before it tries to replace it.

---

*This paper is part of [The Modernisation Control Papers](https://harten.io/papers/). Read the complete series on harten.io.*