← All insights

Finance & ERPOctober 2026 · 7 min read

ERP migration risk: what to check before cut-over

Most cut-over problems are visible weeks ahead, in six places. Weight the critical checks, reconcile counts and balances, and agree go/no-go criteria before the meeting.

Leron Garriques, Baxter Mountain Group

Short answer: most ERP cut-over problems are visible weeks in advance, if you look in the right six places. Those are data readiness, integrations, process and controls, cut-over and reconciliation, people and change, and governance. Weight the critical checks more heavily than the rest. Don’t sign off a load until record counts and balances reconcile, or every difference is explained.

Why do ERP migrations go wrong at cut-over?

Because cut-over is where every unfinished task from the previous six months arrives at once. A data mapping nobody signed off, an integration tested with last year’s file format, a control that existed in the old system but not the new one. Each was a small gap. Together they become a weekend of firefighting, or a delayed go-live.

The answer is not a longer project plan. It is a short list of critical checks, reviewed on a schedule, with an honest signal of whether you’re ready.

What should you check before cut-over?

Group the checks into six areas, and mark the critical ones.

AreaExamples of critical checks
Data readinessMaster data cleansed and owned; mappings signed off; trial loads completed
IntegrationsEvery interface listed, tested end to end with current file formats, with an owner
Process and controlsKey controls rebuilt and tested in the new system; segregation of duties reviewed
Cut-over and reconciliationCut-over plan rehearsed; record counts and balances reconciled after each trial load
People and changeUsers trained on their real tasks; support in place for the first close
GovernanceGo/no-go criteria agreed in advance; a named decision-maker; a rollback plan

Score each check as done, in progress, not started or not applicable. Weight it as critical, important or standard. A critical check left open should count three times as much as a standard one.

Cut-over: the planned window when you stop transacting in the old system, load final balances and open transactions into the new one, reconcile them, and start working live.

A worked example: eight weeks out and not ready

Fictional company and numbers, chosen to show the method. Eight weeks before cut-over, a team scores its 30 checks.

  • Overall readiness is 54%, with 10 critical checks still open.
  • Data readiness is strong at 88%, and integrations sit at 69%.
  • The weak areas are cut-over and reconciliation at 21%, and people and change at 17%.

The signal is red, and that’s useful at eight weeks rather than alarming. The team knows exactly where to spend the next month: rehearse the cut-over and get training onto people’s real tasks. Six weeks from now, nobody should be discovering that the reconciliation plan doesn’t exist.

A red signal at eight weeks is a plan. A red signal at cut-over weekend is a crisis.

How do you reconcile data after a load?

Reconcile counts and balances, not just records. For every object you migrate (customers, vendors, open payables, GL accounts, fixed assets), compare the count in the legacy system with the count in the new one. Then compare control totals and balances.

Take one object in our example. The legacy system holds 2,315 vendor records and the new platform shows 2,309 after the load. Six missing vendors sounds small. But if one of them is owed money on day one, the first payment run fails. Every non-zero difference needs an explanation before sign-off: a deliberate exclusion, a duplicate merged, or a defect to fix.

What makes a good go/no-go decision?

Agree the criteria before the meeting, not in it. A good go/no-go has a named decision-maker, a short list of conditions (for example, no critical checks open, all reconciliation differences explained, rollback tested), and the discipline to say “not yet” when the conditions aren’t met. Parallel runs, where you process a period in both systems and compare, are expensive. They pay for themselves the first time they catch a difference before your customers or auditors do.

Key takeaways

  • Most cut-over problems are visible weeks ahead across six areas.
  • Weight critical checks more heavily, and track open critical items by name.
  • Reconcile record counts and balances after every trial load, and explain every difference.
  • Agree go/no-go criteria and a decision-maker in advance.
  • A red signal early is a plan, not a failure.

Check your own readiness

The ERP Migration Risk Checklist takes you through 30 weighted checks. It scores each area, gives a red, amber or green cut-over signal, lists your top five gaps, suggests what must be true at 90, 30 and 7 days, and includes a record-count reconciliation tool. It’s free and runs in your browser.

Frequently asked questions

What are the biggest risks in an ERP migration?

Unowned master data, integrations tested against outdated formats, controls not rebuilt in the new system, unrehearsed cut-over plans and users trained on demos instead of their real tasks.

How do you know if you are ready for ERP cut-over?

Score a weighted checklist across data, integrations, controls, cut-over, people and governance. You are ready when no critical checks are open and every reconciliation difference is explained.

How do you reconcile data after an ERP migration?

Compare record counts and control totals for each migrated object between the legacy and new systems, and require an explanation for every difference before sign-off.

Is a parallel run worth it?

Often, yes. Processing a period in both systems is costly, but it catches differences before they reach customers, suppliers or auditors.

Explore what AI agents could do inside your business

A short discovery call to find the workflows where our advisors and engineers can deliver impact first.