A New Application Is Not the Same as Every Rule Carried Across. Where Your Records Are Now, and Where They Should Be.

The operator is replacing its fifteen-year-old order application. The new one has been in test for a month, and the reports are good.

An order desk supervisor, trying the new screens, raises an order on a test account marked as depending on the line. It goes straight through. The supervisor stops. On the old screen, that kind of account brings up a small grey box: refer to supervisor before proceeding.

Nobody on the project knew. The rule is in no requirement. It turns out to be eleven lines in the old code, added after an internal review years ago.

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 one narrow risk: that replacing an old application removes something it did for these accounts, and nobody notices.

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 regulator’s decision, the operator itself saw that the status needed a place in its present and future systems. On 1 December 2025 the UK regulator, Ofcom, fined Virgin Media “£23,800,000” after it “failed properly to identify and record the status of telecare customers” while moving customers “from analogue to digital landlines”. 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) records that “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 decision also says that, to uphold “its policy commitment to identify vulnerable consumers and record their needs”, the operator “ought to have” “Taken steps to search the customer service records, where Virgin Media knew this information was stored, to identify Telecare Customers during the screening process for migration.” The move itself was a change of network, which is not our kind of work, and searching customer records is an operator’s own work, not ours.

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.

Change is feared, and so is moving data. 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, nearly four in ten named fear of disrupting operations, and about a third named concerns about moving data, among their reasons for not modernising.

Nobody in the public record reports a rule lost in a replacement of software. We found no public case of an operator’s application being replaced and a rule about these accounts going missing, and we name none. What follows is a caution from our own reasoning.

Our reading is that rules like the grey box were added quietly, after a review or a complaint, and live in the code and nowhere else. They show only on rare accounts, so ordinary tests never meet them, and a replacement specified from what people remember will not have them. A missing screen is noticed on the first day; a missing hold is not noticed at all.

What a Finished Replacement Does Not Tell You

A new application that has passed its tests tells you that work has been done. It does not tell you for which kinds of account the question was ever asked; whether the status reaches every application and job that acts on an account, unchanged; whether every rule the old application held for these accounts was carried across or dropped by a decision someone can name; or which of the orders you have named are held by the system, and which still rest on a member of staff remembering.

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

Four Ways to Replace an Application That Touches These Accounts, 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, before the replacement	Always needed for anyone never asked	The new application may not take in, carry or act on the answers as the old one did
Keep the old application and work around it by hand	A replacement is not yet funded, and a small team knows the accounts	Rules stay unlisted, the check rests on memory, and the replacement is only put off
Replace the application from requirements gathered in workshops, without listing its rules	The firm already holds a full list of what the old application does for these accounts	Rules that fire a few times a year are never mentioned, and are lost without a decision
Assess first: list every rule about these accounts from the old code, rebuild the part that carries the status, and give each rule a matrix line and a named person’s ruling	The firm is about to replace an application that touches these accounts	It costs money before the replacement; code shows the rules in code, not habits of staff; a listed rule may still be wrong, or not enough

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 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
Applications and jobs the status reaches unchanged	Not known; one system holds it	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; known to whoever last read the old code	Every rule listed in plain words, each carried across or dropped on purpose, with who decided	The specification and the traceability matrix
Kinds of order you have named that are held by the system, not by staff memory	None; a person is expected to check	Each kind you have named, held for a person to look at	The rebuilt module and its traceability matrix
Rules found only as habits of staff	Not known	Each one your people describe, written down beside the rules found in code	The specification, confirmed by your own experts

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 application you are replacing, and what it does for accounts that depend on the line. 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, one by one. 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 above. 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. A list and a matrix show that a rule was carried across or dropped by decision; they do not show that the rule is the right one, or that it is enough. That is for you to judge, with your own advisers. Reading code finds the rules that are in code; a safeguard that exists only as a habit of your staff is not there to be found, and only your people can tell us about it. 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. We do not read, clean, correct or fill in customer records, and we do not contact customers or alarm providers. A rule held inside a billing or customer product made by another firm is outside what we can list. 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.

At the end you hold the map of where the status is held, the specification with every rule about these accounts, the risk register, the traceability matrix and code for the module we rebuilt, and the filled-in benchmark. Asking your customers, and deciding what is done for them, stay yours.

What changes for the business:

Role	What they gain
CEO	Replacing an old application does not quietly remove a rule the firm did not know it had.
CTO or CIO	Each rule about these accounts in the old application has a line in the matrix, a place in the new one and a recorded check.
COO	Operations is not the first to find out, after a change, that something the old screen used to stop is no longer stopped.
Head of regulatory affairs	A record, kept by the firm, of which rules about these accounts existed, where each now lives and who checked it.
Head of customer care	The notes and markers customer care relies on for these accounts are listed before a replacement, so none is left behind unnoticed.

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”; the decision records that the operator later identified a need for a flag or field in its existing and future billing systems.

Our part is far narrower than this case, and the decision does not concern a replacement of software. 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. Where an operator replaces an application it built, we list every rule in the old one about such accounts and give each its own line in the traceability matrix.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We set the benchmark before anything is replaced, so that “nearly done” is replaced by a count of rules listed, carried across or dropped by a decision someone can name.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →