One Price at Renewal, and Nothing to Compare. Four Ways to Deal With a Vendor You Depend On, Weighed.

The renewal notice for support of the billing applications arrives sixty days before the term ends. The price has gone up.

The finance head asks for a second quote. The head of IT telephones two other firms. Both are interested, and both ask the same thing first: can you send us a description of the system?

There is nothing to send. The renewal is signed in week seven, with a note in the file that no comparison was possible.

What We Found

For this article we went through the public record on operators and the vendors they depend on: one trade press account of a support renewal at an operator, one industry body’s research on the priorities of telco CIOs, one survey of IT professionals, and one set of rules that operators in India work under.

Four findings stand out. The rules are set out in the next section.

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 South Asia with a few million customers, whose billing and customer systems ran to dozens of separate applications. Its IT support contract was coming up for renewal with a large price rise, and its code had no single central store. The account does not say whether the rise was fair, and we do not suggest it was not. We take one narrow point: an operator with no single store of its code has little to set a price against. What it did afterwards we leave out.

Dependence on a legacy vendor is the usual position, not the exception. In an industry body’s research on telco CIO priorities in the Americas, more than four in five of the region’s telco CIOs said they depend on legacy vendors and systems integrators, against about two in three globally. The news report gives no sample size and no size of operator.

Money already limits what firms can change. In one survey of about five hundred IT professionals in the US, across industries and company sizes, run by a firm that sells software services and not about telecom, more than four in ten named budget limits among their reasons for not modernising old systems.

We found no case of a vendor overcharging an operator, or withholding what a second firm would need. A vendor’s price at renewal may be perfectly fair. Our point is that, without a description of the work, nobody can tell, and that is unfair to the vendor too.

Our reading is that only the present vendor can quote because a quote needs a description, and the only description is in the vendor’s files. A newcomer must learn the system first, and that cost goes into its price. And the comparison is attempted when the renewal notice arrives, the one time there is a deadline.

What Waits on One Party While Nothing Is Written Down

The first thing that waits is the second quote. A firm that has never seen the system cannot price it.

The second is every change. A change only one firm can scope waits in that firm’s queue, however willing it is.

Some changes come with a date attached. In India, TRAI’s Standards of Quality of Service regulations of 2024, notified on 2 August 2024, came into force “with effect from 1st October 2024”. They said every service provider “shall create or upgrade their system within six months of notification of these regulations” for the collection of primary data, its storage, processing, performance report generation “and their online submission to the Authority”. They apply to providers of access and broadband services and to internet service providers, but not to “an Internet Service Provider whose total number of subscribers as on last day of the preceding financial year does not exceed ten thousand”. The regulations name no application and no vendor. Our reading is that where reporting runs through applications only one vendor can change, a dated change of this kind waits on that vendor’s diary. What any rule asks of your firm is a question for your own advisers.

This is our reading of the evidence. It is not a measured market figure, and it is not legal advice.

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 next renewal is decided on one figure again, and changes go on waiting in one queue
Switch to another vendor	The present arrangement no longer fits the business, and the firm can fund a large move	A new dependence, a big move with its own risks, and the same missing record unless one is written first
Write your 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
Rebuild your own applications one module at a time, against a written record	Some of the firm’s own applications are old, and it 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

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	Every one recorded, in a specification a stranger could read	The specification, confirmed by your own experts
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	Your own renewal file
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

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 renewal ahead and the applications only your vendor can describe. 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 a price. The record costs money long before any benefit shows. We promise no saving: a second quote may come in higher, and your present vendor’s price may turn out to be fair. The licence for a packaged billing product lies outside anything we write; we do not read or work inside such a product. We obtain nothing from a vendor, and only the free Review starts without code. We give no legal advice, and a specification is no substitute for a lawyer’s reading of your contract. We do not work on the network. 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	Staying with the vendor becomes a decision the firm makes and can defend, and not a fact it lives with.
CTO or CIO	A second firm can be asked to quote, or to take on one piece of work, because there is a document to hand over.
CFO	A renewal or a change request can be set beside another figure for the first time.
COO	A small change no longer waits in one firm’s queue because nobody else could be asked.
Head of regulatory affairs	If the contract has an exit plan, the firm now holds its own written record to carry it out with, and the knowledge is not all on the other side.

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, an older case (2019): its IT support contract was coming up for renewal with a large price rise, and its code had no single central store.	Our part is far narrower: we do not say the price was unfair, we do not negotiate, and we obtain nothing from a vendor. 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.
TRAI’s regulations notified on 2 August 2024 said every service provider “shall create or upgrade their system within six months of notification of these regulations” for collecting and submitting service-quality data.	We give no regulatory advice and do not say what they ask of your firm. We record what an operator’s own applications do, so a change can be scoped by more than one firm.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We write the record before the renewal notice arrives, so that whichever supplier you choose, you chose it.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →