One telco billing platform we reviewed last year processes roughly 14 million CDRs a day across 240 rate plans. It has run for 15 years. Nobody on the current engineering team wrote a line of it.
That’s the standard relationship telecom companies have with their billing systems: deep respect, quiet terror.
The system everyone is afraid of
Telecom billing on Oracle Forms calculates charges across hundreds of rate plans, applies taxes, surcharges, prorations, partial-month logic, usage tiers, and contractual discounts negotiated individually with enterprise customers. It works. It has worked for years. And nobody wants to be the engineer who breaks it.
The Forms interface is the operations team’s window into the system. Billing adjusters investigate disputes through it. Revenue assurance flags anomalies through it. Finance closes the books each month through it. Customer service explains charges through it.
Replacing this system isn’t like replacing a CRM. One wrong invoice is a regulatory finding.
Why modernization is now unavoidable
Three forces are converging.
5G and IoT billing. Network slicing, IoT device tiers, and usage-based enterprise plans require billing logic the original Forms system wasn’t designed for. New rate plans take weeks of PL/SQL development.
Real-time visibility. Business customers expect a self-service dashboard that answers “how much have we spent this month?” without a support call. Forms cannot expose that data to a customer portal.
Regulatory automation. TRAI, FCC, and EU telecom regulators increasingly require automated compliance reporting. Manual extraction at audit time is no longer accepted.
A layered approach that actually works
Nobody sane rewrites a telecom billing system from scratch. The risk is too high and the timeline too long. We use a three-layer migration instead.
Layer 1: Extract and preserve. Automated analysis of every billing calculation, rate plan rule, and tax routine in the Forms estate. The output is the authoritative spec of what the system actually does — usually the first time anyone has had one.
Layer 2: New interface, same engine. The new TypeScript application connects to the same billing database through REST APIs. Adjusters and analysts get a modern UI. The calculation engine underneath remains untouched.
Layer 3: Gradual engine modernization. Once the interface layer is stable, individual billing components migrate to the new architecture, one rate plan category at a time, validated in parallel against the legacy engine.
This turns the scariest migration in enterprise IT into a sequence of small, reversible steps. The full system is never at risk. Every step has a rollback. The operations team doesn’t get a revolution. They get a better window into a system that keeps working exactly as it always has, until it’s quietly replaced by something they can extend.