Finance has picked the new ERP. The go-live date is on the calendar. Your job, as the person responsible for what actually ships, is to make sure production doesn't stop when accounting celebrates.
That is not a hypothetical concern. The failure modes that follow an ERP cutover in a packaging or label converting environment don't look like IT problems. They look like a die-cut job that can't be invoiced because the item number no longer resolves, a press run whose labor costs post to the wrong work center from day one, or a job that crossed the cutover line whose margin you can never fully reconstruct — because half the actuals are in a system that no longer has accessible credentials. The gap doesn't show up at go-live. It shows up three months later, when someone needs to answer a specific question about a specific job.
This piece is for plant managers and operations directors who are already downstream of the ERP decision and need to know what must be true on the floor — not in the project plan, not in the steering committee deck — before the switch is thrown.
The Four Problems That Are Not One Problem
Implementation partners typically scope data migration as a single workstream. It isn't. Master data, open transactions, balances, and historical transactional detail are four structurally different problems. They require different types of validation, different sign-off owners, and if something goes wrong, different rollback triggers.
Treating them as one extraction-and-load exercise is the most common way a technically successful cutover produces an operationally broken first week.
Master Data: The Exceptions Are the Problem
Item masters, bills of material, routings, customer records, and pricing structures have to migrate before go-live - in practice, days or weeks before - to allow time for validation. That creates an immediate operational burden: from the moment static data migrates, every new record created in your legacy MIS must also be created manually in the new ERP. This is called Dual Maintenance, and it compounds every day the pre-migration window extends.
The high-volume records are not where the failures concentrate. Your implementation partner's extraction scripts will move thousands of item masters without incident. The failures live in the exceptions: items where substrate-specific fields - roll width, core diameter, print repeat, die geometry - were never mapped to a native ERP field and instead live in a legacy free-text note that a press operator knows to read in a specific way. When that item migrates, the field either doesn't come across or comes across as unstructured text that no downstream process can act on.
The gap is between how a field is documented and how it is actually used. The only people who reliably know that gap are your frontline operators and estimators. A validation pass that runs through a spreadsheet comparison will not catch it. A press operator who tries to pull the job and finds a missing die geometry will catch it - on the first day of production.
Routings carry the same risk in a different form. A routing that is structurally valid -every operation present, every sequence correct - can still fail operationally. If the labor-reporting logic for a die-cut operation is missing or mapped to the wrong work center, time capture works, cost posting works, and everything looks fine in the system. Job margin is wrong from day one. That error is invisible until someone questions why a job that should have been profitable wasn't, by which point several more jobs have run under the same misconfigured routing.
The validation that catches this is not a record count. It is a transaction simulation: take a representative sample of real jobs - one press job, one die-cut, one finishing-heavy run - and execute them end-to-end in the new system before go-live. If cost posting lands on the right work centers and produces expected margins, the routing is correct. If it doesn't, you have found the problem before it contaminates live production.
Open Jobs and WIP: The Decision You Have to Make
Work-in-process at cutover is the hardest problem on this list, and there is no clean solution - only a choice between two imperfect options with different cost profiles.
Option one: drain the line.
Stop releasing new work orders roughly two weeks before go-live and run the factory to completion on everything open. In theory, you arrive at cutover with no WIP. In practice, a packaging converter running concurrent press, die-cut, and finishing jobs will find that some jobs cannot finish in two weeks - long-run rolls, multi-stage folding carton work, anything with an external process step. The drain is never complete. And the production freeze has direct revenue implications: jobs that don't ship don't get invoiced.
Option two: migrate open operational state.
Move each open job mid-run into the new system, re-execute material issues and labor history, reconcile costs for each completed operation. Every practitioner who has attempted this at a converter reports the same outcome: massive testing requirements, frequent costing discrepancies, and reconciliation work that continues well after go-live. The operational complexity of re-creating in-progress state across press, die-cut, and finishing operations, each with their own cost structures, is not a theoretical risk. It reliably produces errors.
The practical answer for most converters is a modified drain: identify which jobs can realistically complete before cutover, prioritize them, hold new releases on those presses or lines, and treat any jobs that cannot finish as a defined exception set that will be migrated as opening balances with full documentation of what has and hasn't been costed. That exception list should be agreed and signed off before go-live, not discovered afterward.
Costing History: Two Exposure Windows That Are Not the Same Risk
Most ERP migrations are balance-forward conversions. This is not a deliberate client decision — it is what happens by default when implementation partners are scoped to stand up a new platform, not to reconcile years of legacy transactional detail. Most clients don't know they received a balance-forward migration until they need history that is no longer accessible.
A balance-forward conversion means finance gets an opening balance that reconciles. The plant manager gets a new system with no transactional history from the prior system. For any job that was quoted, plated, and partially run before cutover, the cost build is split: some actuals are in the new ERP, the rest remain in the legacy system.
This creates two distinct exposure windows that should not be treated as one problem.
The first is immediate and operational. From go-live forward, you cannot answer job-margin questions on any job that crossed the cutover line. The actuals are in two systems, and the only way to reconstruct the full picture is to access both — which is manageable while the legacy system is live, increasingly difficult once it is decommissioned, and effectively impossible once it exists only as a read-only archive with credentials that no one has maintained.
The second is delayed and external. Auditors requiring transaction-level support for a job that ran across the cutover period will find that the detail they need exists in an inaccessible system. This does not surface at go-live. It surfaces during the next audit cycle, slowing fieldwork and increasing exposure to findings.
Before go-live, you need clear answers to three questions: Which jobs will cross the cutover line, and what is the plan to document their in-progress cost state? How long will the legacy system remain accessible in a readable form, and who holds the credentials? And does anyone on the implementation team know which type of migration was scoped — full transactional history or balance-forward?
Shipments That Can't Be Invoiced
The stabilization window after an ERP cutover is approximately 48 to 72 hours. After that, daily financial processes — invoicing, receipts, payment runs — must be running correctly. That means the window to catch and escalate a costing or configuration error before it affects the first customer invoice is roughly two business days.
The failure modes that produce uninvoiceable shipments are specific and worth naming:
Orphaned open jobs: a job exists in the legacy MIS, has shipped, and does not exist in the new ERP. Invoice can't be generated. Usually caused by jobs that were mid-run at cutover and fell outside the migration scope without being explicitly tracked.
Item numbers that no longer resolve: an item was migrated under a different identifier, or a substrate-specific variant was consolidated in ways the floor wasn't told about. A shipment posts against a line item that doesn't match what was ordered. The invoice blocks.
UOM mismatches between procurement and shop floor: an item received in rolls is being consumed in linear feet, and the conversion factor wasn't validated. The inventory variance surfaces when the first receipt posts and creates a cascade of incorrect on-hand quantities.
Dual-costing periods: a job that spans cutover has costs posted in two systems at different rates — legacy standard costs on the front end, new ERP costs on the back. Neither system has the full picture. Finance can live with the reconciliation; operations cannot explain the margin.
None of these are exotic failure modes. They appear in nearly every manufacturing ERP cutover. The difference between a converter that navigates them and one that loses two weeks of billing is whether the operations team treated data readiness as their problem before go-live, or assumed it was the project team's problem after.
---
What Operations Owns Before Go-Live
The project plan will have a data migration workstream. That workstream belongs to the implementation partner. What belongs to operations:
A signed-off list of every open job, its current operation step, and its costed-to-date total, validated by the people who run those jobs — not extracted from a report.
A transaction simulation on representative job types, run in the new system before go-live, with cost results reviewed by the people who know what those margins should look like.
Confirmation of who holds legacy system credentials, how long it will remain accessible, and what the process is for looking up a job from the prior system after go-live.
An agreed definition of the WIP exception set — jobs that will not drain before cutover — with explicit documentation of how their costs will be handled.
A named person on the floor who is accountable for the first 72 hours of production in the new system, with authority to escalate a costing or routing problem before it affects an invoice.
Finance changes systems on a date. Production doesn't get to pause for it. What has to be true of the integration between your shop-floor MIS and the new ERP before that date is the whole question — and it is an operations question, not an IT question.
If your organization has a cutover date on the calendar and production readiness hasn't been formally scoped yet, we're glad to walk through the specifics with you — no agenda other than making sure the floor keeps running.