Finance changes systems on a date. Production doesn't get to pause for it. Every job on the floor that morning is still a job that needs to ship, be invoiced, and land in the right period — whether the new ERP is ready for it or not. That gap between "the books moved" and "the plant kept running" is where cutover actually succeeds or fails, and it's almost never an IT problem.
This is a guide for controllers and operations leaders at label, folding carton, and packaging converters who are staring at a cutover date and trying to think clearly about what has to be true before that date arrives — and what has to be managed after it.
The question underneath every cutover decision
Cutover planning gets framed as a migration problem: extract data, map it, cleanse it, validate it, load it. That framing is not wrong, but it puts the weight in the wrong place. The extract-map-cleanse-validate mechanics are the integrator's problem. The finance team's problem — and the one that determines whether go-live is survivable — is whether the books are in a state that the business can actually operate from on day one.
That means three things have to be true before you go live:
1. The legacy system's closing trial balance is loaded into the new GL as of cutover date and reconciled to the dollar. 2. Every sub-ledger — AR, AP, inventory — ties to its control account. 3. The accounting team has enough bandwidth to verify both, because the post-go-live validation stage is systematically under-resourced and that is where late-surfacing discrepancies originate.
Opening balance reconciliation is the single mandatory gate most often treated as a formality. It is not a formality. It is the only moment where you can confirm that the new system starts from the same reality as the old one. Every discrepancy you don't catch here surfaces later, during a close, at audit, or mid-quarter when someone is trying to reconcile a job that straddled the boundary.
Clean cutover vs. parallel run: what the decision is really about
A parallel run sounds conservative. You keep the old system live, run both simultaneously for a period, and compare results. The intention is to catch errors before you're fully committed. In practice, parallel runs have a structural defect: no one is empowered to close them.
Because a parallel run is never formally wrong — there's always one more transaction to verify, one more period to confirm — it drifts. Teams are doing twice the accounting work with the same headcount, and the parallel window becomes a source of exhaustion rather than confidence. If your parallel window runs longer than two monthly close cycles, that is a signal that the new ERP is not ready — not that the parallel run is doing its job.
The fix isn't to avoid parallel runs. It's to define exit criteria in writing before go-live. A workable standard: three consecutive monthly closes reconciling within a defined tolerance (0.1% is a reasonable threshold to discuss with your team and auditors). Without written exit criteria, a parallel run has no end condition and will run until someone is tired enough to stop it.
A clean cutover — a hard boundary where the old system closes and the new one opens — trades that risk for a different one: if the opening balances aren't right, you have no safety net. It demands more preparation and more confidence in the data, but it eliminates the double-entry burden and forces the team to commit. For converters with a clean month-end as a natural boundary and well-prepared master data, a clean cutover is often the better outcome.
The choice between them is a question about your data confidence, not your risk tolerance. If the data is right, a clean cutover is less risky. If the data isn't right, a parallel run doesn't fix it — it just delays the reckoning.
AP is where cutover quietly fails
Accounts payable is the most commonly neglected sub-ledger going into cutover, and it causes the longest operational blackouts when it goes wrong. The reason is that AP is messy in ways that AR usually isn't: partial payments, unapplied credits, vendor statements that don't match the aging, invoices that were received but not yet matched to a PO. None of that cleans itself up during a migration.
The prescribed approach is straightforward, though the work is not:
Pay down what you can before cutover.
Every open bill you can close before the boundary shrinks the migration set. This is unglamorous work, but it directly reduces cutover risk.
Convert the remainder as opening balances.
Open bills, unapplied credits, and partial payments move to the new ERP as opening balances — not as re-entered transactions.
Reconcile the converted AP aging to the legacy aging before go-live.
If the totals don't match, you have a problem. Find it before you're live, not during your first close in the new system.
For packaging and label converters, AP complexity is often higher than it looks because of vendor-managed inventory arrangements, consignment stock, and substrate suppliers with non-standard payment terms. If those aren't mapped correctly into the new ERP before cutover, the disruption isn't just a finance problem — it affects material availability and, by extension, production scheduling.
Master data: the failure that hits everywhere at once
A referential integrity failure in master data — a sales order that references a customer record not yet loaded, or a bill of materials that references an item code that doesn't exist in the new system — doesn't fail quietly. It fails across inventory, finance, and shipping simultaneously. One bad record can block order processing, prevent shipment confirmation, and produce incorrect cost rollups all at once.
For converters specifically, the BOM risk is acute. If substrate specifications, ink formulations, die configurations, or routing sequences migrate incorrectly, the downstream effects include material shortages, scrap, rework, incorrect job costing, and late shipments. These aren't hypothetical — they're the most common source of plant disruption in manufacturing ERP migrations.
The control is sequencing. Master and configuration data must be loaded and validated before transactional records. That means:
- Customer and vendor masters verified against source records before any AR or AP transactions load - Item masters and BOMs validated against current production specs — not the specs from the last time someone touched the record in the legacy system - GL chart of accounts mapped and confirmed before opening balances post
In a converting plant, the person who knows whether a BOM is right is often on the floor, not in IT. Cutover planning that doesn't include production supervisors and estimators in the master data validation stage is planning that will find its errors after go-live.
Jobs in flight when the boundary shifts mid-quarter
This is the problem that accounting-only migration planning usually underestimates. A label or folding carton plant running 200 active jobs on cutover day has 200 transactions that don't belong cleanly to either system. Each one has material consumed, labor posted, partial billing possibly issued, and a cost rollup in progress.
The questions that need written answers before go-live:
Where does the WIP balance land?
Jobs that are open at cutover carry a WIP value. That value needs to be part of the opening inventory balance in the new ERP, and it needs to tie to the job-level detail in the legacy MIS.
What is the rule for partial invoices?
If a job was partially invoiced in the old system and ships after cutover, which system handles the balance? The answer needs to be a rule, not a case-by-case decision made under pressure.
What is the cutoff rule for revenue recognition?
For label and packaging converters, shipment terms and customer acceptance timing can create ambiguity about which period a job's revenue belongs to. That ambiguity gets worse when the period boundary and the system boundary coincide.
These aren't ERP questions. They're accounting policy questions that the ERP has to be configured to enforce. If they're not resolved before go-live, the accounting team will be making them up under time pressure during the first close — which is the wrong time to be inventing policy.
How much history actually needs to move
The working consensus among finance and ERP practitioners is 2–3 years of transactional detail, with everything older archived rather than migrated. The floor on that range isn't arbitrary: IRS minimum retention requirements for tax-supporting records establish a baseline that makes the "one year is enough" position difficult to defend for any business with external audit obligations, active lender covenants, or potential IRS examination exposure.
For prior-year comparatives specifically — which your auditors will need — two full fiscal years of GL detail is the practical minimum. If your audit engagement requires three-year comparatives, that number sets your floor, not the migration team's preference.
What doesn't need to move:
Fully paid, closed AP and AR transactions older than the history window.
Completed jobs with no open warranty, return, or dispute exposure.
Archived GL detail beyond the retained window — this goes to a read-only archive or document management system, not into the new ERP
What does need to move — even if it's old:
Any open item: unpaid invoices, disputed balances, credits not yet applied - Any job with open exposure: warranty claims, pending returns, unresolved disputes - The full chart of accounts history for the years you're retaining, so prior-period reporting runs correctly
The test for any record is not its age but its open status. Age is a proxy. Open status is the actual question.
What has to be true before the date
To summarize the decision framework:
On parallel run vs. clean cutover: Decide based on data confidence, not risk posture. Define exit criteria in writing before go-live. Two consecutive clean closes that reconcile within tolerance is a reasonable gate. A parallel window longer than two close cycles is a warning sign about readiness, not a reason to extend.
On AR and AP: Pay down what you can before cutover. Convert the rest as opening balances. Reconcile converted aging to legacy aging before go-live. AP gets the most attention, because it causes the longest operational disruptions when it goes wrong.
On master data: Sequence it correctly. Masters before transactions. Validate BOMs and routing data with production, not just IT. A wrong BOM in the new system is a production problem, not a data problem.
On jobs in flight: Write the rules before go-live. Where does open WIP land? What is the partial-invoice rule? What is the revenue cutoff rule? These are accounting policy decisions that the ERP has to be configured around — they can't be made up during the first close.
On history depth: Retain 2–3 years of transactional detail. Retain whatever your auditors need for prior-year comparatives. Archive the rest. Open items migrate regardless of age.
The thread running through all of it: cutover decisions are continuity decisions. The question is never "when can we switch systems." The question is "what does the shop floor still need to reference after the books move, and what happens to every job that's in flight when the boundary shifts." Answer those questions first. The date follows from the answers.
If you're working through a cutover plan and want to think through how the MIS-to-ERP integration handles jobs in flight or open sub-ledgers, we're glad to talk it through — no agenda, just the problem.