Who Depends on the Line: What an Operator's Records Could Say

1. At a Glance

Issue study · From the public record.

Organisation type	A UK phone and broadband operator moving its landline customers from analogue to digital lines
Size band	The operator in the record: the decision gives no size band, and we give none. Our reader: a regional internet or broadband provider, a cable operator, a provider of connectivity to businesses, or another mid-size operator whose own applications hold customer records
Region	The case: United Kingdom. Nothing was found from India
The decision at stake	What an operator’s own applications can say, before a move, about which customers depend on the old line, and what to change in them so that a status the firm holds reaches the place where it is acted on
The public outcome	On 1 December 2025 the UK regulator, 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, resulting in significant gaps in the screening process”. Its decision records that the operator had no digital flag for these customers
Why it matters to a mid-size operator	Any operator that retires an old network has to know first who depends on it. That knowledge can only come from its own records and from asking its customers. What its applications can and cannot say is something it can find out before it moves anyone

We should be plain from the start. IOanyT does not work on networks, and nothing it does keeps a phone line, an alarm or an emergency call working, or protects anyone. This study is about what an operator’s own applications record, and nothing more.

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

“We are about to move the first areas off the old line. The plan says a few hundred accounts are marked as depending on it. I asked how we know, and nobody could tell me when the marker was added, which screens set it, or whether a blank means ‘no’ or ‘never asked’. Some agents type it into the notes instead. The order system does not show it at all. And we are replacing that order system next year, from requirements nobody has checked against the old code.”

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

The operator is caught between a move it has to make and records that cannot say who was ever asked. Who depends on the line can only be learned by asking. What the operator’s own applications can and cannot say can be found out first.

3. What We Found

Method. We went through the public record on what an operator’s records could say about customers who depend on the old phone line: Ofcom’s news release of 1 December 2025 and its confirmation decision (case CW/01278/12/23, issued on 1 December 2025, published in a non-confidential version on 19 January 2026), read in full.

One regulator’s decision. These are the decision’s own words.

What	The decision’s words
The move	Migrating “Telecare Customers from analogue to digital landlines” (title of the decision); 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”
The finding about records	”Failure to properly identify and record the status of Telecare Customers” (Contravention 1)
What the operator held before the move	”Before migrations began, Virgin Media did not have a specific record of Telecare Customers.”
How the status was recorded	”Virgin Media did not have a digital “flag” on its system to identify Telecare Customers”; a reference “would be added via text to their customer service record”
How it could be found	”the only way for Virgin Media to identify directly from these records that a customer was a Telecare Customer was to conduct a manual search”
What the screening did	It “did not involve a review of customer service records”, which the operator said “has simply not been practicable”
Ofcom’s view of the effect on the records	”The absence of a digital “flag” and the lack of review effectively rendered any information previously provided by a Telecare Customer to Virgin Media about their telecare status redundant for the purposes of migration.”
Records of what was done	”there were gaps in record keeping when engaging with known Telecare Customers regarding their migration”
What the operator later identified	”On 14 November 2023 Virgin Media identified a need to develop a new identification “flag/field for Telehealth customers in both existing and future billing systems.""
The second finding	The operator’s “approach to disconnecting known Telecare Customers was also a failure to comply with its own policies and procedures for vulnerable consumers” (Contravention 2); “Virgin Media exposed vulnerable consumers to a direct risk of harm”
What Ofcom did not decide	It “decided not to pursue making findings” in this investigation on uninterrupted access to emergency organisations
Period and penalty	”between August 2022 and December 2023” (the decision: 23 August 2022 to 18 December 2023); “£23,800,000”

We report the effect on customers only in the decision’s words above and add nothing to them. 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. The move itself was a change of network, which is not IOanyT’s kind of work.

Our reading of why an operator’s records may not be able to answer. These three are our reasoning. None is a finding of Ofcom, and none is offered as an account of the case above.

1. The question is newer than most accounts. A marker was added to one form at some point, or the answer was typed into notes. Older accounts were never asked, and in a database a blank and a “no” can look the same.
2. The answer does not travel. It is recorded in one application and missing from another, because the jobs that copy customer details between them were written before the marker existed.
3. Rules about these accounts live only in old code. A check that holds certain orders may exist in an old application, listed nowhere, and be lost when that application is replaced.

Illustration, not a real case. A regional operator’s care system has had a tick-box for dependence on the line for six years. Its order system keeps its own copy of customer details, fed each night by a job written before the tick-box existed, which does not carry it. A report on the care system counts the ticks. Nobody can say how many older accounts were ever asked, and the order screen shows no tick for any account. Every detail is invented, and it describes systems only.

4. The Options a Firm in This Position Had

Option	When it fits	What it risks	Our view
Ask every customer again, through the operator’s own process	Always, for anyone never asked; it is the only way to learn who depends on the line	Each new answer lands in the same places as before, and may not reach where orders are raised	Necessary, whatever else is done. It is the operator’s own job, and it stays so
Work around the current systems by hand: a spreadsheet, a note, staff told to check a second screen	A short time before a move, with few accounts and a small team that knows them	It rests on memory, and nothing records whether the check was made	A bridge, for the operator to decide
Replace the application that holds the records, without first listing what it does for these accounts	The firm already holds a full list of what the old application does for them	Any rule nobody listed is lost without anyone deciding to lose it	We would advise against this for any application that touches these accounts
Assess first: where the status is recorded, how it was filled and where it will be blank; then rebuild the part that takes in and carries it, and list every rule about these accounts	The operator needs to know what its records can say before it decides what to do for anyone	It costs money before anything changes; code shows who was asked, not who depends on the line; a rule in software can be wrong, and can be switched off	Our recommendation, alongside the first option

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

For an operator about to move customers off the old line: before anyone is moved, find out what its own applications can say. Record where a customer’s dependence on the line is held, how each field came to be filled and where it will be blank, so that the operator knows which kinds of account it has never asked. Then rebuild the part of its own application that takes in and carries that status, as one module, so that it reaches every application that acts on the account and holds back the orders the operator has named. Where an application is replaced, carry every rule about these accounts into the new one, each with its own line in the traceability matrix and a decision by a named person on the operator’s side. Ask the customers who were never asked alongside it.

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 operator’s own figures, taken in the first review.

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 shown as asked or never asked, from the screens and jobs that set the status	The map and the specification
Applications and jobs the status reaches unchanged	Not known; one system holds it, or notes do	Every one that acts on an account	The specification, reviewed after each module
Rules about these accounts, each with a line in the traceability matrix and a named person’s ruling	None listed	Every rule listed in plain words, carried across or dropped on purpose, with who decided	The specification and the traceability matrix
Kinds of order the operator has named that are held by the system, not by staff memory	None; a person is expected to check	Each kind named, held for a person to look at, with a record of each hold	The rebuilt module and its traceability matrix

7. How IOanyT Would Work

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 study 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.
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. The separate place we set up for trying changes runs on separate data, never your live customer data. 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.

8. What the Client Would Own

• The map: every place in the operator’s own applications where the status can be held, free-text notes included, and the screen or job that fills each.
• The specification: what those applications do with the status, which kinds of account were never asked, what a blank means in each place, and every rule about these accounts, confirmed by the operator’s own experts.
• The risk register: each gap, ranked, ready for the operator’s decision.
• The cost comparison and the staged plan: keeping set beside replacing the part that takes in and carries the status, and each stage with a fixed quote.
• The traceability matrix: for the rebuilt module and for any replacement, every rule linked to its place in the new application, or recorded as dropped on purpose, with who decided.
• The code: the rebuilt module is the operator’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 work on the network, on alarm equipment or on anything that carries a call. Nothing it does keeps a line, an alarm or an emergency call working, and it protects nobody.
• IOanyT does not decide who counts as depending on the line, what question is asked, or what is done for such customers. The operator decides, with its own advisers on the rules that apply to it.
• IOanyT does not read, search, clean, correct or fill in customer records, and does not contact customers or alarm providers. It reads code and database structure. Reading code can show 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.
• A rule in software can be wrong, and it can be switched off. A list and a matrix show that a rule was carried across or dropped by decision, not that it is right or enough. A safeguard that exists only as a habit of staff is not in the code and cannot be listed from it.
• IOanyT works 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 the operator had built, the operator arranges read-only access to the code with its supplier, as its contract allows; that step is the operator’s, and IOanyT does not obtain code from a supplier.
• IOanyT gives no legal or regulatory advice and promises no outcome with a regulator.
• This study does not say IOanyT would have changed anything for the operator described, or that IOanyT has done this work for a telecom operator. It has no published case of it.

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

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

10. Sources

Source	Used for
Ofcom, confirmation decision, case CW/01278/12/23, issued 1 December 2025, non-confidential version published 19 January 2026	The findings about records and the second finding, the period, what the operator later identified, and what Ofcom did not decide
Ofcom, investigation page, case CW/01278/12/23	The case reference and the dates of the decision and its publication
Ofcom, news release, 1 December 2025	The fine, the finding as announced, and the period

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 →