The Skills for Old Systems Are Running Out. The Knowledge Does Not Have To.
We reviewed the public record on the skills shortage for old systems. Here is what we found, what it costs a lender, the options, and the benchmark we would set.
The senior engineer on the loan system has handed in a resignation. The notice period is sixty days.
This is one of three people who understand the system: why it behaves as it does, what must never be touched, what to do when the month-end job fails.
A handover is arranged. It is a series of meetings in which one person talks and two others take notes. Everyone in the room knows sixty days is not enough.
The paradox: The system is the firm’s most valuable software, and its real documentation goes home every evening.
What We Found
Before we suggest anything to a lender, we study its sector. For this article we went through the public record on the skills shortage for old systems: two industry surveys published in 2025, a vendor’s published case study of a core system replacement, and makers’ published support dates.
Four findings stand out.
The shortage is reported even by the firms best placed to pay for skills. In one 2025 survey of several hundred senior leaders at large enterprises that run mainframes, more than two in three respondents said they had had difficulties finding the right skills. Money has not solved it for them.
The gap sits in specific old technologies. In a separate vendor survey, also from 2025, about a third reported gaps in skills for older programming languages such as COBOL, RPG and CICS. The survey does not say who it asked. The shortage gathers around the technologies that stopped being taught.
There is a great deal to know. A group of credit unions shared one heavily customised core system. When it was replaced, the work covered hundreds of screens and hundreds of interfaces to other systems. Each has rules behind it, usually known to a few people and written down nowhere.
The skills and the support can run out together. Standard support for IBM i version 7.4, for example, ended on 30 September 2026, with a paid extension available to 2029. A firm on a technology like that has fewer people each year who can work on it, and a maker that will soon stop fixing it.
What our review does not show: Every skills figure here is about large enterprises and mainframe technologies, which IOanyT does not work on. We found no survey of mid-size lenders. A lender’s old system may be written in Visual Basic 6, Delphi, an old version of PHP or an early Java; that the same shortage applies to them is our reasoning, not a survey finding. We found no reliable figure for pay, contractor rates, time to fill a vacancy or time for a new engineer to become useful, and no primary source for the often-quoted figures on programmers’ ages, so we use none.
What the Firm Cannot Do While the Knowledge Sits With Three People
A skills shortage is usually treated as a hiring problem. Our reading of the record is that it is a problem of control: the firm cannot change its own products.
In a year a lender asks its loan system for a new product, a change to how penalties are charged, a connection for a partner, a correction the regulator wants. Each is a change to rules that only three people understand.
So each one waits for one of the three. When one resigns, the firm finds out which rules nobody else knew, usually when something goes wrong.
The second cost is the one the board sees. The business plan gets sized to what three people can deliver. Growth that would need a fourth is quietly dropped.
The gap we see: most firms with old systems know they depend on a few people. Few have done the one thing that ends it: taking what the system does out of those people’s heads and putting it in a document the firm owns, while they are still here to check it. A firm that has that record can change its own products. A firm that does not is waiting on a resignation letter.
This is our reading of the evidence. It is not a measured market figure.
Four Ways to Answer a Skills Shortage, Weighed
Each of these options is right for somebody.
| Option | When it fits | What it risks |
|---|---|---|
| Retention pay and contractors | The system is due to be retired soon, and the date is set | It buys a year at a time and writes nothing down. The knowledge stays with people who can still leave |
| Train your own people on the old technology | A few engineers want the work, and the system will stay for many years | Capable engineers are reluctant to spend years on a skill few other employers want. The best ones may leave |
| Buy a packaged product to replace the system | The need is standard and a product already covers it | The firm’s own rules must fit the product or be dropped, and nobody can list those rules yet |
| Write the knowledge down from the system, then move in stages to a technology the firm can hire for | The system is old, customised and built around the business | It takes the experts’ time, which is the scarcest thing the firm has. Two systems run side by side for a time |
Our recommendation: write down what the system does, taken from the system itself and confirmed by the people who know it, before anyone else resigns. Then move it in stages to a technology the firm can hire for. We do not supply people for the old technology, and we do not maintain the old system. Your current team keeps it running while each part moves. For core banking itself, a packaged product is usually the right answer, and implementing one is not work we do.
Whichever option is chosen, the first step is the same: a written record of what the system does, owned by the firm.
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 |
|---|---|---|---|
| People able to change each module | Two or three, for the whole system | Several for each module, including people who never learned the old technology | A named list for each module, reviewed at every stage |
| Functions with a written line | Almost none; the rules live in people’s heads | Every function in scope described in writing and confirmed by your experts | The specification, checked against the code |
| Modules on technology the firm can hire for | None | Rising with each stage, until nothing in scope is left on the old technology | The staged plan, reported at every review |
| A handover record | Meeting notes from the last resignation | A specification and a record linking each old function to its replacement, owned by the firm | The specification and the traceability matrix |
The starting points above are what the public record suggests and 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 lender.
How We Work With You
- We listen: a free Reliability Review. A first conversation about the system, the people who understand it, and the changes that are waiting on them. You leave with a short written note of what we found.
- 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.
- We read the system and propose: the Legacy System Specification Assessment. It produces a written specification of what the system 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.
- If you approve, we build. We replace a system one module at a time while the old one keeps running, onto technology your firm can hire for. 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.
- 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 changes for the business:
| Role | What they gain |
|---|---|
| CEO | The business no longer depends on a handful of named people. A resignation is a staffing matter, not a crisis. |
| CTO or CIO | Others on the team can work on the system, and leave or retirement can be planned for. |
| CFO | The firm is no longer in the position of paying whatever it takes to keep a few people. |
| COO | Work no longer queues behind one person who is on leave. |
| CHRO | A succession plan for the system as well as the people. |
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| A group of credit unions replaced a heavily customised shared core, and the work covered hundreds of screens and hundreds of interfaces. | Our assessment writes down what a system does, taken from the system itself, before anything is rebuilt. Our part is the systems a lender builds around its core; we do not implement packaged core banking products. |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We do not lend you people for the old system; we write down what it does, so it stops depending on the few who know.
Sources
- News report of a vendor's survey, 2025
- A vendor's survey, 2025
- A vendor's case study
- endoflife.date/ibm-i
In this issue
Scarce skills for old systems
Research note 2
You Cannot Hire for Your Old System. You Can Stop Needing To.
Retention pay, contractors, retraining or a packaged product: each answers a skills shortage for a while. The four options weighed, and the benchmark we set.
Research note 3
The Scarce Skill Is Reading the Old Code. Here Is the Benchmark for Needing It Less.
Every new engineer on an old lending system learns its code from an expert. The benchmark we would set so the reading is done once and kept.
Issue study
When the Last Person Who Understands It Retires
When only a few people understand an old lending system: what the public record shows, the options, what we would advise against and our benchmark.
More from Banking
Regulator restrictions and penalties
A Replacement Plan Needs Stages Someone Can Check. Here Is the Benchmark We Would Set.
Dependence on one vendor or shared provider
A Supplier Runs Your System. Here Is the Benchmark for Overseeing It.
Weak patch and change process