Two People Know How Your System Works. Four Ways to Stop Depending on Them, Weighed.

The developer who wrote the scheduling program has given three months’ notice. It is a friendly parting. They have been with the firm nineteen years and have earned a change.

The program decides every morning which vehicle and which driver take which route, and what a late cancellation costs the customer. Nobody else in the firm has ever opened it. The language it is written in is one nobody else on the team knows.

The head of people posts an advertisement. Six weeks later it has drawn four replies, and none of the four has worked in that language. The head of technology starts to count the days.

What We Found

We looked at the public record on how hard old-technology skills are to find, and on what happens when firms try to write down an old system quickly. None of it is about logistics, travel or hospitality: the research behind this article holds no named firm in this sector and no figure for it, and every fact below is labelled cross-sector.

The skills are hard to find, even where the money is. In a vendor-commissioned survey of several hundred senior leaders at large enterprises that run mainframes, about seven in ten said they had struggled to find the right skills. Mainframes are not our kind of work, and the report sets the figure beside a need for cloud, security and AI skills as well as mainframe ones.

The pool for one common old business language is small. In one large developer survey of 2025, Visual Basic (.NET), the later form of the language, is used by just over 4% of respondents and wanted by under 2%. VB6, the original form, is not listed at all. Its maker states that “The Visual Basic 6.0 IDE and Visual Studio 6.0 IDE are no longer supported as of April 8, 2008.” Which old languages firms in this sector run was not researched, and “not listed” does not mean nobody uses it.

A quick written account can be worse than none. One engineer who expects to maintain a legacy codebase for years, writing on a developers’ forum about documentation colleagues had produced with AI tools, put it bluntly: the documents were simply wrong, made up from start to finish, and sometimes no document is better than a bad one. It is one person’s account. We give it as the reason an engineer must check whatever a tool drafts, and for no wider claim.

What Waits on One Person

A resignation like the one above is usually treated as a recruitment problem. Our reading is that it is first a business problem.

Fares, schedules and cancellation charges cannot be changed or explained without them. A change to a fare rule or a route waits in one person’s queue, and so does every question about why the system did what it did.

A disputed charge is conceded. When the one person who can explain a charge is busy or away, the quickest answer for a customer is a refund, right or wrong.

The vacancy stays open. An advertisement for a skill few people are learning brings few replies, and the one person who has it covers the empty post as well as their own.

This is our reading of the evidence. It is not a measured market figure, and we do not put a value on a departing expert here. That figure has to come from your own business.

Four Ways to Stop Depending on One Person, Weighed

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

Option	When it fits	What it risks
Hire or contract people for the old technology	People can still be found for it where you are, and the program has a long life ahead	The pool shrinks each year; a new hire or contractor becomes the next single point of knowledge; what they learn leaves with them. We are not a staffing firm and supply no developers
Ask your experts to write it down in their spare time	The program is small, and the experts have time that nothing else claims	There is rarely spare time; what gets written is what one person remembers, unchecked against the code; it stops when the notice period ends
Have an AI tool generate documentation from the code, and use it unreviewed	The output is only ever a starting point that someone who knows the code will check	Unchecked, it can be confidently wrong, and one wrong answer sends staff back to the one person
A specification produced from the code: AI does a first pass, engineers review it and trace it to the code, your own experts confirm it; then, if you choose, a staged rebuild off the scarce technology	The program matters, keeps changing, and its expert is still there	It costs money and the expert’s time now; it turns up rules nobody can explain; the old skill is still needed for the old code until the last module has moved

The honest costs. The specification asks for your expert’s time at the moment the firm has least of it. If the expert has already gone, it can still be made from the code, with more left unexplained. A specification lets a newcomer understand the program, not edit the old code without knowing its language; until the last module has moved, your own developer or contractor keeps the old program going.

Where You Are Now, and Where You Should Be

Before the next advertisement goes out, we would set a benchmark for the decision itself.

Measure	Typical starting point	Where it should be	How it is checked
What the program does	In the code, and in one person’s memory	Written in plain words and confirmed by your own experts	The specification
The expert’s notice period	Spent teaching one successor	Spent confirming the specification	Who confirmed each part of the specification
Changes that need the scarce skill	Most of them, not counted	Counted, and falling at every stage	Your own count, reported at every review
The size of one commitment	A replacement of the whole program, or nothing	The specification first; then one module, with the freedom to pause after any accepted module	The staged plan

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 logistics, travel or hospitality firm.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about the program, the people who understand it, and what happens if one of them leaves. 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 scheduling, booking or dispatch program your firm built or had built, in one of the technologies 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. 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 moving the parts you choose off the scarce technology onto one your firm can hire for, each new module written from the specification. We never do a single cutover. 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.

What you need to bring: a start made while your expert is still there; read-only access to the code once the assessment begins; protected time from the expert to confirm what the program does; and your own developer, contractor or supplier to keep the old program running throughout.

What we do not do: we are not a staffing firm, and we do not supply developers, fill vacancies, recruit or train. We do not maintain, patch or run the old program. We offer no assistant that answers questions about your system. We do not read COBOL, RPG, FoxPro or the languages of mainframe booking engines. We do not work inside a packaged reservation, booking or property management product, and we do not work on the systems that run aircraft, trains or vehicles. We give no advice on employment, pay or retention. We have no published case of this work for a logistics, travel or hospitality firm.

What changes for the business:

Role	What they gain
CEO	A resignation stops being a threat to the business and becomes an ordinary handover.
CTO or CIO	New engineers start from the record and not from the old language, and the parts worth replacing can move to a technology people can be hired for.
CFO	The firm is no longer in the position of paying whatever it takes to keep one person, because the knowledge is not theirs alone.
COO	Changes operations has asked for are no longer queued behind the one person who can make them.
Head of people	Vacancies can be advertised for skills people have today, and long-serving experts are asked to review and decide, not to teach the same thing again.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
This article names no organisation: we found no named logistics, travel or hotel firm that lost its only expert. Its figures come from a cross-sector skills survey, one developer survey, a software maker’s support statement and one engineer’s account.	For programs in the technologies we read, we write down what the program does, checked by our engineers and confirmed by your own expert, and rebuild it one module at a time if you approve. We supply no developers, and we do not read COBOL, RPG or the languages of mainframe booking engines.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We do not fill the vacancy; we write down what the vacancy was protecting.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →