Every Operator Agrees the Old Billing Applications Must Go. What We Found Is Why Nobody Names the Date.

The item is on the agenda for the fourth year: replace the billing and customer applications.

Nobody argues against it. They are fifteen years old. A new tariff takes three months to launch. Two people understand the charging rules.

Then the head of operations asks which weekend. Not before the festive season. Not at financial year end. Not in the month the new plans launch. The room looks at the calendar and finds no weekend it is willing to lose. The item is carried forward.

What We Found

For this article we went through the public record on moves off old billing and customer systems at telecom operators: one news report of a fine after a move to a new billing system, one regulator’s published finding at a move of landline customers, 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.

Four findings stand out.

A billing fault has run for months in public. In an older case, in October 2016 the UK regulator, Ofcom, fined Vodafone £3.7 million, finding that between December 2013 and April 2015 it gave 10,452 pay-as-you-go customers incorrect information that they would receive the services they paid for with top-ups, and that “the account balance information did not accurately reflect the true extent of the credit for which they had paid”. Press reports at the time said the operator linked the failures to a move to a new billing system; Ofcom’s notice gives no cause. Neither says anything about what went wrong inside that system, and we do not guess. Press reports tied it to a move to a new billing system, a kind of move we do not make.

In one regulator’s finding at a move, the failure was in what the operator identified and recorded. On 1 December 2025 the UK regulator, Ofcom, fined Virgin Media “£23,800,000”. Its finding was that, while moving customers “from analogue to digital landlines”, the operator “failed properly to identify and record the status of telecare customers, resulting in significant gaps in the screening process”. Telecare is an alarm service that works over the phone line. The move was a change of network, which is not our kind of work, and we take one point only: the finding was about what the operator had identified and recorded when it moved its customers. We did not examine why the status was not recorded, and we draw no cause from it.

Operators’ technology heads say moving is 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 and no operator size.

Firms that stay give money, disruption and data as reasons. 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, nearly four in ten named fear of disrupting operations and about a third named concerns about moving data. Half said that their current system still works.

Our reading is that the fear is sound and aimed at the wrong thing. An operator bills every customer every month, so whatever is wrong on the first bill run is wrong for everyone on it. That danger belongs to the single date on which everything changes, not to replacement itself.

What Waits While Nobody Names the Date

The first cost is the tariff that waits. Every change to a plan, a discount or a charge is made in applications two people understand.

The second cost is the knowledge that leaves. The people who know why a part-month is charged the way it is are a year closer to leaving every time the item is carried forward, and what they know is in no document.

The third is the move that gets harder: each year adds rules and links, so the replacement put off is larger when it comes.

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

Four Ways Off the Old Billing Applications, Weighed

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

Option	When it fits	What it risks
Stay, and patch around the old applications	The applications are stable, few changes are needed, and the people who understand them are staying	Each patch adds a rule nobody has written down, and the move grows
Replace everything in one large move, on a single date	The old applications are failing and there is no time to stage the work	One bill run tests every rule at once, with no old system to fall back on
Replace one module at a time, while the old applications keep running	The applications must go, and a month’s billing cannot be staked on one date	Two systems run side by side for a time, and keeping accounts in step has to be planned
Buy a packaged billing or customer product	The firm wants a maker’s product in place of what it built, and has the specialists to implement it	That is its own move, with 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
Modules accepted and running beside the old system	None; the plan has one date for every application	Each module accepted by your own people and running while the old application still runs	The staged plan and each module’s acceptance record
Single cutovers in the plan	One, for every application at once	None	The staged plan, reviewed at each stage
Old functions matched to new ones	Not recorded; requirements written from memory	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; the new system is tested against a requirements document	Compared, for the accounts your team chooses, before the module is released	Your own team’s comparison, recorded at each review
Stages approved	The whole replacement approved at once	One stage at a time, each with a fixed quote	The staged plan and your board’s approvals

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. The comparison of bills is a check your own team runs.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about the replacement that keeps being carried forward. 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 that pass details 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. 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 limits. “Billing applications” here means the applications an operator built or had built around its billing system, not a packaged billing product; we do not convert, upgrade or move such a product, and its own specialists deal with anything inside one. We do not migrate customer or billing data; your own team does, or the firm you choose. We do not work on the network or the systems that run it. We do not keep the old applications running or secure while we work; your own team or vendor does. Two systems run side by side for a time, and keeping accounts in step between them is real engineering that has to be planned. Our published terms on access cover code, not customer records. 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.

What changes for the business:

Role	What they gain
CEO	The move off the old applications can begin without staking a month’s billing on one date.
CTO or CIO	A part that is not ready stays switched off and the old one carries on. Nobody repairs live billing with customers watching.
CFO	No single date on which a bill run can go wrong for every customer at once, and spend released one stage at a time.
COO	The service floor and billing operations meet one change at a time, and never every change on the same date.
Head of regulatory affairs	The largest operational risk in the year’s plan is cut into small ones, each with a way back and each on record.

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

The case	What IOanyT does
In October 2016 Ofcom fined Vodafone £3.7 million over top-ups sold to 10,452 pay-as-you-go customers; press reports linked the failures to a move to a new billing system. An older case.	Our part is far narrower: the reported cause was a move to a new billing system, a kind of move we do not make, and we do not migrate data or say what went wrong. For applications an operator built around its billing system, we replace one module at a time while the old one keeps running.
Ofcom fined Virgin Media £23,800,000 on 1 December 2025, finding it “failed properly to identify and record the status of telecare customers” during a move of landlines.	Our part is far narrower: that was a change of network, which we do not work on; nothing we do protects a customer, and we do not say what went wrong. For applications an operator built, the assessment writes down what they do before any module is replaced.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We start by reading the old applications, because a plan without a switch-over weekend begins there.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →