In real projects...

Implementation success is rarely blocked by a missing screen. It is blocked by evidence gaps: teams cannot prove data quality, cannot explain who approved exceptions, and cannot trace the workflow that produces the numbers leadership sees after go-live.

A common issue we see...

Projects treat “go-live” like a technical switch, but close and reconciliation workflows need ownership, reason codes, and evidence acceptance rules. Without those, users improvise—and the ERP becomes hard to trust.

For example...

  1. Lock the cutover calendar and define posting cutoffs for key processes.
  2. Map data migration outcomes to evidence artifacts (what proves the migrated data is correct).
  3. Run at least one parallel run and compare outcomes using the same identifiers.
  4. Define how exceptions are handled (reason codes, approvers, evidence expectations).
  5. Archive the go-live evidence pack so audit/review questions have a stable answer path.

Note: Scenarios are representative and educational. Validate decisions with qualified finance/IT/legal advisors for your organization.

Methodology: This is an educational guide using representative scenarios from public documentation and common implementation/audit patterns. It is not based on any one client’s confidential details.

ERP implementation failures are rarely technical failures—they are process, data, and change management failures. This checklist covers the non-technical steps that determine whether go-live is a launch or a crisis.

  1. Complete a detailed process mapping exercise for each in-scope module before any configuration begins—undocumented processes cannot be configured accurately.
  2. Run a data quality audit covering all master data that will be migrated: customers, suppliers, employees, products, and chart of accounts.
  3. Build a test plan that covers normal scenarios, edge cases, and integration failures—not just the happy path.
  4. Complete user acceptance testing with real users using real data from a recent period, not only sample records.
  5. Train all users with role-appropriate training that covers the actual workflows they will perform—not generic software tours.
  6. Run a go-live readiness assessment against defined criteria before committing to the cut-over date; do not proceed if critical issues are open.

Artifacts to expect:

  • Process documentation for each in-scope module.
  • Data quality audit report with remediation plan.
  • Test plan with scenarios, results, and sign-off.
  • UAT completion certificate with issue log.
  • Training completion records by user and role.
  • Go-live readiness assessment against defined criteria.

What usually goes wrong (failure modes)

  • Data migration quality is only discovered during go-live
    Data issues that were known during testing were not resolved before cut-over, and the volume of corrupt or missing records prevents normal operation.
    Mitigation: Start a data quality audit at least twelve weeks before go-live. Define pass criteria for each data domain—customer, supplier, product—and do not proceed to go-live until criteria are met.
  • Integration failures are not discovered until production volumes are reached
    Integrations were tested with sample records but not with production-volume transactions, and performance or error handling gaps are exposed at go-live.
    Mitigation: Test all integrations end-to-end with production-volume data and error scenarios before go-live. Integration gaps discovered after go-live create cascading data inconsistencies.
  • Users revert to legacy systems because training was insufficient
    Training was delivered as a feature tour rather than a role-based workflow walkthrough, so users do not know how to perform their actual daily tasks.
    Mitigation: Design training around specific job roles and real-world scenarios. Verify competency with a practical test before go-live, not just a course completion certificate.

Controls and evidence checklist

  • Define go-live readiness criteria in writing before the project starts.
  • Require UAT sign-off from business process owners for each in-scope module.
  • Maintain an open issues log with priority ratings and a resolution owner for each item.
  • Complete data quality audits and migration tests before UAT begins.
  • Archive all test results, training records, and issue resolutions as part of the project documentation.
  • Plan a hypercare period of at least four weeks after go-live with enhanced support coverage.

Implementation checklist

  1. Define in-scope processes and out-of-scope processes in writing before configuration begins.
  2. Complete master data extraction and quality assessment before migration configuration starts.
  3. Build and execute a structured test plan covering all in-scope processes and integrations.
  4. Run UAT with actual business users using real data and realistic transaction volumes.
  5. Complete role-based training and verify competency before go-live.
  6. Execute the cut-over plan, confirm data integrity, and operate with enhanced support for the first four weeks.

Frequently asked questions

Where do teams usually lose time in ERP implementation projects?

Most time is lost on data migration—specifically on resolving data quality issues that were not identified until the migration test runs. Starting a data quality audit at least twelve weeks before go-live, with clear ownership per data domain, consistently reduces go-live delays compared to teams that address data issues only during user acceptance testing.

What should we validate before committing to a go-live date?

Confirm that all integrations have been tested end-to-end with production-volume data, not just sample records. Integration failures discovered after go-live are significantly more disruptive than configuration issues, because they often require immediate workarounds that create data inconsistencies that are hard to unwind. UAT sign-off from all module owners is also required—not just the core finance team.

When should we delay go-live?

Revisit go-live readiness criteria when any critical test fails within two weeks of the planned go-live date. The pressure to proceed is high at this stage, but partial go-lives with known data or integration gaps create problems that typically take three to six months to fully resolve and undermine user confidence in the system. A two-week delay at this stage is consistently less expensive than a problematic go-live.

Sources

Conclusion and next steps

Successful ERP implementation is mostly discipline: documented processes, clean data, tested integrations, and trained users—before go-live, not after.

Define your go-live readiness criteria on day one of the project. If you cannot explain what 'ready' looks like before you start, you will not be able to agree when you have reached it.