Most Operators Say They Depend on Their Legacy Vendors. What Few Hold Is Their Own Record of What They Run.
We went through the public record on telecom operators and the vendors of their old systems: an industry body's research on telco CIOs, an older case of a support renewal, and a survey of IT professionals. Here is what we found, what is missing, the four ways forward and the benchmark we would set.
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.
The paradox: The operator runs the system, pays for it and answers for it, and is the one party that cannot say how it works.
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, 81% of the region’s telco CIOs “acknowledge dependence on legacy vendors and systems integrators”. The global figure is 66%. 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, 88% of the region’s telco CIOs “say migrating from closed legacy systems is difficult”, against 73% globally, and 54% name “IT modernisation and technical debt reduction” 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 2019 a trade press account described a mobile operator in Sri Lanka, “a three-million customer business”, whose billing and customer stack ran to “more than 60 different applications”. Its IT support contract was “coming up for renewal with a significant price hike”, and “there was no centralized code repository”. 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 504 IT professionals in the US, across industries and company sizes, run by a firm that sells software services and not about telecom, 32% named “lack of vendor support or updates” 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 our review does not show: We found no figure for what operators pay their vendors, how long a change request waits, or what leaving costs. The industry body’s research covers the Americas, with no sample size or operator size. The named operator is from 2019 and outside India, and its record gives one fact about its support contract. The survey is cross-sector, from the US, and was run by a vendor. We found nothing from India or about regional operators. Contracts, licences and the ownership of code were not researched. The opening scene is imagined. That the missing record is what keeps operators asking their vendor is our reasoning.
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.
The gap we see: most operators that depend on the vendor of an old system do not need to leave it as much as they need their own written record of what the applications built for them do, and of what those applications send to the vendor’s product and expect back. A firm that holds that record can keep its vendor and still answer its own questions, check an answer and read a quote.
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 |
Our recommendation: write your own record first, then decide. With a specification of the applications built for you in your own hands, staying with your vendor is a legitimate choice you can defend, a comparison is possible, and a later rebuild of your own applications has a written starting point. We do not read or work inside a vendor’s packaged billing product; for such a product we record only what your own applications send to it and expect back. We obtain nothing from your vendor, we give no legal advice, and we do not work on the network.
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
- 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.
- 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.
- 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, arranging access to it is your step, under your own contract. 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. You get the options and our recommendation.
- 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.
- 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. Those are yours to arrange under your own contract, 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 Sri Lanka, an older case (2019): with “more than 60 different applications”, its IT support contract was “coming up for renewal with a significant price hike”, and “there was no centralized code repository”. | 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. |
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.