A Move to a New Billing System

1. At a Glance

Issue study · From the public record. None of the organisations described here was an IOanyT client, and IOanyT had no part in the events described. Everything about them comes from the public record.

Organisation type	Telecom operators that bill every customer every month through applications built around the billing system: charging, care, activation and dealer payments, joined by jobs that pass details between them
Size band	The operators in the record: two UK operators, one of which the source calls “The world’s second-largest mobile operator”. Our reader: a regional internet or broadband provider, a cable operator, a provider of connectivity to businesses, or another mid-size operator
Region	The cases: the UK. The rules: India
The decision at stake	Whether to keep deferring the replacement of the old billing and customer applications, to replace them in one large move on a single date, or to replace them one module at a time while they keep running
The public outcome	In an older case, in October 2016, the regulator fined one operator £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. In 2025 a regulator fined another operator £23,800,000, finding that it “failed properly to identify and record the status of telecare customers” while moving customers to digital landlines
Why it matters to a mid-size operator	A move that goes wrong shows on customers’ bills. In India, TRAI’s Standards of Quality of Service regulations, 2024, in force from 1 October 2024, set benchmarks for resolving billing complaints for access and broadband providers and for internet providers with more than ten thousand subscribers, while the charging rules sit in applications nobody dares change

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

“Everyone on the board agrees the billing and customer applications have to go. They are fifteen years old, two people understand the charging rules, and a new tariff takes months. Every year the plan comes down to one weekend when the old system goes off and the new one comes on. Nobody will name it, because if one rule is wrong it is wrong on every customer’s bill. So we carry it forward again. I do not want to bet a month’s billing on one date, and I cannot keep patching applications nobody dares touch.”

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

The operator is caught between applications too risky to keep and a move too risky to make.

3. What We Found

Method. 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, one survey of IT professionals on why old systems stay, and the rules that operators in India now work under on billing complaints.

Two public cases. These are the record’s own words. Neither operator was an IOanyT client, and both moves were of kinds IOanyT does not make.

Case	What the public record says
Vodafone (UK), an older case from 2016	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 or whether the move was made on one date. The reported cause, a move to a new billing system, is a kind of move IOanyT does not make
Virgin Media (UK), fined by Ofcom on 1 December 2025	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 fine was “£23,800,000”, for “serious systemic failures in Virgin Media’s migration process between August 2022 and December 2023”. The move was a change of network, which is not IOanyT’s kind of work. This study uses the case only for the regulator’s finding about records and the fine

How the move is regarded. 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 legacy systems is difficult, against nearly three in four globally. The report gives no sample size and no operator size. In one survey of about five hundred IT professionals in the US, across industries and company sizes, run by a vendor and not about telecom, more than four in ten named budget limits as a reason for not modernising, more than a third each named fear of disrupting operations and data migration concerns, and half said the current system still works.

What Indian operators now work under. TRAI’s Standards of Quality of Service regulations, 2024, in force “with effect from 1st October 2024”, set customer-service benchmarks including “Resolution of billing/ charging complaints within four weeks” (for 100% of complaints) and adjustment to the customer’s account “within one week from the date of resolution”. The regulations apply to providers of access and broadband services and to internet service providers, but not to “an Internet Service Provider whose total number of subscribers as on last day of the preceding financial year does not exceed ten thousand”. A consultation of 5 August 2026 proposes resolving billing complaints “within one week”; that is a proposal only, and TRAI had not notified it as of 14 October 2026. Our reading is that every tariff or billing change, and every correction, still waits on a system nobody dares touch; what the rules ask of a particular firm is for its own advisers.

Our reading of why the move is deferred, and why it goes wrong. These four are our reasoning from the record above. None is a finding of any source, and none is offered as the explanation of either named case.

1. Nobody has a written record of what the old applications do. The rules for part-months, old discounts and suspended lines are in the code. A replacement built from workshops and memory misses the cases nobody mentioned.
2. Everything changes on one date. Because charging, care and activation read each other’s data, the plan becomes one weekend for all of them, with no way back.
3. The new system is checked against a document, not against the old one. A rule missing from the requirements is missing from every check made against them.
4. The price is set before the system has been read. Bids come in far apart, the real scope appears after the contract, and the checking and the period when old and new run side by side are cut to hold the date.

Illustration, not a real case. A regional broadband provider replaces its in-house charging application and switches over on one weekend. The first bill run charges every customer who changed plan in the middle of the month for both plans in full. The old application had charged each plan by the day; nobody mentioned it in the workshops, and the requirements did not list it. Nobody on the service floor or in billing operations did anything wrong.

4. The Options a Firm in This Position Had

Option	When it fits	What it risks	Our view
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; tariffs and corrections wait; the move grows	Right for a year or two where little changes; not as a plan
Replace everything in one large move, on a single date	The old applications are failing and there is no time to stage the work	Every rule is tested at once on the first bill run, with no old system to fall back on	We would advise against this for applications that bill every customer every month
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; keeping accounts in step has to be planned; it takes longer on the calendar and costs more than a patch	Our recommendation
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	It is a move of its own, priced and carried out by the product’s own specialists	The operator’s choice. IOanyT does not implement, configure or move such a product

5. Our Recommendation, and the Decision It Asks of the Board

Have the old applications read first: the applications the operator built or had built around its billing system, and the jobs between them. Write down what they do, including the charging rules, in a specification the operator’s own experts confirm, with the risks in a register and the cost of keeping set beside the cost of replacing. Then replace them one module at a time while the old ones keep running. Each rebuilt module is checked, function by function, against the specification and the traceability matrix before the operator accepts it. The operator’s own team may also run the same accounts’ bills through old and new side by side before a module is released; that is the team’s own check, set as a target in the benchmark. Where old and new disagree, the operator’s own people rule on which rule the new module keeps. A written record shows what the old system does, not whether it is right, and no check proves a charge right; what to do about charges already made is for the operator and its advisers. IOanyT gives no view on refunds, back-billing or what must be reported.

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
Modules accepted and running beside the old system	None; the plan has one date for every application	Each module accepted by the firm’s 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	Compared, for the accounts the firm’s team chooses, before the module is released	The firm’s own team’s comparison, recorded at each review
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 the board’s approvals
Unknowns	A percentage added to the figure	A list in the risk register, each with an owner	The risk register

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about the replacement that keeps being carried forward and the applications it concerns. 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 applications your firm built or had built around its billing system, such as charging, care, activation and dealer payments, and the jobs between them; not a packaged billing product. 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 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. 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 each of the operator’s own applications and jobs does, including the charging rules, confirmed by the operator’s own people.
• The risk register: the fragile, undocumented and tied-together parts, listed before any stage is priced.
• The cost comparison and the staged plan: the cost of keeping beside the cost of replacing, and a fixed quote for the stages.
• The traceability matrix: for every module IOanyT rebuilds, every old function linked to its replacement.
• 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.

9. What This Approach Does Not Cover

• “Billing applications” in this study means the applications an operator built or had built around its billing system. IOanyT does not convert, implement, configure, upgrade or move a packaged billing or customer product. A rule inside one is for its own specialists.
• IOanyT does not migrate customer or billing data. The operator’s own team does, or the firm it chooses.
• IOanyT does not work on the network or the systems that run it, and nothing it does keeps a service working for any customer or protects anyone.
• IOanyT does not keep the old applications running or secure while a module is rebuilt. The operator’s own team or vendor does.
• Keeping accounts in step while old and new run side by side has to be planned for each operator; this study does not say how. Comparing the same bills through old and new is the operator’s own team’s check.
• A specification records the rules the code applies. A rule kept by hand, outside any program, is found only by asking the people who apply it.
• IOanyT’s published terms on access cover code, not customer records.
• IOanyT gives no legal or regulatory advice. What TRAI’s regulations ask of a particular operator is for its own advisers; this study does not say, does not say that any work makes an operator compliant, and promises no outcome with a regulator. It gives no view on refunds, back-billing or reporting.
• This study does not say that IOanyT has done this work for a telecom operator. IOanyT has no published case of it.

About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.

10. Sources

Source	Used for
Ofcom enforcement bulletin, case CW/01160, 26 October 2016	Vodafone: the finding, the customers, the period and the penalty
Euronews, 26 October 2016	The cause the operator gave, as reported at the time
Ofcom, 1 December 2025	Virgin Media: the finding about records, the period and the fine
News report of an industry body’s survey, 2026	How operators’ technology heads regard the move
A vendor’s survey of US IT professionals, 2025	Why old systems stay
TRAI, Standards of Quality of Service regulations, 2024 (consolidated)	Billing-complaint and adjustment benchmarks, scope and exemption
TRAI consultation paper, 5 August 2026	The proposed one-week rule for billing complaints

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, so that the move off them is a series of accepted modules and never a single weekend.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →