When the Last Person Who Understands It Retires
A study of the skills shortage for old systems from the public record: two industry surveys, a heavily customised shared core and how much it held, the options a lender has, what we would advise against, and the benchmark we would set.
1. At a Glance
Issue study · From the public record. No organisation described here was an IOanyT client, and IOanyT had no part in the events described. Everything about them comes from the public record.
| Organisation type | A group of credit unions sharing one heavily customised core system, set beside two industry surveys of the skills shortage for old technologies |
| Size band | The credit union group: many branches and a large membership. The surveys: large enterprises |
| Region | The credit union group: not stated in the source. The surveys: not limited to India |
| The decision at stake | What to do when only a few people can work on an old system, and fewer each year |
| The public outcome | When the shared core was replaced, the work covered hundreds of screens and hundreds of interfaces to other systems. In one survey, more than two in three leaders at large mainframe-based enterprises reported difficulties finding the right skills |
| Why it matters to a mid-size lender | Many lenders run systems built around their core that only two or three people understand. The question is whether that knowledge is written down before those people leave |
2. The Business Problem, in the Buyer’s Words
“Three people understand our loan system. One of them retires next year. We have had a vacancy open for most of this year, and the only applicant who knew the technology wanted far more than we could pay. Every change from the business waits for one of the three. We have tried handover meetings. Nobody believes the notes would be enough.”
These words are imagined. They describe the decision as the research shows it, not a real conversation.
The firm is caught between a shrinking pool of people and a system whose rules are written down nowhere. Paying to keep the people looks safer every year, and the dependence never ends.
3. What We Found
Method. 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.
How much there is to know. A group of credit unions shared one heavily customised core system. Its vendor scheduled it to be retired in 2024, and it was replaced.
| What | Figure |
|---|---|
| Institutions sharing the system | A group of credit unions |
| Their size | Many branches and a large membership |
| The system | Heavily customised, scheduled by its vendor to be retired in 2024 |
| What the replacement rebuilt | Hundreds of screens and hundreds of interfaces to other systems |
Every screen and interface has rules behind it. In most firms, those rules are known to a few people.
Who is left to explain it. 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. In a separate vendor survey from 2025, about a third reported gaps in skills for older programming languages such as COBOL, RPG and CICS; that survey does not say who it asked.
Skills and support run out together. Standard support for IBM i version 7.4 ended on 30 September 2026, with a paid extension to 2029. A firm on a platform like that has a maker’s date and a shrinking pool of people at the same time.
Our reading of why the knowledge stays with a few. These four are our reasoning from the record above. None is a survey finding.
- The technology went out of use: colleges stopped teaching it, and new engineers have never seen it.
- The team shrank to the people who stayed, and they became the experts by default.
- The experts are too busy to write anything down, because every urgent request goes to them.
- Each new person learns from scratch beside an expert, so nothing is kept.
What this record does not show. The credit union source is a vendor’s own case study; it does not say where the institutions are, or how many people understood the old system. Both surveys concern large enterprises and mainframe technologies, which IOanyT does not work on. We found no survey of mid-size lenders, and that their old technologies (Visual Basic 6, Delphi, old versions of PHP, early Java) face the same shortage is our reasoning. We found no reliable figure for pay, contractor rates, the time it takes to fill a vacancy or onboarding time, and no primary source for the often-quoted figures on programmers’ ages, so we use none.
4. The Options a Firm in This Position Had
| Option | When it fits | What it risks | Our view |
|---|---|---|---|
| Retention pay and contractors | The system’s retirement already has a firm date | It buys a year at a time and writes nothing down | Right only as a bridge with an end date |
| Train people on the old technology | A few engineers want the work, and the system will stay for years | Few engineers want a skill other employers will not ask for; the best may leave | Worth trying for one or two volunteers; not a plan on its own |
| Buy a packaged product | The need is standard and a product covers it | Everything moves at once, and the firm’s own rules are unwritten | Usually right for core banking itself; we do not implement packaged products |
| Write the knowledge down from the system, then move in stages to a technology the firm can hire for | The system was built around the business and customised for years | Two systems side by side for a time, and the experts’ time is needed most at the start | Our recommendation for the systems around the core |
What we would have advised against: for a firm in this position, relying on handover meetings in an expert’s notice period as the only record of the system, and moving capable engineers onto the old technology against their wishes as the answer to every vacancy.
5. Our Recommendation, and the Decision It Asks of the Board
For the systems a lender has built around its core (loan origination, collections, agent and branch portals, reporting): first write down what the system does, taken from the system itself and confirmed by the people who know it, while they are still in the firm. Then move it in stages, one module at a time while the old one keeps running, to a technology the firm can hire for. Treat retention pay and contractors as a bridge with an end date.
The decision it asks of the board: approve a fixed-price assessment now, before the next resignation, and protect some of the experts’ time for it. Then approve each stage on its own evidence, with the freedom to pause after any accepted module. The board stops renewing the same dependence each year and starts approving a plan that ends it.
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 firm’s own figures, taken in the first review.
| 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 the firm’s 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 |
| Where a new joiner starts | Beside an expert | With the record, going to the code only when needed | The onboarding plan |
7. How IOanyT Would Work
- We listen: a free Reliability Review. A first conversation about the system, the people who understand it, and the changes waiting on them. 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.
- 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.
- 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.
- If you approve, we build. We replace a system one module at a time while the old one keeps running, onto technology the firm can hire for. 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.
- 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 specification: what the system does, in plain language, confirmed by the firm’s own experts, and portable to any supplier.
- The risk register: what depends on the few people, and on the old technology, listed before any price is set.
- The traceability matrix: every old function linked to its replacement, with how it was checked.
- The code: the new modules are the client’s, on technology the firm can hire for. No runtime or platform fee.
- The filled-in benchmark: each measure, where it started and where it stands.
9. What This Approach Does Not Cover
- IOanyT does not supply COBOL, RPG or mainframe developers, and is not a staff augmentation firm. It does not lend people to cover the old system.
- IOanyT does not maintain the old system while its skills run down. The client’s current team or vendor keeps it running until each module has moved.
- The old technologies IOanyT reads are VB6, Delphi, AngularJS, PHP 4 to 8, Java 8 and .NET Framework / classic ASP. The survey figures and the IBM i example describe the wider problem; they do not mean IOanyT works on those platforms.
- IOanyT does not implement packaged core banking products. Its part is the systems a firm builds around its core.
- This study does not say IOanyT would have prevented the events described, or that IOanyT has done this work for a bank.
About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.
10. Sources
| Source | Used for |
|---|---|
| A vendor’s case study | The credit union group |
| News report of a vendor’s survey, 2025 | Survey of several hundred senior leaders: difficulties finding the right skills |
| A vendor’s survey, 2025 | About a third reporting gaps in COBOL, RPG and CICS skills |
| endoflife.date, IBM i | IBM i 7.4 support dates |
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.
Read the research notes on this issue
Scarce skills for old systems
Research note 1
The Skills for Old Systems Are Running Out. The Knowledge Does Not Have To.
Old lending systems often rest on two or three people, and the skills behind them are scarce. What the public record shows, the options, and our benchmark.
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.