Every Change Waits on One Scarce Skill. Four Ways Out, Weighed.

A capable engineer joined the IT team in March. Six years of experience, good references, quick to learn.

In the first week the head of IT asked them to look at how the planning application decides the order of jobs. The engineer opened the code, read for an hour and came back. “I do not know this language. I can learn it, but it will take a while, and I cannot tell which of these forty files to start with.”

It is now November. The engineer can make small changes, with the one experienced developer sitting alongside. That developer’s own work has slowed to make room, and the plant’s list of changes has grown.

What We Found

For this article we went through the public record on applications written in old technologies and the people who can work on them: the maker’s support statement for VB6, one vendor’s page of case studies, and two vendor surveys on skills.

The supported way to change these programs ended in 2008. The VB6 development tool has been unsupported since 8 April 2008, and its maker “strongly recommends that you replace your applications with modern technology”. The part that lets VB6 programs run is still supported in a limited way on current Windows, so the programs keep working. The difficulty is changing them.

There can be a great deal to read. One vendor’s page of case studies names one ERP product of several million lines of VB6, and one firm’s own custom ERP system in the same language. The page does not say who uses them. A plant’s own application will be far smaller, and we do not work inside packaged ERP products; the figure shows only how much was once written in this one tool.

People who can read old code are short everywhere. In one vendor’s survey, about a third of organisations said they lacked skills in COBOL, RPG and CICS, with no sample size given. In another vendor’s survey of 500 leaders at large enterprises that run mainframes, seven in ten said they had found it hard to hire the right skills, among them cloud, security and AI. Both surveys cover every sector, and both are about technologies outside our work: we do not read RPG or COBOL.

Our reading is that working on an old application is two jobs. Understanding what it does is where the scarce skill is spent. Changing it, once it is understood, is ordinary engineering. When nothing is written down, every newcomer must learn the language before they can follow a single rule, and learns it from the one person who already can.

What Opens Up When the Application Can Be Read Without the Old Language

The usual answer to a scarce skill is to find more people who have it. Our reading is that the larger opening is to need it for less.

• The plant’s changes can be planned. When what the application does is written down, a change can be scoped by any competent engineer, and only the part that touches the old code waits for the old skill.
• New people start from a document. A newcomer reads the record first, and goes to the code only when they must. The experienced developer reviews instead of teaching.
• The application can grow again. A part rebuilt from the record, on a technology the team already knows, can take the next new rule without waiting for one desk.
• The business can check its own rules. Planners and accounts can read how the system decides, and say whether that is what they meant.

This is our reading of the evidence. It is not a measured market figure.

Four Ways Out, Weighed

There are four real options. Each one is right for somebody.

Option	When it fits	What it risks
Hire or contract another VB6 developer	The application is small, changes rarely, and one more person would cover the next few years	The pool shrinks each year, and what the newcomer learns is kept nowhere when they leave
Keep the one developer, and wait	Few changes are needed, and the developer is staying for some years	Every change queues behind one desk, and the day that person leaves arrives with no record
Run an automatic conversion tool over the code	The application is well understood, and the firm mainly wants it off the old tool soon	The old structure is carried across as it was, and the result must still be checked against what the old one did, which nobody has written down
Write down what the application does first, then rebuild it one module at a time on a current technology	The application matters, keeps changing, and only one person can read it	It costs money before anything changes, and the old skill is still needed until the last module has moved

Where You Are Now, and Where You Should Be

Before any work begins we set a benchmark: a few measures taken from your own application, each with a target.

Measure	Typical starting point	Where it should be	How it is checked
What the application does	In the code, and in one person’s memory	Each rule written down in plain words, including the exceptions	The specification
Who can understand a given rule	One person	Any engineer who reads the record, and the people who use the rule	The specification, confirmed by your own people
Each module of the application	Not described	Specified, with where it lives and what depends on it	The specification and the map of the system
Rules nobody can explain	Not known	Listed for the business to decide	The risk register
Changes that need the scarce skill	Not counted	Counted, and falling at every stage	Reported at every review

The starting points above are 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 manufacturer.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about your application, who can read it, and the changes that wait. 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 article is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. Here the system is the application you built or had built in VB6, Delphi or another technology we read. 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. 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. Here that means your own application, each new module written from the record of the old one, on React, Node.js, Python or Java. 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.
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.

This approach has limits. A record of what the application does shows what it does, not whether it is right: an old mistake is written down as faithfully as a good rule, until your people decide about it. The record is only as good as the checking, so your expert’s time is still needed, for review. It must be kept current if the old application changes, and we do not keep it up for you. The record does not let anyone change the old code without knowing its language. We do not keep the old application running or secure it in the meantime; your own developer or contractor does. We are not a staffing firm: we do the reading, and we do not lend you a reader. We do not read RPG or COBOL, and we do not install, configure, upgrade or change a packaged ERP product. We have no published case of this work for a manufacturer.

What changes for the business:

Role	What they gain
CEO	How the firm’s own application works is no longer written in a language few people can read.
CTO or CIO	Engineers who never learned the old language can understand the application from a record, and go to the code only when they must.
CFO	One piece of reading replaces a cost that came back with every new contractor.
COO	Operations staff can read how the system decides, and say whether that is what they intended.
Head of people	A new joiner starts from a document, and not from months beside the last person who knows the language.

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

The case	What IOanyT does
No organisation is named in this article: we found no named manufacturer in this position. The finding is that the supported tool for changing VB6 programs ended on 8 April 2008, and that people who can read old code are short in every sector.	For applications in VB6 and the other technologies we read, we write down what the application does, checked by our engineers and confirmed by your own expert, and rebuild it one module at a time. We supply no reader, and we do not read RPG or COBOL.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We read the old code once, so that nobody after us has to start from nothing.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →