What to Test Before an ERP Go-Live

An ERP system sits underneath finance, inventory, procurement, and operations at the same time, so a problem that would be a minor bug elsewhere can disrupt how the whole business runs. Go-live testing needs to be scoped to that reality.

Core business processes end-to-end, not module by module

Testing each module in isolation misses the point: an ERP's value is in connecting them. A process like order-to-cash or procure-to-pay needs to be tested as one continuous flow across every module it touches, not as separate, disconnected checks.

Data migration accuracy, especially financial data

Opening balances, outstanding invoices, inventory counts, and historical transactions all need to reconcile exactly against the legacy system. A discrepancy here does not just cause a display bug; it can misstate the company's financial position.

Integrations with everything else the business runs on

An ERP rarely stands alone. Payroll, e-commerce, banking feeds, and other connected systems all need to be tested against the new ERP specifically, since integration points are consistently where go-live problems originate.

Role-based access and approval workflows

Who can see what, who can approve what, and what happens at each step of an approval chain needs explicit verification. Getting this wrong at go-live is both a compliance risk and an operational one.

A dry run with real users, on real data, before the real cutover

A rehearsal go-live, with actual finance and operations staff working through their real daily tasks in the new system, surfaces problems that scripted test cases usually miss, because it exposes how the system handles the way people actually work.