How to Cut Over a Legacy ERP Without Freezing Operations

For: COO at a mid-market manufacturing or distribution company whose team runs daily operations through a 10-year-old ERP — orders, inventory, invoicing — and has just been told by IT that the new system go-live is in six weeks, with no credible answer for what happens to in-flight purchase orders, open invoices, and warehouse picks during the switchover window

The safest way to cut over a live ERP is to declare a hard system of record at every stage of the timeline — never let two systems own the same transaction at the same time. If your six-week plan doesn't specify, per hour, which system authoritatively writes purchase orders, GRNs, invoices, and stock movements, you don't have a cutover plan. You have a hope. This playbook is for the COO whose IT team just handed over a go-live date with vague answers about the parallel run.

The non-obvious part: the cutover weekend itself is rarely where go-lives break. What breaks them is the 72-hour dual-write window that precedes it, where both systems accept transactions and neither is the declared truth. The reconciliation debt you accumulate there is what surfaces on Monday morning as missing stock, duplicate invoices, and picks against phantom inventory.

When this playbook applies

You're a mid-market manufacturer or distributor. Your existing ERP — SAP ECC, Dynamics NAV/GP, Infor, Sage, or a heavily customized Oracle EBS — has been running your operations for a decade. You have open POs with suppliers, unshipped sales orders, WIP on the floor, warehouse picks against live stock, and an AR ledger with partially applied receipts. You cannot close the business for a weekend. You cannot stop invoicing. Customers are calling for order status the moment go-live starts.

If any of that matches, the following seven steps are the sequence I'd run.

Step 1: Freeze the transaction taxonomy before you touch data

Before anyone talks about data migration scripts, you need a single, signed-off document that lists every transaction type your business runs and classifies each one into a cutover bucket. Not fields. Not tables. Transactions — the verbs your business actually performs.

For each transaction (Create PO, Receive Goods, Issue to Production, Pick, Pack, Ship, Invoice, Receipt Application, Credit Note, Inventory Adjustment, Journal Entry, etc.), you classify it as:

• Complete-in-old: any instance opened before cutover T-72h must be closed in the legacy system. No exceptions.
• Redirect-at-T0: from cutover moment forward, all new instances open in the new system.
• Dual-track: cannot be cleanly split — needs a specific handling protocol (usually multi-day picks, partial shipments, and long-cycle production orders).

The dual-track bucket is where most ERP go-lives quietly die. It's usually smaller than people think — maybe 8-15% of transaction volume — but it's operationally 80% of the pain. Get your operations lead, warehouse manager, and controller in one room and force a decision on each dual-track item: does it complete in old, or migrate mid-flight?

Anti-pattern: letting IT write this document. They will classify by module (Finance, Inventory, Sales). Operations classify by transaction. You need the operations view.

You'll know this step is done when your warehouse supervisor can point at any live pick ticket and tell you, without asking IT, which system will invoice against it.

Step 2: Establish the T-72 freeze — but only for the transactions that need it

The blanket "code freeze" concept from software deployment doesn't map to ERP. You cannot freeze order intake for 72 hours. You can freeze specific transaction types selectively.

Working backward from go-live (T0), publish a freeze schedule to the whole company:

• T-14 days: Freeze master data changes in legacy — no new SKUs, no new customer/vendor records, no new BOMs. New master data goes into the new ERP staging area only.
• T-72h: Freeze long-cycle transactions — no new production orders spanning cutover, no new POs with delivery dates past T0, no new blanket sales agreements.
• T-24h: Freeze financial period-close activities — no manual journals, no revaluations, no depreciation runs.
• T-4h: Freeze all remaining transactions. Legacy is read-only from this point.

Short-cycle transactions (single-day picks, cash sales, walk-in receipts) can continue in legacy up to T-4h. This is the part most cutover plans get wrong — they overfreeze, which crushes the last week of the month's revenue, or they underfreeze and end up with production orders that started in one system and need to close in another.

Anti-pattern: announcing the freeze internally only. Your suppliers and top 20 customers need to know. If a supplier ships against a PO on T-1 and the GRN gets stuck between systems, that's inbound stock you cannot pick against on Monday.

You'll know this step is done when each department head has signed off on the freeze calendar and communicated it to their external counterparties in writing.

Step 3: Kill the parallel run fantasy — run a shadow instead

Here's the counterintuitive part. Traditional advice says run both ERPs in parallel for a week and reconcile daily. Don't. Parallel runs in a live-transaction environment produce two divergent truths, and every hour they diverge, the reconciliation gets harder. By day three, no one can tell you what the real inventory position is.

Instead, run a shadow. Legacy remains the sole system of record until T0. The new ERP receives a one-way replicated feed of every transaction posted in legacy during the T-72h window, transformed into new-ERP format, posted automatically. Nobody keys into the new system during shadow. Nobody uses it as a source of truth. It is a validation harness.

What you're validating: does every legacy transaction land correctly in the new schema? Do balances reconcile at the end of each shadow day? If a shadow post fails, you catch the mapping bug 72 hours before go-live, not 72 hours after.

This requires a real data pipeline, not a nightly CSV export. In our experience integrating live operational systems — the kind of work we do on legacy modernization engagements — the shadow feed is usually built as a change-data-capture layer on the legacy database plus a transformation service that maps to the new ERP's API. If your integrator is proposing manual daily exports during parallel run, push back hard.

Anti-pattern: letting operations users "try out" the new system during shadow. The moment someone keys a real transaction into it, you've created a divergence you cannot recover from without a full rollback.

You'll know this step is done when three consecutive shadow days close with zero unreconciled transactions and every general ledger control account matches to the cent.

Step 4: Pre-stage the in-flight transaction snapshot

At T-4h, when legacy goes read-only, you take the snapshot that defines opening balances in the new system. This is not a data migration — that happened weeks ago in your test cycles. This is the delta snapshot: every transaction that changed state between the last full test migration and the freeze moment.

Specifically, you export:

• Open POs with quantity received vs. quantity outstanding per line
• Open sales orders with pick/pack/ship status per line
• WIP by production order with materials issued and operations completed
• On-hand inventory by SKU by bin location (down to the physical bin, not the warehouse)
• AR aging with partial receipts applied
• AP with matched but unpaid invoices
• GL trial balance

Two people from operations physically walk the warehouse during this window and spot-check bin counts against the snapshot. Every ERP cutover I've seen has at least one "but the system says…" moment on go-live morning where the physical count doesn't match. Catch it now, adjust in the snapshot, don't inherit the discrepancy.

Anti-pattern: trusting perpetual inventory. If your legacy system's cycle-count discipline has been slipping for the last decade, this is the moment it bites you.

You'll know this step is done when the snapshot is loaded into new ERP, opening balances match legacy trial balance exactly, and a random sample of 30 bins physically match the migrated stock.

Step 5: The switchover — sequence matters

The actual T0 switchover is the least interesting part if steps 1-4 were done right. But sequence within the switchover window still matters. Bring systems live in this order:

1. Master data lookup services (SKU, customer, vendor, BOM). These are read-only until step 3 below.
2. Inventory system with opening balances loaded. Warehouse can now query stock positions.
3. Transactional modules in order: Receiving → Picking → Shipping → Invoicing → Cash Application → GL.
4. Integrations: EDI feeds to customers, portal integrations, shipping carrier APIs, bank feeds. Bring these up last, one at a time, with a human watching each.

Why this order? Because a warehouse worker showing up Monday morning needs to be able to look up a SKU and see stock before they can do anything else. If lookup works but posting doesn't, they can at least tell a customer whether stock exists. If posting works but lookup is broken, the entire warehouse stops.

Anti-pattern: big-bang activation where every module comes up simultaneously and the first error cascades through six systems before anyone can isolate it.

You'll know this step is done when a designated pilot user in each department has successfully posted one real transaction end-to-end and the GL reflects it correctly.

Step 6: Staff a hypercare war room, not a helpdesk

For the first 10 business days post-go-live, you need a physical (or virtual, but always-on) room with: one senior operations person per major function, one integration engineer, one finance controller, and one decision-maker with authority to override process. Not a ticket queue. A room.

The reason: the issues that surface in the first two weeks are almost never single-system bugs. They're process-and-data intersections. "The invoice printed but the customer's PO number is missing" is a five-person conversation, not a ticket. Ticketing systems serialize what needs to be parallelized.

Track two metrics only, in a shared view visible to everyone:

• Transaction backlog: unposted transactions, unreleased picks, unmatched receipts. Should trend to zero within 5 business days.
• Exception rate: percentage of transactions requiring manual intervention. Should be under 3% by day 10.

If either metric flatlines instead of trending down, you have a systemic problem, not a training problem, and you need to escalate to a rollback decision by day 7.

Anti-pattern: declaring victory at day 3 because "orders are flowing." Orders flowing doesn't mean the money flows correctly. Watch AR aging and inventory accuracy — those lag by a week or two and are where quiet failures compound.

You'll know this step is done when exception rate is stable under 3%, backlog is zero, and finance has closed the first post-go-live period on the new system.

Step 7: Decommission on a written trigger, not a calendar date

Keep legacy in read-only mode for at least one full financial close cycle after go-live. But do not set a decommission date in advance. Set a decommission trigger: legacy gets shut down when (a) two consecutive month-ends have closed cleanly in new ERP, (b) exception rate has been under 1% for 30 days, and (c) no operational team has needed to query legacy for reference data in 14 days.

The reason to keep it read-only: audit trail, historical lookups, disputed customer invoices that reference legacy PO numbers, tax authority queries. Kill it too early and every disputed invoice becomes a research project.

You'll know this step is done when your controller signs off that legacy access is no longer needed for close, audit, or customer/vendor dispute resolution.

Failure modes I've seen

A few patterns worth naming because they're the ones that don't show up in vendor methodology decks:

• The half-picked pallet. Warehouse starts a pick in legacy on Friday, doesn't finish it, and Monday morning the pick doesn't exist in new ERP because migration logic only moved "open" or "complete" orders — not "in-progress." Rule: every transaction has to be forced into a binary state before snapshot. Partial states get either completed or reversed. No exceptions.
• The disappearing serial number. Serialized inventory (medical devices, high-value electronics, regulated goods) often lives in a bolt-on module. Migration teams focus on the main ERP tables and miss the serial registry. You go live and can ship stock but cannot record which serial went to which customer, which breaks recall traceability.
• The unmapped tax code. Legacy has 40 tax codes accumulated over a decade. New ERP has 12 cleaner ones. Mapping table has 38 entries. Two obscure codes used quarterly by one customer segment get missed and their invoices post with 0% tax for three weeks before anyone notices.
• The EDI silence. Large customers send POs via EDI. On go-live, the EDI endpoint switches to new ERP but the acknowledgment format differs by one field. Customer's system rejects the ack, stops sending POs, and nobody notices until orders drop 40% mid-week.
• The reconciliation debt from parallel run. Which is why we don't do parallel runs. See step 3.

How CodeNicely can help

Most of what makes an ERP cutover succeed or fail is not the target system — it's the integration, data, and process work around it. This is where we spend our time. On the Vahak engagement, we rebuilt the core operational platform for a logistics marketplace that could not go dark — trucks, loads, and payments were in flight continuously. The shadow-feed pattern and staged switchover approach in this playbook comes directly from that kind of work: replacing a running system without pausing the business it supports.

If you're mid-cutover and your integrator hasn't answered the questions in step 1 with specificity, or if you need an independent second opinion on your parallel-run plan before you're 72 hours out, that's the conversation to have. We're not an ERP reseller — we don't push you toward any particular target platform. We build the integration, data migration, and cutover orchestration layer that makes whichever ERP you've chosen actually go live cleanly. See our digital transformation practice for how we approach legacy modernization end-to-end.

Closing thought

ERP cutovers fail on operational discipline, not technology choice. The vendors will sell you a methodology deck with 47 workstreams. Ignore most of it. Get the transaction taxonomy right, kill the parallel-run fantasy, staff a real war room, and sequence the switchover so lookups come up before posts. Everything else is scaffolding.

Frequently Asked Questions

Can we do a big-bang cutover instead of phased, or is phased always safer?

Big-bang is often safer for mid-market manufacturers and distributors, counterintuitively. Phased cutovers (module by module, or site by site) require you to run integrations between old and new ERP for months, and those integrations are where data quality quietly degrades. Big-bang is riskier on go-live weekend but eliminates the long-tail integration debt. The exception is multi-site operations where each site can be cut independently — then phased-by-site is usually the right call.

How do we handle open purchase orders that span the cutover date?

Decide per-PO in step 1 of the playbook: either close it in the old system (ask supplier to invoice against the old PO number and receive fully in legacy) or reopen it as a new PO in the new ERP with matching terms. Do not try to migrate partially-received POs mid-flight — the receipt history rarely survives cleanly and you end up with duplicate GRNs against the same physical goods.

What happens if we discover a critical bug on go-live morning?

You need a pre-agreed rollback trigger and a rollback runbook written before T0. Typical triggers: inability to ship any orders for four consecutive hours, financial postings failing on more than 10% of transactions, or inventory accuracy dropping below a defined threshold. Because legacy is in read-only mode (not decommissioned), rollback means re-enabling writes in legacy and reversing any new-ERP transactions posted in the interim. Painful, but recoverable.

How long should parallel or shadow operation actually run?

Shadow (one-way validation feed, legacy as system of record) should run at least 72 hours before go-live so you catch at least two full business days plus one financial close mini-cycle. Longer than 5-7 days rarely adds value and creates fatigue. True two-way parallel operation is what we argue against — it produces divergence, not confidence.

What does a cutover engagement with CodeNicely typically look like?

It depends heavily on your target ERP, your data quality, your integration surface, and how far into the project you already are. We've come in at the planning stage and also as emergency support four weeks before a failing go-live. For a specific scope and timeline against your situation, contact CodeNicely for a personalized assessment.