Only the Vendor Can Explain It

1. At a Glance

Issue study · From the public record. Everything about it comes from the public record. No vendor is named, and nothing here says any vendor behaved badly.

Organisation type	Telecom operators whose billing system, and the applications built around it, were built and are looked after by a vendor or an integrator
Size band	The operator in the record: a mobile operator with a few million customers. The research: telco CIOs in the Americas, with no sample size and no operator size. Our reader: a regional internet or broadband provider, a cable operator, a provider of connectivity to businesses, or another mid-size operator
Region	The case: South Asia. The research: the Americas, with global figures beside it
The decision at stake	Whether to renew support for the old applications as before, switch vendor, or first write the operator’s own record of what its applications do and what they send to the vendor’s product and expect back
The public outcome	In an older case, from the late 2010s, the operator’s IT support contract was due for renewal at a much higher price, and its code was not kept in one central place. The record does not say whether the rise was fair, and this study does not suggest it was not
Why it matters to a mid-size operator	An operator that holds no written record of what its own applications do cannot get a comparable second quote, and every change waits on one party, however fair that party is

2. The Business Problem, in the Buyer’s Words

“Our billing vendor built the charging rules, the care portal and the finance reports, and has looked after them for years. They do a good job. But when finance asks how a first bill is worked out, we raise a ticket. When the support renewal came in higher this year, we asked two other firms to quote, and both asked us for a description of the system. We had a contract, some invoices and a list of screen names. We signed. I am not saying the price was wrong. I am saying I could not tell, and that every new plan we launch ties us a little more.”

These words are imagined. They describe the decision as the research shows it, not a real conversation.

The operator is caught between a vendor it has no reason to leave and a position it cannot judge.

3. What We Found

Method. 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; one industry body’s article on the subject; and one survey of IT professionals on old systems.

What technology heads say. In an industry body’s research on telco CIO priorities in the Americas, as a news report gave it:

What the report says	The region	Globally
Telco CIOs who say they depend on the vendors and integrators of their old systems	About four in five	About two-thirds
Telco CIOs who say moving off closed old systems is difficult	Nearly nine in ten	Nearly three-quarters
Modernising IT and reducing technical debt as an investment focus	Just over half	Not given
Sample size and operator size	Not given	Not given

The report does not say why CIOs depend on their vendors or why leaving is difficult.

One public case. These are the record’s own words.

Case

What the public record says

A mobile operator in South Asia with a few million customers, an older case from the late 2010s

A trade press account described a billing and customer stack that 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 this study does not suggest it was not. What the operator did afterwards is another organisation’s work and is not part of this study

From outside telecom. In one survey of about 500 IT professionals in the US, across industries and company sizes, run by a vendor and not about telecom, about a third named a lack of support or updates from vendors among the top challenges of their old systems, more than four in ten named budget limits among their reasons for not modernising, and nearly four in ten named fear of disrupting operations.

One line of opinion. An industry body’s article, sponsored by a vendor of equipment, spoke of old ways of running IT as having held back agility, speed, innovation and, in the end, growth. That is opinion from a party with something to sell, with no figure behind it.

What we did not find. No case of a vendor withholding knowledge or code from an operator, refusing a hand-over, or overcharging. We say so plainly.

Our reading of how an operator comes to be tied. These three are our reasoning from the record above. None is a finding of any source, none describes the conduct of any vendor, and none is offered as the explanation of the public case.

1. The knowledge sits on one side. The vendor built the applications and wrote whatever was written. The operator bought a working system, not a written account of one, and every change since has gone through the vendor.
2. Only one firm can describe the work, so only one can price it. Without a description, a second firm cannot quote, and the present vendor’s price, which may be perfectly fair, cannot be weighed.
3. Every addition reaches the vendor’s product in its own place. Each project takes the quickest route. Nobody counts the ties or writes down what passes along them, and together they decide whether anything can change.

Illustration, not a real case. A regional broadband provider has used the same billing vendor for eleven years. The vendor built its charging rules, its care portal and its finance reports, and has served it well. When the support contract comes up for renewal at a higher price, the provider asks two other firms to quote. Both ask for a description of the system. Neither can price a contract, a set of invoices and a list of screen names, and the renewal is signed. Nobody has behaved badly, and the provider still cannot say whether it paid a fair price.

4. The Options a Firm in This Position Had

Option	When it fits	What it risks	Our view
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 renewal is decided on one figure again	A legitimate choice once the firm can judge it; before that, it is a decision made without evidence
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 with its own risks, and the same missing record unless one is written first	We would advise against this as an answer to dependence alone, before the firm knows what it would be moving
Write the operator’s own record first, then decide	A renewal or a large change is a year or more away, and the firm wants something to compare against	It costs money long before any quote changes; a second quote may come in higher; the record goes stale unless someone keeps it	Our recommendation
Rebuild the operator’s own applications one module at a time, against a written record of what each sends to the vendor’s product and expects back	The record shows which of the firm’s own applications are old, and the firm wants them changed without one large move	It costs more than renewing; old and new run side by side for a time; it does not lower what the firm pays its vendor	The natural second step for some applications, once the record exists

5. Our Recommendation, and the Decision It Asks of the Board

Write the operator’s own record first, well before the next renewal. For each of the applications the operator built or had built around its billing system, the specification records what it does, and what it sends to the vendor’s packaged product and expects back. The operator’s own experts confirm it, and the operator keeps it and can take it to any supplier, including its current one, subject to its own contract with its present supplier. Then decide: renew with the vendor by choice, ask for a comparable quote against the same written scope, or rebuild some of the operator’s own applications one module at a time, each built to send and expect exactly what the record says. IOanyT does not read or work inside the vendor’s product, obtains nothing from the vendor, and gives no legal advice; the operator arranges read-only access to the code with its supplier, as its contract allows.

6. Benchmark: Where You Are Now, and Where You Should Be

These are targets, not results. In an engagement the starting points are replaced by the firm’s own figures, taken in the first review.

Measure	Typical starting point	Where it should be	How it is checked
The firm’s own applications that talk to a vendor’s product, each with a written record of what it sends and expects back	Not counted; none written	Every one counted and recorded, confirmed by the firm’s own experts	The map of the applications as they stand, and the specification
The renewal decision	Made on one figure, with a note that no comparison was possible	Made with at least one comparable quote against the same written scope, or a written reason for not seeking one	The firm’s own renewal file
Change requests that only the vendor can scope	Not counted	Counted, and falling as the record grows	The firm’s own change log and the risk register
Questions about how a charge or an activation is worked out	Each one a ticket to the vendor	Answered from the specification, with a ticket only where the record is silent	The firm’s own ticket log
Code for the firm’s own applications held in its own repository	Not known; often held elsewhere, or nowhere	Held in a repository the firm controls, as its contract allows	The firm’s own repository list (arranging it is the firm’s step)
Old functions matched to new ones, where an application is rebuilt	Not recorded	Each function linked to its replacement	The traceability matrix

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about the applications only your vendor can explain, and the renewal ahead. 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 study 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.
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. A traceability matrix links every old function to its replacement. 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.

8. What the Client Would Own

• The map and the specification: what each of the operator’s own applications does, and what it sends to the vendor’s product and expects back, confirmed by the operator’s own experts. The operator can take it to any supplier, including its current one, subject to its own contract with its present supplier.
• The risk register: the ties and the risks in them, listed before any price is set.
• The traceability matrix: for every module IOanyT rebuilds, every old function linked to its replacement.
• The code: the rebuilt modules are the client’s. No runtime or platform fee.
• The filled-in benchmark: each measure, where it started and where it stands.

9. What This Approach Does Not Cover

• IOanyT does not read or work inside a vendor’s packaged billing product, and does not implement, configure, change, upgrade or replace one. For such a product it records only what the operator’s own applications send to it and expect back.
• IOanyT does not work on the network or the systems that run it.
• IOanyT obtains nothing from a vendor: no code, no access and no documents. The operator arranges read-only access to the code, and any documents, with its supplier, as its contract allows. Only the free Review starts without code.
• IOanyT gives no legal advice on contracts, licences or the ownership of code, and does not negotiate with a vendor. A specification is no substitute for a lawyer’s reading of the contract.
• IOanyT has no integration product, is not a staffing firm and does not take over the day-to-day support of a system.
• A written record does not end an operator’s need for its vendor, lower what it pays, or make leaving easy. A second quote may be higher than the first, and the present vendor’s price may be fair. Staying is a legitimate choice.
• IOanyT does not keep the old applications running while one is rebuilt.
• This study does not say that IOanyT has done this work for a telecom operator. IOanyT has no published case of it.

About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.

10. Sources

Source	Used for
News report of an industry body’s research, September 2026	What telco CIOs in the Americas, and globally, say about dependence and leaving
Light Reading, 7 August 2019	A mobile operator in South Asia: the applications, the support renewal and the code repository
An industry body’s article, vendor-sponsored, 2025	The quoted opinion
A vendor’s survey of about 500 US IT professionals, 2025	Challenges of old systems and reasons for not modernising

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 the operator’s own written record, so that the next renewal is a choice and not a signature.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →