Migrating factory data: item master, bills, routings and open orders

The item master is the genuine critical path

Everything else references it, so nothing else can be finished until it is. Expect duplicates created by different naming habits, parts that have not moved for years but cannot be deleted because history references them, missing units of measure, planning parameters that were never populated, and descriptions that only make sense to one retired storeman. The cleanse cannot be outsourced, because deciding whether two entries are the same part requires knowledge that exists only in the plant. Start it before the software is chosen, because it is valuable regardless of which system wins.

Bills and routings: structure or fiction

Bills usually migrate reasonably because someone maintains them. Routings are the ones that describe a factory that no longer exists: operations on machines that were sold, times set for a previous material, sequences that ignore a cell reorganisation. Re-timing everything is unaffordable, so the realistic choice is to migrate as they stand, fix the routings carrying most volume before cutover, and accept a correction programme afterwards driven by comparing booked time against routed time. Pretending they are accurate is what turns a scheduling module into an expensive ornament.

Open transactions are what makes cutover hard

Static data can be loaded and checked at leisure. Open purchase orders with partial receipts, works orders halfway through a routing, material in transit between sites, subcontract stock at a supplier and unshipped customer backlog all have to move in a state both systems agree on. For each category decide whether to close and re-enter, migrate in place, or run out in the old system. Closing and re-entering is cleaner and adds work at the worst possible moment; migrating mid-operation work in progress is where the most painful surprises live.

What you can legitimately leave behind

Transaction history is the usual argument. Migrating years of movements inflates cost and risk, and the value is nearly always reporting comparability rather than operational need. Keeping the legacy system readable, or extracting history into a queryable archive, satisfies most retention and audit obligations at a fraction of the effort. Superseded document revisions, closed orders, obsolete items with no stock and no open commitment, and long-inactive supplier records can generally stay behind. Decide against a written retention requirement rather than against the instinct to bring everything.

Proving the cutover before anyone transacts

Reconciliation is a defined activity with a sign-off, not a feeling that the load looked fine. Compare stock quantity and value by location and by item class, open purchase commitment, customer backlog value and work in progress, between the two systems, on the same frozen point. Then run a small set of complete transactions end to end in the new system — receive, issue, complete, ship, invoice — and confirm the accounting entries land where finance expects. Whoever signs the reconciliation should be the person who will later be asked why the accounts moved.

Frequently asked questions

How clean does the data have to be before we migrate?

Clean enough that a wrong record causes a visible failure rather than a plausible one. Duplicated items, missing conversions and absent planning parameters all produce output that looks credible and is wrong, which is far more damaging than a load that rejects. Prioritise by consequence: items with stock or open commitment, bills for products currently sold, routings on work centres that constrain the plant. Dormant records can migrate untouched or stay behind entirely.

Should we bring transaction history across?

Rarely, and almost never for the reason given. The stated need is usually comparative reporting, which an extract or a read-only legacy environment satisfies without dragging historical structures into a new data model. Migrated history also inherits the old system's assumptions about cost, structure and coding, so the comparisons it enables are less reliable than they appear. Bring balances and open items; leave movements behind unless a retention obligation specifically requires them to be live.

Who should sign off that the migration worked?

The people who will be held responsible for the numbers afterwards: the finance controller for balances and valuation, the inventory owner for stock by location, the purchasing lead for open commitment, the sales lead for backlog. A project manager's sign-off means little, because they leave. Make the reconciliation a document with named signatories and a stated point in time, since disputes about what the balances were on cutover day surface months later and are otherwise unresolvable.