Decide what you are actually replacing
Operations rarely run one system. They run an accounting package, a spreadsheet that holds the real stock picture, a shared drive of certificates, and a set of habits that exist because none of those talk to each other.
Before choosing anything, write down which of those a new system will absorb and which it will not. The migrations that go badly are usually the ones where that boundary was assumed rather than agreed, and it surfaces during training as an argument.
Master data first, and expect it to be worse than you think
Items, units of measure, suppliers, customers, recipes. This is the least interesting part of a migration and the one that most reliably determines its outcome.
Assume your existing data has duplicates, inconsistent units, items nobody has bought in four years, and recipes that no longer match what the floor actually does. Finding that out during cleansing is normal. Finding it out after go-live is expensive.
- Deduplicate items and suppliers before mapping anything
- Fix units of measure and conversions - these cause silent errors rather than loud ones
- Confirm recipes against current practice, not against the document
- Decide explicitly which historical records migrate and which stay readable in the old system
Opening balances are the moment of truth
At some point you must state what you hold: which lots, in what quantity, in which locations, with which expiry dates. For batch manufacturers this is harder than a simple stock count, because identity matters as much as quantity.
If lot identity is not currently tracked, this is where it starts, and the practical consequence is that you begin with a partial genealogy. That is acceptable and normal - but it should be a decision that is understood, not a surprise discovered during the first trace.
Sequence by process, not by module
A common failure is going live module by module - inventory this month, purchasing next. It sounds prudent and it splits the one thing that must stay whole: a transaction that spans receiving, stock, and cost.
Sequencing by process works better. Get receiving through to stock correct first, because everything downstream depends on it. Then production. Then fulfilment. Each step is testable end to end rather than half-finished in three places.
Run in parallel briefly, but set an end date
A short parallel period builds confidence and catches mapping errors. An open-ended one is corrosive: staff keep the old system as the real one, the new data drifts, and the migration never actually completes.
Set a date at the outset for when the old system becomes read-only, and hold it unless something genuinely blocking emerges.
Train on your own data
Training on demo data teaches people the software. Training on their own items, suppliers, and recipes teaches them their job in the new system, which is a different and more useful thing.
It also surfaces data problems while there is still time - a warehouse operator will spot a wrong unit of measure on a familiar item faster than any validation script.