The Old System Still Works. That Is Why the Replacement Never Starts.
We went through the public record on why firms keep old systems and how long replacing operations software can take. It holds no case of a mid-size logistics, travel or hotel firm, and we say so. Here is what we found, the four ways forward weighed, and the benchmark we would set.
The proposal to replace the booking system is on the owner’s desk for the third time in six years.
It is a careful proposal. The build runs for thirty months, everything goes live together at the end, and the price is one figure on one page. The head of sales asks what will be different next season. Nothing, is the answer. And the season after that? Nothing then either.
Nobody says the old system is fine. It holds fifteen years of fares and exceptions, two people understand it, and every request from agents is answered “after the replacement”. But it took four thousand bookings yesterday. The owner signs this year’s support fee and puts the proposal back in the drawer.
The paradox: The old system is kept because it still works, and the replacement is refused because it asks for everything before it delivers anything.
What We Found
For this article we went through the public record on replacing long-serving operations software in travel and transport, and one cross-sector survey of why firms keep their old systems. The sources were published in 2025 and 2026.
First, what we did not find: no case of a mid-size logistics, travel or hotel firm replacing an application it built. The one organisation we name below is far larger than the firms we write for.
Replacing long-serving operations software is measured in years, even where the need is plain. This is a very large airline, and airline operations systems are not our kind of work. At a large US airline, crew-scheduling software “First implemented in 2004” was, in one report’s words, “overwhelmed by the number of flight changes necessary” after a winter storm in December 2022. That event is an older case. The same report, published in July 2026, says “The airline hopes to complete the transition by 2028”: a move of its systems to a new architecture. We report that date as the airline’s hope, not as a fact and not as a model. We do not know what the transition costs or why it takes as long as it does. Our narrow point: software that served for years is not replaced in a season.
Most firms still run old systems. In one cross-sector survey of 504 IT professionals in the US, which is not about this sector, “62% of organizations still use legacy systems”.
“It still works” is the first reason firms wait. In the same survey, “50% say the biggest reason they haven’t upgraded is because ‘the current system still works.’” In an ordinary week, an old booking application does still work.
Money, disruption and data come next. Budget limitations were named by 44%, fear of disrupting operations by 38% and data migration concerns by 35% among the reasons for not upgrading.
Waiting is not free either. High maintenance or support costs were named by 39% among the top issues with old systems.
Our reading: each of these is a reason to refuse one large project, not to keep an old system forever. A replacement planned as one project asks for the whole budget, the whole disruption and the whole move of data at once, years before anything is in use. Against that, “it still works” wins every year.
What our review does not show: We found no firm in this sector of our readers’ size that replaced an application it built, no figure for the cost or time, and nothing from the Middle East on this issue. The airline’s system is far beyond our readers’ scale, and its 2028 date is a hope reported in the press, not a result. The survey is cross-sector, from a firm that sells related services. That most replacements wait because they are offered as one large project is our reasoning, not a measured finding.
What a First Stage in Use Changes
A replacement is usually judged on its total. Our reading is that the decision turns first on when the firm gets anything back.
Something is in use after the first stage. One module, rebuilt beside the old application and accepted by the people who use it, goes into use while the old application does everything else.
The first commitment is small enough to approve. The board decides one stage, with a price known before it says yes, and not the whole programme on one page.
Stopping stops being a loss. After any accepted module the firm can pause, and keeps what it has.
What the old system does is written down. Before anything is rebuilt, its rules are put on paper and confirmed by the firm’s own people.
The gap we see: most firms in this sector that need a replacement have only been offered one shape of it: one project, one price, one go-live, so the board chooses between “all of it, years from now” and “nothing, again”. The opportunity is a third shape, in which something is in use after the first stage and the board can pause after any accepted module.
This is our reading of the evidence. It is not a measured market figure.
Four Ways to Deal With a System Everyone Wants Replaced, Weighed
There are four real options. Each one is right for somebody.
| Option | When it fits | What it risks |
|---|---|---|
| Keep the old system and live with it | It is stable, the people who understand it are staying, and nothing the business needs is waiting on it | The cost of staying is never written down. The people who understand it leave one day, and every request stays “after the replacement” |
| Replace it in one large project, with one price and one go-live | The application is small, well documented and easy to switch over in one go | Nothing is in use for years. The price is set before anyone has read the system, and a project stopped halfway delivers nothing |
| Replace it with a packaged reservation, warehouse, property management or ERP product | The firm’s way of working fits such a product, and it can carry a long change | The firm’s own rules must be refitted to the product. This is the firm’s decision, and not our kind of work |
| Read the application first, then rebuild it in stages, billed by milestone, each milestone tied to a module you accept, with a pause after any accepted module | The application is the firm’s own, much changed over the years, and the business cannot stop while it is replaced | It costs money before anything new is built. Old and new run side by side for a time, and the whole may take as long as one project, or longer |
Our recommendation: read the application first, so that the price is set after what it does is written down. Then replace it in stages, one module at a time, with the old application still running, billed by milestone, each milestone tied to a module you accept, and with the freedom to pause after any accepted module. We do not say this is quicker or cheaper overall; it is a different arrangement of the same work. This is for applications a firm built or had built, in technologies we read; we do not implement or move packaged products, and we do not work on the systems that run aircraft, trains or vehicles.
Where You Are Now, and Where You Should Be
Before any work begins we set a benchmark: a few measures, each with a target. For this issue it would look like this.
| Measure | Typical starting point | Where it should be | How it is checked |
|---|---|---|---|
| Modules in use after the first stage | None until the final go-live | At least one module accepted and in use, with the old application doing the rest | Acceptance recorded for each module |
| A price for each stage | One figure for everything, given before the application was read | A price for each stage, known before that stage is approved | The staged plan with a fixed quote |
| The size of one commitment | The whole replacement, or nothing | One module, with the freedom to pause after any accepted module | The staged plan |
| The cost of staying | The support fee alone | The fee, the work done by hand around the system and the requests waiting on it, in one place | The cost comparison |
| What the old application does | In the heads of two people | Written down, and confirmed by your own experts | The specification |
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
- We listen: a free Reliability Review. A first conversation about the application and the proposals in the drawer. 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 the booking, dispatch or billing application your firm built or had built, in a technology we read: VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, or .NET Framework and 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. 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 your own application, rebuilt beside the old one, module by module, each module in use once you accept it. 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.
What we do not do: we do not keep the old application running while the work goes on; your own team or supplier does, until each module is accepted. We do not move, clean or reconcile your records as a stated service. We do not implement, upgrade or move a packaged reservation, booking, warehouse, property management or ERP product, and we do not change the customisations inside one. We do not work on the systems that run aircraft, trains or vehicles, and we do not read COBOL, RPG or the languages of mainframe booking engines. We do not say a staged replacement is quicker or cheaper overall. 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 replacement stops going back in the drawer, because the first commitment is one module the board can approve this year, with the freedom to pause after it. |
| CTO or CIO | Each module goes into use when it is accepted, so the team learns from real use early and is never years from its first delivery. |
| CFO | Each stage that is paid for ends in a module that is accepted and in use, so spending and use arrive together and not years apart. |
| COO | Depots and desks meet one change at a time, each checked and accepted, and keep the old screens for everything else. |
| Head of sales and marketing | The part customers and agents see can be among the first modules in the staged plan, so sales is not told to wait for the whole programme. |
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| A large US airline’s crew-scheduling software was first implemented in 2004; the airline hopes to complete the transition of its systems to a new architecture by 2028. An older case for the 2022 event. | Our part is far narrower, and we do not work on airline systems or comment on the airline’s plan. For an application a firm in this sector built or had built, we write down what it does and replace it one module at a time, with the old application still running. |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We would rather your replacement put one module into use than put one more proposal in the drawer.
Sources
In this issue
Too slow and costly to replace