The Store the Product Stopped Using

1. At a Glance

Issue study · From the public record.

Organisation type	One app maker, described here only in general terms; and IT professionals in general, from one survey
Size band	The app maker: not given here. Our reader: a small or mid-size software firm whose product has run for years and been rebuilt or moved at least once
Region	Not given here for the app maker. The survey: United States. Nothing from India
The decision at stake	How a software firm can know every place its product keeps data, and what its code really does with a record, when its own list was written from memory
The public outcome	A published account says data of one kind was still held in an older store, which it says appeared to contradict the firm’s own policy that data of that kind was deleted once it had served its purpose
Why it matters to a small or mid-size software firm	Most products that have run for years keep data in more places than anyone remembers. Nothing IOanyT does keeps anyone’s records safe. What a firm can hold is a list of the stores its own code names, and a written account of what the code does with each kind of record, for its own security people and lawyers to act on

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

“Our product is eight years old. The first version kept files one way, the second another, and two years ago we moved everything to new storage. Our list of what we hold was written from interviews with each team. Our policy says what happens to a record when an account is closed. Last month an engineer found a storage area from the first version on the bill, and nobody could say what was in it or whether the policy’s sentence had ever been true.”

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

The firm is caught between a list written from memory and a product whose code has never been read for this purpose. It cannot learn from a list what the list leaves out. It can decide to read the code.

3. What We Found

Method. We went through the public record on old data held in places a product no longer uses as its main store: one published account of a data exposure, written by a law firm, and one survey of IT professionals on old systems.

What IOanyT does not do, said first. IOanyT does not carry out security reviews. It does not close, secure or delete a data store, and does not look at, copy, move or handle the data in one. It cannot tell whether a store has been reached by anyone. It says nothing about what any data protection rule requires.

One published account, in general terms.

What	Public record
Who	One app maker, not named here and not described further
When	Recently
What the account describes	Data of one kind still held in an older store, which the account says appeared to contradict the firm’s own policy that data of that kind was deleted once it had served its purpose
The source	A law firm’s published article, not the firm’s own statement or a regulator’s finding
How the store was reached, why it still held the data, what followed for anyone	Not said in the account, and not said here

We take one narrow point from it: data from an earlier time was still held, in a place that was no longer the product’s main store, which the account says appeared to contradict the firm’s policy.

Old systems are common, and they stay because they work. 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, the summary finding was that “62% of organizations still use legacy systems”. Among the top challenges of those systems, 43% named security vulnerabilities. Half said the biggest reason they had not upgraded was that “the current system still works”, and 35% named data migration concerns among their reasons for not modernising.

Our reading of why products come to hold data nobody remembers. These four are our reasoning. None is a finding about the app maker above, and the case is not said to have come about for these reasons.

1. Nobody has a list of every store the product uses or once used. The firm’s record is written from what people remember, and a store nothing uses is the first to be forgotten.
2. What the code does with a record once its purpose is served has never been read. The policy states the intention.
3. The copies the code makes on the way are not followed. Exports, logs and smaller versions of images can outlive the original.
4. A move or a rebuild ends when the new thing works. What happens to the old store is nobody’s task and nobody’s decision.

What is and is not in IOanyT’s part. This division is our own, and it is narrow on purpose.

Not IOanyT’s part	IOanyT’s part, in the product’s own code only
Reviewing security, or saying whether a store was reached	Listing every store the code still writes to or reads from, and those nothing uses any longer
Closing, securing, moving or deleting a store, or handling its data	A written account of what the code does with each kind of record once its purpose is served
Saying whether a policy or a rule is met, or what any rule requires	A line in the traceability matrix for every old store when a part is rebuilt, with who decided
Deciding what must be kept, and for how long	Keeping development apart from the live product, on separate data

4. The Options a Firm in This Position Had

Option	When it fits	What it risks	Our view
The firm’s own team lists the stores from memory and from the storage bills	The product is young, and the people who built it are still there	A list from memory leaves out what was forgotten; a bill names an account, not what a store was for	A useful second source, set beside a list from the code
An outside security or data-protection firm reviews, of the firm’s own choosing	The firm needs a view on its security or its duties	The review starts from what the firm can name; a store or copy on no list may never reach it	The firm’s own decision, and stronger when it starts from a list read from the code
Leave it until the next rebuild	A rebuild is close and already planned	The old stores carry on until then, and a rebuild planned without the list may leave its own behind	Right only where the rebuild is close and starts with the list
Read the code first, then hand the list and the written account to the firm’s own people, or to the outside firm it chooses	The product is old and much changed, and nobody holds a full list	It costs money before anything changes, covers only what the code names, and every decision after it is still the firm’s	Our recommendation

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

For a software firm whose product has run for years and been rebuilt or moved: start with an assessment of the product’s own code and the structure of its databases, taken from the code or from a structure-only export from the firm’s own team, never the data. Get a list of every store the code still writes to or reads from, and of those nothing uses any longer, and hand it to the firm’s own security people. Get a written account of what the code does with each kind of record once its purpose is served, and every copy it makes on the way, and hand it to the firm’s own people and lawyers to set beside the policy. Then, whenever a part of the product is rebuilt or a store replaced, give every old store a line in the traceability matrix, with who decided.

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

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	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; the policy describes the design	Every kind of record the code handles, with what the code does once its purpose is served	The written account in the specification, confirmed by the firm’s own people
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
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

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about your product, how long it has run, the moves and rebuilds it has been through, and what your own people believe it keeps. 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 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; and, for each kind of record, it gives a written account of what the code does once the record’s purpose is served, for your own people and lawyers to set beside your policy. 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.
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. 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.

8. What the Client Would Own

• The store list: every store the product’s code still writes to or reads from, with what uses each, and those nothing uses any longer, for its own security people.
• The written account: for each kind of record, what the code does once its purpose is served, and the copies it makes on the way, confirmed by its own people.
• The specification: what the product does, in writing, confirmed by its own experts.
• The risk register: each finding, ranked, ready for the firm’s own decisions.
• The cost comparison and the staged plan: keeping set beside replacing, and each stage with a fixed quote.
• The traceability matrix: for every part IOanyT rebuilds, each old store carried across or dropped on purpose, and who decided.
• The code: the rebuilt modules are the firm’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 carry out a security review of a product, its servers or its data stores.
• IOanyT does not close, lock, secure, empty, move or delete a data store, and does not migrate data. The firm’s own team carries out every decision.
• IOanyT does not look at, copy or handle the data in a store. It reads code and the structure of databases, taken from the code or from a structure-only export from the firm’s own team.
• IOanyT cannot say whether anyone has reached a store.
• The list covers the stores the code names. A copy made by hand, or a store whose code no longer exists, will not be on it.
• Reading code shows what the code would do. Whether a scheduled job really runs is confirmed by the firm’s own team.
• IOanyT does not judge whether a policy is met, says nothing about what any data protection rule requires, does not decide what must be kept or for how long, and offers no compliance, audit or legal service.
• Nothing in this approach keeps anyone’s records safe. This study does not say IOanyT would have changed anything for the app maker described, or that IOanyT has done this work for a software firm.

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
A law firm’s published article (cited without link)	The app maker, in general terms: data of one kind still held in an older store, which the account says appeared to contradict the firm’s policy
A vendor’s survey of 504 US IT professionals, 25 August 2025	Use of old systems; security vulnerabilities among the top challenges; reasons for not modernising

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. Here we read the code and write down what it names and what it does, and every decision about the data stays with your own people.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →