Not on the List
A study of manufacturers whose own applications were written in technologies few people now learn, built from the public record: the maker's statement, the surveys, the options, what we would advise against, and the benchmark we would set.
1. At a Glance
Issue study · From the public record. This study names no organisation as its case, because the public record holds none: we found no named manufacturer unable to hire for an application written in an old technology. It is built from a maker’s support statement, a published support date and surveys, most of them about developers or firms in general, not manufacturers alone. Nothing here describes an IOanyT client, and IOanyT had no part in anything described.
| Organisation type | Manufacturers whose own order, planning, quality or costing applications were written years ago in VB6 or a similar desktop tool, set beside the published facts about that tool and the people who work with it |
| Size band | The figures: firms and developers of all sizes, not broken down. Our reader: a mid-size manufacturer with one or two people who can change its main in-house application |
| Region | The figures: not broken down by country. No case from India was found |
| The decision at stake | What to do when every change to an important application waits on a skill the firm cannot hire for |
| The public outcome | The VB6 development tool has been unsupported since 8 April 2008, and its maker “strongly recommends that you replace your applications with modern technology”. In one large survey of developers in 2025, the language’s later form was used by 4.4% of developers and wanted by 1.9%; VB6 itself was not listed |
| Why it matters to a mid-size manufacturer | An application only one person can change cannot change or grow faster than that person. A post advertised for that skill fishes in a pool that gets smaller each year |
2. The Business Problem, in the Buyer’s Words
“Our order and planning application was written for us in VB6 a long time ago. It works. One developer looks after it, and they would like to work fewer hours. We have advertised for a second for months and nobody suitable has applied. The engineers we can hire are good, but they cannot read it, and the ones we asked to learn it said they would rather leave. Meanwhile the plant has a list of changes it has been waiting for since spring. I do not need another advert. I need to stop depending on a skill I cannot buy.”
These words are imagined. They describe the decision as the research shows it, not a real conversation.
The firm is caught between an application that still works and a skill it cannot replace. Hiring looks like the answer every year, and every year the pool is smaller.
3. What We Found
Method. We went through the public record on the old technologies in which many manufacturers’ own applications were written, and on the people who can work on them: 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.
What the maker says about VB6.
| What | Public record |
|---|---|
| The development tool | Unsupported since 8 April 2008 |
| The maker’s advice | It “strongly recommends that you replace your applications with modern technology” |
| The programs themselves | The part that lets VB6 programs run is still supported in a limited way on current Windows. VB6 programs have not stopped working; there is no supported tool to build or change them |
How much was written in it. 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. The vendor sells conversion work; its work is not part of this study. The figure shows only how much business software was once written in this one tool.
What is known about the supply of people. 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 is not listed in the survey at all. The survey covers developers in every sector.
Two more surveys bear on skills. Neither is about VB6, and both are about technologies IOanyT does not work on:
| Survey | Finding | What it is about |
|---|---|---|
| A vendor’s survey, no sample size given | About a third of organisations lack skills in COBOL, RPG and CICS | Older languages IOanyT does not read |
| A vendor’s survey of 500 leaders at large enterprises | Seven in ten had found it hard to hire the right skills, among them cloud, security and AI | Enterprises that run mainframes |
The business computers that run RPG. IBM i, also known as AS/400, is a family of business computers common at manufacturers and programmed in RPG. Its version 7.4 left standard support on 30 September 2026, with extended support to 30 September 2029. IOanyT does not read RPG and does not work on these computers. This section is here because the issue is named for the language; nothing in sections 4 to 8 applies to it.
Our reading of why hiring does not solve it. These four are our reasoning from the record above. None is a finding of any source.
- The market has stopped producing the skill. Nobody teaches it, and fewer people hold it each year. A better advert or a higher salary does not create more of them.
- Understanding the application needs the old language. With nothing written down, every newcomer must learn the language before they can follow a single rule, and learns it from the one person who can.
- Good engineers decline the work, and they are right to. It has no future elsewhere, so assigning it can cost the firm the engineer. Neither they nor the experienced developer is at fault.
- The application stays where it is. Each hire, contractor or reassignment keeps things going for a few years and leaves the dependence unchanged.
What this record does not show. No named manufacturer appears, because none was found. We found no figure for pay, contractor rates, how long such a post stays open, or how many manufacturers run VB6 or RPG. The surveys cover every sector, and the skills surveys were run by vendors and are about mainframes, COBOL and RPG. The page of case studies is a vendor’s and says nothing about manufacturers. That VB6 is absent from one survey’s list is a fact about that survey. Nothing here is specific to India or to mid-size firms. This study does not claim that any firm has lost business for the reasons given above.
4. The Options a Firm in This Position Had
| Option | When it fits | What it risks | Our view |
|---|---|---|---|
| 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 | Right only as a bridge, with a plan for what comes after |
| 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 | Right only as a pause with an end date |
| 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 nobody can say whether the result does what the old one did | Right only once what the application does is written down to check against |
| Rewrite the whole application at once, and switch over on one date | The application is small, simple and understood by more than one person | Every rule nobody wrote down arrives missing on the same day, with no way back | We would advise against this for an old, much-changed application only one person can read |
| 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 | Costs money before anything changes; the old skill is still needed until the last module has moved | Our recommendation |
What we would have advised against: for a firm in this position, treating the scarcity as a recruiting problem to be solved by a better advert; asking good engineers to take on a technology they do not want, as a substitute for a plan; and replacing the whole application on one date before anyone has written down what it does.
5. Our Recommendation, and the Decision It Asks of the Board
For an application a manufacturer built or had built in VB6 or another technology IOanyT reads: write down what it does first, from its code, and have the firm’s own people confirm it. Then rebuild it one module at a time on a technology the firm’s engineers already know, starting with the parts that change most, with the old application still running. Each module is checked against the record of the old one, accepted by the firm’s own people against a benchmark agreed before work starts, and paid for by milestone once accepted. The firm’s own developer or contractor keeps the old application going until the last module has moved; the old skill is needed until then.
The decision it asks of the board: approve a fixed-price assessment now, separately from any rebuild budget and from the recruiting budget. Then approve each stage on its own evidence, with the freedom to pause after any accepted module. The board stops asking when the post will be filled, and starts approving a plan in which the need for it falls at every stage.
6. Benchmark: Where You Are Now, and Where You Should Be
These are targets, not results. In an engagement the starting points are replaced by the manufacturer’s own figures, taken in the first review.
| 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 |
| 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 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 | 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 |
7. How IOanyT Would Work
- We listen: a free Reliability Review. A first conversation about your application, 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.
- We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This study is an example of that work.
- 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.
- 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 module rebuilt on React, Node.js, Python or Java from the record of the old one. 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.
- 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.
8. What the Client Would Own
- The map and the specification: what the application does, in plain words, confirmed by the firm’s own people, so that understanding it no longer needs the old language.
- The risk register: what the assessment found, listed before any price is set, including rules nobody can explain, listed for the business to decide.
- The traceability matrix: for every module IOanyT rebuilds, every old function linked to its replacement, with how it was checked.
- The code: the rebuilt modules are the client’s. No runtime or platform fee.
- The filled-in benchmark: each measure, where it started and where it stands, including how many modules are still in VB6.
9. What This Approach Does Not Cover
- IOanyT does not read RPG or COBOL and does not work on the business computers they run on. A manufacturer whose applications are in RPG needs a different specialist; nothing in sections 4 to 8 applies to it.
- IOanyT is not a staffing firm. It supplies no developer for an old technology, fills no vacancy, and does not recruit or train staff.
- IOanyT does not keep the old application running or secure it during the rebuild, and does not host it. Someone with the old skill is still needed until the last module has moved.
- A written record lets engineers understand an application and rebuild it. It does not let them change the old code without knowing its language.
- A record of what the application does shows what it does, not whether it is right. Deciding about an old rule is the business’s.
- IOanyT does not install, configure, upgrade or change a packaged ERP product, including one written in VB6.
- A staged rebuild takes longer on the calendar than one switch-over, and runs two systems side by side for that time.
- This study does not say IOanyT has done this work for a manufacturer. IOanyT has no published case of this work for a manufacturer.
About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.
10. Sources
| Source | Used for |
|---|---|
| Microsoft, VB6 support statement | VB6 support, the maker’s advice, and the runtime |
| A large developer survey, 2025 | Use of the language’s later form; VB6 not listed |
| A vendor’s case-study page | ERP software written in VB6 |
| A vendor’s survey article, 2025 | Skills in COBOL, RPG and CICS |
| News report of a vendor’s survey, 2025 | Skills at large enterprises that run mainframes |
| endoflife.date/ibm-i | IBM i 7.4 support dates |
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 writing down what the application does, so that the post nobody fills can be closed on purpose.
Read the research notes on this issue
Scarce vb6 and rpg skills
Research note 1
The Advert for a VB6 Developer Goes Unanswered. The Public Record Says It Is Not the Advert.
The advert for a VB6 developer goes unanswered because the market stopped making the skill. What we found, four ways to respond, and our benchmark.
Research note 2
Every Change Waits on One Scarce Skill. Four Ways Out, Weighed.
When only one person can read an old VB6 application, every change waits on them. Four ways out, from hiring to conversion tools, weighed, and our benchmark.
Research note 3
A Technology You Can Hire For: The Benchmark for Moving an Old Application, Module by Module.
Good engineers decline work on a technology with no future. Three ways to move an old VB6 application, weighed, and the benchmark we would agree first.