Every organisation with a legacy codebase describes it the same way. It is a black box. Nobody wants to touch it. Everyone is terrified of what will break. The last person who really understood it left years ago.
The system usually still works, which is part of what makes the problem so hard. It is difficult to justify a modernisation programme for something that technically functions, even when the cost of maintaining it compounds every year and every new feature takes three times longer than it should.
The real cost of legacy systems
Legacy systems rarely fail suddenly. They fail slowly, in ways that are hard to measure until the cumulative drag becomes undeniable. Developer velocity drops. Onboarding new engineers takes months. Simple changes require understanding a web of undocumented interdependencies. Infrastructure costs stay high because the system will not run cleanly on modern cloud architecture. Security vulnerabilities accumulate in libraries that cannot be updated without breaking something else.
The number we hear most often from clients who have done the analysis is that new feature delivery is running at only a fraction of what the team could theoretically produce, because so much engineering time goes to understanding and working around the existing system rather than building forward.
Why modernisation projects fail
The instinct when faced with a legacy system is usually one of two things: ignore it and build around it, or rip it out and start again. Both tend to produce poor outcomes.
The big-bang rewrite is the more dangerous option. History is full of expensive, multi-year rewrites that either never finished or finished only to discover that the new system replicated the bugs and business logic of the old one because nobody fully understood what the old system was actually doing.
The ignore-and-build-around approach creates a different problem: two systems, inconsistently maintained, with business logic split across both and a growing integration layer that becomes the next legacy problem.
The archaeological approach
What we call Digital Archaeology is a disciplined alternative. Rather than rewriting or ignoring, we start by understanding deeply, completely, and with documentation that survives the process.
That means reverse-engineering the codebase to produce architecture diagrams, data flow maps, and business logic documentation. It means building a characterisation test suite that captures what the system actually does so that any change can be validated against existing behaviour. Then it means replacing components incrementally, using patterns like the strangler fig, so the system stays live throughout the modernisation.
It is slower than a rewrite. It is dramatically more reliable. And in every engagement we have run this way, it has been considerably cheaper in total because the failed rewrite it replaces would have cost far more.
If your team is afraid to touch a legacy system, the answer is not to be bolder. It is to understand it well enough that the fear goes away. That is where we start.