Ready to Move Is Not the Same as Known. Where Your Customer Records Are Now, and Where They Should Be.

The move to the new platform is eleven weeks away. At the readiness review the project lead reports on customer data. Every account was extracted. Every account loaded in the rehearsal. The counts match.

The head of regulatory affairs asks three questions. How many accounts have no installation address? What does the letter “S” in the status column mean? And which of the old programs fills that column, and when?

Nobody in the room can answer any of the three.

What We Found

For this article we went through the public record on customer records at the moment an operator moves its customers: one regulator’s published finding and one survey of IT professionals on what holds firms back.

Two findings stand out.

In one regulator’s finding at a move, the failure was in what the operator identified and recorded. On 1 December 2025 the UK regulator, Ofcom, fined Virgin Media “£23,800,000”. Its finding was 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”. Telecare is an alarm service that works over the phone line. The move was a change of network, which is not our kind of work, and we take one narrow point: the finding was about what the operator had identified and recorded at the time it moved its customers. We did not examine why the status was not recorded, and draw no cause from it.

Firms know the data is the hard part. 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, about a third named concerns about moving data among their reasons for not modernising, and half said that their current system still works.

Our reading is that a move is usually planned as carrying, not as checking. A blank field loads perfectly, and so does a default. What tells you where a field will be blank, and why, is the program that filled it: whether the field was ever compulsory, which screen or job writes it, and which copy wins when two applications disagree. That can be read before the move.

What a Matching Count Does Not Tell You

A matching count tells you that every record arrived. It does not tell you four things.

It does not tell you which fields were blank by design: optional on the form since the day they were added, or never asked for at all.

It does not tell you which values are defaults. “No” and “nobody asked” can be stored the same way.

It does not tell you which copy won. If the billing system and the care portal disagree, the move takes one of them, and the rule that chose it may be a copy job nobody has read.

And it does not tell you whether the step that spoiled the records is still running, ready to feed the new platform from the first day.

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

Four Ways to Prepare Customer Records for a Move, Weighed

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

Option	When it fits	What it risks
Move the records as they are, and correct them afterwards	The move is small, and the records are known to be in good order	The first weeks after the move are spent on accounts that came across wrong
Run a clean-up just before the move	The errors are old, and the systems that made them are being switched off	If the step that spoiled the records feeds the new platform too, the errors return after the move
Have your own team, or the firm carrying out the move, count the blanks, defaults and unknown codes in each field	The firm has people who know the data, and time before the move	A count shows how much is missing, not which program made it so, or whether that program will keep running
Trace where records are spoiled, record each key field’s path, and rebuild the step at fault before the move	The same kinds of error keep coming back, and the step that makes them will survive the move	It costs money before anything is moved, and it does not correct a single record by itself

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
Places each key customer field is copied between applications	Not mapped	Every place mapped, with the program, copy job or manual step that moves the field	The map of the applications as they stand
Steps that spoil records	None named	Each recurring kind of error tied to a named rule or step, with an owner on your side	The specification and the risk register
Fields that are blank by design, or filled by default	Found at the move, or after it	Each key field marked as compulsory, optional or defaulted, from the code that fills it	The specification
Which copy wins when two applications disagree	Decided by whichever job runs last	Written down for each key field, and agreed by your own people	The specification
Checks at the point of entry, in each rebuilt module	A field the firm relies on is optional, or takes any text	Every detail your people call compulsory is asked for and checked where it is entered	The rebuilt module, accepted against the specification
Old functions matched to new ones, where a module is rebuilt	Not recorded	Each function of a rebuilt module linked to its replacement	The traceability matrix
Steps at fault that would feed the new platform	Not known	Each one either rebuilt or switched off before the move	The staged plan, reviewed at each stage

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 move ahead and the customer records it will carry. 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 and copy jobs your firm built or had built around its billing system, and the assessment traces a wrong customer record through them, and the manual steps your people describe, to the step that spoils it. For each key field the specification records where it is entered, where it is copied and where it is blank by design. 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. 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 the step at fault, such as an entry screen, a rule or a copy job, rebuilt with checks at the point of entry beside the old application. 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 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. We do not clean, correct, merge, reconcile or migrate customer records, and we do not carry out the move; your own people do, or the firm you choose. We read code; your own people count the blanks. A detail that no program ever asked for cannot be found by reading programs. We do not work inside a packaged billing or customer product, old or new; its own specialists deal with a rule inside one. We do not work on the network, and nothing we do keeps a service working for any customer. Our published terms on access cover code, not customer records. We give no legal or regulatory advice and promise no outcome with a regulator. 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 specification with each key field’s path, the risk register, the traceability matrix and code for every module we rebuilt, and the filled-in benchmark. The counting, the correcting and the move are your team’s, or your chosen firm’s.

What changes for the business:

Role	What they gain
CEO	A move to a new system is approved knowing which steps spoil customer records and which have been rebuilt, and not only that the counts match.
CTO or CIO	For each key customer field, a written record of where it is entered, where it is copied and where it is blank by design, to hand to whoever plans the move.
CFO	The steps that spoil records are named and priced in a staged plan before the move’s contract is signed, and are not left as an assumption at the back of it.
COO	The first weeks after a move are not spent correcting accounts that a known step had spoiled.
Head of regulatory affairs	The firm holds a written record of what it traced before it moved its customers, and what it decided about each step at fault.

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

The case	What IOanyT does
Ofcom fined Virgin Media £23,800,000 on 1 December 2025, finding it “failed properly to identify and record the status of telecare customers” during a move of landlines.	Our part is far narrower: we do not work on networks or carry out moves, nothing we do protects a customer, and we do not say what went wrong. For applications an operator built, we record where each key customer field is entered, copied and left blank, and rebuild the step at fault.

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 the move, so that “ready” means the operator knows what its records hold and where they go wrong.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →