A Dwindling Number of People

1. At a Glance

Issue study: a public case, not an IOanyT client. None of the bodies named here was an IOanyT client, and IOanyT had no part in the events described. All are national governments or national agencies, far larger than the departments, municipal bodies, utilities and boards we write for. Both government cases concern COBOL and assembly language. IOanyT does not read COBOL or assembly language and does 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 knowledge held by a few people. We found no public record of an Indian public body, or of a body of our readers’ size, on this issue. Each case is reported as the public record gives it, without judgement on any government, body, official or contractor.

Organisation type	National bodies whose oldest systems depend on a dwindling number of skilled people, as their own auditors, reviews and the press report it, set beside a mid-size public body whose oldest application is understood by one or two people
Size band	The cases: national. Our reader: a state department or directorate, a municipal corporation or council, a public utility, a board or authority, or a public-sector undertaking
Region	The cases: US and UK. The reader: anywhere
The decision at stake	What to do when the people who understand an old application are leaving: extend their service, re-engage them or renew the contractor, train successors in the old technology, or write the application down while they are in post and then decide its future
The public outcome	The US national auditor described selected Treasury systems, written in COBOL and assembly language, as using “programming languages that have a dwindling number of people available with the skills needed to support them” (as quoted in press coverage of its 2025 report). The UK government’s own review says its tax authority “relies heavily on costly third-party services to maintain outdated systems”
Why it matters to a mid-size public body	If national governments, with far larger budgets, depend on a shrinking pool of people for their oldest systems, a smaller body whose oldest application rests on one or two people has fewer places to turn. What those people know can be kept only while they are still in post

2. The Business Problem, in the Buyer’s Words

“The officer who has run our pension application since it was built retires in March. The only other person who understands it is a contractor, whose agreement ends in June. We have asked for an extension of service twice. A tender for maintenance drew no eligible bid, so we renew the contractor every year, single source. The post we advertised for the old skill drew no applicants. Every new officer in the section learns the system from the same two people, and nothing is written down. I do not know what the application does in enough detail to decide whether to keep it, replace it or hand it to someone else.”

These words are imagined. They describe the decision as the research shows it, not a real conversation.

The body is caught between people it cannot keep and knowledge it has never written down. Every option it has tried buys a year; none of them leaves the knowledge behind.

3. What We Found

Method. We went through the public record on scarce skills for old government systems: 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 on the UK tax authority (2025), press reporting on a letter from US lawmakers about AI and old code (December 2025), two vendors’ surveys of large enterprises that run mainframes, and one maker’s support statement for an older development tool. The sector research behind this study holds no Indian public body and no body of our readers’ size on this issue.

A dwindling number of people. Press coverage of the US national auditor’s 2025 report quoted its words on selected Treasury systems, which use “Common Business Oriented Language, or COBOL, and Assembly Language Code”: “programming languages that have a dwindling number of people available with the skills needed to support them”. The auditor’s own report found that 8 of the 11 most critical federal legacy systems use outdated languages; those systems are “about 23 to 60 years old”. COBOL and assembly language are not IOanyT’s kind of work.

A need that outlasts the people. The same coverage reported that, of the 10 most critical legacy systems the auditor had named in 2019, three modernisations had been completed six years later. The auditor’s report records that one health department system is now expected in fiscal year 2035, five years later than planned, which officials put down to funding. Until a system is replaced, someone must support it.

A skill bought from outside. The UK government’s own review says its tax authority “relies heavily on costly third-party services to maintain outdated systems”. No figure is given, and we give none. We make no comment on the authority or on any contractor; the people who still hold these skills are why such systems still work.

A thin market everywhere. 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. Another vendor’s article reports that “One-third said they were lacking skills in programming languages such as Cobol, RPG and CICS”, with no sample size. Neither survey is about public bodies, and none of those languages is one IOanyT reads.

The tools age before the programs. The maker of VB6, a technology IOanyT does read, has not supported its development tool since 8 April 2008, and “strongly recommends that you replace your applications with modern technology”. VB6 programs still run on a runtime the maker supports on current Windows.

A caution about AI. Reporting in December 2025 described a letter in which eleven US lawmakers questioned a plan to use AI on the old COBOL code of their national tax agency, citing “the many known limitations with AI conversion capabilities”. We take no side on that plan. We draw one point from it: what a tool drafts from old code must be reviewed by people who can check it.

Our reading of why the knowledge sits with so few. These four are our reasoning from the record above. None is a finding of any source.

1. The knowledge was never written down. While the experts were present, a question was answered at a desk, so nobody recorded the answer.
2. The dates are known, and nothing is done. The system works, so the risk appears on no report until the day someone leaves.
3. The body buys the skill, not the knowledge. Posts and tenders ask for experience in the old language, the one thing the market cannot supply.
4. Every newcomer starts from nothing. Officers are transferred and contractors change, and each learns the system from the same one or two people.

4. The Options a Body in This Position Had

Option	When it fits	What it risks	Our view
Extend the expert’s service	The application will be retired within the extension, and the officer is willing	Buys a year, not a plan; the request returns. Whether it is allowed is the body’s own rule	Right only as a bridge to a dated plan; we give no advice on the rule
Re-engage the retired officer, or renew the contractor	The work is small and the person is willing to continue	Rests on one person’s goodwill, with no second source and no planned end	Often necessary while the knowledge is written down; not a plan on its own
Train successors in the old technology	The application will run for many years, and people are willing to learn it	Months of the expert’s time; the skill is hard to keep; what is learned stays unwritten	Right where the body will keep the application long term; not a service we offer
Write the application down while the experts are in post, then decide: keep, rebuild 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	Costs money and the experts’ time before anything changes; turns up rules nobody can explain	Our recommendation, for technologies we read

5. Our Recommendation, and the Decision It Asks of the Board

For an application written in a technology IOanyT reads (VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, or .NET Framework and classic ASP): write it down now, while the people who know it are still in post. Read what the application does from the code itself, set it out in plain language, and have the body’s own experts confirm each rule and say why it exists. List in a risk register every part of the application that depends on one person, with the date that person leaves. Then decide, on the written record and a cost comparison, whether to keep the application, rebuild it onto a current stack one module at a time while the old one keeps running, or hand the work to another firm. For a system written in COBOL or assembly language, or running on a mainframe, the same principle holds, but the work is for another firm: IOanyT does not read those. How any stage is bought, and any decision on service or recruitment, is the body’s own under its own rules.

6. Benchmark: Where You Are Now, and Where You Should Be

These are targets, not results. In an engagement the starting points are replaced by the body’s own figures, taken in the first review.

Measure	Typical starting point	Where it should be	How it is checked
Rules written down	Few or none; held in one or two people’s memory	Each rule written in plain language and confirmed by the body’s own experts, with the reason for it	The specification
Single-person dependencies	Not recorded	Each one listed, with what depends on that person and when they leave	The risk register
Questions answerable without one desk	Every question waits for one person	A question about what the system does can be answered from the record	The specification, checked against recent questions
Cost of keeping the arrangement against cost of rebuilding	Not compared	Set side by side	The cost comparison
Who owns the record	Nobody, or a supplier	The body, which can show it to any supplier	The specification, handed over
Each rebuilt module, if the body rebuilds	Not applicable until a stage is approved	Every old function linked to its replacement	The traceability matrix

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about the application, the people who know it, when they leave and what has been tried. 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 study 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, 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.
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. A traceability matrix links every old function to its replacement. 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.

8. What the Client Would Own

• The map and the specification: what the application does, rule by rule, in plain language, confirmed by the body’s own experts. The body can show it to any supplier or any new officer.
• The risk register: every part of the application that depends on one person, and every rule nobody could explain, each with a decision to make.
• The cost comparison: keeping the present arrangement set beside rebuilding.
• The traceability matrix: if the body rebuilds, every old function linked to its replacement, with how it was checked.
• The code: any rebuilt modules are the body’s. No runtime or platform fee.
• The filled-in benchmark: each measure, where it started and where it stands.

Keeping the record current as the application changes is the body’s own team’s work, or part of a later stage if the body chooses one.

9. What This Approach Does Not Cover

• IOanyT does not read or work in COBOL or assembly language and does not work on mainframes. A body whose system is written in those needs another firm for that system.
• IOanyT supplies no staff, programmers or contractors, does not replace a retiring officer or a present contractor, and does not offer training as a service.
• IOanyT does not maintain the old application or keep it running while it is written down or rebuilt; the body’s own people or its present contractor do.
• IOanyT gives no advice on service rules, recruitment rules or procurement rules, including extensions of service, re-engagement and single-source purchase.
• IOanyT does not say it is empanelled, registered or approved as a supplier to any government, or that it meets the conditions of any tender.
• IOanyT has not stated that it delivers AI on a government cloud or on a body’s own servers.
• This study does not say IOanyT would have solved any of the cases described. IOanyT has no published case of this work for a public body.

10. Sources

Source	Used for
US Government Accountability Office, GAO-25-107795, 17 July 2025	8 of the 11 systems in outdated languages; “about 23 to 60 years old”; the fiscal year 2035 date and its reason
FedScoop, 17 July 2025	Press coverage of the same report: COBOL and assembly language, “a dwindling number of people”, three modernisations completed
UK State of Digital Government Review, 21 January 2025	The tax authority’s reliance on “costly third-party services”
FedScoop, 18 December 2025	The lawmakers’ letter on AI and old code
News report of a vendor’s survey, 9 September 2025	”Seventy percent of respondents”
A vendor’s survey article, 26 March 2025	”One-third said they were lacking skills”
Microsoft, VB6 support statement	The VB6 development tool’s support date

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We write down what your last experts know while they can still confirm it, so the body can decide its application’s future on paper.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →