The Advert for a VB6 Developer Goes Unanswered. The Public Record Says It Is Not the Advert.

The advert went up in May. Developer wanted, VB6, for the order and planning application. It is now October.

Three people have applied. One had never used the language. One could work only two days a week, from another city. The third had worked in it for years, knew it well, and asked for a rate the head of people had to read twice.

Meanwhile the one developer who looks after the application has mentioned, more than once, a wish to work fewer hours. The plant’s list of changes waits.

What We Found

For this article we went through the public record on the old technologies many manufacturers’ own applications were written in: the maker’s support statement for VB6, one large survey of developers from 2025, one vendor’s page of case studies, a published support date for one family of business computers, and two vendor surveys on skills.

Four findings stand out.

The maker stopped supporting the tool in 2008, and told its users to move. 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 themselves have not stopped working.

Few developers now work in the language’s later form, and VB6 itself is not counted at all. 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 was not on the survey’s list. The survey covers developers in every sector, not manufacturing alone.

Large business systems were written in the tool. 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 written in the same language. The page does not say who uses these products, and we draw nothing from it about manufacturers. It shows how much was once written in this one tool.

The shortage is wider than one language, and part of it is outside our work. In one vendor’s survey, about a third of organisations said they lacked skills in COBOL, RPG and CICS; no sample size is given. RPG is the language of one long-lived family of business computers, IBM i, common in manufacturing; its version 7.4 left standard support on 30 September 2026, with extended support to 30 September 2029. 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, and the skills they named include cloud, security and AI, not only the old ones. We do not read RPG or COBOL, and nothing in what we offer applies to them.

Our reading is that the advert goes unanswered because the market has stopped producing the skill, not because the advert is wrong. A better advert or a higher salary fishes in the same shrinking pool.

What Waits While the Post Stays Open

An unfilled post is usually treated as a recruiting problem. Our reading is that it holds the application in place.

The first cost is the queue. Every change the plant asks for waits for the one or two people who can make it.

The second cost is growth that does not happen. A new warehouse or product line needs the application to change, and it can change only as fast as its one developer.

The third is that the dependence deepens. Each change the developer makes is one more piece of the business that only the developer understands. The developer is not at fault: they are doing what the firm asked.

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

Four Ways to Answer a Post Nobody Fills, Weighed

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

Option	When it fits	What it risks
Keep advertising, and raise the salary	The application is small, changes rarely, and the firm needs one person for a few more years	The pool shrinks each year whatever is offered, and the same search returns when that person leaves
Take on a contractor for the old language	A few urgent changes must be made now, and the firm has a plan for what comes after	The stopgap becomes the arrangement, and what the contractor learns about the application leaves with them
Ask one of the firm’s own engineers to learn the old language	An engineer genuinely wants the work, and has the time	Good engineers often decline work with no future elsewhere, and the firm now has two people on a skill that is running out
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 nobody but 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	Every function written down in plain words, confirmed by your own people	The specification
Where the application depends on the old skill	Not known: all of it is assumed to	Each part named, with how often it changes	The map of the system and the risk register
Changes that need the scarce skill	Not counted	Counted, and falling at every stage	Reported at every review
Modules still in VB6	Not counted	Counted, and falling at every stage	Reported at every review
The cost of keeping the old skill set beside the cost of ending the need	Never compared	Set side by side, in figures	The cost comparison

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 applications, the post that stays open, 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 order, planning or other 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, rebuilt one module at a time on React, Node.js, Python or Java, while your own developer keeps the old one going. 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 a price. It does not fill the post. For as long as the old application runs, somebody who knows its language is still needed to keep it going. 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 supply no developer, fill no vacancy, and do not recruit or train anyone. We do not read RPG or COBOL, and do not work on the business computers that run them. We do not install, configure, upgrade or change a packaged ERP product, including one written in VB6. The older technologies we read include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP. We have no published case of this work for a manufacturer.

What changes for the business:

Role	What they gain
CEO	A post that could not be filled is replaced by a plan with stages, and the firm’s systems stop waiting on a job advert.
CTO or CIO	A clear picture of which parts of the application truly need the old skill, and an order in which to stop needing it.
CFO	The cost of going on hiring for the old technology can be set beside the cost of ending the need for it.
COO	Changes the plant has been waiting for get a place in a plan that does not depend on finding a rare person.
Head of people	Recruiting effort goes to posts that can be filled, and the post that cannot is closed on purpose.

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 could not hire for an old application. The finding is that the VB6 development tool has been unsupported since 8 April 2008, and that its later form is used by 4.4% of developers and wanted by 1.9%.	For applications in VB6 and the other technologies we read, we write down what the application does and rebuild it one module at a time on a current technology, with the old one still running. 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 start by finding where the application truly depends on the scarce skill, because that is where the plan to need it less begins.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →