The Product Moved to New Storage Three Years Ago, and the Old Store Is Still Running. A Benchmark for Every Old Store.

The project to move the product’s files to new storage finished three years ago. It was a good project. It ended on time, and the closing report has four ticks on it.

New store built. Data copied. Product switched over. Old store kept for thirty days, in case.

There was no fifth line. Nobody was asked to come back on day thirty-one. The engineer who ran the move was put on the next project the following Monday. The old store is still running today, with a copy of everything the product held three years ago.

What We Found

For this article we went through the public record on why firms hesitate over moving data and replacing old systems: one survey of IT professionals on the challenges of old systems and the reasons for not replacing them. We say first what is not ours to do. IOanyT does not migrate, close or delete data, does not carry out security reviews, and does not look at or handle the data in a store.

Three findings stand out.

Moving data is itself a reason firms hold back. In one survey of 504 IT professionals in the US, “across industries and company sizes”, run by a firm that sells software services and not about software firms alone, 35% named data migration concerns among their reasons for not modernising, and 38% fear of disrupting operations.

What still works tends to stay. In the same survey, half said the biggest reason they had not upgraded was that “the current system still works”. An old store kept “in case” still works too, and nothing about it asks for attention.

Old systems are common. In the same survey, the summary finding was that “62% of organizations still use legacy systems”, and 39% named high maintenance and support costs among the top challenges of those systems.

Our reading is that with so much attention on getting the move right, little is left for what happens afterwards. Success is defined as the new store working. The old store is kept on purpose, for good reasons, with no date on which that reason ends. Removing it is a small technical job and a large decision, and the decision belongs to nobody who was in the project. The same is true of a rebuild: when a feature is dropped from a new version, its data has to go somewhere, or be kept on purpose, and somebody should choose which.

What Waits While the Old Store Has No Decision

A store left behind by a move does not stay a technical matter. Our reading is that it becomes a question nobody has been asked to answer.

The first cost is that the store drops off the firm’s own record. The record is updated to show the new store, and the old one stays where it was. The record becomes tidier than the truth.

The second cost falls on engineering. Engineers can remove a store, and will not decide to, because whether anything in it must be kept is not their question. So it stays, and is paid for.

The third is that the firm’s security team protects what is on its list. An old store that has left the list has left their work too.

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

Four Ways to Deal With the Old Stores, Weighed

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

Option	When it fits	What it risks
Let the project team decide, store by store, at the end of the move	The data is not personal, and the team knows what each store held	Engineers are asked to judge what must be kept, which is not their question
Have an outside security or data-protection firm review the old stores, of the firm’s own choosing	The firm needs a view on its duties, and can name the stores	The review covers the stores the firm can name; one that left the list may not reach it
Leave them until the next rebuild	A rebuild is close, and the stores are not growing	They carry on until then, and the rebuild leaves its own old stores behind
Read the code first, then give every old store a line in the traceability matrix, with a named person’s decision	The product is old, has moved or been rebuilt more than once, and nobody holds the full list	It takes the time of people outside engineering, and every decision still has to be made and carried out by the firm

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 product, 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
Stores named in the code, set beside the stores on the firm’s own list	Never compared; the list was written from memory	Every store the code names is on the firm’s list, or marked as a difference for the firm’s own people to look into	The store list, set beside the firm’s own record
Kinds of record with a written account of what the code does with them	None	Every kind of record the code handles, with what the code does once its purpose is served	The written account in the specification
Old stores with a line in the traceability matrix and a named person’s decision	None; kept “for now”	Every old store a rebuilt part used: carried across, or dropped on purpose, with who decided	The traceability matrix
Decisions carried out	Not recorded	Each decision carried out by the firm’s own team, and confirmed by them	The firm’s own confirmation, noted against the matrix
Development kept apart from live data	Not stated	All work done apart from the live product, on separate data, never live customer data	The staged plan, reviewed at every 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 software firm.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about your product, the moves and rebuilds it has been through, and the stores your own people believe are still running. 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 it is limited to your product’s own code and the structure of its databases, taken from the code or from a structure-only export your team gives us, never the data in them. It lists every data store the code still writes to or reads from, and of those, the ones nothing uses any longer, for your own security people to act on. 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. Where you decide to rebuild a part of the product or replace a store, we rebuild it one module at a time while the old product keeps running, on React, Node.js, Python or Java. We never do a single cutover. The traceability matrix records every old store that part used, carried across or dropped on purpose, and who decided; your own team carries out what was decided and confirms it. We keep development work apart from your live product, and the separate place we set up for trying changes runs on separate data, never your live customer data. 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. We do not migrate, close, secure or delete a store, and we do not look at, copy or handle the data in one; your own team carries out every decision. A line in the matrix removes nothing by itself, and some old stores will rightly be kept. We do not decide what must be kept or for how long, and we say nothing about what any data protection rule requires. We do not carry out a security review, and we cannot tell you whether anyone else has reached a store. 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 software firm.

What changes for the business:

Role	What they gain
CEO	A move to new systems ends with the old ones accounted for, and not left running because nobody was asked.
CTO or CIO	A matrix with a line for every old store, showing what replaced it and who decided what happens to it.
CISO	Stores the firm decides not to keep are retired by its own team on a decision and a date, and stop sitting unwatched.
Head of risk and compliance	A dated record, kept by the firm, of what was decided for each old store and by whom.
Head of product	A feature that is dropped takes its data out of the product’s future, by a decision somebody made.

None of these means that anyone’s records are safe, or that a store has not been reached by someone else.

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

The case	What IOanyT does
This article names no organisation. Its figures come from a vendor’s survey of IT professionals, which we do not name.	When a part of a product is rebuilt or a store replaced, our traceability matrix records every old store, carried across or dropped on purpose, and who decided. Your own team carries out each decision. We do not migrate, close or delete data, or say how long anything must be kept.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We give every old store a line and a named decision, and the benchmark shows you, before and after, how many have one.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →