Judge a billing migration by each customer's first bill
Telecom billing migrations are usually declared successful when the data reconciles after cut-over. The test that protects customers comes weeks later: whether each migrated customer's first bill matches their own history or differs for a reason someone can state.
Most billing migrations in telecoms are declared successful on the Monday after cut-over, when the reconciliation balances and the old system stops taking orders. I think that is the wrong day and the wrong test. A migration is finished when every migrated customer has received a first bill on the new platform that either matches what they would have paid on the old one or differs for a reason we can state in a sentence. Until then, the programme has moved data. It has not yet moved the customer.
My position comes from two migrations fourteen years apart. In 2010, as the integrator's programme director, I watched a fixed-line operator send 31,000 incorrect bills three weeks after a cut-over that every report called clean. In 2024, as the client's chief information officer, I approved a migration wave at Lonmara that sent 7,900 incorrect bills, because I had accepted a sampled check where I knew a complete one was possible. The second failure was smaller, and it was more plainly mine.
What the cut-over report does not count
A standard migration reconciliation compares populations and totals. So many accounts left the old system and so many arrived; so much outstanding balance left and the same amount arrived; so many active products, discounts and payment arrangements on each side. These checks matter, and a programme that fails them should not proceed. But they measure the movement of records between two systems. They say very little about how the new system will behave the first time it rates a month of usage, applies a discount that spans a bill date or prorates a change made halfway through a cycle.
That behaviour is where customers are hurt. At Ardenmoy Telecom in 2010, every account and every euro reconciled. The defect lay in how the new platform treated line rental for customers whose billing date had moved during migration: it charged the part month twice. At Lonmara in November 2024, the defect lay in how a converged discount was prorated for households holding both a broadband service and a mobile plan whose mobile cycle had been aligned with the broadband one. Neither defect could have appeared in a reconciliation of migrated data, because the data was correct. The calculation applied to it the following month was not.
Integrators and vendors know this, and most programmes run a parallel bill on a sample of accounts before each wave. The sample is usually chosen to cover tariffs and products. That is sensible, and it misses the combinations that exist only in a merged customer base: the household with three mobile lines and a television package, two discounts and a payment plan agreed after a complaint. In a merger, those combinations are the point of the exercise and the least tested part of it.
Every customer's own history as the test
After the November 2024 wave I stopped the programme for seven weeks and changed the test. From the fourth wave onwards, every migrated account received a shadow bill on the new platform for its first cycle, compared with that same account's last three bills on the old one. Any first bill that differed from the customer's own average by more than twelve per cent, or by more than eight euros, was held. A held bill was released only when an analyst could state the reason in one sentence the customer would accept: a price change notified in advance, a promotion that had ended, a handset instalment paid off. Bills without such a reason were corrected before they were issued.
The thresholds were judgements, not science. We tried several against the bills already issued in the first three waves and chose the pair that would have caught every harmed account in November with a manageable number of false alarms. Across the remaining thirteen waves we compared 912,000 first bills and held 2,140. Of those, 1,610 had a legitimate explanation and 530 were wrong. The programme's cost rose by €6.4 million, mostly because of the pause, and the savings from closing the mobile billing platform arrived one quarter later than our business case had assumed.
Our integrator had argued that complete shadow billing was disproportionate at mobile volumes, and our finance director worried about the precedent of stopping a programme that was on schedule. Both were reasonable positions. I think they weighed the cost of the check against the cost of the programme, when the comparison that mattered was with the cost of a customer finding the error first. That cost is not only the refund. It is the call to the contact centre, the complaint escalated to ComReg, the customer who decides that a merged operator cannot be trusted with a direct debit, and the goodwill the merger depended on.
Who signs before the bill run is released
The second change concerned authority. Before November 2024, the decision to release a wave's first bill run sat with the programme, which in practice meant the integrator's release manager and our programme director. Both were measured on the schedule. From the fourth wave, release required a signature from the head of revenue assurance, who reports to our finance director, and from the director of customer operations, whose teams take the calls. Neither had any stake in the date. Either could hold the run.
This sounds like more bureaucracy, and on two occasions it delayed a wave by a week. It also changed behaviour inside the programme. Engineers began bringing borderline results to revenue assurance early, because they knew the signature was real. The customer operations director started sending two agents to sit with the analysts reviewing held bills, so the explanations we gave customers were written by people who would have to say them on the telephone.
I would not ask another operator to copy our thresholds. Customer bases differ, and a market with more prepaid customers or fewer bundles would need a different test. I would ask three things of any board or executive committee approving a billing migration. First, ask what the acceptance criteria say about a customer's first bill, rather than about record counts. Second, ask whether every migrated customer will be compared with their own history, and if not, what the excluded customers have in common. Third, ask who can stop the bill run, and whether that person is measured on the date.
A merged operator gets one early chance to show customers that the merger has not made their bill less reliable. Most of them will never know which platform produced it. They will know whether it was right.