Most Operators Say They Depend on Their Legacy Vendors. What Few Hold Is Their Own Record of What They Run.

The finance head has a simple question. When a business customer joins part-way through a month, how does the system work out the first bill?

The billing operations manager does not know. Neither does the head of IT. The charging application was built for the firm eight years ago by its billing vendor, and the vendor has looked after it well ever since. So a ticket is raised.

The answer comes back nine working days later. It is two lines long, and it is clear. Nobody in the firm can check it.

What We Found

For this article we went through the public record on telecom operators and the vendors of their old systems: one industry body’s research on the priorities of telco CIOs, as a news report gave it; one trade press account of an operator’s old billing and customer stack; and one survey of IT professionals on the challenges of old systems.

Five findings stand out.

Most technology heads in one region say they depend on legacy vendors. In an industry body’s research on telco CIO priorities in the Americas, about four in five of the region’s telco CIOs said they depend on the vendors and integrators of their old systems. The global figure is about two-thirds. The news report gives no sample size and no size of operator, and nothing on why they depend on them, so we do not guess.

Most of them also find leaving hard. In the same research, nearly nine in ten of the region’s telco CIOs said moving off closed old systems is difficult, against nearly three-quarters globally, and just over half named modernising IT and reducing technical debt as a focus of investment.

In one older case, a support renewal came with a higher price, and the code had no single home. In the late 2010s a trade press account described a mobile operator in South Asia with a few million customers, whose billing and customer stack ran to dozens of applications. Its IT support contract was due for renewal at a much higher price, and its code was not kept in one central place. The account does not say whether the rise was fair, and we do not suggest it was not. What the operator did afterwards is another organisation’s work, and we leave it out.

Support from a vendor is a challenge in other sectors too. In one survey of about 500 IT professionals in the US, across industries and company sizes, run by a firm that sells software services and not about telecom, about a third named a lack of support or updates from vendors among the top challenges of their old systems.

We found no case of a vendor withholding knowledge or overcharging an operator. We say so plainly, because this article is not about bad faith.

Our reading is that the dependence grows by itself. The vendor built the applications, so whatever was written down sits in its files. The contract bought a working system, not a written account of one. And every change since has gone through the vendor, so each year the vendor knows a little more and the operator a little less. Nobody did anything wrong.

What an Operator Cannot Do Without Its Own Record

The first thing it cannot do is answer a question about its own system. Every question becomes a ticket, and the answer is kept nowhere.

The second is to check what it is told. A vendor’s answer is taken on trust, because there is nothing on the operator’s side to hold it against. That is unfair to the vendor as well: a good answer cannot be shown to be good.

The third is to read a quote. A change request arrives as one figure, and nobody inside can say what the change touches.

This is our reading of the evidence. It is not a measured market figure.

Four Ways to Deal With a Vendor You Depend On, Weighed

There are four real options. Each one is right for somebody.

Option	When it fits	What it risks
Renew as before	The vendor serves the firm well, the price has been tested some other way, and no large change is planned	The firm still cannot explain its own system, and the next question becomes the next ticket
Switch to another vendor	The present arrangement no longer fits the business, and the firm can fund a large move	A new dependence on a new firm, a big move, and the same missing record unless one is written
Write your own record first, then decide	The firm wants to know what it runs before it renews, compares or changes anything	It costs money before anything changes, it changes nothing in the system, and it goes stale unless someone on your side keeps it
Rebuild your own applications one module at a time, against a written record	The firm’s own applications are old, and it wants each one changed without one large move	It costs more per application than adding to what is there, old and new run side by side for a time, and the vendor’s product can be met only where it allows

Where You Are Now, and Where You Should Be

A recommendation is only useful if you can tell later whether it worked. So before any work begins we set a benchmark: a few measures taken from your own applications, each with a target.

For this issue, the benchmark would look like this.

Measure	Typical starting point	Where it should be	How it is checked
Your own applications that talk to a vendor’s product, each with a written record of what it sends and expects back	None written; known only in the vendor’s files	Every one listed, with what it sends, what it expects and what happens when the answer does not come	The map of the applications as they stand, and the specification
Questions about how the system works out a charge or an activation, answered from your own record	Each one a ticket to the vendor	Answered from the specification, with a ticket only where the record is silent	Your own ticket log, reviewed at each stage
Change requests that only the vendor can scope	Not counted	Counted, and falling as the record grows	Your own change log and the risk register
Code for your own applications held in your own repository	Not known; often held elsewhere, or nowhere	Held in a repository your firm controls, as your contract allows	Your own repository list (arranging it is your step)

The starting points above are what the public record suggests and what we expect to find. In an engagement they are replaced by your own figures, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a telecom operator.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about the systems only your vendor can explain. 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 article 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, by its vendor or anyone else, around its billing system. For a vendor’s packaged billing product, which we do not read or work inside, the specification records only what your own applications send to it and expect back. Where a vendor or an integrator holds the code of the applications built for you, your firm arranges read-only access to the code with its supplier, as its contract allows. 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. The specification is yours, and you can take it to any supplier, including your current one, subject to your own contract with your present supplier. You get the options and our recommendation.
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 at a time, rebuilt to send and expect exactly what the specification records. We never do a single cutover. Each module has a traceability matrix. 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.

This approach has limits. We do not read or work inside a vendor’s packaged billing product, and we do not change, configure or replace one; for such a product we record only what your own applications send to it and expect back. We do not work on the network or the systems that run it. We obtain nothing from a vendor: no code, no access and no documents. You arrange read-only access to the code, and any documents, with your supplier, as your contract allows, and only the free Review starts without code. We give no legal advice on contracts, licences or who owns code, and we do not negotiate with your vendor. A written record does not end your need for your vendor, and we promise no saving. We are not a staffing firm and do not take over the support of a system. The older technologies we read include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP. We have no published case of this work for a telecom operator.

What changes for the business:

Role	What they gain
CEO	The firm is no longer the one party that cannot explain how its own billing operations work.
CTO or CIO	A specification the firm owns: what each application does, what it sends to the vendor’s product and what it expects back.
CFO	When a change is quoted, finance can see what the change touches, and not only what it costs.
COO	Questions about how a charge or an activation is worked out are answered in-house, without a ticket to the vendor.
Head of regulatory affairs	When asked how the firm oversees its most important supplier, there is something in the firm’s own hands to show.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
A mobile operator in South Asia with a few million customers, an older case: with dozens of applications, its IT support contract was due for renewal at a much higher price, and its code was not kept in one central place.	Our part is far narrower: we do not say the price was unfair, we do not negotiate or obtain anything from a vendor, and we do not read inside a packaged billing product. For applications an operator built or had built, we write a specification it owns and can take to any supplier, including its current one, subject to its own contract with its present supplier.

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 with your own written record, because a firm that knows what it runs can then decide whether to stay, compare or change.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →