Everything Waits for "After the Replacement". Four Ways Forward, Weighed.
What customers and agents ask for is promised for "after the replacement", and the replacement is one figure nobody can explain. Here is what waits meanwhile, the four ways forward weighed, and the benchmark for the decision.
The head of sales has the agents’ list in front of her again. It has not changed in two years.
Live availability. Instant confirmation. Statements agents can download. Each time she takes the list to technology, the answer is the same: after the replacement. When is that? Nobody knows, because the replacement has not been approved.
It has not been approved because of the figure. One supplier saw the booking system for an afternoon and quoted one large sum, forty per cent due on signing. The finance head asked what the sum was made of. Nobody could say.
The paradox: Every request waits for the replacement, and the replacement waits for a figure nobody can explain.
What We Found
We looked at the public record on a large system project that ended in dispute, at why firms put off replacing old systems, and at one Indian rule already in force.
A single large commitment can end in a lawsuit. This is a very large US firm, an older case, and a packaged ERP product, which is not our kind of work. Its packaged ERP roll-out in the mid-2000s ended in a lawsuit against the software’s maker, later settled out of court. We did not examine why the roll-out led to a lawsuit, and we draw no cause from it or say who was at fault. We use it for one narrow point: when a replacement is bought as one large commitment, a disagreement about it can be as large as the commitment.
Firms wait because of money, and because the system works. In one cross-sector survey of about 500 IT professionals in the US, which is not about this sector, half say the main reason they have not upgraded is that the current system still works. More than two in five named budget limitations.
Some changes do not wait for a replacement. In an advisory of 17 December 2024, India’s GST network made multi-factor authentication (login with a username, a password and a one-time code) mandatory on the e-way bill and e-invoice systems in steps, the last “from 1st April 2025 for all other taxpayers and users”. The same advisory said “The generation of E-Way Bills will be restricted to documents dated within 180 days from the date of generation”. Who must act: those who generate e-way bills; the advisory speaks of “taxpayers and users” and names no sector. Whether that includes a transporter is for a tax adviser to confirm. These changes are already in force.
What our review does not show: The services firm’s case was a packaged ERP programme at a very large firm, in the mid-2000s, not the kind of work we describe, and we draw no cause from it. We found no figure for what keeping or replacing an old system costs a mid-size firm in this sector, no case of a firm here replacing its own application, and nothing from the Middle East on this issue. No source ties the GST rule to any firm’s old dispatch system; that link is our reading. The survey is cross-sector, from a firm that sells related services.
What Waits for “After the Replacement”
Beside one large figure, keeping the old system looks cheap. Our reading is that most of what waiting costs is never written down.
The requests. Live availability, instant confirmation, a new rate type: each is answered “after the replacement”, and the dropped ones appear in no budget.
The figure nobody can explain. A quote given after an afternoon’s look prices what the supplier could not see as a margin. A margin cannot be examined, so the safe answer is no.
The people. The rules of an old booking application often live in two or three heads, and leave with them.
The dates set by others. Our reading, and only that: a dispatch application that logs in to the e-way bill system with a stored password and raises bills on its own may have had to change when the second login step became mandatory. If the answer was a manual workaround “until the replacement”, that workaround is part of the cost of waiting. Whether and how the rule applies to your business is for you and your tax adviser.
The gap we see: judged against one large figure for replacing everything, waiting always wins. Judged against the full cost of waiting, and a replacement bought one module at a time with a price for each stage, it is a different decision. The opportunity is to put both columns before the board, give the waiting requests a place in a staged plan, and make the first commitment small enough to pause after.
This is our reading of the evidence. It is not a measured market figure, and we put no rupee value on it; that has to come from your own business.
Four Ways to Answer “After the Replacement”, Weighed
| Option | When it fits | What it risks |
|---|---|---|
| Keep the old system and live with it | It is stable, its experts are staying, and nothing the business needs waits on it | The cost of waiting stays unwritten, and a date set by someone else can arrive first |
| One large replacement project, with one price and one go-live | The application is small, well documented and can be switched over in one go | The whole sum is committed before the system has been read. What nobody listed arrives later, as change requests or a dispute |
| A packaged reservation, warehouse, property management or ERP product | The business runs close to the way the product expects, and can carry one large change | The firm’s own rules must be refitted to the product. This is the firm’s decision, and not our kind of work |
| The assessment first, then a staged rebuild, 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, and the business cannot stop while it is replaced | It costs money before anything new is built. The specification may show more work than the first quote assumed. Old and new run side by side for a time, and the whole may take as long as one project, or longer |
Our recommendation: the assessment first, so the price is set after the old application has been read and its unknowns listed. Then a staged rebuild, billed by milestone, each milestone tied to a module you accept, with the freedom to pause after any accepted module. We do not say this is quicker or cheaper overall; it replaces one figure nobody can explain with a price for each stage. This is for applications a firm built or had built, in technologies we read. We do not implement packaged products, which is what the one public case here involved, and we do not work on the systems that run aircraft, trains or vehicles.
Where You Are Now, and Where You Should Be
Before another year on the old system is agreed, we would set a benchmark for the decision.
| Measure | Typical starting point | Where it should be | How it is checked |
|---|---|---|---|
| Requests waiting on the replacement | A list on a whiteboard, answered “after the replacement” | Each request placed against the module that would carry it | The staged plan |
| 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 |
| 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 |
| Unknowns | A margin in the quote | Listed, each with what it could change | The risk register |
| The size of one commitment | The whole replacement at once, or nothing | One module, with the freedom to pause after any accepted module | The staged plan |
| Dates set by others | Not linked to any part of the system | Each listed against the part of the application it reaches | The risk register beside the staged plan |
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.
How We Work With You
- We listen: a free Reliability Review. A first conversation about the application and the quotes you have had. 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 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. We never do a single cutover. 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 you need to bring: a budget for the assessment, approved separately from any replacement; read-only access to the code once the assessment begins; time from the people who know the system; and your own team or supplier to keep the old application running until each module is accepted, at your cost.
What we do not do: we do not keep the old application running or secure while the work goes on. 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 the one public case in this article was one. We do not work on the systems that run aircraft, trains or vehicles. Meeting the GST network’s rules, or any other rule, is your own work: we do not offer a compliance, audit or legal service, and we do not say what any rule requires of a particular firm. 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 | A replacement becomes a decision the owner can take this year, one stage at a time, on a figure with a basis. |
| CTO or CIO | A scope taken from the application itself, so the estimate stops being the technology head’s personal guess. |
| CFO | A price for each stage, set beside the written cost of staying, and decided one stage at a time. |
| COO | Running old and new side by side is in the plan from the start, so it is not the first thing cut when money runs short. |
| Head of sales and marketing | Sales can see what each stage brings, so the requests from customers and agents have a place in a plan, not “after the replacement”. |
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| A large US 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. An older case. | Our part is far narrower: we do not implement packaged ERP products, and we do not say why that roll-out led to a lawsuit. For applications a firm built or had built, we read the system before we price, list the unknowns in a risk register and price each stage. |
| In an advisory of 17 December 2024, India’s GST network made multi-factor authentication mandatory on the e-way bill system in steps, the last “from 1st April 2025 for all other taxpayers and users”. | Our assessment shows where an application raises e-way bills and what replacing that part would take. Meeting the rule is the firm’s own work. |
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 put the requests waiting on “after the replacement” into a plan you can approve one stage at a time.
Sources
- Trade press article, 2025
- A vendor's survey, 2025
- GSTN advisory, 17 Dec 2024 (copy on Maharashtra GST)
In this issue
Too slow and costly to replace
Research note 1
The Old System Still Works. That Is Why the Replacement Never Starts.
The public record on why firms keep old systems and how long replacing operations software takes: what we found, four ways forward weighed, our benchmark.
Research note 3
Finished Should Mean Matched. The Benchmark We Would Set for a Replacement.
A replacement reported as seventy per cent complete can still be years from right. Our benchmark for replacing an old booking, dispatch or billing application.
Issue study
Too Big to Approve
Replacements too large to approve: an ERP roll-out that ended in a lawsuit, long-serving scheduling software, why firms wait, the options and a benchmark.
More from Logistics, travel and hospitality
Scarce skills and missing documentation
A Record Your Staff Open Before They Pick Up the Phone. Here Is the Benchmark We Would Set.
Inherited systems nobody understands
A Year After the Deal You Still Run Two of Everything. Here Is the Benchmark We Would Set.
Old servers and operating systems