Too Big to Approve

1. At a Glance

Issue study · From the public record. None of the organisations described as a case here was an IOanyT client, and IOanyT had no part in the events described. Both are far larger than the firms we write for, and neither replaced an application it had built: one rolled out a packaged ERP product, the other runs airline operations software. We found no public case of a mid-size logistics, travel or hotel firm replacing its own booking, dispatch or billing application. Each case is reported as the public record gives it, and we give no cause of our own.

Organisation type	A large US services firm whose packaged ERP roll-out in the mid-2000s ended in a lawsuit against the software’s maker, later settled out of court (an older case), and a large US airline whose scheduling system is about two decades old, set beside a mid-size firm that moves goods, moves people or looks after guests, with an old application everyone wants replaced
Size band	The cases: large. Our reader: a mid-size transporter, courier, forwarder, bus or tour operator, travel seller or hotel group with a booking, dispatch or billing application it built or had built
Region	The cases: US. The reader: anywhere
The decision at stake	What to do with an old application whose replacement keeps going back in the drawer: keep it, replace it in one large project, buy a packaged product, or read it first and replace it in stages
The public outcome	The services firm’s packaged ERP roll-out in the mid-2000s ended in a lawsuit against the software’s maker, later settled out of court. The airline’s scheduling system, about two decades old, failed during a period of heavy disruption, and the airline says it is moving off it later this decade
Why it matters to a mid-size firm	A replacement offered as one large commitment is hard to approve and, when it goes wrong, hard to unwind. Most firms answer by waiting, and the requests that depend on the replacement wait with it

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

“The proposal to replace our booking system has come to me three times in six years. Every time it is the same shape: two and a half years, nothing usable until the end, and one figure from a supplier who looked at the screens for an afternoon. Meanwhile every request from our agents is ‘after the replacement’. The old system still works. It is also held together by two people, and I do not know what it does. I cannot sign the figure, and I cannot keep saying no.”

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

The firm is caught between an application that still works and a replacement offered in a shape it cannot approve. The longer it waits, the more the business depends on what nobody has written down.

3. What We Found

Method. We went through the public record on large replacement projects and on long-serving operations software: reporting on a packaged ERP roll-out that ended in a lawsuit, reporting on an airline’s crew-scheduling software and the move of its systems, and one cross-sector survey of why firms keep their old systems. The sources were published or last updated in 2025 and 2026. The sector research behind this study holds no case of a mid-size firm on this issue, no figure for what a replacement costs or how long it takes at one, and no figure for what waiting costs.

A single large commitment that ended in a lawsuit. The first case is a large US services firm. This is an older case, and a packaged ERP product is not IOanyT’s kind of work.

What	Public record
The project	A packaged ERP roll-out in the mid-2000s
What followed	A lawsuit against the software’s maker
How it ended	The two companies later settled out of court
Cause	We did not examine why the roll-out led to a lawsuit, and we draw no cause from it. We do not say who was at fault

Long-serving operations software. The second case is a large US airline, and airline operations systems are not IOanyT’s kind of work.

What	Public record
The software	Crew scheduling, about two decades old
A past failure (an older case)	It failed during a period of heavy disruption
The move	The airline says it is moving its systems to a new architecture later this decade, reported as the airline’s hope

We report that timing as a hope, not as a fact that it will happen, and not as a model. We do not know what the transition costs or why it takes as long as it does.

What firms say about their old systems. In one cross-sector survey of about 500 US IT professionals, which is not about this sector, about three in five organisations still use legacy systems. Half say the main reason they have not upgraded is that the current system still works. More than two in five named budget limitations, more than a third fear of disrupting operations and about a third concerns about moving data among the reasons for not upgrading, and nearly two in five named high maintenance or support costs among the top issues with old systems.

What a developer says about changing them. One developer, writing about working on old codebases, said that changing a critical old system that has no tests is the most frightening work there is. One person’s account, and not about this sector.

Our reading of why replacements in this sector keep waiting. These four are our reasoning from the record above. None is a finding of any source, and none is said of the two organisations described here.

1. The replacement is offered as one project. It asks for the whole budget, the whole disruption and the whole move of records at once, years before anything is in use, and the argument that it still works wins.
2. The price is set before anyone has read the system. What the supplier could not see becomes a margin, and a margin cannot be examined.
3. Nobody has written down what the old application does. So nobody can say when a new part is finished, and differences are found on live bookings.
4. Stopping halfway loses everything. A single project halted at two-thirds has nothing in use, so starting feels like a bet on finishing.

4. The Options a Firm in This Position Had

Option	When it fits	What it risks	Our view
Keep the old application and live with it	It is stable, its experts are staying, and nothing the business needs waits on it	The cost of staying stays unwritten; requests pile up; the experts leave one day	Right for some firms for a time, but only once the cost of staying is written down
Replace it in one large project, with one price and one go-live	The application is small, well documented and can be switched over in one go	Nothing in use for years; the price is set before the system is read; a project stopped halfway delivers nothing	We would advise against this for a firm’s own, much-changed application
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 and links to agents, depots and billing must be refitted to the product	The firm’s own decision, and not IOanyT’s kind of work
The assessment first, then a staged rebuild, billed by milestone, each milestone tied to a module the firm accepts, with a pause after any accepted module	The application is the firm’s own, much changed, and the business cannot stop	Costs money before anything new is built; old and new run side by side for a time; the whole may take as long as one project, or longer	Our recommendation

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

For the applications a firm built or had built (booking and quotation tools, dispatch and trip-planning, consignment tracking, customer and agent portals, in-house billing), in a technology IOanyT reads: read the application first. Write down what it does, confirmed by the firm’s own experts, list the unknowns in a risk register, set the cost of keeping it beside the cost of replacing it, and price each stage. Then replace it one module at a time beside the old application, each module checked against the old one with a traceability matrix and accepted before the next is begun. The old application keeps working, run by the firm’s own team or supplier, until each module is accepted. We do not say this is quicker or cheaper overall; it may take as long as one project, or longer. What it changes is that something is in use after the first stage, each stage has a price before it is approved, and the firm can pause after any accepted module.

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
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, set before anyone read the system	A price for each stage, known before that stage is approved	The staged plan with a fixed quote
The cost of staying	The support fee alone	The fee, work done by hand, requests dropped and the people the system depends on, in one place	The cost comparison
Unknowns	A margin in the quote	Listed, each with what it could change	The risk register
What the old application does	In the heads of two or three people	Written down and confirmed by the firm’s own experts	The specification
Old behaviour matched	Compared once, in a trial at the end	Every old function linked to its replacement and checked before the module is accepted	The traceability matrix
The size of one commitment	The whole replacement, or nothing	One module, with the freedom to pause after any accepted module	The staged plan

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about the application, the proposals that went back in the drawer and the requests waiting on it. 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 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.
4. 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, each module checked against it before you accept it. 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.
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 the firm’s own application does, in writing, confirmed by its own experts.
• The risk register: the unknowns, listed before any price is set, each with what it could change.
• The cost comparison and the staged plan: the cost of keeping beside the cost of replacing, and a price for each stage.
• The traceability matrix: for every module IOanyT rebuilds, every old function linked to its replacement, with how it was checked.
• 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.

Switching off each part of the old application, and running it until then, belong to the firm’s own team.

9. What This Approach Does Not Cover

• IOanyT does not keep the old application running or secure during the replacement. The firm’s own team or supplier does, until each module is accepted.
• IOanyT does not move, clean or reconcile the firm’s records as a stated service. While old and new run side by side, bookings and records must be kept in step between them, and that is planned with the firm.
• IOanyT does not install, upgrade, move or choose a packaged reservation, booking, warehouse, property management or ERP product, does not work on the customisations inside one, and is not a partner of any maker.
• IOanyT does not work on the systems that run aircraft, trains or vehicles, or on anything on which a traveller’s safety depends, and does not read COBOL, RPG or the languages of mainframe booking engines.
• IOanyT does not say a staged replacement is quicker or cheaper overall. It may take as long as one project, or longer, and old and new running side by side has a cost.
• The assessment will not remove every unknown; it tells you which ones remain. A traceability matrix shows that a module does what the old one did, not that the old one was right, and not how the module behaves at the heaviest volume.
• IOanyT does not train staff or manage the change in how people work.
• IOanyT does not offer a compliance, audit or legal service, and says nothing about what any tax, transport or data protection rule requires of a particular firm.
• This study does not say IOanyT would have prevented the events described, or how either organisation described here should have run its project. 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
Trade press article, 2025	A large US services firm: the roll-out, the lawsuit and the settlement
Trade press article, 2026	A large US airline: the software’s age, a past failure and the airline’s plan to move off it
A vendor’s survey, 2025	Why firms keep old systems
A developer’s post, 2025	One developer’s account of changing old systems without tests

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. A replacement too big to approve can be split into a first stage that is not.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →