The Scarce Skill Is Reading the Old Code. Here Is the Benchmark for Needing It Less.

A new engineer joined the team in January. Well qualified, with four years of experience elsewhere.

It is now September. The engineer can make small changes to the loan system, with supervision. The onboarding plan was one line long: sit next to the senior engineer and learn.

So for eight months the firm has had one engineer learning, and one of its three experts teaching. The expert’s own work has fallen behind.

What We Found

We looked at what the public record says about how much there is to understand in an old financial system, and who is left to explain it.

There is a great deal to read. When a group of credit unions replaced a shared, heavily customised core system, the work covered hundreds of screens and hundreds of interfaces to other systems. Each has rules behind it, and a new engineer absorbs them one conversation at a time.

The people who can explain it are scarce. 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.

Reading and changing are different jobs. Working on an old system has two parts: understanding what it does, and changing it. The first is where the scarce skill lies: old code was written to work, not to be read.

Nothing is kept. What one engineer works out is written nowhere, so the next works it out again, with the same expert beside them.

What Reading Once Opens Up

If the reading is done once and written in plain language, three things change.

• The experts’ time comes back. They review and decide, instead of teaching the same system to each new person.
• More people can work on the system. An engineer who never learned the old language can work from the record, and rebuild from it.
• The business can check its own rules. Finance and operations staff cannot read old code. They can read a rule in plain words and say whether it is what the business intended.

This is our reading. It is not a measured market figure.

Three Ways to Get the Old Code Understood, Weighed

Option	When it fits	What it risks
Each new joiner learns beside an expert	The system will be retired soon and few people need to learn it	It uses the scarcest people as teachers, and what is learned leaves with each person
Handover meetings and notes before an expert leaves	Someone has resigned and there is nothing else in place	It starts too late. People cannot recall everything they know, and notes are not a specification
Read the system once, write it down, have the experts confirm it, then move in stages	The system is old, customised and needed for years	The record is real work, must be kept current, and will turn up rules nobody can explain

Where You Are Now, and Where You Should Be

The benchmark we would set before the reading begins, filled in as each module is accepted:

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	Every function in scope described in plain language and confirmed by your experts	The specification, each line traced to the code
Where a new joiner starts	Beside an expert	With the record, going to the code only when needed	The onboarding plan
Who can check a business rule	Only the engineers who read the old code	Business staff, from the written line	Sign-off by the business owner of each rule
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	Notes from handover meetings	Each old function linked to its replacement, with how it was checked	The traceability matrix

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.

A small part of a finished specification might look like this.

Function	Written line	Confirmed by
Late-payment penalty	A penalty is charged when an instalment is more than five days late	Head of collections
Field-visit allocation	Overdue accounts above a set amount go to a field visit; the rest get a phone call	Operations manager

The rows above are an illustration, not taken from a real system.

How we do the reading. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Nothing enters the specification without that trace. Your experts add why a rule exists.

How We Work With You, and What You Are Left With

1. We listen: a free Reliability Review. A first conversation about the system, the people who understand it, and how new joiners learn it today. 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.
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.
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. A traceability matrix links every old function to its replacement. As each module is accepted, it is handed back to your own team. 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 above. As each module is accepted 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.

This has a price. Your experts’ time is needed most at the start, when it is scarcest. The record will turn up rules nobody can explain, and some that are wrong, and each needs a decision from the business. And it must be kept current, or it becomes one more old document. It is slower than the next shadowing arrangement, and it is the last time the reading has to be done.

At the end you hold three things: the specification, the matrix, and modules your own team can work on.

What changes for the business:

Role	What they gain
CEO	The experts’ time goes to decisions, not to answering the same questions for each new person.
CTO or CIO	Engineers who never learned the old technology can work from the record.
CFO	One piece of work replaces a cost that returned with every new hire and contractor.
COO	Business staff can read how the system decides things, and check that it is right.
CHRO	New joiners become useful sooner, and passing on knowledge no longer depends on shadowing one person.

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 does the reading once and writes it down, traced to the code and confirmed by the firm’s experts. 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. The reading is done once, and the record stays with your firm.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →