Before Old Figures Are Carried Into a New System, Know Where They Were Made.

The project plan for the new system has two hundred lines. Line one hundred and sixty-three reads: migrate stock and production data.

At the readiness meeting, the project manager reports that the data is ready: the record counts match. The head of operations asks what is in it. Everything that was in the old system.

Nobody in the room can say whether the units of measure are consistent, which bins show stock that is not there, or what the code “X” in the status field has meant since 2011.

What We Found

For this article we went through the public record on what a business can rely on when its systems change: a company’s own filing, a survey of manufacturers on what holds back their use of AI, and one survey on why firms keep old systems.

A new system can go live without the business being able to rely on what it shows. A large US food manufacturer moved to a new ERP system. Afterwards it reported that it could not see its finished stock at its warehouses, which cost it more than 100 million US dollars in sales in 2024. This is about stock that could not be seen, not data that was wrong. We take one narrow point: what a new system shows on its first day decides whether goods leave.

Firms hesitate over the data as much as the system. In one survey of about 500 IT professionals in the US, run by a firm that sells software services, about a third named concerns about moving data among their reasons for not replacing old systems. That survey covers every sector, not manufacturing alone.

Manufacturers name data ahead of old equipment. In one survey of manufacturers, run by an industry body, respondents picked their top three barriers to using AI. Problems with data came first, named by about six in ten; the need to upgrade old equipment was named by about a quarter.

Our reading is narrow. Data is usually planned as cargo: one line near the end of a plan, checked by counting records. Its figures were made by rules in the old programs, some of them wrong. Unless someone knows where each key figure was made, the faults travel with the data.

What Knowing the Figures Opens Up

Preparing data is usually the last task of a project. Our reading is that it is where a board can still change the plan.

• The plan gets an honest line for data. The cost of putting records right can be priced before the contract, not found after go-live.
• The new system is judged fairly. Its first weeks are not spent hunting for stock the screen says is there.
• A pilot is scoped on what the figures can bear. An AI project can be pointed at the figures known to be sound.

This is our reading. It is not a measured market figure.

Three Ways to Prepare Old Figures for a New System, Weighed

Option	When it fits	What it risks
Move the records as they are, and correct them after go-live	The old records are few, recent and well understood	Every fault arrives in the new system with a fresh date on it
Have the records cleaned by a specialist before the move	The faults are known and their causes fixed	If the old programs that made the faults stay in use beside the new system, the faults return
Trace the key figures to where they are made, rebuild the parts that make them wrong, and have your own staff correct the rest before the move	The old programs are much changed, and some stay in use beside the new system	It adds work before the project starts, and what it finds is usually unwelcome

Where You Are Now, and Where You Should Be

This is the benchmark we would set before the first module is rebuilt, and fill in as each module is accepted.

Measure	Typical starting point	Where it should be	How it is checked
Key stock and production figures	Known to be doubtful, not traced	Each traced from where it is entered to where it is reported	The specification
Rules that change a figure on its way	In the code and in people’s memory	Each written down: what it does, where it lives, what depends on it	The specification and the map of the system
Checks at the point of entry	An old screen accepts blanks, duplicates and impossible values	Each rebuilt part refuses an entry that cannot be right, with the checks written down	The specification and the traceability matrix, for modules we rebuild
Places where the old data cannot be relied on	Found after go-live	Listed before any move, for the business to decide	The risk register
Disagreement between screen and rack on key parts	Noticed, never kept	Measured by your own staff on a sample they choose, before and after each part is rebuilt	Your staff’s own count, reported at every review

The starting points above are what we expect to find. In an engagement they are replaced by your own position, 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 manufacturer.

Two lines need a word. The traceability matrix shows that each old function has its replacement, not that every record is right, so disagreement between screen and rack is counted by your own staff. And the list of where the old data cannot be relied on is drawn from the rules that wrote it, not from your records: we do not examine or measure them.

A small part of the filled-in benchmark might look like this.

Figure	Where it is made	What cannot be relied on	Decision, by your own people
Stock of a bought-in component	Goods receipt screen, converting kilos to metres	One conversion figure set years ago, used for every receipt	Rebuilt receipt screen checks the conversion; stores staff recount the part before the move
Status “X” on a stock line	An old adjustment program	Set for two meanings since 2011	The business chooses one meaning; the stores team corrects the lines that carry the other

The rows above are an illustration, not taken from a real firm.

How We Work With You, and What You Are Left With

1. We listen: a free Reliability Review. A first conversation about the move ahead and the figures nobody trusts. 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.
3. We read the system and propose: the Legacy System Specification Assessment. Here the system is the stock, production and dispatch programs you built or had built beside your ERP, whose figures are about to be carried across. It produces 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. We replace a system one module at a time while the old one keeps running. We never do a single cutover. A traceability matrix links every 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 above. As each module is accepted 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 has a price. It adds cost before the project starts, and your own people must decide about each weakness and correct the records. A specification corrects nothing: the cleaning is still to be done, by your people or by whoever moves the data. We have no data cleaning, reconciling or migration service, and we do not count stock. Where a figure is made inside a packaged ERP product, we cannot see it, and our account stops at its edge. Errors made on the floor are not caused by software and are not cured by it, so a count before the move will still be needed. We promise nothing about what an AI tool will find. We have no published case of this work for a manufacturer.

At the end you hold the specification, the traceability matrix for every module we rebuilt, and a filled-in benchmark that shows where each key figure is made, what was rebuilt, and what your people decided about the rest.

What changes for the business:

Role	What they gain
CEO	A replacement or an AI project is approved knowing what figures it will start with.
CTO or CIO	A written account of where each key figure is made, for whoever plans the move.
CFO	The cost of putting the records right is in the plan before the contract is signed.
COO	The first weeks on a new system are not spent hunting for stock the screen says is there.
Head of digital	An AI pilot is scoped on what the figures can bear, and not on what was hoped.

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

The case	What IOanyT does
After its move to a new ERP system, a large US food manufacturer reported that it could not see its finished stock at its warehouses, which cost it more than 100 million US dollars in sales in 2024.	Our part is far narrower: we do not install packaged ERP products or migrate data, and draw no cause from the record. For a manufacturer’s own programs, we write down where each key figure is made before a move, and rebuild the parts that make it wrong.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We would rather know where a figure was made before it is carried across than learn it in the first week on a new system.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →