Could Not Keep Up With the Changes

1. At a Glance

Issue study: a public case, not an IOanyT client. None of the organisations named as a case here was an IOanyT client, and IOanyT had no part in the events described. All three are far larger than the firms we write for: two airlines and a national railway. We found no public case of a mid-size logistics, travel or hotel firm whose booking, dispatch or tracking application slowed or failed in its busy season. Each case is reported as the public record gives it, and the railway, a government body, without judgement.

Organisation type	A large US airline whose long-serving crew-scheduling software met more change than it could work through (an older case), set beside the position of a mid-size firm that moves goods, moves people or looks after guests, before its busiest season
Size band	The cases: large. Our reader: a mid-size transporter, courier, forwarder, bus or tour operator, travel seller or hotel group whose own applications slow on its busiest days
Region	The airlines: US. The railway: India. The reader: anywhere
The decision at stake	What to do after a slow season or a bad day: buy more servers again, move the hosting, replace the application with a packaged product, or find the part whose design sets the limit and rebuild it
The public outcome	After Winter Storm Elliott, from 21 to 30 December 2022, the airline’s crew-scheduling software, first implemented in 2004, was “overwhelmed by the number of flight changes necessary”; “over 16,700 flights were canceled”, the airline recorded losses of over one billion US dollars, and it was fined 140 million US dollars by the US transport department, “the agency’s largest fine in history”
Why it matters to a mid-size firm	Software can serve for years with a limit nobody has seen. An application built for an ordinary week has one part that gives way first, and most firms find out which in the week they can least afford to

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

“Our year is made in a few weeks: the holidays, the festival fortnight, the big shippers’ launches. Every year the booking screen crawls on the first Friday, and every monsoon the dispatch screen stands still when a main road closes. Afterwards we are told it was the load, and we buy more servers. Last year we doubled them, and the dispatchers still went back to the whiteboard. I do not know which part gives way, whether servers were ever the answer, or what I should spend on before the next season.”

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

The firm is caught between applications built for an ordinary week and a business whose best weeks are anything but. The answer it can buy quickly, capacity, may not reach the part that limits it.

3. What We Found

Method. We went through the public record on booking and operating systems that met their limits: reporting on a long-serving crew-scheduling system that could not keep up after a storm, reporting on an airline’s two IT groundings in 2025, a published capacity figure for a national reservation system, one cross-sector survey on how firms see their old systems, and the one result of this kind that IOanyT has published. The sources were published between August 2025 and July 2026. The sector research behind this study holds no case of a mid-size firm on this issue, no figure for bookings lost in a slow hour and no figure for how often it happens.

Software that could not keep up with the changes. The first case is a large US airline. This is an older case, it began with a storm and not with bookings, and airline operations systems are not IOanyT’s kind of work.

What	Public record
The software	Crew scheduling, “First implemented in 2004”
What happened	It was “overwhelmed by the number of flight changes necessary” after Winter Storm Elliott, 21 to 30 December 2022
The cause, as reported	Blame “was primarily assigned to the failings of” the airline’s “crew scheduling software”
Effect	”over 16,700 flights were canceled”
Cost	Losses of over one billion US dollars
Penalty	Fined 140 million US dollars by the US transport department, “the agency’s largest fine in history”

An operation that stopped when one part failed. The second case is another large US airline. It had two IT groundings “in a matter of months” in 2025, in July and on 23 October. On the October day the airline said, “we’ve had more than 229 flight cancellations”. The cause it gave in October was “a failure at its primary data centre”, and it said the event was not a cybersecurity incident; in July it was “a critical hardware failure at a data centre”. This was not a system overwhelmed by demand, and we do not present it as one. We use it only to show that a whole operation can stop when one part it depends on fails.

A ceiling, stated. In a written answer in the Lok Sabha in August 2025, the railway minister said that “the booking capacity of the current PRS”, the passenger reservation system of Indian Railways, “is about 25,000 tickets per minute”. That is a very large capacity, and it is still a limit, written down in advance. We report the figure as given and say nothing about how the system performs or about its announced replacement.

What firms say about their old systems. In one cross-sector survey of 504 US IT professionals, which is not about this sector, 40% named limited scalability among the top issues with their old systems, and half said the biggest reason they had not upgraded is that the current system still works.

What IOanyT has itself published. In IOanyT’s cloud migration for an e-commerce client outside this sector, capacity went from 300 to 30,000+ concurrent users. It was a move of hosting to AWS. It was not a replacement of old code, and it is one client’s result, not a forecast.

Our reading of why these applications give way at peak. These four are our reasoning from the record above. None is a finding of any source.

1. Nobody knows which part gives way first. In an ordinary week every part has room to spare, so nothing shows where the limit is.
2. Capacity is fixed, and demand is not. The firm has the same servers in its busiest fortnight as in its quietest week.
3. Some steps were built to take turns. A step that must be exact, such as allotting a seat, a room or a vehicle, or re-planning a trip, was often written to deal with one request at a time, and more servers do not change that.
4. The answer is always more servers. They can be bought quickly, so the real limit is not looked for.

4. The Options a Firm in This Position Had

Option	When it fits	What it risks	Our view
Add servers or a bigger hosting plan	The limit really is a shortage of capacity, and the application’s parts can share the work	Does nothing for a step that serves one request at a time; servers bought for the peak sit idle all year	Right only once the reading shows capacity is the limit
Move the hosting to the cloud, with capacity that rises and falls	The application’s parts can run as many copies, and the firm is free to use the cloud	A project with its own risk, not to be made just before a season; a busy week costs more than a quiet one; does nothing for a step that serves one at a time	Right for the parts that can share the work, as a separate decision
Replace the application with a packaged reservation or booking 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; nobody yet knows which limit the old application had	The firm’s own decision, and not IOanyT’s kind of work; we would advise against this as the answer to slow seasons alone
Read the code to find the part whose design is the limit, then rebuild that part module by module	Slow seasons and stalled bad days keep coming back after servers were added	Costs money before anything is faster; removing one limit shows the next	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): find the part first, then rebuild it. Read the code to see how each shared part is built and what waits on it, and name the part whose design is most likely to set the limit, such as the availability search, the allotment step or the step that re-plans trips. Then rebuild that part module by module beside the old application, with a traceability matrix to prove each module does what the old one did. The old application keeps working until each module is accepted. Where the reading shows that the limit is a shortage of capacity and the parts can share the work, a move of hosting may be the right answer instead or as well, as a separate decision. Behaviour at peak volume is measured by a load test the firm’s own team arranges, and the bad day is run on a plan the firm’s own team owns.

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
Each part of the application, with its known limit	Not listed; “the load”	Every shared part listed, with how it is built and what waits on it, as read from the code (not from a load test)	The specification and the risk register
The part that sets the ceiling	Found in the busy week, if at all	Named in a quiet month, with the reason	The risk register
Answers weighed after a bad season	One: more servers	Four, each weighed against the part that gave way	The cost comparison
The limiting part rebuilt	Untouched, because it decides which vehicle, seat or room goes where	Rebuilt module by module beside the old application, each module shown to do what the old one did	The traceability matrix
What must never go wrong	Assumed	Written down: no vehicle given two trips at once, no seat or room allotted twice	The specification, and the traceability matrix
Behaviour at peak volume	Learned from agents, staff and dispatchers on the day	Measured in a load test the firm’s team arranges; IOanyT claims no figure	The firm’s own load test
A plan for the bad day	In one senior dispatcher’s head	Written and owned by the firm’s team	The firm’s plan; IOanyT takes no part on the day

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about the applications, the last season and the servers bought since. 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 tracking application your firm built or had built. 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 the part whose design is the limit, rebuilt beside the old application. 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, with each shared part and what waits on it.
• The risk register: the parts most likely to set the limit, 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: 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.

The load test and the plan for the bad day belong to the firm’s own team.

9. What This Approach Does Not Cover

• IOanyT does not monitor or run the application, does not analyse incidents as a service, and is not on call in a busy week or on a bad day. The firm’s own team or supplier runs it, before, during and after.
• IOanyT does not host the application.
• IOanyT promises no uptime and no figure for speed or capacity, and claims nothing about how the application will behave at peak volume.
• IOanyT does not run load tests, and its assessment does not include one. Reading the code shows where limits are likely to be; only a test gives a number. A traceability matrix shows that a rebuilt part does what the old one did, not how it behaves under full load.
• When one limit is removed, the next narrowest part becomes the limit, so the work may not end with one module. No software reopens a road or changes the weather.
• Cloud capacity is paid for by use, so a very busy week costs more than a quiet one. A hosting move should not be made just before a season.
• 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 cannot reach a limit inside such a product or another company’s service.
• 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 the languages of mainframe booking engines.
• IOanyT does not offer a compliance, audit or legal service, and says nothing about what any transport, aviation or data protection rule requires of a particular firm.
• This study does not say IOanyT would have prevented the events described. IOanyT’s one published result of this kind was a move of hosting for an e-commerce client; it has no published case of this work for a logistics, travel or hospitality firm.

10. Sources

Source	Used for
Simple Flying, 8 July 2026	The first airline: the software, the storm, the cancellations, the losses and the fine
Aerospace Global News, 24 October 2025	The second airline: the two groundings, the cancellations and the causes the airline gave
News report of a Lok Sabha written answer, 20 August 2025	Indian Railways’ reservation capacity, as the railway minister gave it
A vendor’s survey, 25 August 2025	Limited scalability, 40%; “the current system still works”, half
IOanyT case study	IOanyT’s cloud migration for an e-commerce client

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. Every application has a ceiling; we read the code to find which part of yours sets it, before the next season does.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →