When an organisation is preparing for another transformation, I keep asking what will actually be different this time. They have usually transformed before.
I remember “legacy” meaning applications that had been running for 25 or 30 years. Now I encounter the same verdict on services built roughly ten years ago, close enough to include work from my own recent career. It makes me wonder what happened to the last promise of lasting renewal.
Digital, agile, cloud and AI address different problems and can bring real improvements. Each can also arrive with a promise to escape the previous arrangement. The technology changes, teams are reorganised, and eventually the replacement is declared legacy too.
The UK government's definition of legacy IT, updated on 17 August 2026 gives that verdict some substance. It describes persistent, unacceptable burden or risk where technology can no longer be supported or secured effectively or economically. Age, technology type, hosting and fashion do not determine the classification. Insufficient skills and knowledge or dependence on another legacy system can be enough to cross the threshold. The remedy might be renewed support or recovered knowledge, rather than a new platform.
The skills and knowledge criterion matters when we replace technology and reorganise its teams together. Moving the people who understand a service into the new programme could leave unchanged code harder to support.
What the verdict invites
In medicine, the nocebo effect describes negative expectations around treatment triggering or worsening real symptoms. Positive expectations can contribute to placebo effects. The comparison with software is an analogy about what expectations might lead people to do: would I judge the same defect equally, and allow time for the same useful upgrade, in a legacy service and a favoured cloud or AI programme?
In my article on Dev Psyops, I argued that engineering narratives help establish what counts as good work. Declaring a service finished might make its upgrades harder to justify and its shortcuts easier to accept. Over time, those choices could help produce the condition everyone expects.
A small controlled study gives limited support to the broken-window intuition. Twenty-nine developers extended Java systems containing different amounts of duplicated logic and poor naming. Higher existing debt led to less reuse and poorer new names, even though low-debt solutions were possible. The researchers changed the code, not its legacy label. The wider organisational loop remains a hypothesis; real defects could explain both the verdict and the subsequent decisions.
The costs themselves are substantial. The January 2025 State of Digital Government review, which predates the new definition, reports that legacy maintenance often costs three to four times as much as modern alternatives, citing HMRC's COBOL maintenance contracts as an example. That comparison cannot guarantee the savings from a particular replacement. More revealing for this argument, half its survey respondents said remediation budgets were frequently reallocated. The review describes funding that favours new programmes over continuous improvement.
Some of those choices may be unavoidable. An urgent policy change still needs implementing. But the service continues to need care, so moving its budget cannot by itself remove the work or make retirement happen.
Imagine buying an evergreen tree, leaving nobody responsible for watering it, then commissioning a better tree when it turns brown. The replacement is a cloud-native tree. Watering remains outside the programme.
When the exit moves
Sometimes replacement is necessary, and spending less on a service due to close is sensible. Technical debt can buy something useful sooner at the cost of more expensive changes later. If there will be few later changes, repayment may achieve little.
Consider a service with an eligibility rule copied into several places. A new requirement arrives. The team could consolidate the rule and add tests, or update the copies and add another. If the service will disappear in three months, “we're replacing it anyway” may justify the quicker option.
Then the replacement slips by a year. Work that looked wasteful over three months may be worthwhile over fifteen. If the engineers have moved into the new programme, the service owner needs someone able to release their time and delay other work, or explicitly accept the continued shortcut. Otherwise an old forecast keeps governing a service with a new lifetime.
The person who can move the retirement date needs to be able to fund its consequences. I would look at which improvements were deferred because of the original date, then see whether those decisions changed when it moved. A planned exit has to include users, data and dependencies; if someone's eligibility history goes missing during the move, the service owner must be able to get it restored across the two systems.
No one has to become careless for repeated, individually reasonable shortcuts to make a service harder to change. A replacement may remove those compromises and make future changes cheaper. The question is whether its owners can keep doing the necessary work once the programme ends.
“Evergreen” would mean being able to upgrade a dependency, simplify a rule or retire a component without waiting for the whole service to become intolerable. It requires people who understand the service and can make time for that work, including postponing a feature when necessary.
Before accepting the next promise, I would ask the successor's owner to show how they will pay for an ordinary upgrade and get it done when their new system has become the old one.
(Views in this article are my own.)