Re: Telecom Billing Migrations: Lessons Learned From Real Projects The most valuable lesson seen time and again is this:
billing migrations fail (or limp) because of commercial and operational edge-cases, not because “the data didn’t move”. The technology can be solid, but if the contract logic, rating rules, credits, tax handling, and “how we actually do it” exceptions aren’t nailed down, the first invoice run becomes a customer service and cashflow incident.
The part that usually needs the most preparation: product catalogue / tariff normalisation and mapping (plus the surrounding governance). It’s rarely glamorous, but it’s where most hidden complexity sits.
Lessons learned (practical, from real migrations) 1) Treat the product catalogue as the source of truth, not an afterthought If the legacy platform has years of “specials”, one-off discounts, manual overrides, and grandfathered plans, you can’t just map “Plan A” to “Plan A2” and hope. The prep work is:
- Define a clean target catalogue (plans, bolt-ons, bundles, discounts, fees, minimum terms).
- Decide what gets migrated as-is vs retired vs replaced.
- Create a mapping table with clear ownership and sign-off (commercial + finance + ops).
- Lock down change control: no new tariffs or price tweaks without a migration impact check.
If this isn’t controlled, the migration becomes a moving target and testing never stabilises.
2) Reconciliation needs to be designed, not “done at the end” A solid approach is to agree reconciliation rules early:
- What is “correct” for revenue: invoice total, rated usage, billed usage, or recognised revenue?
- Tolerance thresholds (pennies vs pounds) and what explains them (rounding, proration, tax).
- Golden accounts: a set of customers that represent every awkward scenario (mid-cycle changes, multiple services, discounts stacking, partial months, cessations, backdated orders).
Without this, teams argue about numbers rather than fixing root causes.
3) Parallel billing is only useful if you control the inputs Running two systems side-by-side sounds safe, but it can create false confidence if:
- Orders are being entered differently in each system.
- Usage feeds are transformed differently.
- Credit notes/adjustments are applied manually in one system but automated in the other.
Best practice is to freeze or tightly govern operational changes during the parallel window, and log every manual intervention so it’s not mistaken for a system defect.
4) Data cleansing is less about “clean” and more about “fit for billing” A lot of cleansing effort gets wasted fixing fields nobody uses. Focus on what drives charging, tax, collections, and compliance:
- Customer identity and account hierarchy (payer vs user, multi-site, parent/child).
- Service start/cease dates, contract terms, and billing cycle alignment.
- VAT treatment and address quality (UK VAT rules, exemptions, place of supply where relevant).
- Direct Debit mandates and payment method tokens (and how they’ll be re-established).
5) Don’t underestimate the “people migration” User training isn’t just screens and clicks. Billing and finance teams need:
- A new month-end timetable (what runs when, what reports are relied on).
- Clear ownership of exception queues (failed rating, disputed usage, suspended accounts).
- A playbook for credits, re-rates, and backbilling so customer support stays consistent.
Where UK businesses often get caught out - VAT and invoice compliance: invoice wording, VAT breakdown, credit note handling, and audit trail. If you’re selling mixed services (telecoms + hardware + managed services),VAT treatment can get messy quickly.
- Direct Debit continuity: if mandates need re-authorising, churn and aged debt can spike. Plan customer comms and fallbacks early.
- Revenue reporting vs billing reporting: finance may need a different cut of data than operations. If the new platform can’t replicate key reports, the “go-live” isn’t really a go-live.
If picking one “most preparation” area Catalogue + rating rules + contract edge-cases, with proper sign-off from commercial and finance. Once that’s right, data migration and testing become far more predictable. When it’s wrong, every test cycle throws up “surprises” that are really just undocumented business logic.
If helpful, share what type of operator this was (MVNO, fixed-line, ISP, enterprise voice, etc.) and whether the biggest pain was usage rating, discounts, or invoice presentation—those usually dictate where the real traps are.
