Nick Denning, Managing Director of Policy Monitor and its subsidiary Diegesis, explains the hidden costs of inaction and how legacy infrastructure stifles innovation
During my career, both in the military and IT, I have heard a familiar refrain: “It works. Why change it?” or perhaps more colloquially, “ain’t broke, don’t fix it” or “we’ve always done it this way”.
At first glance, this sounds like an economic strategy, often called “sweat the asset”. Unfortunately, doing nothing is seldom neutral. It exposes a range of risks that frequently materialise with significant impacts.
In denial
The most common reason for not investing in a system is “because we are replacing it in three years”, but organisations have been planning the replacement for ten years or more and may have had multiple failed attempts to replace it in the past.
In fact, the system is often “broken” because it is very “brittle”. Describing the code as “spaghetti” or “held together with sticking plaster” is the result of many small, poorly scoped changes made to keep a legacy system just surviving.
What do we mean by legacy?
Some technologies have been around since I entered the tech industry. ORACLE, IBM zSeries mainframes, COBOL programming, and C programming, for example. In my time, I have used technologies such as Informix and Informix-4GL, TUXEDO and Ingres, MySQL, Delphi, Java, PASCAL and FORTRAN, IBM WebSphere, FileNet and IBM MQ Series.
Which of these would we term as legacy? Certainly not the ORACLE RDBMS, but probably ORACLE FORMS as a development environment, perhaps TUXEDO and probably Ingres. Ingres, now owned by Actian, remains well supported by the vendor, but there is very little appetite for organisations to adopt it for new projects, and integrating Ingres applications, typically written in ABF or OpenROAD, is very difficult to leverage in new applications.
Innovation delayed is innovation denied
When infrastructure is rigid, every innovation initiative becomes a transformation programme. Every pound spent maintaining outdated systems is capital that cannot be invested in growth initiatives. But more subtly, legacy systems impose an ‘innovation tax’ on every new initiative – Extra integration work, manual regression testing, longer release cycles, higher change management overhead and increased governance complexity.
Every transformation project becomes progressively more complex as the number of steps required to get from the AS-IS to the TO-BE increases. Legacy systems don’t just slow innovation, they repel the very people who drive it.
Staff retention
Following on from the above topic of innovation, if there is no material development underway and the only strategy is shortcuts, it is difficult to retain staff with the appropriate seniority and experience to manage any innovation when it is finally required.
The most talented engineers want to build and experiment. They want to work with modern toolchains and cloud-native architectures. When organisations fail to modernise, they create a two-tier culture: A small group maintaining “the old world” and a group trying to build “the new world” around it.
The hidden cost? Erosion. Lost institutional knowledge. Escalating contractor spend. And a widening skills gap that becomes harder to close over time.
The illusion of stability
Legacy systems often give organisations a false sense of security. They’ve survived mergers, regulatory changes, and economic downturns – They’re battle-tested, but stability is not the same as adaptability.
In a world shaped by hyperscale cloud providers like Amazon Web Services, Microsoft Azure, and Google Cloud, customer expectations are set by companies that deploy multiple times a day, experiment continuously, and scale globally in minutes. If your infrastructure requires months to provision environments, weeks to deploy a release, and committees to approve minor changes, you’re not competing on the same playing field.
The real cost of legacy isn’t just hardware maintenance or licensing fees. It’s the opportunity cost of slowness.
The compounding risk curve
Another myth is that doing nothing avoids risk. It concentrates it.
Security patches become harder to apply. Compliance reporting becomes more manual. Disaster recovery plans become theoretical rather than tested.
I’ve sat with executives after incidents where a single point of failure brought down entire operations. In almost every case, the root cause wasn’t a dramatic cyberattack or a reckless decision. It was accumulated technical debt; years of incremental compromises that eventually converged.
Modernisation is not a big-bang rewrite
One of the reasons organisations delay action is fear. They imagine modernisation as a high-risk, multi- year, all-or-nothing transformation, a big bang, but modernisation is incremental, minimising the change in each step, testing it and taking the next step. It’s strategic.
We work with clients to identify high- impact domains first – customer-facing systems, data platforms, and integration layers. We decouple where it matters, where technologies cannot be integrated into the same image, by using integration technologies. We re-platform components selectively. We introduce automation and observability gradually.
The most successful organisations treat modernisation as a continuous capability, not a one-time programme
It’s just risk management
Sellers use the SPIN model, Situation, Problem, Implication and Need payoff. Soldiers follow the rules of military appreciation: Aim, Factors, Options, Best Option.
Making good decisions is fundamentally about balancing the risk versus the reward. This can be addressed through competence and experience across a range of disciplines to manage a project and its associated risks.
Perhaps the biggest obstacle to helping an organisation is governance: allowing the organisation to take on the risk, have the experience, and have the authority to make the best decisions without being constrained.
From cost centre to innovation engine
When legacy constraints are removed, something remarkable happens. Release cycles shrink from months to weeks, even days. Product teams gain autonomy. Experimentation becomes affordable. Data becomes accessible across the enterprise. Infrastructure scales elastically rather than expensively.
I’ve watched organisations pivot entire business models once their core platforms were no longer anchors. New revenue streams emerge. Partnerships become easier. Geographic expansion accelerates. The ability to innovate at every level is promoted.
And perhaps most importantly, culture changes. When teams see that change is possible and safe, they think bigger.
This blog has been also featured in our article featured in Open Access Government.