Ask the Person Who Wrote It
A study of old booking and scheduling systems that one or two people understand and nobody has written down, from the cross-sector public record: skills surveys, a retired development tool, documentation that drifts from the system, the options a mid-size logistics, travel or hotel firm has, what we would advise against, and the benchmark we would set.
1. At a Glance
Issue study · From the public record. No organisation is named in this study, and none described here was an IOanyT client. The public record we went through holds no named logistics, travel or hotel firm with this problem, and no figure for it in this sector. What it holds is cross-sector: surveys of technology leaders and developers, a software maker’s support statement, and one engineer’s account. We set that record beside the position of a mid-size firm in this sector, and we label every fact as cross-sector.
| Organisation type | No single organisation: the cross-sector record on scarce skills and documentation that drifts from the system, set beside a mid-size firm that moves goods, moves people or looks after guests, whose booking, scheduling or dispatch application one or two people understand |
| Size band | The surveys: large enterprises and IT professionals across sectors. Our reader: a mid-size transporter, courier, forwarder, bus or tour operator, travel seller or hotel group |
| Region | The surveys: the US and UK, and enterprises worldwide. The reader: anywhere |
| The decision at stake | What to do when the rules behind fares, schedules and cancellation charges are known to one or two people, nothing is written down, and the skill cannot be hired: hire for the old technology, ask the experts to write it down, let an AI tool draft it, or have a checked specification made, then decide whether to move off the scarce technology |
| The public outcome | In one survey of large enterprises that run mainframes, about seven in ten said they had struggled to find the right skills. In another, of technology leaders, more than nine in ten reported harm to the business from a gap between the architecture as built and the documented standards. The tool for one common old business language has been unsupported since 8 April 2008 |
| Why it matters to a mid-size firm | Many firms in this sector run an application written years ago that holds every pricing and scheduling rule they have, readable by one or two people. The question is whether that knowledge is written down and confirmed while those people are still there, or whether a resignation forces the issue |
2. The Business Problem, in the Buyer’s Words
“Our booking and scheduling program was written in-house nearly twenty years ago. Two people can read it. When a customer disputes a cancellation charge, we wait for one of them, and if they are on leave we usually refund. Every change we want to a fare or a route sits in their queue. One of them has just given notice, and the advertisement has had no reply from anyone who knows the language. There is a manual somewhere. Nobody has opened it in years, because it was wrong.”
These words are imagined. They describe the decision as the research shows it, not a real conversation.
The firm is caught between a program only two people can read and a skill nobody is learning. Advertising again looks like the answer each time, and the knowledge stays where it was.
3. What We Found
Method. We went through the public record on old systems whose workings only a few people can explain: a vendor’s survey of technology leaders on documentation, a vendor’s survey of IT professionals on their old systems, a news report of a vendor-commissioned survey on skills, one large developer survey, a software maker’s support statement for one old development tool, and one engineer’s account on a developers’ forum. The surveys were published in 2025 and the engineer’s account in 2026. The sector research behind this study holds nothing on this issue: no named firm, no figure, and no evidence from India or the Middle East.
Skills for old technology are hard to find, even for very large firms. In a vendor-commissioned survey of several hundred senior leaders at mainframe-based enterprises, about seven in ten said they had struggled to find the right skills. The report sets the figure beside a need for skills in cloud, security and AI as well as the mainframe itself, so it is not a count of old-language skills alone. Mainframes are not IOanyT’s kind of work.
Few developers work in one common old business language.
| What | Public record |
|---|---|
| Visual Basic (.NET), the later form of the language | Used by just over 4% of respondents in one large developer survey of 2025, and wanted by under 2% |
| VB6, the original form | Not listed in that survey at all |
| The tool for building and changing VB6 programs | ”The Visual Basic 6.0 IDE and Visual Studio 6.0 IDE are no longer supported as of April 8, 2008.” Programs built with it still run on current Windows |
Which old languages firms in this sector run was not researched, and “not listed” does not mean nobody uses it.
What was built and what was written down drift apart. In one vendor’s survey of several hundred technology leaders and practitioners in the US and UK, more than nine in ten reported harm to the business from a gap between the architecture as built and the documented standards. The survey is about software in general, not about booking rules.
Old systems are the normal case, and they cost money to keep. In another vendor’s survey of about 500 IT professionals in the US, about two thirds of them in technology or software firms, about three in five organisations still use legacy systems, and nearly two in five named high maintenance or support costs among the top issues with them.
A quick written account can be worse than none. One engineer who expects to maintain a legacy codebase for years, writing about documentation colleagues had produced with AI tools, called it simply wrong, made up from start to finish, and added that sometimes no document is better than a bad one. It is one person’s account, used here only as the reason an engineer must check whatever a tool drafts.
Our reading of why the knowledge stays with one or two people. These four are our reasoning from the record above. None is a finding of any source.
- The rules were never written anywhere but the code. Each was a small change at the time, and there was always someone to ask.
- The technology went out of use. New developers do not learn it, so the people who know it cannot be replaced like for like.
- Each answer is given and then lost. An expert reads the code, replies by word of mouth or email, and nothing is kept.
- Documents that were written were not kept true. They were projects with no owner, went stale, gave one wrong answer and were abandoned.
What this record does not show. Nothing in it is about logistics, travel or hospitality, and no firm of the reader’s size appears in it. The skills survey is about large enterprises that run mainframes, a technology IOanyT does not work on, and its skills include cloud, security and AI. The developer survey is about one language. The documentation survey concerns architecture and documented standards, not booking rules. The engineer’s remark is a single voice, and does not say the documents were of the legacy codebase. All the surveys were run or paid for by firms that sell related products or services. We found no figure for what a departing expert costs a firm, how long such a vacancy stays open, what a contractor charges, or how many questions one person answers. This study does not claim that any firm in this sector has suffered any particular event.
4. The Options a Firm in This Position Had
| Option | When it fits | What it risks | Our view |
|---|---|---|---|
| Hire or contract people for the old technology | People can still be found for it where the firm is, and the program has a long life ahead | A shrinking pool; the new person becomes the next single point of knowledge; what they learn leaves with them | Right only as a bridge with an end date. IOanyT is not a staffing firm and supplies no developers |
| Ask the experts to write it down in their spare time | The program is small, and the experts truly have time | There is rarely spare time; what is written is what one person remembers, unchecked against the code | Better than nothing, rarely finished |
| Generate documentation with an AI tool and use it unreviewed | The output will only ever be a starting point that someone who knows the code checks | Unchecked, it can be confidently wrong, and one wrong answer sends staff back to the one person | We would advise against this used on its own |
| A specification produced from the code (AI first pass, engineers review it and trace it to the code, the firm’s own experts confirm it), then, if the firm chooses, 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 | Our recommendation |
What we would have advised against: for a firm in this position, leaving the handover to the notice period and spending it on teaching one successor; advertising again and again for a skill few people are learning; trusting documentation that nobody has checked against the code; and replacing the whole program in one step before anyone has written down what it does.
5. Our Recommendation, and the Decision It Asks of the Board
For the applications a firm built or had built (booking and quotation tools, scheduling and dispatch programs, rate and tariff tools, in-house billing), in the technologies IOanyT reads: have the program read and its rules written down in plain words, with the firm’s own experts, including the person who knows it best, confirming each part while they are still there. Hold that specification in the firm, give it an owner of the firm’s own, and count the questions that still only one person can answer. Then decide, on that evidence, whether to move the program off the scarce technology one module at a time, or to keep it and work from the record. The old program keeps running, looked after by the firm’s own team or supplier, throughout.
The decision it asks of the board: approve a fixed-price assessment now, while the expert is still there, rather than another round of advertising. If a rebuild follows, approve each stage on its own evidence, with the freedom to pause after any accepted module. The board stops asking who will take over, and starts tracking how many questions still only one person can answer.
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 |
|---|---|---|---|
| Rules behind fares, schedules and cancellation charges | In the code, and in one or two people’s memory | Written down in plain words and confirmed by the firm’s own experts | The specification, with who confirmed each part |
| Questions only one person can answer | Not counted | Counted, and falling at every review | The firm’s own count, reported at every review |
| Rules nobody can explain | Not known | Listed for the business to decide on | The risk register |
| Where the record lives | In one person’s head, or a supplier’s files | Held by the firm, in a form any competent engineer or supplier can work from | The specification, handed over |
| Who keeps it current | Nobody | A named owner in the firm, with time set aside | The firm’s own arrangement; IOanyT does not keep it |
| The size of one commitment | A whole replacement, or nothing | The specification first; one module at a time if a rebuild follows, with the freedom to pause after any accepted module | The staged plan |
7. How IOanyT Would Work
- We listen: a free Reliability Review. A first conversation about the program, the people who understand it, and the questions and changes 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.
- 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 booking, scheduling or dispatch application your firm built or had built, in one of the technologies we read: VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, and .NET Framework or classic ASP. 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 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. 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. As the specification is confirmed and each module is accepted, 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 program does, in plain words, confirmed by the firm’s own experts, held by the firm and usable by any competent engineer or supplier.
- The risk register: what the assessment found, including the rules nobody could explain, listed before any price is set.
- The traceability matrix: for every module IOanyT rebuilds, every old function linked to its replacement, with how it was checked.
- The code: any rebuilt modules are the client’s. No runtime or platform fee.
- The filled-in benchmark: each measure, where it started and where it stands.
Keeping the specification current, and the count of questions only one person can answer, belong to the firm’s own team.
9. What This Approach Does Not Cover
- IOanyT is not a staffing firm. It does not supply developers for the old technology, fill a vacancy, cover for someone on leave, recruit or train staff.
- IOanyT has no ask-the-system assistant and offers none. A checked, current record is useful without one; an assistant over an unchecked record gives wrong answers faster.
- IOanyT does not maintain, patch or run the old application, and does not keep the specification up to date once it is handed over. An owner on the firm’s side does, and that is a cost every year.
- IOanyT reads VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, and .NET Framework or classic ASP. It does not read COBOL, RPG, FoxPro or the languages of mainframe booking engines.
- A specification lets a newcomer understand the program; it does not let anyone edit the old code without knowing its language. Until the last module has moved, the firm still needs its own developer or contractor for the old code.
- IOanyT does not decide whether a rule is right; the firm’s own people do.
- IOanyT does not install, upgrade, move or work inside a packaged reservation, booking, warehouse or property management product, and does not work on the systems that run aircraft, trains or vehicles.
- Nothing here keeps anyone from leaving. IOanyT gives no advice on employment, pay or retention.
- IOanyT has no published case of this work for a logistics, travel or hospitality firm.
About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.
10. Sources
| Source | Used for |
|---|---|
| News report of a vendor’s survey, 2025 | The difficulty of finding the right skills (cross-sector, mainframe-based enterprises) |
| A large developer survey, 2025 | How many developers use and want Visual Basic (.NET); VB6 not listed |
| The maker’s VB6 support statement | The VB6 development tool’s end of support |
| A vendor’s survey report, 2025 | Architecture and documented standards out of step (cross-sector) |
| A vendor’s survey, 2025 | Organisations still using legacy systems; maintenance and support costs (cross-sector) |
| Developers’ forum post, 2026 | One engineer’s account of unchecked AI-written documentation |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We write down what one or two people know while they are still there to confirm it, so the firm can stop asking the person who wrote it.
Read the research notes on this issue
Scarce skills and missing documentation
Research note 1
The Rules for Your Fares Live in Code Two People Can Read. Here Is What the Public Record Shows.
Fare, schedule and cancellation rules often live in old code few can read. What the cross-sector record shows, the options, and the benchmark we would set.
Research note 2
Two People Know How Your System Works. Four Ways to Stop Depending on Them, Weighed.
When one or two people know how the system works, a resignation is a business risk. Four ways to stop depending on them, weighed, and our recommendation.
Research note 3
A Record Your Staff Open Before They Pick Up the Phone. Here Is the Benchmark We Would Set.
Most firms documented their old system once, and nobody opens it. The benchmark we would set for a record people use, and why we build no assistant.