Operators Can Count the Accounts They Marked. What Nobody Can Count Is Who Was Never Asked.

The planning meeting for the first three areas has one slide on customer records. It says 18,400 lines are to be moved, and that 212 accounts carry the marker for customers who depend on their line.

The head of regulatory affairs asks one question. Of the 18,400, how many were ever asked?

Nobody in the room knows. The question was added to the sign-up form six years ago. Older accounts were never asked it. And in the database, an account that answered “no” and an account that was never asked look exactly the same.

What We Found

We should be plain at the start. Nothing we do keeps a phone line, an alarm or an emergency call working, and this article is not about the network. It is about what an operator’s own applications record about customers who depend on the line, and how far that can be relied on.

For this article we went through the public record: one regulator’s published decision about an operator’s records during a move of landlines, one survey of IT professionals on why old systems stay, and one industry body’s research on moving off them.

Four findings stand out.

In the one regulator’s decision we found, the operator had no field for the status. On 1 December 2025 the UK regulator, Ofcom, fined Virgin Media “£23,800,000”. Its announcement said that, while moving customers “from analogue to digital landlines”, the operator “failed properly to identify and record the status of telecare customers, resulting in significant gaps in the screening process”. The decision’s glossary describes a telecare device as “A personal alarm that relies on a functioning fixed voice connection to make calls to an alarm receiving centre”. Ofcom’s confirmation decision (case CW/01278/12/23, issued on 1 December 2025, published in a non-confidential version on 19 January 2026) says: “Before migrations began, Virgin Media did not have a specific record of Telecare Customers.” It found that the operator “did not have a digital “flag” on its system to identify Telecare Customers”, that a reference to a customer being a telecare user “would be added via text to their customer service record”, and that the screening for the move “did not involve a review of customer service records”, which the operator said “has simply not been practicable”.

The regulator’s finding covered how known customers were treated, and we report it only in its own words. The decision also found that the operator’s “approach to disconnecting known Telecare Customers” was “also a failure to comply with its own policies and procedures for vulnerable consumers”, and that “Virgin Media exposed vulnerable consumers to a direct risk of harm”. The decision records that Ofcom “decided not to pursue making findings in this investigation” on the operator’s obligations “to ensure uninterrupted access to emergency organisations”. The move itself was a change of network, which is not our kind of work. We did not examine why the operator had no field for the status, and we draw no cause from it beyond the decision’s own words.

Old systems stay because they still work. 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, half said that “the current system still works” was a reason for not modernising. About a third named concerns about moving data.

Moving off old systems is hard even for those who want to. In one industry body’s research on the priorities of telecom chief information officers, as reported in the news, 88% of those in the Americas said migrating from closed legacy systems is difficult, against 73% globally. The report gives no sample size and no operator size.

Our reading is that operators record dependence on the line, where they record it at all, wherever there was room when the question came up: a note on the account, a field added to one form, a spreadsheet. Nobody wrote down where, or for whom the question was put. So before a move, a firm can count answers but not questions. This is our reasoning, not an account of the case above.

What Waits While Nobody Knows Who Was Asked

The first cost is a number nobody can vouch for: a count of marked accounts counts people who were asked and said yes, and nobody else.

The second is a blank read as an answer. Where “no” and “never asked” are stored the same way, a report counts every blank as a no.

The third is an answer the firm holds but cannot find, typed into a note years ago that no screen or report reads.

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

Four Ways to Find Out What Your Records Can Say, Weighed

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

Option	When it fits	What it risks
Ask every customer again, through your own process	Always needed for anyone never asked; it is the only way to learn who depends on the line	The answers still have to be recorded where every application can see them
Work around the current systems by hand: a spreadsheet, a note, a second screen to check	A short time before a move, with few accounts and a small team that knows them	It rests on memory, and nothing records that the check was made
Replace the application that holds the records, without listing what it does for these accounts	The firm already holds a full list of what the old application does for them	Anything nobody listed is lost without anyone deciding to lose it
Assess first: where the status is held, how it was filled, where it is blank; then rebuild the part that carries it and list every rule	The firm needs to know what its records can say before it decides anything	It costs money before anything changes; code shows who was asked, not who depends on the line

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
Kinds of account for which the question was ever asked, as recorded in the applications	Not known; only a count of marked accounts	Every kind of account (by age, route of sign-up, product) shown as asked or never asked, from the screens and jobs that set the status	The map of the applications as they stand and the specification
Places the status can be held, free-text notes included	One field known, or none	Every field, table and free-text box where it can be written, each with the screen or job that fills it	The map of the applications as they stand
What a blank means in each place	Read as “no”	Written down for each place: “no” or “never asked”	The specification
Rules in your own applications that read the status	None listed	Every one listed in plain words, with a named person’s ruling on it	The specification 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 what your applications record about customers who depend on the line, and where. 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 your own applications that hold customer records, read through their code and database structure, never the records themselves. The assessment says where a customer’s dependence on the line is recorded, how that field came to be filled and where it will be blank, and lists every rule in those applications about such accounts. 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 part that takes in and carries that status, 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. You get the options and our recommendation.
4. If you approve, we build. We rebuild only the part of your own application that takes in and carries that status, as one module, while the old application keeps running. Which orders it holds back, and for which accounts, is your decision. We never do a single cutover. Where you replace an application, every rule about these accounts gets its own line in the traceability matrix: where it lives in the new application, or that it was dropped on purpose and who decided. 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, and on this subject they matter most. We do not work on the network, on alarm equipment or on anything that carries a call, and nothing we do keeps a line, an alarm or an emergency call working or protects anyone. We do not decide who counts as depending on the line, what question is asked, or what is done for such customers; you decide, with your own advisers on the rules that apply to you. We do not read, clean, correct or fill in customer records, or contact customers or alarm providers. Reading code shows where an answer could be recorded and which kinds of account no screen ever asked; it cannot show what any note says, or who depends on the line. Only asking customers shows that. We work only on applications an operator built or had built, not inside a billing or customer product made by another firm. Where a supplier holds the code of an application you had built, you arrange read-only access to the code with your supplier, as your contract allows; that step is yours, and we do not obtain code from a supplier. We give no legal or regulatory advice. 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	Before a change to the network is approved, the board knows what the firm’s systems can and cannot say about who depends on the line.
CTO or CIO	A written account of every place the status is held, which screen or job fills it, and where it was never asked for.
COO	The teams planning a move know which accounts the systems can vouch for and which will need asking.
Head of regulatory affairs	The firm can say in writing what its records were able to show before it moved anyone, and what it did about the gaps.
Head of customer care	Customer care knows which customers have never been asked, and can plan to ask them before a move and not after.

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

The case	What IOanyT does
On 1 December 2025 Ofcom fined Virgin Media £23,800,000, finding that while moving customers from analogue to digital landlines it “failed properly to identify and record the status of telecare customers”; its decision records that the operator had no digital flag for them.	Our part is far narrower than this case. We do not work on networks, carry out moves, read customer records or contact customers, and nothing we do keeps a line working or protects anyone. For applications an operator built, we say where such a status is recorded, how the field came to be filled and where it will be blank.

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 by asking your own applications whom you have never asked, so that the people who must ask your customers know where to begin.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →