Legacy Systems Aren't the Problem. Not Knowing Them Is.

Most engineering teams have a system they've quietly made peace with. It doesn't get touched unless it's absolutely necessary. When it does, the change request comes with a level of caution that seems out of proportion, until you realise nobody is entirely sure what's connected to what anymore.

COBOL is the obvious example most people reach for. A substantial share of the world's banking, insurance, and government infrastructure still runs on it, not out of nostalgia, but because it works. These systems have been running longer than some of the people maintaining them have been alive.

The Codebase Was Fine. Everything Around It Wasn't.

For a long time, the industry told itself a convenient story: old language, old stack, old problem. Replace the technology and the problem goes away.

That diagnosis was mostly wrong.

The technology was rarely what made these systems difficult to work with. What made them difficult was everything surrounding the code. Documentation that hadn't been updated in a decade. Institutional knowledge that walked out the door every time a senior developer retired. Architectural decisions that made sense in 1998 but were never written down for anyone who came after.

Systems accumulate years of patches, fixes, and quiet workarounds. Nobody sits down and draws the full picture. Gradually, the mental model of how the system actually works stops existing anywhere except in a few people's heads, and eventually, not even there.

This is how a perfectly functional system starts eating a disproportionate share of the IT budget just to stay running. It's not the system that's fragile. It's the organisation's understanding of it. When engineers don't know what a change will ripple into, even a small modification feels dangerous. So they leave it alone. And the cycle continues.

What AI Actually Changes Here

Using AI to help with legacy systems isn't a new idea. What's genuinely new is that it's now practical.

Modern AI tools can work through large, complex codebases in a way that wasn't feasible before, tracing dependencies, surfacing how different parts of a system interact, and generating documentation that reflects how the system actually behaves rather than how someone once intended it to behave. Analysis that used to take a team of consultants several months can now be done in a fraction of that time.

More importantly, it can be repeated. Refined. Updated as the system evolves.

This changes the starting point for modernisation work. Instead of beginning a project with a foggy sense of what you're dealing with, teams can begin with a real picture of the system in front of them.

What This Looks Like in Practice

Picture a core banking system that's been running for 15 or 20 years. It processes transactions reliably every day. But the original developers have long since moved on; the documentation is several versions out of date, and the system has been patched so many times that nobody has a clear view of its full architecture.

In that situation, changing something as routine as a validation rule can take weeks, not because the change is inherently complex, but because nobody can confidently predict what it will affect. Every change becomes an exercise in caution, testing, and tribal knowledge.

That's where most legacy systems get stuck. Not because they're unstable, but because they've become opaque.

Modernisation Isn't Rewriting Code

There's a common misconception worth clearing up. Modernisation isn't synonymous with rewriting an old system in a new language. That framing leads to the kind of large, expensive, high-risk projects that have a poor track record.

A more grounded approach works in sequence: understand the system first, document it properly, then plan how it should evolve, and only then begin making changes, with validation built into every step.

Done this way, legacy and modern systems can run in parallel for a period. Teams can compare outputs, build confidence in what they've changed, and identify discrepancies before they become problems. That parallel-running phase alone takes a significant amount of risk off the table.

Rethinking What Legacy Systems Actually Are

When you finally understand a legacy system properly, not theoretically but in detail, something shifts in how you think about it.

These systems have been shaped by years, sometimes decades, of real business decisions. Every edge case they handle, every rule they encode, represents something that actually happened and needed to be dealt with. That's not technical debt. That's accumulated knowledge about the business, about its customers, about edge cases that newer systems haven't encountered yet.

The question stops being "how do we replace this?" and becomes "how do we build on what already works?"

Being Realistic About What This Involves

It's worth being honest about the limits here.

This is not a quick fix. Modernising a critical legacy system is still a months or years long undertaking. The most consequential decisions, what to prioritise, how to manage risk, how to align technical changes with business strategy, still require human judgment. No tool changes that.

What changes is the quality of information available when those decisions get made. Teams can move with more clarity, more confidence, and less of the uncertainty that usually inflates timelines and costs.

A Third Option

For a long time, organisations felt like they had two choices with legacy systems: leave them alone and keep paying the maintenance tax, or commit to a full rebuild and accept the risk that comes with it.

Neither option is particularly good. The first is expensive and slow. The second is risky and often fails.

What's emerging now is a genuine third path. Analyse the system, understand how it actually works, and modernise it in increments. Validate each change. Measure each improvement. Let the system evolve without disrupting the business that depends on it.

The Real Barrier Is Falling

Legacy systems became a source of anxiety not because they were bad engineering, but because understanding them became genuinely difficult over time. People left, documentation lapsed, and complexity compounded.

That's the barrier that's now starting to come down.

The organisations that make real progress on legacy modernisation in the coming years won't be the ones that found a way to avoid the hard work. They'll be the ones that built a real understanding of their systems and used that understanding to evolve them deliberately.

This is the philosophy behind how we approach legacy work. We start with understanding, mapping how a system actually behaves, where its dependencies lie, and what a realistic path forward looks like. Modernisation follows from that foundation, step by step, with risk managed at every stage.

The goal isn't to rebuild for the sake of it. It's to unlock what already works and extend its life on better terms.