Hiring for the Oldest Code

1. At a Glance

Issue study · From the public record. Everything about it comes from the public record.

Organisation type	Software firms whose product is written in a technology few developers now work on: one maker of insurance software as its own account describes it, set beside one large survey of developers and other public accounts
Size band	The firm in the record: mid-size to large, by the research’s estimate. Our reader: a small or mid-size software firm whose product has sold for ten years or more
Region	The firm: Europe. The surveys: developers worldwide, and large enterprises that run mainframes
The decision at stake	How a firm keeps changing its product when few people can read the code it is written in, and fewer apply
The public outcome	The firm said it was growing harder to recruit new staff who could work in VB6. It is an older case, from the late 2000s
Why it matters to a small or mid-size software firm	Its roadmap is capped by how many people can read its oldest code, and every question waits for the same two or three

2. The Business Problem, in the Buyer’s Words

“Our product has sold for fifteen years. Its oldest part is written in a language three of our twelve engineers can read. We have advertised for a fourth since the spring. The good candidates ask what our plan for the technology is, and we have none to show them. Meanwhile the three answer every question from product, fix the faults and check every change the new people make. Nine of the fourteen items on the roadmap need them. I am not short of engineers. I am short of engineers who can touch that part.”

These words are imagined. They describe the decision as the research shows it, not a real conversation.

The firm is caught between a skill it cannot hire and a product it cannot pause. Hiring for the old technology gets harder each year, and every year adds more to what only the few can change.

3. What We Found

Method. We went through the public record on products written in technologies fewer developers now work in: one product firm’s own words in a case study published by a vendor, one large survey of developers in 2022 and 2025, a news report of a vendor’s survey on skills at large enterprises, one survey of developers who work mainly in PHP, one developer’s account of old code, and one engineer’s post on a developers’ forum.

One product firm’s own words. From a case study published by a firm that sells a conversion tool. We use only the problem it describes, not what the firm did next, and do not name it. The page is not dated.

What	Public record
The firm	A maker of insurance software in Europe; an older case, from the late 2000s by the versions named
The product	Written in VB6, an old business language
What it said	That recruiting new staff who could work in VB6 was growing harder
How long vacancies lasted, and what it cost	Not in the account

What developers use and want. From one large survey of developers. These figures describe developers in general, not software firms.

Technology	Used by	What else the survey shows
Visual Basic (.NET), the later form of VB6	About 4% in 2025	Wanted by about 2%. VB6 itself is not listed
AngularJS, an old framework for web screens	About 7% in 2025	Wanted by about 4%. Only about one in five of its users want to continue, the lowest of any web framework shown
PHP, a web language	About 21% in 2022, about 19% in 2025	Wanted by about 9%
Delphi, an old desktop language	About 3% in 2022, about 2.5% in 2025

“Not listed” does not mean unused, and “wanted by few” does not mean nobody will take the work. The figures show a short and slowly shortening list of candidates.

Skills, records and tests elsewhere.

• In a vendor’s survey of about 500 senior leaders at large enterprises that run mainframes, reported in the news, seven in ten said they had had difficulty finding the right skills. Mainframes are not IOanyT’s kind of work; the figure shows only the shape of the difficulty.
• One engineer, writing on a developers’ forum about documentation teammates had produced with AI tools: said the documentation the tools drafted was simply wrong, invented throughout, and that sometimes no document is better than a bad one. One person’s account, used only as a reason for engineers to review what a tool drafts.
• In one survey of more than 1,700 developers who work mainly in PHP, about a third said they still write no tests at all.
• One developer, writing about old code, said nothing is more frightening than changing a critical old system that has no tests.

Our reading of why a product stays dependent on a few people. These four are our reasoning from the record above. None is a finding of any source.

1. The code is the only record of what the product does. Anyone who needs to know must read the code, or ask someone who can.
2. The supply of people for the old technology is small and shrinking. No advert changes that.
3. None of the old part can be worked on by the engineers the firm can find. However capable they are, it is closed to them.
4. Nothing in the product says whether a change broke it. So every newcomer’s change is checked from a senior engineer’s memory.

4. The Options a Firm in This Position Had

Option	When it fits	What it risks	Our view
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	Right only while the old part is small, and only beside a plan
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 what is learned stays in a few heads	Useful for the experts’ successors, not as the whole answer
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	We would advise against this without engineers checking every rule 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	Costs money before anything moves; old and new run side by side; the old skill is still needed until the last module moves	Our recommendation

5. Our Recommendation, and the Decision It Asks of the Board

Write down what the product does first, in plain language, from its own code: tools draft, engineers check each rule against the code, and the firm’s own experts confirm it. Record what the modules newcomers change first do today, as tests the firm’s engineers can run. Then rebuild the product one module at a time, as a web application on a stack developers will work on, beside the old product, each module checked function by function against the record and paid for by milestone once accepted. The product keeps selling throughout, and the part only a few can touch gets smaller 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 firm’s own figures, taken in the first review.

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 the firm’s 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
How a newcomer’s first change is checked	A senior engineer reads it from memory	The tests pass, and any difference is explained against the record before release	The record of each change
Old functions matched to new ones	Not recorded	Each function of a rebuilt module linked to its replacement	The traceability matrix

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about your product, who can work on which part of it and the questions that wait for them. 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 study is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. Here the system is your own product’s code, and the specification is written so that engineers who never learned the old technology can read it. 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.
4. If you approve, we build. We replace a system one module at a time while the old one keeps running, rebuilding each module as a web application on React, Node.js, Python or Java. We never do a single cutover. A traceability matrix links every old function to its replacement. For the modules newcomers change first, we add tests that record what they do today and hand them to your engineers. 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.

8. What the Client Would Own

• The map and the specification: what each part of the product does, in plain language, confirmed by the firm’s own people.
• The risk register: what the assessment found, listed before any price is set.
• The tests: for the modules newcomers change first, a record of what the product does today, handed to the firm’s engineers.
• The traceability matrix: for every module IOanyT rebuilds, every old function linked to its replacement.
• 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.

9. What This Approach Does Not Cover

• IOanyT is not a staffing firm. It does not supply developers for the old technology or the new, recruit for a client, or train a client’s staff.
• IOanyT gives no advice on pay, employment or keeping staff, and does not promise that any vacancy will be filled or that anyone will stay.
• IOanyT has no assistant that answers questions about a product’s code, and offers none.
• IOanyT does not convert code by machine. It rebuilds, as a web application on React, Node.js, Python or Java. It does not build desktop programs or mobile apps.
• IOanyT does not maintain the product, the record or the tests afterwards. The firm’s own team does, and a record that is not kept current goes out of date.
• Until the last module has moved, the firm still needs people who can read the old technology.
• Tests show that a product behaves as it did; they do not prove it correct. A record shows what the product does, not whether it is right.
• The older technologies IOanyT reads include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP.
• This study does not say that IOanyT has done this work for a software firm. IOanyT has no published case of it.

About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.

10. Sources

Source	Used for
A vendor’s case study: insurance software	One product firm’s remark on recruiting
A large developer survey, 2025 and the same survey, 2022	What developers use and want
News report of a vendor’s survey, September 2025	Skills at mainframe-based enterprises
Developers’ forum post, March 2026	One engineer on documentation drafted with AI tools
A tool maker’s developer survey, October 2025	Testing among developers who work mainly in PHP
A developer’s post, November 2025	One developer on changing old code with no tests

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 product does, so that fewer questions wait for the few who can read its oldest code.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →