One of our clients was trapped by a decades-old system.
Replacing it cost too much, risked months of disruption and would exceed their available budget.
So, they asked the developer who knows their system whether AI could improve it. The answer was an emphatic “no”: too old and too fragile.
Nobody could challenge that because no one else knows how the thing works.
The two bad choices boards have lived with
If this sounds familiar, you’ve probably faced the same binary choice for years.
Approve a replacement you may not have the budget or appetite for. Or keep paying to keeps your ageing system exactly as it is.
For a long time, the second option felt safer, easier to control and cheaper.
But it also gave power to whoever has that system knowledge. Sometimes that’s one person, other times an IT team who all answer the same way.
An MD recently told me they were losing sleep over their creaking Access 97 system. Only one person understood it, and they were close to retiring. Nobody knew how they would fix it after that.
That’s how old software becomes a hostage situation and why breaking that dependency used to be expensive.
You no longer need to choose between a full replacement and indefinite dependence on an individual.
AI-assisted engineering changes the starting point. Give an outside team access, and they can read the code, database and configuration in days. They can then take on support, deal with what is exposed and document how the system works, without waiting for whoever has always controlled the answers.
The person with the final say
I hear about this type of developer a lot. Sometimes they are on the payroll, but often they’re a retained contractor. Either way, the pattern is similar. Every system request comes back with the same responses: “it’ll take weeks”, “it’s too risky” or simply “not possible”.
Nothing is documented, so the next system issue reinforces their position as the expert everyone needs.
Suggest using AI to move the dial and you’ll likely get a lecture on poor code quality or a flat refusal to let it anywhere near the system. Another client had developers who, until recently, refused to touch AI coding on principle.
Developers call it caution, but when no one else can test their answer, technical judgement risks becoming a veto on every system decision.
Why boards give in
Most leaders aren’t technical, so they accept reassurances that their old platform is safe behind a firewall, and safer still if it isn’t connected to the internet.
The real risks in systems over 15 years old usually stay hidden until a penetration test finds them, or a breach exposes them.
This isn’t only a technical problem. Recent Microsoft research found that organisational culture and managerial support drive far more of AI’s business impact than employee mindset or behaviour (67% compared with 32%). Legacy systems show that the barrier is often organisational, even when it seems purely technical.
Many older systems can still deliver more than anyone is getting out of them. The problem is getting past the old assumptions that prevent change.
Fragility: the right word for the wrong risk
Developers are right about the fragility of legacy systems, but often misjudge where it lies.
One change can easily have a knock-on effect and break something else. That’s the argument for reading your system properly, mapping it and testing it. AI-assisted reading finds the dependencies and builds a map of what exists, where the risks sit and what can safely change.
The bigger risks are the security ones: the sign-in pages that expose active accounts, platforms that stopped receiving security updates years ago or passwords readable in a settings file. None of these stops your system from working, so they never make it to the change list.
Quoting “weeks or months” for seemingly basic changes is the same story. Most of that time went on working out how the system behaved before anyone could safely touch it.
When the objection turns to AI, ask how the risk can be safely managed. As an example, for this work, we use approved enterprise tooling, so the code never trains the models behind it, and nothing reaches a live system until an experienced engineer has tested it.
How this works in practice
Our approach starts with support. We take responsibility for old systems, deal with their exposed risks first, document how they work and start reducing the technical debt that makes every change expensive.
Then the backlog starts to shrink. Reports nobody could previously build. A process that took too many steps. The integration that was always “too risky”, and the improvements quoted as if they were major projects.
None of this depends on a single developer or an internal IT team being the only route to an answer.
If this sounds like your current situation, book a 20-minute call to tell us what the business needs that your system won’t give you.
We’ll tell you whether we can take it on, what we’d examine first and how we would start cutting both that cost and your dependency.
RELATED: There’s a cheaper option than replacing your legacy software
