The Rules for Your Fares Live in Code Two People Can Read. Here Is What the Public Record Shows.

A customer of many years disputes a cancellation charge. It looks high for a booking cancelled three weeks ahead.

The reservations manager checks the booking. The charge is what the system worked out. Why it worked it out that way, the manager cannot say. Nor can anyone else on the floor.

The question goes to one of the two developers who can read the booking code. That developer is on leave until Monday. When the answer comes, four days later, it runs to three lines: a rule added years ago for one season’s group bookings, and never taken out. By then the charge has been refunded.

What We Found

For this article we went through the public record on old systems whose workings only a few people can explain: two vendor surveys of technology leaders and IT professionals, a news report of a third vendor survey, one large developer survey and a software maker’s support statement for one old development tool. The surveys were published in 2025.

First, what we did not find: nothing from logistics, travel or hospitality. The research behind this article found no named firm in this sector with the problem, and no figure for it. Every fact below is cross-sector, and we label it so.

What was built and what was written down drift apart, and it costs firms. 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 or this sector.

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.

The skills are hard to find, even for very large firms. 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 skills in cloud, security and AI as well as the mainframe itself, so it is not a count of old-language skills alone.

Few developers still work in one common old business language. 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, does not appear in the survey 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.” Programs built with it still run on current Windows; the supported tool for building and changing them is what ended. Which old languages firms in this sector run was not researched, and “not listed” does not mean nobody uses it.

Our reading: each rule in a booking or scheduling application was a small change at the time, and while its authors were down the corridor, asking them was quicker than writing it down. So the rules now live in code one or two people can read, and each answer they give is used once and lost.

What Waits While the Rules Stay in Code

A question that waits for one developer is usually treated as an inconvenience. Our reading is that it shapes what the business can do.

A disputed charge is conceded. When nobody can say why the system charged what it did, the quickest answer for a good customer is a refund, whether or not the charge was right.

Fares and schedules change slowly. A new fare rule, a change to a cancellation charge or a new route waits for the one person who can see what else it touches.

The vacancy stays open. An advertisement for the old technology brings few replies, so the load on the people who have it does not ease.

This is our reading of the evidence. It is not a measured market figure.

Four Ways to Find Out What Your System Does, Weighed

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

Option	When it fits	What it risks
Ask the developer, each time a question comes up	Questions are rare, and the people who know the code are staying for years	Every answer is paid for and then lost, and the arrangement ends the day they are away or gone
Use the old manual or notes	They were written recently and have been kept up with every change	Most were written once, years ago; one wrong answer and staff go back to the developer
Have an AI tool draft documentation from the code, and use it as it comes	The draft is only a starting point that someone who knows the code will check	Unchecked, it can be confidently wrong, and nobody can tell which parts until a customer finds one
Read the code once and write a specification, checked by engineers and confirmed by your own experts	The application matters, keeps changing, and one or two people can read it	It costs money and your experts’ time before anything is easier, and it turns up rules nobody can explain

Where You Are Now, and Where You Should Be

Before any work begins we set a benchmark: a few measures taken from your own application, each with a target. For this issue it would look like this.

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	Each written in plain words, with where it lives in the application	The specification
Who has confirmed each rule	Nobody	Your own experts, named against each part they confirmed	Who confirmed each part of the specification
Rules nobody can explain	Not known	Listed for the business to decide on	The risk register
Questions only one person can answer	Not counted	Counted, and falling at every stage	Your own count, reported at every review

The starting points above are 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 logistics, travel or hospitality firm.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about the application, the people who understand 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 article is an example of that work.
3. 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. 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.
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 people can be hired for, each new module written from the specification. 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.
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 we do not do: we are not a staffing firm, and we supply no developers for the old technology. We do not maintain, patch or run the old application, before, during or after; your own team or supplier keeps it going. We do not keep the specification up to date for you once it is handed over; that is your firm’s own work. 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 have no published case of this work for a logistics, travel or hospitality firm.

What changes for the business:

Role	What they gain
CEO	The firm can say how its own fares, schedules and charges are decided, and no longer waits for one person to explain.
CTO or CIO	A plain-language record of the scheduling and booking rules, traced to the code, so a question is answered by reading and not by digging.
CFO	A disputed charge or fare can be explained from a written rule, and need not be conceded for want of an answer.
COO	Reservations and dispatch staff can read why the system did what it did, and can tell a customer.
Head of people	What the firm knows about its systems stops being held in two heads, so leave and workload can be managed as for anyone else.

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 in this position. Its figures come from cross-sector vendor surveys, one developer survey and a software maker’s support statement.	For booking, scheduling and dispatch applications in the technologies we read, we write down what the application does, checked by our engineers and confirmed by your own experts. 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 read the old code once, so that nobody has to wait until Monday to learn the firm’s own rules.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →