The Day the Plan Changes Is the Day That Counts. Here Is the Benchmark We Would Set.

At six in the morning the highway north is closed. Three hundred and forty of the day’s trips run on it.

Each needs a new route, a new arrival time and, for some, a different vehicle. The dispatch application can do all of that, one trip at a time, each taking most of a minute. After last year’s festival the firm doubled the servers. This morning they are barely working.

By eight the dispatchers have stopped waiting. They are on the phones, with a whiteboard, re-planning by hand. The queue is in a routine written eleven years ago that saves one changed trip before it starts the next.

What We Found

We looked at the public record on software that met more change than it could work through, and at one cross-sector survey. None of it is about a firm of our readers’ size: the research behind this article holds no case of a mid-size logistics, travel or hotel firm whose application stalled when its plan changed.

A design limit does not show until the day it is reached. This is an older case, from 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 Winter Storm Elliott, from 21 to 30 December 2022. In the same report, “over 16,700 flights were canceled”, and the airline recorded losses of over one billion US dollars. The report assigns the blame primarily to that software; we add no cause of our own, and take one narrow point: software that had served for years met more change in a few days than it could work through.

Old systems are widely seen as hard to grow. In one cross-sector survey of 504 IT professionals in the US, which is not about this sector, 40% named limited scalability among the top issues with their old systems.

What Knowing the Limit Opens Up

A list of an old application’s limits is usually seen as the technology team’s homework. Our reading is that it frees more.

• The money goes to the limit. Spending is tied to the step that holds up the day, not spread across servers that were never the problem.
• The fix has a test of “done”. A rebuilt step is checked, function by function, against the old one before it re-plans a real trip.
• The bad day gets a plan. With the weak steps named, your own team can write down who re-plans what, what is done by hand, and who decides, before the next road closes.

This is our reading. It is not a measured market figure.

Three Ways to Prepare for the Next Bad Day, Weighed

Option	When it fits	What it risks
Double the servers again	The last stall was a plain shortage of capacity, and the application’s parts can share the work	If the limit is one step’s design, the bill rises and the dispatchers still reach for the whiteboard
Commission a load test and act on the result	The application is already well understood, and the firm wants a number before the season	A test shows where the application slows, not why, and leaves little time to act on what it finds
Read the code, rebuild the limiting step module by module, and prove each module does what the old one did; your team then tests and plans for the bad day	Stalls keep coming back after capacity was added	It costs money before anything is faster, removing one limit shows the next, and it does not by itself show behaviour at peak volume

Where You Are Now, and Where You Should Be

This is the benchmark we would set before the first module is rebuilt, and fill in as each module is accepted.

Measure	Typical starting point	Where it should be	How it is checked
Answers weighed after a bad day	One: more servers	Each weighed against the step that gave way	The cost comparison
The limit named	Called “the load”	Named: a shortage of capacity, or a step built to deal with one request at a time, as read from the code	The specification and the risk register
The cost of a bad day	Scattered across budgets	Servers, staff time, late work and the cost of each answer, in one place	The cost comparison
The size of one commitment	A new system, or nothing	One module, with the freedom to pause after any accepted module	The staged plan
The limiting step rebuilt	Untouched, because it decides which vehicle goes where	Rebuilt module by module beside the old application, each shown to do what the old one did	The traceability matrix, module by module
What must never go wrong	Assumed	Written down for the rebuilt step: 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 dispatchers on the day	Measured in a load test your own team arranges; we claim no figure	Your own load test, outside our work
A plan for the bad day	In one senior dispatcher’s head	Written, and owned by your team: who re-plans what, what is done by hand, who decides	Your plan; we take no part on the day

The starting points above are what we expect to find. In an engagement they are replaced by your own position, 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.

A small part of the finished list might look like this.

Part of the application	Its known limit, as read from the code	Status
Re-planning of trips after a change	Saves each changed trip before starting the next, so changes take turns	Stage 1: rebuilt beside the old application; matrix accepted; load test arranged by the firm
Tracking page	Reads the plan; built to run as many copies side by side	No rebuild needed
Devices in the vehicles	Systems that run vehicles	Outside our work

The rows above are an illustration, not taken from a real firm.

How We Work With You, and What You Are Left With

1. We listen: a free Reliability Review. A first conversation about the application and the last bad day. 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.
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 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 step 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 above. As 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.

This has a price. The step that sets the ceiling is usually the most delicate code in the application: it decides which vehicle, seat or room goes where. When one limit is removed, the next narrowest part becomes the limit, so the work may not end with one module. A traceability matrix shows that the new step does what the old one did; it does not show how it behaves under full load. We do not run load tests, our assessment does not include one, and we promise no uptime, no speed and no capacity. We do not monitor, run or host your application, and we are not on call on a bad day; your own team or supplier runs it. If the limit sits inside a packaged reservation, booking, warehouse or property management product, or another company’s service, we cannot reach it; we do not install, upgrade, move or choose such products. We do not work on the systems that run aircraft, trains or vehicles. And no software reopens a road or changes the weather. We have no published case of this work for a logistics, travel or hospitality firm.

At the end you hold the specification, the list of parts with their known limits, and the traceability matrix and code for every module we rebuilt. The load test, the plan for the bad day and the decision on the next limit are your team’s.

What changes for the business:

Role	What they gain
CEO	The old step that held up every change on a bad day is rebuilt, and the board knows which limit comes next.
CTO or CIO	The step that handled one change at a time is replaced by code built to handle many, and checked against the old for the same answers.
CFO	Spending on servers that did not move the limit can stop, and each stage is approved on its own evidence.
COO	What must never go wrong when trips are re-planned, such as one vehicle given two trips, is written down and checked, function by function, in the rebuilt step.
Head of sales and marketing	The re-planning step behind the tracking page is rebuilt and checked against the old, and sales knows who tells customers what on a bad day.

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, first implemented in 2004, was overwhelmed by the number of flight changes after a storm in December 2022, and over 16,700 flights were cancelled. An older case.	Our part is far narrower, and we do not work on airline systems or say what would have helped. For an application a firm in this sector built, we find the step whose design sets the limit and rebuild that step alone, with the old system 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 cannot promise that a bad day will go smoothly, and we will not; we can show you which step it will turn on.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →