A Public Service Should Not Rest on a Retirement Date. Four Ways Forward, Weighed.

The file is on the procurement head’s desk for the seventh year. Renewal of the maintenance contract for the licensing application, on a single-source basis.

The justification note has not changed since the first year: no other firm has the skills. A tender floated two years ago drew no eligible bid. This year the file carries one new page. The contractor has written, courteously, that they intend to stop working at the end of next year.

The licensing counters open every morning on that application.

What We Found

For this article we went through the public record on how long old systems need scarce skills, and how governments obtain them: the US national auditor’s 2025 report on the most critical federal legacy systems and press coverage of it, the UK government’s own review of its digital services (January 2025), trade-press reporting in 2025 on the UK tax authority, and two vendors’ surveys of large enterprises that run mainframes.

First, the limits. Both government cases concern COBOL and assembly language. IOanyT does not read COBOL or assembly language, and we do not work on mainframes; a body whose system is written in those needs another firm for that system. We use the cases for what they show about a skill nobody can buy more of. We found no Indian or mid-size public body on this issue.

The need lasts longer than the people. Press coverage of the US auditor’s report quoted its words on selected Treasury systems written in COBOL and assembly language: “programming languages that have a dwindling number of people available with the skills needed to support them”. The auditor’s report itself records that one health department system is now expected to be modernised in fiscal year 2035, five years later than planned, which officials put down to funding. Until a system is replaced, someone has to support it.

Where the skill is scarce, governments buy it from outside. The UK government’s own review says that its tax authority “relies heavily on costly third-party services to maintain outdated systems”. The review gives no figure. We give none either, and we make no comment on the authority or on any contractor.

The market for the old skills is thin everywhere. Another vendor’s article reports that “One-third said they were lacking skills in programming languages such as Cobol, RPG and CICS”; it gives no sample size. In one vendor’s survey of 500 senior leaders at large enterprises that run mainframes, “Seventy percent of respondents have had difficulties finding the right skills”; the skills meant include cloud, security and AI, not only the old languages. Neither survey is about public bodies.

Our reading: a tender for a skill reaches only the few who have it. What a body can act on is not the skill but the knowledge of its own application, which is written nowhere.

What Waits on a Retirement Date

The usual view is that the arrangement works, so it can be renewed. Our reading is that four things wait meanwhile.

A public service rests on one person’s date. The officer’s retirement or the contractor’s last year is known in advance. The service does not move with it.

The tender cannot find a second bidder. The notice asks for the old skill, which is the one thing in short supply. Bids cannot be compared because there is one.

The post cannot be filled. A vacancy that asks for experience in an old language draws no eligible applicants.

The system’s future cannot be decided. Keeping it, rebuilding it or handing the work to another firm needs a description of what the application does. Only the people who are leaving can give it.

This is our reading of the evidence. It is not a measured market figure.

Four Ways Forward, Weighed

There are four real options. Each one is right for somebody.

Option	When it fits	What it risks
Extend the expert’s service	The application will be retired within the extension, and the officer is willing	It buys a year, not a plan, and the same request returns. Whether it is allowed is the body’s own rule; we give no advice on it
Re-engage the retired officer, or renew the contractor, for the old work	The work is small and the person is willing to continue	It rests on one person’s goodwill and health, with no second source and no planned end
Train successors in the old technology	The application will run for many years, and the body has people willing to learn it	It takes the expert’s time for months, the skill is hard to keep, and what the successor learns is still unwritten
Write the application down while the experts are in post, then decide: keep it, rebuild it onto a current stack, or hand the work on	The application is in a technology the assessor can read, and the experts have hours to review a draft	It costs money and the experts’ time before anything changes, and the decision that follows may need a budget the body does not yet have

Where You Are Now, and Where You Should Be

Before any work begins we set a benchmark: a few measures taken from your own systems, each with a target. For this issue it would look like this.

Measure	Typical starting point	Where it should be	How it is checked
Applications that depend on one person or one contractor	Known informally	Each one listed, with the person’s leaving date or the contract’s end	The risk register
What the application does	Known to the people who are leaving	Written down and confirmed by them while in post	The specification
Cost of keeping the arrangement against cost of rebuilding	Not compared	Set side by side	The cost comparison
What another firm or a new officer would need to take over	Nothing written	The specification, owned by the body	The specification, handed over
The application’s future	Renewed each year without a decision	Decided on the written record: keep, rebuild in stages, or hand on	The staged plan

The starting points above are what we expect to find; in an engagement they are replaced by your own figures, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a public body.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about the application, who supports it now, and when that will change. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. Here the system is an application in a technology we read: VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, or .NET Framework and classic ASP. It is not a COBOL or assembly language system, or a mainframe. It produces a map of the system as it stands, a written specification of what it does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage. You get the options and our recommendation.
4. If you approve, we build. We replace a system one module at a time while the old one keeps running, onto technology that is still supported. We never do a single cutover. Each module has a traceability matrix. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
5. We review against the benchmark. Before work starts we set the benchmark. After each module we show you where each measure stands, and the filled-in benchmark is yours at the end.

The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.

What we do not do: we do not read or work in COBOL or assembly language, and we do not work on mainframes; a body whose system is written in those needs another firm for that system. We supply no staff or contractors, we do not replace a retiring officer or a present contractor, and we offer no training as a service. We do not maintain the old application or keep it running while it is rebuilt; the body’s own people or its present contractor do. We give no advice on service, recruitment or procurement rules, and we do not say we are empanelled with any government. We have no published case of this work for a public body.

What changes for the business:

Role	What they gain
Head of department	The department can change who does the work without fearing that nobody will understand the system.
Head of procurement	A renewal stops being the only option: the work is described in a written specification that firms working in current technology can price.
Head of IT	Engineers who never learned the old technology can work from the record, and the application is rebuilt on something people can be hired for.
Head of finance	Spending on scarce skills has a planned end, and the cost of staying is set beside the cost of moving.
Head of personnel	Posts can be filled with skills that exist in the service and in the market.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
The US national auditor: Treasury systems in COBOL and assembly language with “a dwindling number of people available with the skills needed to support them”; one health department system now expected in fiscal year 2035, five years late.	We do not read those languages, and we make no comment on any agency. For a public body’s own application in a technology we read, we write the specification while its experts can confirm it, and rebuild it in stages only if the body approves.
The UK tax authority “relies heavily on costly third-party services to maintain outdated systems”, in the government’s own review.	We do not work in COBOL, we supply no contractors, and we make no comment on the authority or its suppliers. For a body’s own applications, we set the cost of staying beside the cost of moving, on a written record the body owns.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We help a body stop needing a skill nobody can buy, by writing the application down first and deciding its future on paper.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →