You Cannot Hire for Your Old System. You Can Stop Needing To.

The vacancy has been open for eight months. The title is Senior Developer. The technology is the one the firm’s loan system was written in, years ago.

Two people have applied. One wanted far more than the budget. The other withdrew after the first interview, on learning what the work was.

Next year’s plan needs more engineers on that system, not fewer.

What We Found

We looked at two things: what the public record says about the skills shortage for old technologies, and how firms usually respond to it.

The largest firms report the same wall. 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. Paying has not been enough.

The shortage is in particular technologies. In a separate vendor survey 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. It shows where the gap sits: in the technologies that colleges stopped teaching.

The skills problem can arrive with a support problem. 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 faces a maker’s date and a shrinking labour market at once.

Each of the usual answers buys a year. Hiring competes for the same few people as every other firm on the same technology. A retention bonus keeps an expert for another year and writes nothing down. A contractor gets the work done, and the knowledge leaves when the contract ends. None of them makes the pool of people any larger.

The Cost of Staying Staffed, and What Moving Opens Up

The usual budget question is how much more to pay to keep the system staffed this year. Two other questions decide it.

What staying staffed really costs. It is more than retention pay and renewals. It is the requests from operations that never get made, because managers have learned not to ask. It is the capable engineers moved onto the old system who then leave. It is the product that was not launched because three people could not build it. And it is the same bill next year, for a slightly smaller pool.

What moving opens up. A system on a technology that ordinary engineers know can be staffed from the ordinary market. The team can grow to match the plan. People can move between systems. The experts stop being the bottleneck and become what they should be: the people who confirm that the new system does what the old one did.

The pressure gets worse before it gets better: for a time the firm runs two systems and needs both sets of skills. Some experts will see the end of the old system as the end of their role, and they deserve an honest answer.

This is our reading of the evidence. It is not a measured market figure, and we do not put a rupee value on it here. That figure has to come from your own business.

Four Ways to Keep an Old System Worked On, Weighed

Option	When it fits	What it risks
Retention pay and contractors	A retirement or replacement of the system already has a firm date	Each year costs more for a smaller pool. The knowledge stays with people, inside the firm or outside it
Train your own engineers on the old technology	A few engineers genuinely want the work, and the system will stay for many years	Few engineers want a skill other employers will not ask for. Move good people onto it and the best may leave
Buy a packaged product	The need is standard, and a product already covers most of it	Everything moves at once. The firm’s own rules must fit the product or be dropped, and nobody has written them down
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 run side by side for a time, and the experts’ time is needed most at the start

Where You Are Now, and Where You Should Be

Before the next retention payment or contractor renewal is signed, we would set a benchmark for the decision itself.

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, hired from the ordinary market	A named list for each module, reviewed at every stage
Functions with a written line	Almost none; each answer means asking an expert	Every function in scope described in writing, so engineers who never learned the old technology can rebuild it	The specification, checked against the code
Modules on technology the firm can hire for	None; every vacancy is for the old technology	More after every stage, until nothing in scope is left on it	The staged plan, reported at every review
A handover record	Whatever the last contractor left behind	A record linking each old function to its replacement, owned by the firm	The traceability matrix
What each year of paying to stay buys	The same system, one year older	Fewer modules on the old technology at the end of each year	The count, reported at each renewal

The starting points above are what we expect to find. In an engagement they are replaced by your own position, 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

1. We listen: a free Reliability Review. A first conversation about the system, the vacancies and renewals, and the plans that are waiting on the people. You leave with a short written note of what we found.
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. 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.
4. 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. 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 you need to bring: a budget for the assessment, approved separately from the next renewal; read-only access to the code once the assessment begins; and a few hours from the people who know the system.

What changes for the business:

Role	What they gain
CEO	The technology team can grow to match the business plan.
CTO or CIO	Engineers can be hired from the ordinary market and moved between systems.
CFO	Staffing costs that can be planned, with less reliance on scarce contractors and retention pay.
COO	More people can make changes, so operations’ requests are done sooner.
CHRO	Roles that candidates want, and less strain on retention.

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

The case	What IOanyT does
This article names no organisation. Its figures come from industry surveys of large enterprises and a maker’s published dates.	Our assessment writes down what the system does and prices each stage of moving it; the build moves it one module at a time onto technology the firm can hire for. We do not supply people for the old technology.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. You cannot hire your way out of an old technology, but you can move off it, and then hire like everyone else.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →