The Manufacturing ERP Migration Guide

Nobody migrates off a working ERP for fun. By the time a manufacturer is seriously planning a migration, the old system has usually earned the decision: the vendor sunset the version, the customizations nobody understands anymore break with every patch, or the plant has outgrown a package bought when the company was a third its size. The migration itself, though, is where good decisions get expensive. The new software is rarely what fails; what fails is the move - the data that arrives dirty, the cutover nobody validated, the six spreadsheets that quietly kept the old system honest and got left behind. This guide covers the decisions that determine whether a migration lands: what to bring, how to clean it, how to run the transition, and how to avoid the failure modes that recur across shops of every size.

Decide what you are actually migrating

The first real decision is scope, and the useful cut is between three kinds of data that deserve three different answers.

Master data comes with you, cleaned. Items, bills of material, routings, work centers, customers, suppliers, pricing. This is the data the new system runs on, and it must be migrated - but “migrated” should mean rebuilt to current reality, not copied. More on cleaning below.

Transaction history mostly should not. Every closed sales order since 2011, every material issue against every long-shipped job - loading it all into the new system is a common instinct and usually a mistake. Old transactions carry the old system’s structures and codes; forcing them into the new data model is expensive translation work that produces records nobody trusts. The standard pattern is to migrate open transactions only - open orders, open POs, open work orders, current inventory balances, open AR and AP - and preserve history in a read-only archive of the legacy system or a queryable snapshot. You need history for reference and analysis; you do not need it living inside your new transactional tables.

Compliance records get special handling. Here the archive answer is not enough on its own. Quality records, device history, lot and serial genealogy, signed inspection results, and calibration histories may carry retention obligations measured in decades, and for regulated work they must remain producible on demand. An aerospace supplier asked to trace a fielded part cannot answer “that was two ERPs ago.” Decide explicitly, record by record type, whether compliance data migrates into the new system’s quality module, moves to a validated archive, or both - and document the decision, because an auditor will eventually ask where the records went and why.

Clean the data before it moves, not after

Legacy ERPs accumulate sediment: duplicate part numbers with slightly different descriptions, BOMs that no longer match how the part is actually built, routings with setup times last touched by an engineer who retired, suppliers that went out of business, and item masters full of one-time specials that will never be ordered again. Migrating that sediment does not preserve it - it activates it. The new system will plan, purchase, and schedule off whatever you load, and dirty inputs produce confident, wrong outputs from day one.

Cleaning is unglamorous and it is where migration quality is actually determined. Deduplicate the item master and kill the dead records. Walk the BOMs for your active parts against how the floor really builds them. Reconcile inventory balances with a physical count before extraction, because migrating a known-wrong quantity guarantees the new system starts life untrusted - and starting with accurate counts is half the battle for inventory accuracy afterward. Assign owners by domain: engineering owns BOMs and routings, purchasing owns suppliers, quality owns specifications. A migration where “IT is handling the data” is a migration where nobody who understands the data is handling it.

One warning from experience: cleaning always takes longer than the plan says, because every dirty record is a small decision and there are thousands of them. Start it before you finish selecting the new system if you can. Nothing about a clean item master is vendor-specific, and it is the one migration task with zero risk of being wasted effort.

Parallel run: valuable, expensive, and worth scoping tightly

A parallel run - operating the old and new systems simultaneously and comparing outputs - is the classic risk control, and it has a real cost that plans routinely underestimate: every transaction entered twice, by people who already had full-time jobs. A full-plant parallel run of any length tends to collapse under its own weight, with the second system getting half-hearted entries that make the comparison meaningless.

The workable version is a targeted parallel: pick the flows where an error is expensive - order entry through invoicing, payroll-adjacent finance, inventory transactions on your highest-value materials - and run those in both systems for a defined, short window with named people responsible for the daily reconciliation. Everything else gets validated by conference-room pilot instead: structured test scripts running your real orders, real BOMs, and real month-end close through the new system before go-live. A pilot with your ten hardest jobs teaches you more than a month of unfocused double entry.

Cutover: validate like it is an audit, because it will be

Cutover weekend is a checklist exercise, and the checklist should be written weeks earlier. Freeze changes in the legacy system, extract final balances, load, and then validate before anyone transacts: trial balance ties to the penny, open order counts and values match, inventory quantities match the final count, open PO and AR/AP detail reconcile line by line. Set explicit acceptance thresholds in advance and a named person who signs each one, because “it looks close enough” at 11pm on Sunday is how week-one chaos gets approved. Just as important, agree on the rollback condition before you start - the specific findings that would send you back to the old system for another cycle. Teams that define abort criteria almost never need them; teams that refuse to discuss rollback are the ones who end up improvising one.

Plan the first two weeks after go-live as part of the cutover, not as the return to normal. Floor support at the points of entry, a daily triage of discrepancies, and fast fixes to the master data errors that only production can reveal - this is where a migration is won. A structured implementation process treats validated go-live as a phase with its own exit criteria, not a date on a Gantt chart; Cortrova’s five-phase approach, for example, puts data migration and validation ahead of go-live explicitly, and most manufacturers complete the full deployment in a typical 4-8 week window because the validation work is front-loaded rather than discovered late.

Preserve traceability across the seam

The subtlest migration risk is the break in the chain of custody. On Friday a lot’s genealogy lives in the old system; on Monday its remaining quantity lives in the new one. If nobody planned the seam, traceability now requires knowing which system to ask - and in five years, nobody will. Carry forward the linkage deliberately: migrate open lots and serials with their upstream references (material certs, heat lots, source POs) attached or cross-referenced, keep the legacy archive queryable and access-controlled, and record the cutover date and mapping rules in your controlled documents so the answer to “where is the history for this part?” is written down rather than remembered. Regulated shops should treat the archive itself as a controlled system: retained, backed up, and readable for the full retention period, which may outlive the file formats if nobody checks.

Retire the shadow systems on purpose

Around every legacy ERP grows a ring of spreadsheets that exist because the old system could not do something: the scheduling spreadsheet, the quote log, the expedite list, the quality tracker with the real NCR statuses. A migration that ignores them replaces the ERP and keeps the shadow systems, which means it keeps the old failure modes. Inventory the spreadsheets honestly - ask each department what they maintain by hand and why - and treat each one as a requirement: either the new system covers the need and the spreadsheet is retired on a named date, or it does not and you should know that before selection is final, not after. This inventory is also one of the best selection inputs you will ever produce, which is why our ERP buyer’s guide recommends building it early, and the implementation checklist includes shadow-system retirement as an explicit workstream.

The failure modes, named

Migrations fail in patterns. Migrating everything - hauling fifteen years of transactions into the new system and spending the budget on translation instead of cleaning. Cleaning nothing - loading the sediment and losing the floor’s trust in week one. The unscoped parallel run - double entry everywhere, reconciliation nowhere. Cutover by optimism - no acceptance thresholds, no rollback plan, no named owners. The orphaned archive - legacy history switched off with the server, discovered missing during an audit. The surviving spreadsheets - a new ERP wrapped in the old workarounds. Every one of these is avoidable, and every one is avoided the same way: by making the decision explicitly, early, with the person who owns the consequence in the room.

A migration done this way is still work. But it is bounded, inspectable work - and it ends with something the old system could no longer give you: a single system the whole plant actually believes.