You Are Asked to Approve a Move Nobody Can Price. Where Your Replacement Plan Is Now, and Where It Should Be.

The board paper on replacing the old applications runs to twelve pages. The figure is on page eleven.

The chair asks the finance head what it is based on. Three firms have bid. The lowest bid is less than half the highest. All three worked from the same tender document, which describes the system as a list of module names. None of them has seen inside it.

The paper recommends the middle figure, with a quarter added on top “for unknowns”. The board is asked to approve the whole sum today.

What We Found

For this article we went through the public record on how operators regard the move off old systems and what holds firms back: one industry body’s research on the priorities of operators’ technology heads, and one survey of IT professionals on why old systems stay in place.

Three findings stand out.

Operators’ technology heads regard the move as hard. In one industry body’s research on the priorities of operators’ technology heads in the Americas, as reported in the news, nearly nine in ten of the region’s telco CIOs said moving off closed old systems is difficult, against nearly three-quarters globally. The report gives no sample size, no operator size and no reasons.

Money and data are among what hold firms back. In one survey of about 500 IT professionals in the US, across industries and company sizes, run by a firm that sells software services and not about telecom, more than four in ten named budget limits as a reason for not modernising, and about a third named concerns about moving data.

The public record holds no price. We found no public figure for what it costs an operator to replace applications it built, or how far apart bids for that work usually are, and we give none.

Our reading is that bids come in far apart because nobody has read the system. A quote for new software estimates work that can be described. A quote to replace an old application estimates work nobody has described yet: rules that took fifteen years to gather, jobs that run at night and links to other systems that no demonstration shows. Each bidder prices its own assumptions, and the board is asked to approve the gap between them as “unknowns”.

What a Figure Without a Basis Costs the Board

The first cost is the approval taken twice. The board approves the whole sum at the start, on a guess; then, halfway, it is asked for more, when stopping would waste what has been spent.

The second cost is discovery turned into dispute. Every rule that was not in the tender becomes a change request, and every change request an argument about who should have known.

The third is what gets cut. When money runs short, the first things to go are often the checking and the period when old and new run side by side, which were there to protect the bills.

This is our reading of the evidence. It is not a measured market figure.

Four Ways to Approve the Move Off the Old Applications, Weighed

There are four real options. Each one is right for somebody.

Option	When it fits	What it risks
Approve nothing yet: stay, and patch around the old applications	The applications are stable, and the money is needed elsewhere this year	The cost of staying is never set beside the cost of moving, and the move grows
Approve the whole replacement at once, for one large move on a single date	The scope is already well known and written down, and the old applications cannot be kept	The figure rests on a tender document; the real scope appears after the money is committed
Approve the reading first, then one stage at a time, with the old applications running until each module is accepted	The applications must go, and nobody has yet written down what they do	The assessment is paid for before the firm knows whether it will go ahead, and the board takes several decisions, not one
Approve a packaged billing or customer product	The firm wants a maker’s product in place of what it built	It is priced and implemented by its own specialists; we do not implement or move such a product

Where You Are Now, and Where You Should Be

A recommendation is only useful if you can tell later whether it worked. So before any work begins we set a benchmark: a few measures taken from your own applications, each with a target.

For this issue, the benchmark would look like this.

Measure	Typical starting point	Where it should be	How it is checked
Stages approved	The whole replacement approved at once, on a tender figure	One stage at a time, each with a fixed quote	The staged plan and your board’s approvals
Unknowns	A percentage added to the figure	A list in the risk register, each with an owner on your side	The risk register
Cost of keeping beside cost of replacing	Not set side by side	Both in one document before the first stage is approved	The cost comparison
Single cutovers in the plan	One, for every application at once	None	The staged plan, reviewed at each stage
Modules accepted and running beside the old system	None	Each module accepted by your own people and running while the old application still runs	Each module’s acceptance record
Old functions matched to new ones	Not recorded	Each function of a rebuilt module linked to its replacement	The traceability matrix
Bills and charges from a rebuilt module compared with the old system’s before release	Not compared	Compared, for the accounts your team chooses, before the module is released	Your own team’s comparison, recorded at each review

The starting points above are what the public record suggests and 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 telecom operator.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about the replacement your board is being asked to approve. 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 article is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. Here the system is the applications your firm built or had built around its billing system, such as charging, care, activation and dealer payments, and the jobs between them. 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.
4. If you approve, we build. We replace a system one module at a time while the old one keeps running. Here that means one of your own applications, or one part of it, rebuilt beside the old one and checked, function by function, against the specification. 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.
5. We review against the benchmark. Before work starts we set the benchmark above. 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.

This approach has a price. You pay for the assessment before you know whether you will go ahead, and the figure that comes back may be higher than the lowest bid you had. Stages take longer on the calendar than a plan with one date, and the old applications have to be kept and paid for all the while; we do not keep them running. The board has more decisions to take, not fewer. “Billing applications” here means the applications an operator built or had built around its billing system, not a packaged billing product, which we do not convert or move. We do not migrate customer or billing data, and we do not work on the network. We give no legal or regulatory advice. The older technologies we read include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP. We have no published case of this work for a telecom operator.

At the end you hold the specification, the risk register, the cost comparison, the traceability matrix and code for every module we rebuilt, and the filled-in benchmark. If you stop after the assessment, the specification, the risk register and the staged plan are still yours.

What changes for the business:

Role	What they gain
CEO	The board approves the first stage on a figure with a basis, and decides about each stage after seeing what the last one produced.
CTO or CIO	A scope taken from the system itself, so nobody has to own an estimate made from memory.
CFO	A price for each stage, set after the system has been read, with the unknowns listed before the contract.
COO	Running old and new side by side, and time for staff to learn each change, stay in the plan, because no single date squeezes them out.
Head of regulatory affairs	The risks of the move are in a register, each with an owner, before the money is committed.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
This article names no organisation: we found no public figure for what it costs an operator to replace applications it built. Its figures come from an industry body’s research on operators’ technology heads and a vendor’s survey of IT professionals, which we do not name.	We read your own applications before we price them, set the benchmark before work starts, and replace one module at a time while the old ones keep running, each stage with a fixed quote. We do not move a packaged billing product, migrate data or work on the network.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We ask a board to approve the reading first, so that every decision after it rests on something the board can hold.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →