A Technology You Can Hire For: The Benchmark for Moving an Old Application, Module by Module.

The IT team has four engineers. Three were hired in the last five years and are very good. They built the dealer portal and the quality dashboard, and they are proud of both.

The fourth has been with the firm for twenty-two years and looks after the order and planning application. Whenever that application needs a change, it goes to that one desk.

Last month the head of IT asked one of the three to start learning it. The reply was polite. “I will help in an emergency. But if that becomes my job, I will have to look for another one.”

What We Found

For this article we went through the public record on the tool many manufacturers’ own applications were written in, and on the people who can work on it: the maker’s support statement for VB6, one large survey of developers from 2025, and one vendor’s survey on skills.

The maker told its users to move, years ago. The VB6 development tool has been unsupported since 8 April 2008. 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.

Few developers work in the language now. In one large survey of developers in 2025, Visual Basic (.NET), the later form of the language, was used by 4.4% of developers and wanted by 1.9%. VB6 itself was not on the survey’s list at all. It covers every sector.

Finding the right skills is hard even for very large firms. In one 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, and the skills they named include cloud, security and AI, not only the old ones. Mainframes are not our kind of work, and we do not read RPG or COBOL.

Our reading is narrow. The younger engineers are not at fault for declining the work: they are reading the market correctly. Nor is the experienced developer, for being the only one who can do it. The lasting answer is to move the application, a part at a time, to the technology good people already know.

What Opens Up When the Application Moves to the Team

Moving off an old technology is usually treated as one large project. Our reading is that, done a part at a time, it grows the team the firm already has.

• The whole team can work on each moved part. A module rebuilt on a technology the team knows is one any of them can pick up.
• Vacancies ask for skills candidates have.
• The experienced developer checks instead of carrying. Nobody else can say whether a new module does what the old one did, which makes the developer the most valuable person in the plan.
• The dependence can be counted. Each module moved is one less that needs the old skill, and the board can see the number fall.

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

Three Ways to Move Off an Old Technology, Weighed

Option	When it fits	What it risks
Rewrite the whole application at once, and switch over on one date	The application is small, simple and well understood by more than one person	Every rule nobody wrote down arrives missing on the same day, and the plant has no way back
Run an automatic conversion tool, then hand the result to the team	The firm mainly wants the code off the old tool, and the team can read what comes out	The old structure is carried across as it was, and nobody can say whether the result does what the old one did
Write down what the application does, then rebuild it one module at a time on a current technology, each module accepted against a benchmark, with the old one still running	The application matters, keeps changing, and the team must keep working on it throughout	It takes longer on the calendar, two systems run side by side, and the old skill is still needed until the last module has moved

Where You Are Now, and Where You Should Be

This is the benchmark we would set before the first module moves, and fill in as each module is accepted.

Measure	Typical starting point	Where it should be	How it is checked
Modules still in VB6	All of them, and not counted	Counted, and falling at every stage	Reported at every review
Modules specified	None	Each module specified, and confirmed by your own people, before it is rebuilt	The specification
Changes that need the scarce skill	Not counted	Counted, and falling at every stage	Reported at every review
Modules rebuilt on React, Node.js, Python or Java, and handed over	None	Each accepted module handed over, with its code and its part of the specification	The record of each accepted module
Old functions matched to new ones	Not recorded	Each function of the old module linked to its replacement	The traceability matrix
The old application while each module is rebuilt	The only way the work gets done	Still running until the new module is accepted	Reported at every review
Who accepts a module	Nobody: there is no new module	Your own people, for each module, in writing	The record of each accepted module

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 manufacturer.

A small part of the filled-in benchmark might look like this.

Module	Specified	Rebuilt on	Status
Rush-order rules	38 rules, confirmed by the planning team	Node.js	Accepted; old screen retired
Shift calendar	22 rules, confirmed by the plant office	Node.js	Under review; old module still running
Customer delivery report	Not started	Not started	Waiting; old module still running

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

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

1. We listen: a free Reliability Review. A first conversation about your application, the team you have, and what the old technology is costing you. 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. Here the system is the application you built or had built in VB6, Delphi or another technology we read. It produces 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.
4. If you approve, we build. We replace a system one module at a time while the old one keeps running. Here that means each module rebuilt on React, Node.js, Python or Java, while your own developer keeps the old application going. 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.
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. It takes longer on the calendar than one switch-over, and for all of that time the old application still runs and still needs someone who knows its language. Keeping the data of old and new in step is real engineering, agreed at scoping. Your experienced developer’s time is needed to confirm the record and check each module, and the plan asks a great deal of the one person whose skill it will make less necessary; that conversation is yours to have. We do not keep the old application running or secure it in the meantime. We are not a staffing firm and do not join your team as extra hands. 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.

At the end you hold the specification, the code of every module we rebuilt, the traceability matrix for each, and a filled-in benchmark that shows how far the dependence on the old skill has fallen, and who accepted each module.

What changes for the business:

Role	What they gain
CEO	The plant’s systems move onto a technology the next generation of its engineers already knows.
CTO or CIO	Each rebuilt module is one the whole team can work on, and the old language shrinks a module at a time.
CFO	Spend is released module by module, and dependence on a scarce skill falls with each one accepted.
COO	The plant keeps working on the old application until each new part has been accepted by the people who use it.
Head of people	Vacancies ask for skills that candidates have and want, and the old expert’s knowledge is used for checking, not carrying.

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 that lost engineers over an old application. The finding is that the maker of VB6 “strongly recommends that you replace your applications with modern technology”, and that few developers now work in the language.	For applications in VB6 and the other technologies we read, we rebuild one module at a time on a current technology, with the old one still running, each module accepted against a benchmark agreed before work starts. We supply no staff, 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 move the application to the team you have, one module at a time, and count the old skill out as we go.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →