A

Their IT team wanted to finish in four months. The CFO wanted to start with finance, because CFOs always want to start with finance. It's the most visible, the numbers matter most, and if reporting breaks, everyone notices immediately.

They migrated finance first. They ran parallel systems for three months. The reconciliation was brutal. Numbers didn't match, and nobody could figure out why, because inventory transactions from the old system were still flowing and the new system was trying to reflect them in real time. The accounting team worked weekends for most of the quarter.

There's a better sequence. It takes longer in calendar time but costs less in pain.

Why ERP Migrations Usually Go Wrong

Most factory ERP migrations fail not because the software is bad, but because the sequence is wrong.

The instinct is to start with what matters most to the people with authority. Finance matters most to the CFO. So finance goes first. This is backwards.

Finance is downstream of everything else. Financial records in an ERP are produced by inventory movements, production orders, purchase receipts, and sales invoices. If those upstream processes are still running in the old system while the new system is trying to record the financial implications, you get discrepancies. Two systems, one set of transactions, no clean way to reconcile them.

Inventory is the right starting point. It's upstream of everything. It's also the easiest to validate: count the stock, enter the counts into the new system, verify they match. Simple enough to check, consequential enough to matter, but isolated enough that mistakes don't cascade into financial reporting.

The Migration Sequence That Works

The approach is borrowed from software architecture: the Strangler Fig pattern. Replace the old system module by module, running old and new in parallel at each stage until the new one is trusted, then cut over. Never migrate everything at once. The same principle that applies to software rewrites applies here — [→ How to Rewrite Your Software System Without Stopping Your Business] covers that side of it in detail.

For a manufacturing factory, the sequence runs roughly like this:

Phase 1, months 1-2: Item master data and inventory. Import the product catalogue, set up warehouses and storage locations, enter opening stock counts. Run the new system for inventory lookups only. The old system still handles everything else. Validate the counts. Fix the discrepancies. When inventory in the new system matches physical counts reliably, move on.

Phase 2, months 3-4: Purchase orders and goods receipts. Raise new purchase orders in the new system. Receive goods in the new system. The old system still handles invoices and payments. You'll be entering some data twice, but the double-entry is limited to the PO-to-receipt workflow. After a month of clean purchase data, the team builds real confidence in the new system's accuracy.

Phase 3, months 5-6: Production orders, work orders, and bill of materials. This is the core manufacturing module and the most complex phase. Run production orders in the new system while keeping the old system as a reference. Validate output quantities, scrap rates, and labour hours against historical data from the old system for four weeks before cutting over. If the numbers don't agree, find out why before moving on.

Phase 4, month 7: Accounting cutover. This is the only phase where timing is a hard constraint. Cut over at the end of a fiscal quarter, ideally at fiscal year-end. Never mid-month, never mid-quarter. The opening balance in the new system is pulled from the old system at the cutover date. If the upstream modules are clean, the accounting data is clean. The parallel running period for finance drops from months to weeks.

Phase 5, month 8+: Old system decommission. Keep read-only access for 90 days for historical lookups. Then shut it down.

The Part Everyone Gets Wrong

Finance first. Every time.

The CFO's logic is understandable. Finance is measurable. If a purchase order sits in the wrong system, operations notices but management doesn't. If the trial balance is wrong, everyone notices.

But the trial balance is only wrong because inventory and production are wrong. Fix those first and the finance cutover becomes clean. Skip that step and you get three months of the accounting team reconciling two systems that are both receiving live transaction data. That's the version that produces spreadsheets nobody trusts and weekend work nobody wanted.

The other thing factories consistently get wrong is migrating their customisations without first asking whether they still need them.

Every factory's ERP has customisations built for problems that no longer exist. A report required by a client who stopped ordering four years ago. An approval workflow built for a manager who left in 2019. These don't need to migrate. They need to die. But nobody has looked at them since they were built, so they all go into migration scope by default, adding weeks to the timeline and cost to the budget.

Do a customisation audit before migration planning starts. For each one, ask: if we were building this system fresh today, would we build this? If the answer is no, cut it.

What Running Parallel Actually Means

Running parallel doesn't mean operating two full ERP systems simultaneously for all business processes. That's the version that burns out accounting teams.

It means running the new system as the primary system for one module while keeping the old system available as a reference. The parallel period for each module should be four to six weeks, not months. After that, the old system is reference-only for that module, and the team moves to the next phase.

The metric to track during each parallel phase is exception rate: how often does a transaction in the new system produce a different result than the old system for the same input. Target below 1% before cutting over each module. If exceptions are higher, find the root cause before moving on.

A clean parallel phase is boring. The numbers match, the team stops checking both systems obsessively, the new one becomes trusted. That boredom is the goal.

When Big-Bang Goes Wrong

Imagine a plastics manufacturer in MM2100 that tried a big-bang cutover. They went live on a Monday. By Wednesday, the production floor couldn't issue materials to work orders because the BOM structure had been mapped incorrectly during migration. By Friday, the operations manager was calling the old system vendor to ask about reactivating their subscription.

A phased approach would have caught that BOM mapping problem in Phase 3. The big-bang approach had no Phase 3.

Big-bang cutovers work when the new ERP is close enough to the old one that data mapping is clean and the team is already familiar with the new interface. That describes a version upgrade. For a factory moving from one ERP to a completely different platform, big-bang concentrates all the risk into a single weekend. If anything is wrong — and something usually is — you have no fallback position that doesn't involve going backwards.

A 6-month phased migration costs more in project management hours than a big-bang cutover. That's true. It also has a dramatically higher success rate. The extra cost is an insurance premium, and it's a cheap one compared to what a failed cutover costs in lost production time and emergency consulting fees.

FAQ

Q: We're on Excel and WhatsApp, not an ERP. Does the phased approach still apply?

A: Yes, and it's even more important. Moving from Excel to a formal ERP means no clean master data, no transaction history to validate against, and a team unfamiliar with formal system workflows. Run the new ERP in parallel with whatever you're currently doing for the first two modules. Don't try to go live on everything simultaneously.

Q: How long does a 200-person factory realistically take to fully migrate?

A: With a phased approach, 8-10 months is realistic for a full migration including a clean accounting cutover at quarter-end. Factories that claim to finish in 3 months either have very simple operations or haven't actually finished when they say they have.

Q: What data absolutely has to be clean before we start?

A: Item master data. Every SKU, every unit of measure, every storage unit, every BOM component. If the item master is messy, nothing downstream will be clean. Plan 4-6 weeks for item master cleanup before any migration work starts.

Q: Who should own the migration project internally?

A: Not IT alone. The project needs a business owner from operations or finance who has authority to make decisions and resolve conflicts between what the new system does and what the factory is used to doing. Without a business owner, migrations stall on decisions that IT can't make.

Q: What happens if we discover mid-migration that the new ERP can't handle something our old system did?

A: Stop, scope the gap, decide. Either the new system needs customisation (adds cost and time), you change the business process to fit the new system (often the better answer), or you reconsider the ERP choice entirely. Finding this in month 2 is painful. Finding it in month 7 after accounting has already cut over is much worse.

The factories that migrate ERP successfully aren't the ones with the best software. They're the ones that did the sequence right, validated before cutting over each module, and said no to migrating customisations they no longer needed.

Inventory first. Finance last. The principle is the same one that applies to any major system rewrite: migrate at the edges before touching the core.

If your factory is evaluating an ERP migration and the vendor's implementation plan shows finance in the first three months, ask them to walk you through the logic. What they say next will tell you something important about whether they've actually done this before.