When you replace an ERP, you're ending a ten-year conversation between people and software. That conversation is messy, half-finished, and full of workarounds nobody ever wrote down. When the new system arrives, the conversation does not get to carry on - it has to be either restated, or abandoned.
The single most common mistake at this point is treating the legacy ERP as a database to be copied across. It isn't. It is a record of decisions, and the trick is to separate the decisions that matter from the historical noise around them.
The "frozen-in-time" mindset
The moment a legacy system goes read-only, the question "what was the actual cost rollup on this assembly?" stops being interesting. The number is the number. Nobody is going to argue about it now. If the BOM rollups are slightly wrong, they were slightly wrong for ten years and the business survived.
What does stay interesting is the shape of the data. The relationships between finished goods, the bills of material that built them, the routings that produced them, and the suppliers that fed them. A customer calling about a part number from 2017 doesn't care that the original system has been retired. They care that someone can still tell them what was in it, who supplied it, and how it was put together.
That four-way lookup — finished good to BOM to routings to supplier — is the survival case. Everything else is optional.
What "good enough" actually looks like
The businesses that handle this well share three habits.
The first is being ruthless about scope. The old system has hundreds of tables. The four-way lookup needs about a dozen, properly joined. The rest can be archived as raw exports for the auditors and otherwise forgotten. The temptation to "just bring it all across, in case" is real and is almost always wrong — the data has no warranty in the new world either way, and the new system has better things to do than be haunted by old tables.
The second is preserving the lookup pattern, not the schema. The old system probably had its own primary-key conventions, its own column names, its own idea of what an item master looked like. None of that is sacred. What matters is that the next time someone types in an old part number, the answer comes back — through whatever interface, against whatever lightweight target, with whatever joins make sense today.
The third (this is the one that catches people out) is to look into building a small reporting layer on the extracted data before decommissioning the source. Not a beautiful enterprise dashboard. A minimal Power BI report or equivalent that runs over the new home for the data and answers the survival questions. It is the only honest way to test that the extract is fit for purpose. Anything that survives the report works in the wild.
Why this matters before the cutover, not after
Most businesses treat the old ERP as something to be switched off and forgotten the moment the new one goes live. That is fine for the live data. It is not fine for the legacy queries that turn up six months later from a customer-service team or an external auditor, and finding out at that point that nobody can answer them is an expensive surprise.
The cheaper move is to do the four-way-lookup work in parallel with the new implementation, sign it off as part of cutover, and put it on a footing that does not depend on the old box still being powered on. A minimal hosted database, a thin reporting front end, a documented refresh pattern. None of that is technically hard. All of it is operationally invisible until the day you need it.
How I think about it
This is the unglamorous, low-drama work that gets forgotten in the louder ERP-implementation conversations. It is also the work that quietly separates a smooth go-live from a slow-burn embarrassment six months later.
When I help a business replace an ERP, the legacy-data conversation is one of the first ones we want to have, not the last. I ask which part numbers customers still ring up about. I ask which suppliers are still in scope for legacy product support. I ask which finished goods are still under warranty obligation. The lookup pattern falls out of that conversation in about an hour.
I then build the smallest thing that survives the cutover — a slim data home and a minimal report against it — and the project can get on with the new implementation knowing the old conversation isn't going to bite anyone in October.
The takeaway
Replacing an ERP is not a copy job. It is a decision about which conversations the old system was having that need to carry forward, and which conversations can quietly end.
Get the four-way lookup right. Build the smallest possible report against it. Decommission the old box. Then forget about it, properly.
