The Advert Has Been Open for Months. A Software Firm Can Stop Waiting for the Old Skill.
Software firms whose product is written in an old technology hire from a short list that keeps getting shorter. Here is what that holds back, the four ways forward, weighed, and the one we would recommend.
The advert has been open since the spring. It asks for a developer with five years in the language the product is written in.
Four people have applied. Two had last used the language a long time ago. One asked, in the first interview, whether the firm planned to move to something current, and withdrew when the answer was vague. The fourth accepted another offer.
The head of people suggests widening the advert. The head of engineering says there is nothing to widen it to. The product is written in what it is written in.
The paradox: The firm can find good engineers. It cannot find engineers for the one part of its product it most needs them to work on.
What We Found
For this article we went through the public record on hiring for old technologies: what developers say they use and want in one large survey, in 2022 and 2025, one product firm’s own words in a case study published by a vendor, a news report of a vendor’s survey on skills at large enterprises, and one engineer’s account of documentation drafted with AI tools.
Three findings stand out.
The list of candidates is short, and slowly getting shorter. In one large survey of developers in 2025, Visual Basic (.NET), the later form of VB6, an old business language, was used by 4.4% of developers and wanted by 1.9% for the year ahead; VB6 itself was not listed. AngularJS, an old framework for web screens, was used by 7.2%, and only 21.9% of its users wanted to go on with it, the lowest of any web framework the survey showed. PHP, a web language, fell from 20.87% of developers in 2022 to 18.9% in 2025, and 9.2% wanted to work with it next year. Delphi, an old desktop language, went from 3.25% to 2.5%. These are developers in general, not software firms. “Wanted by few” does not mean nobody will take the work. It means the firm is choosing from a short list.
Firms feel it, in their own words. One maker of insurance software said of its VB6 product that “recruiting new staff with the Visual Basic 6.0 skill set is becoming more difficult”. It is an older case, from a vendor’s case study, and we use only the problem. Elsewhere, in a vendor’s survey of “500 senior leaders at mainframe-based enterprises”, “Seventy percent of respondents have had difficulties finding the right skills”. Mainframes are not our kind of work; the figure shows only that the difficulty is common.
The quick fix needs checking too. Some firms hope AI tools can explain the old code instead. One engineer, writing on a developers’ forum about documentation teammates had produced with AI tools: “The AI docs are simply wrong, 100% hallucinations.” It is one person’s account. Tools can draft; engineers still have to check what they draft against the code.
Our reading is that “we cannot find people for our technology” is usually treated as a question about people. The figures suggest it is a question about the technology. No advert makes more developers for an old language. What a firm can change is how much of its product needs one.
What our review does not show: The research found no figure for how long a vacancy for an old technology stays open, what such developers are paid or how many there are, in India or anywhere else, and we give none. The survey figures are about developers in general. The product firm’s remark is one sentence, in an older case from a vendor’s case study. The skills survey is about large enterprises that run mainframes. The forum post is one engineer’s account. We found no case of a software firm whose rebuild on a new stack filled its vacancies, and we do not claim one. The advert in the opening scene is imagined.
What a Firm Waiting for the Old Skill Cannot Do
While the product’s oldest part can only be changed by people who read the old technology, the firm is limited in three ways.
It cannot grow the team that matters. However many engineers it hires on current technology, the old part is closed to them, and the roadmap items that touch it queue behind the same two or three people.
It cannot answer a candidate. The best candidates ask where the technology is going, and “there is no date” loses them. That is a fair thing for a candidate to weigh.
It cannot make the search easier. Each year the product stays where it is, the list of people who can work on it is a little shorter, and each departure starts the same search again.
The gap we see: the opportunity is not a better advert. It is a product that more of the engineers the firm already has, and the ones it can hire from the ordinary market, can work on. Each module rebuilt on a current stack takes one part of the product out of the group that only a few can touch. A firm with a written record of what the product does can do that one module at a time, while it keeps selling.
This is our reading of the evidence. It is not a measured market figure.
Four Answers to a Shortage of Developers, Weighed
There are four real options. Each one is right for somebody.
| Option | When it fits | What it risks |
|---|---|---|
| Keep hiring for the old technology | The product has few years left, or the old part is small and stable | A short list that gets shorter, and each departure restarts the search |
| Train people in-house on the old technology | Engineers who want to learn it, and experts with time to teach | The experts’ time goes on teaching, and engineers spend years on skills few firms use |
| AI-generated documentation alone | A first draft is wanted quickly | A record that reads well and is wrong, with nobody checking it against the code |
| A specification of what the product does, then a module-by-module rebuild on a stack developers will work on | The product is large, sells every day, and few can read its oldest part | It costs money before anything moves, old and new run side by side for a time, and the old skill is still needed until the last module moves |
Our recommendation: the last. Write down what the product does first, from its own code: tools draft it, engineers check each rule against the code, and your own experts confirm it. Then rebuild the product one module at a time, as a web application on React, Node.js, Python or Java, beside the old product, so that customers keep using it while each part moves. Start with a module that changes often, so more of the team can work where the work is. We are not a staffing firm, we do not convert code by machine, and nothing here fills the vacancy you have today.
Where You Are Now, and Where You Should Be
A recommendation is only useful if you can tell later whether it worked. So before any work begins we set a benchmark: a few measures taken from your own product, each with a target.
For this issue, the benchmark would look like this.
| Measure | Typical starting point | Where it should be | How it is checked |
|---|---|---|---|
| Functions of the product written down | Few or none; the code is the record | Every function in plain words, confirmed by your own people | The specification |
| People able to explain each module | Two or three, for the oldest modules | More than a few for every module, working from the record | The map of the product, reviewed at each stage |
| Modules on a current stack | None, or only the newest parts | Rising at every stage, with a date for each | Reported at every review |
| Old functions matched to new ones | Not recorded | Each function of a rebuilt module linked to its replacement | The traceability matrix |
| How a newcomer’s first change is checked | A senior engineer reads it from memory | Against the record, and by tests where they exist | The record of each change |
The starting points above are what the public record suggests and 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 software firm.
How We Work With You
- We listen: a free Reliability Review. A first conversation about your product, the part of it few people can change and the vacancies that wait on it. 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 article is an example of that work.
- We read the system and propose: the Legacy System Specification Assessment. Here the system is your own product’s code, and the assessment marks which modules only a few people can change today. 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.
- If you approve, we build. We replace a system one module at a time while the old one keeps running. Here that means the product keeps selling while each module is rebuilt as a web application on React, Node.js, Python or Java, which engineers on a current stack can work on. 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.
- 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 is a rebuild, and a rebuild is a larger piece of work than an advert. Old and new run side by side for a time, and the same customers use both. Until the last module has moved, you still need people who can read the old technology, and your experts are needed throughout, as reviewers. We are not a staffing firm: we do not supply developers, recruit or train your staff, we give no advice on pay or employment, and nothing here fills a vacancy or keeps anyone. We have no assistant that answers questions about your code. We do not convert code by machine. What we rebuild is a web application, not a desktop program or a mobile app, and a web application is not what every customer of a desktop product wants. We do not maintain the product or the record afterwards; your own team does. 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 software firm.
What changes for the business:
| Role | What they gain |
|---|---|
| CEO | The firm’s plans stop being limited by how many people can still be found for one old language. |
| CTO or CIO | Each rebuilt module is one that any competent engineer on a current stack can work on, so the part only a few can touch gets smaller. |
| Head of product | Roadmap items stop queueing behind the two or three people who can change the old code. |
| CFO | The firm hires from the ordinary market for engineers, and is no longer bidding for a small and shrinking group. |
| Head of people | A vacancy can be written for skills candidates have and want to use, and the firm has an answer when a candidate asks about the technology. |
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| This article names no organisation. Its figures come from one large survey of developers, one product firm’s words in a vendor’s case study, a news report of a vendor’s survey and one engineer’s forum post. | We write down what your product does, then rebuild it one module at a time on a current stack while it keeps selling. We do not fill vacancies, supply or train staff, or convert code by machine. |
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 a product, one module at a time, to where the engineers are, so the firm stops waiting for the old skill.
Sources
In this issue
Few developers for the old technology