Still Running After All These Years: The Ancient Software Holding Up British Life

Every developer has a horror story about legacy code. Far fewer of us have thought seriously about why that legacy code is still there — and why, in several cases, it's outlasted every attempt to replace it.

Because here's the uncomfortable truth: a lot of the software propping up British daily life is older than the junior developers maintaining it. And it mostly works.

The Mainframe Under the Bank

Start with banking. A meaningful chunk of UK payment processing still touches mainframe systems written in COBOL, some descended from codebases dating back to the 1970s. These machines process batch settlements overnight, handle enormous transaction volumes, and — crucially — have fifty years of edge cases baked in. Every obscure pension rule, every bank holiday quirk, every rounding convention from decimalisation: it's in there.

Why hasn't it been replaced? Because nobody can fully specify what it does. A replacement project has to match behaviour that only exists as millions of lines of code and the memories of retired staff. Several big banks have tried; the graveyard of abandoned migrations is well documented. The realistic strategy most have settled on is strangler-fig migration: peel off one service at a time, decade by decade.

VB6 and the Booking System of Doom

Away from the big institutions, the picture gets more charming. Talk to developers at UK councils, leisure centres and travel firms and you'll keep hearing about Visual Basic 6 applications — grey Windows forms, Access databases on a shared drive, one person in the office who knows how it all hangs together.

One reader told us about a holiday park booking system written in 2003 that's still taking deposits daily. It survived because it matches the business exactly: the pricing rules, the seasonal quirks, the way the owner likes the reports. A modern SaaS replacement was trialled in 2019. Staff hated it. The VB6 app won.

Is that a failure? Partly, yes — it's a bus factor of one and a security posture best described as 'hopeful'. But it's also evidence that software which fits its users beats software that's merely fashionable.

The NHS and the Fax Machine Problem

The NHS deserves its own section in any honest discussion of legacy tech. Fax machines persisted in GP surgeries long after they vanished elsewhere, not out of stubbornness but because the surrounding systems — referral workflows, information governance rules, interface obligations — were all built around them. Remove the fax and you have to rebuild the process, the training and the compliance sign-off around it.

That's the pattern across legacy estates: the software is the cheap part. The process, the contracts, the institutional knowledge wrapped around it — that's the expensive part.

What This Means for Your Career

Here's the practical takeaway for UK developers: legacy skills pay, and they pay oddly well. Contractors with COBOL experience command rates that would make a React specialist wince. VB6, Delphi, classic ASP — the talent pools are tiny and the demand, while niche, is persistent.

There's also a genuine career angle beyond the money. Being the person who can read the old system, document it, and de-risk the migration makes you indispensable in a way that greenfield work rarely does. The hardest engineering problem in Britain right now isn't building new things. It's understanding what the old things do well enough to replace them safely.

So next time you sneer at a twenty-year-old system, ask what it's survived: the crash of 2008, a pandemic, every platform migration since. Then ask whether your microservices architecture will still be running in 2044. Old doesn't mean broken. Sometimes it just means battle-tested.