Recorded in One System Is Not Known in the Next. Four Ways to Deal With a Status That Gets Lost, Weighed.

Internal audit is following one test account through the operator’s systems, as an exercise.

On the care screen the account carries the marker: depends on the line. An agent set it in April, when the form asked. Audit then opens the same account in the order system, which is where a request to move a line would be raised. The marker is not there.

The order system keeps its own copy of customer details, refreshed each night by a job written in 2014. The job copies forty fields. The marker was added to the care system in 2019, and nobody added it to the job.

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 none of this article is about the network. It is about whether a fact an operator already holds reaches the screen of the person about to act on the account.

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

Four findings stand out.

In the regulator’s decision, the status had been recorded, but not where the move could use it. On 1 December 2025 the UK regulator, Ofcom, fined Virgin Media “£23,800,000” for failures in its move of customers from analogue to digital landlines “between August 2022 and December 2023”, including that it “failed properly to identify and record the status of telecare customers”. 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) found that “Virgin Media did record the telecare status of a customer”, but that “the reference was stored in its customer service record, without a digital “flag” for identification purposes”. So “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”.

Records of what was done for known customers had gaps too. The decision quotes the operator: “[d]ue to the manual nature of this dialling, some outbound calls were made but not recorded on the customer account.” Ofcom found that there “were gaps in record keeping when engaging with known Telecare Customers regarding their migration”. The move itself was a change of network, which is not our kind of work. We did not examine which systems were involved beyond what the decision says, and we draw no cause from it.

Old systems stay because they still work, and change is feared. 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, and nearly four in ten named fear of disrupting operations.

Nobody in the public record traces a status from the screen where it is entered to the screen where an order is raised. We found no public account, from any operator, of which program carried such a status between systems, or dropped it.

Our reading is that a status like this is added to one screen when the question first comes up, while the jobs that copy customer details between systems are older than the field and copy only what they were written to copy. A blank from one system can then sit beside, or replace, a “yes” held in another, and the check becomes a person remembering to open a second screen. This is our reasoning, not an account of the case above.

Why a Recorded Status Gets Lost Between Systems

An operator that has asked the question holds some answers. What it often cannot do is make them reach the place where an order is raised. The path has four parts, and the status can be lost at each: taken in, at the moments the firm has chosen; held in one place that is its master; carried unchanged by every job that copies customer details, so that a blank never overwrites a “yes”; and acted on by the application that issues an order, which holds back the kinds of order the firm has named for a person to look at.

While that path is missing, three things are lost: the answer itself, invisible where it is needed; any record that a check was made; and the firm’s own decision about these accounts, which exists in a policy and nowhere in its systems.

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

Four Ways to Deal With a Status That Gets Lost, 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	Each new answer lands in the same place as before, and the same jobs fail to carry it
Work around the current systems by hand: a spreadsheet, a note, staff told to check the care screen first	A short time before a move, with few accounts and a small team that knows them	It rests on memory on a busy afternoon, and nothing records whether the check was made
Replace the application that raises orders, without listing what the old one 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
Assess first; then rebuild the path that takes in and carries the status, and list every rule about these accounts	The firm holds answers it cannot use where orders are raised	It costs money before anything changes; it carries only what was recorded; a hold needs people to review it; a rule in software can be wrong, and can be switched off

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
Applications and jobs that act on an account and receive the status unchanged	Not known; one system holds it	Every one, receiving it as entered	The map of the applications as they stand and the specification
Places where a blank can overwrite a recorded answer	Not known	None in the rebuilt module	The rebuilt module, accepted against the specification
Kinds of order you have named that are held by the system, not by staff memory	None; a person is expected to check a second screen	Each kind you have named, held for a person to look at, with a record of each hold	The rebuilt module and its traceability matrix
Moments at which the question is asked	One form, at sign-up	Each moment you have decided, in the screens that take the status in	The specification

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 where the status is recorded today, and which screens never show it. 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 and the jobs between them, 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, where it will be blank and where it is dropped on the way between systems, and lists every rule 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: the entry screen, the jobs that copy it, and the check in the application that raises orders. 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. The module’s traceability matrix links each 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.

This approach has a price, and limits. A rebuilt path carries only what has been recorded: an account that was never asked is still unknown, and what your systems do with “unknown” is your decision. A hold slows orders down, and held orders need your people to review them. A rule in software can be wrong, and it can be switched off; who looks after it on your side, once built, is yours to decide. 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 or what is done for them; you do, with your own advisers on the rules that apply to you. We do not read, clean, correct or fill in customer records, and we do not contact customers or alarm providers. Where part of the path runs through a billing or customer product made by another firm, that part is outside what we rebuild. 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	A decision the firm has made about these accounts is built into its systems, and does not rest on every member of staff remembering it.
CTO or CIO	The status is entered once, reaches every application that acts on the account, and cannot be overwritten by a blank.
COO	An order the firm has said must not go ahead without a check is held by the system for a person to look at.
Head of regulatory affairs	A commitment the firm has made exists as a rule in its systems that can be pointed to, with a record each time it held an order back.
Head of customer care	Agents are prompted for the answer when it can still be given, and it is still there when the next team opens the account.

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 for failures “between August 2022 and December 2023” in moving customers from analogue to digital landlines; its decision found the telecare status was held as text in the customer service record, without a digital flag.	Our part is far narrower than this case. We do not work on networks, carry out moves, read or search customer records or contact customers, and nothing we do keeps a line working or protects anyone. For applications an operator built, we rebuild the part that takes in such a status and the jobs that carry it, so that it reaches every system that acts on the account.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We rebuild only the path a status travels between your own applications, so that an answer your firm already holds is there when someone is about to act on it.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →