A billing system that hadn't changed in 25 years was replaced, in 3 months.

The client is a Lebanese internet service provider with roughly 2,000 customers. Their operations had been running on two disconnected systems for years: a 25-year-old billing platform on one side, and a RADIUS authentication server on the other. We replaced the legacy billing interface with a modern operations platform, shipped continuously over three months, with bidirectional sync to the RADIUS server, full audit trail on every customer change, a Telegram bot for self-service, and a built-in AI assistant that lets the team query their own data in plain language. The engagement is ongoing and the system keeps growing as the business grows.

What was actually broken

The day-to-day operations ran on two separate platforms that had never been properly connected.

On one side, a billing system built on technology that was 25 years old when we started. It worked. It billed customers reliably every month. It had also been patched and extended so many times by so many different people that nobody could fully describe how it worked anymore. The system was load-bearing and inscrutable, which is the most uncomfortable combination a business-critical system can have.

On the other side, a RADIUS authentication server with a dated admin interface. RADIUS handles the actual network access. When a customer's account changed in billing, the change had to be made in RADIUS too. Every customer change happened in both places. When somebody missed a step, the systems disagreed: an account might show inactive in billing and active in the authentication server, or the reverse. Customers either got service they weren't paying for, or got cut off despite their account being current.

There was no audit trail. No record of who changed what, or when. Customer support meant a phone call, because there was nothing online for customers to do for themselves. The team was managing nearly 2,000 customers across a setup that had no room to grow and no margin for error.

What we built

We replaced the legacy billing interface with a modern operations platform, built from scratch and shipped in tight cycles over three months.

The platform brings five things into one place. Customer and subscriber management is the spine: every customer record, every subscription, every status change, in a single source of truth. Invoicing is built in, with the templates and tax handling specific to the Lebanese telecom context. Collector workflows give the team a structured way to handle outstanding invoices, with status tracking and escalation rules. Employee permissions are tier-based, so a customer service agent can do their job without having access to billing changes or admin functions. Network station inventory lives in the same database, so the team can see exactly which infrastructure serves which customer.

A sync layer connects the new platform to the existing RADIUS server. Changes in either system propagate to the other, with conflict resolution rules the team agreed to upfront. The first time a customer is suspended in billing, the RADIUS access is cut within seconds. The first time a payment is recorded, the customer is restored. The two systems behave like one system, with a full audit trail on every action.

For customers, we built a Telegram bot that lets them share their location for service queries, report issues, and manage basic account tasks without calling anyone. Telegram is the messaging app the customer base already uses, which mattered more than building a polished mobile app from scratch. The bot gets the customer to the answer in three or four messages instead of a 12-minute phone call.

We also built an AI assistant directly into the operations platform, configurable per organisation, supporting multiple AI models. The team can query their data in plain language: "How many customers in Beirut downgraded their plan last month?" or "Which network stations have had more than three incidents in the last quarter?" The assistant translates the question into a query, runs it against the database, and returns the answer. The team doesn't have to know SQL. They don't have to know which screen the data lives on. They ask, the system answers.

Why we built it the way we did

Two design decisions that shaped everything.

The first was that we didn't try to specify the old system before building the new one. The standard playbook for replacing a 25-year-old platform is to write a comprehensive specification of what it does, then build a new system that does all the same things. That approach has a near-perfect failure rate. The specification of a quarter-century-old system is a fiction. A lot of what it does is workarounds for problems that no longer exist, and writing those into the spec carries the legacy forward.

Instead, we mapped the actual work. Three weeks of sitting with the operations team, the customer service team, and the finance team, watching them work. Not interviews. Their actual day. What did you just do, why did you do it, what would happen if you didn't, and is there a way the system could have helped that wouldn't have required you to do it manually. The 2026 map of what the team actually does looked nothing like the 2001 map of what the system was originally designed for.

The second decision was to keep the boundary between the operations platform and the RADIUS server clean. We didn't try to absorb RADIUS into the new platform. RADIUS does what it does well, and replacing it would have tripled the scope of the project. Instead, the sync layer keeps the two systems consistent with each other while leaving them functionally separate. That made the migration possible inside three months rather than nine.

The migration

Legacy data was in better shape than we'd been warned. Twenty-five years of patches had produced a database that was inconsistent in specific, knowable ways, but not chaotic. We wrote a migration script that mapped the old schema to the new one, ran it against a snapshot on a Friday, validated the results over the weekend, and went live the following week.

The first two weeks ran both systems in parallel. The old billing system was authoritative, the new one was producing the same outputs (or rejecting them and flagging why). When the two systems agreed for ten consecutive days, we cut over.

The cutover was uneventful. Which is the highest compliment a system replacement can receive.

What's happened since

The legacy system is off. Almost 2,000 customer records now live in a single, consistent database. Actions that used to require switching between three different screens happen in one place.

The pace tells its own story. The platform shipped its first major version within weeks of kickoff. Within two months of launch, the team submitted a structured list of 13 new feature requests, which means they were using the system closely enough to know exactly what they wanted next. That's the real adoption signal: not how many people log in, but whether the people who do start asking for more.

Reconciliation that used to take two days at month-end now takes about three hours, because the audit log makes finding discrepancies trivially fast. New product tiers can be launched in days, where they used to take weeks. The team isn't waiting on the system to add a row anymore.

What we got wrong

We underestimated how much training the customer service team would need. The new system was substantially better at the things it was designed for, but the team had built habits around the old system's quirks. Some of those habits were specific clicks in a specific order that no longer applied. Some were mental models of how data flowed that needed updating. We'd budgeted two weeks of training. The team needed closer to five.

We also underestimated the morale cost of changing the tool people had worked with for years. The system was old, and the team complained about it constantly, but it was familiar. The first month after the switch, several people on the team quietly missed the old system, even as they acknowledged the new one was better. We'd dismissed this as a non-issue going in. It turned out to be real, and worth taking seriously.

Where this is now

The client is on an ongoing engagement with us. New features ship regularly. The Telegram bot has expanded to handle more self-service flows. The AI assistant has new query patterns the team uses for monthly reporting. The system keeps growing as the business grows.

The thing the team tells us when we drop in is that they don't think about billing very much anymore. Which is, again, the highest compliment a system can get.

If you're sitting on a similar setup, the lesson we'd offer is the simplest one. Don't try to specify the old system. Map the actual work. Build for the work. The legacy will resolve itself.