Contents
Short answer
When an ERP start-up goes badly, the software is rarely the cause; the migrated data is. The article gives the migration order (items, third parties, bills of materials and routings, work centres, prices, open items), advises migrating only what moved over twenty-four months, deduplicating before import, physically counting stock and rehearsing the migration at least three times before cut-over.
When an ERP go-live goes badly, the software is rarely to blame. In the vast majority of cases, it is the migrated data that causes the trouble: duplicate items, obsolete bills of materials, theoretical stock far from reality. An ERP does not clean up bad data — it spreads it faster.
What you migrate, and in what order
Migration follows a hierarchy of dependencies. You cannot import a bill of materials without items, nor a work order without a routing:
- Item master: codes, descriptions, units, families.
- Third parties: customers, suppliers, delivery addresses, payment terms.
- Bills of materials and routings: composition and manufacturing operations.
- Work centres and resources: machines, teams, capacities.
- Prices and commercial terms.
- Open items: open orders, jobs in progress, stock.
The “migrate everything” trap
Thirty years of history contain thousands of items never ordered in ten years, vanished customers and bills of materials for discontinued products. Importing them carries into the new system the clutter that made the old one painful.
Set a simple, deliberate rule: migrate only the items with movements in the last twenty-four months, and the third parties with at least one transaction over the same period. The rest goes to a consultable archive, not the active master.
Duplicates, the silent enemy
“VIS M6X20”, “Vis M6x20”, “VIS-M6-20”: three codes for one and the same item, three partial stocks, three purchase prices. Requirements planning will order three times. Handle de-duplication before the import, in a spreadsheet if need be: it is tedious, but infinitely less costly than after go-live, once movements have piled up on each of the three codes.
Physically count the stock
The gap between the old system's theoretical stock and the reality on the shelves commonly reaches ten to thirty percent. Migrating the theoretical figure means starting with wrong net requirements on day one, and ruining users' trust in the new tool within a week. A full physical count at the switchover is not optional.
Rehearse the migration, at least three times
A migration that succeeds on the first try does not exist. Plan three passes:
- Dry run #1: catch invalid formats, missing mandatory fields, forbidden codes.
- Dry run #2: check business consistency — does a bill of materials point to existing items, do routings point to valid work centres?
- Switchover: on the day, with a set of numeric checks prepared in advance.
The checks to prepare before the switchover
Define in advance about ten figures to compare between old and new systems: number of active items, total stock value, number of open orders, order book amount, number of bills of materials. If a gap appears, it must be explained line by line before opening the system to users.
Who does the work
The vendor provides the import tools and the validation rules. Deciding what counts as correct data belongs to the company, and to it alone: no one else knows whether two codes designate the same part. Assign a named owner per domain — items, third parties, engineering — with time genuinely freed up.