ERP go-live readiness: the 5 dimensions + checklist

The go-live date is in the calendar. The external communication has gone out. The board has made the decision. And three weeks before the date, the IT manager discovers that fifteen percent of the test scenarios are still open, the master data contains errors, and two critical interfaces have not yet been validated.

This is not an exceptional situation. From the experience of 265+ specialists, we see this pattern time and again: go-live dates are treated as contractual obligations, while the actual readiness of system, data and organisation is not measured systematically. The date overtakes the substance.

What does a failed go-live cost? The direct costs are visible: recovery projects, additional consultancy, master-data corrections and lost productivity in the first weeks after launch. The indirect costs are structurally larger: loss of trust among end users, a fallback to shadow administrations, and organisational exhaustion that limits the capacity to absorb future improvements. Planning around a postponed go-live costs less than planning around a failed one.

ERP go-live readiness is the systematic test of whether your ERP implementation is ready for launch on every critical dimension: technical, functional, organisational and managerial.

What is ERP go-live readiness?

ERP go-live readiness is the degree to which an organisation is demonstrably ready to put its new ERP system into production, based on verifiable criteria across five dimensions: functional test coverage, data quality, user acceptance, technical stability and governance.

It is emphatically an organisational decision, not an IT decision. A system that functions technically but whose master data is incomplete and whose employees have not been trained is not go-live-ready.

An ERP selection is a board-level decision. So is the go-live.

Why go-live readiness is structurally underestimated

ERP projects run on two competing timelines. The first is the project timeline: deliverables, milestones, deadlines. The second is the readiness timeline: the degree to which the system, the data and the organisation are actually ready.

In well-governed projects these two timelines run in sync. In practice, the project timeline dominates. Readiness signals are then interpreted as “issues still to be resolved”, not as go/no-go criteria.

What we structurally see from 265+ specialists: the definition of “ready” is too rarely set in advance. Who decides when the data-migration quality is sufficient? Who determines whether the user acceptance test has passed? Who gives the formal go-live approval? If these roles and criteria are not assigned beforehand, the go-live decision is made on project pressure, not on readiness evidence.

The five dimensions of ERP go-live readiness

1. Functional test coverage

The first dimension is the most visible: have you tested what the system needs to do?

Go-live readiness on testing requires more than a percentage of executed test cases. It requires certainty that the critical business processes have been tested, that findings have been resolved or consciously accepted, and that the owner of each process has given formal approval.

Indicators of insufficient test coverage:

Open test findings affecting primary processes (purchasing, sales, finance)
Test cases repeatedly postponed due to availability problems among key users
Integration points not tested end-to-end
User acceptance tests carried out only by functional management, without involvement of end users

Read more about the approach to test management for ERP implementations at ERP Company.

2. Data quality and migration status

ERP go-live readiness is, to a large degree, a data question.

Incomplete or incorrect master data, articles, customers, suppliers and chart of accounts, causes operational disruption immediately after go-live. Transaction data that is migrated incompletely leads to reporting discrepancies that are discovered months later and then still need to be corrected.

A go-live readiness check on data covers at least:

Validation of master-data completeness and consistency by the data owner
Verification of the migration test run: results, deviations and acceptance criteria
Confirmation of the data owner per domain (customers, articles, general ledger)
A defined migration window and a documented rollback procedure

3. User acceptance and change readiness

The third dimension is the human side of go-live readiness.

Systems go live. People come along, or they do not.

Change readiness measures whether the organisation is genuinely willing and able to work with the new system. Technically correct systems that employees avoid deliver no business value.

Signals that change readiness is insufficient:

Training programmes that started later than planned
Key users who have not fully taken up their training role due to operational pressure
Employees who “wait until after go-live to really learn”
No formal hypercare plan for the first four weeks after go-live

See our approach to ERP change management and user adoption.

4. Technical stability and integrations

The fourth dimension is technical readiness: does the system perform as expected under realistic production load?

An ERP that runs stably in the test environment is not automatically stable in production. Performance testing, integration validations and security checks are preconditions for a responsible go-live.

Points of attention:

Have all critical integrations been tested end-to-end with production-equivalent data?
Has performance been tested under expected peak load?
Is the rollback procedure documented and tested?
Are authorisations configured in line with the approved authorisation matrix?

5. Governance and decision control

The fifth dimension is managerial: who decides, and on which criteria, that the go-live proceeds?

Go-live readiness requires a formal go/no-go structure with documented criteria, a designated decision-maker and a documented assessment. Projects without explicit go/no-go criteria almost always drift toward a date set by momentum, not by facts.

ERP Company sits on the client’s side of this decision. Our role in go-live guidance is to provide the steering committee with an independent judgement, not a confirmation of the existing plan.

Practice pattern: what 265+ specialists see

On go-live questions, from 265+ specialists we see four structural patterns that lead to avoidable go-live problems.

Pattern 1: starting test preparation too late

Test scenarios are only worked out after the configuration is complete. In most projects that is too late: the configuration is already behind and test capacity is planned against the original schedule. The test phase compresses, the configuration phase does not. The result is a four-week test phase that should really have taken eight.

Pattern 2: data quality as the final milestone

Data-migration testing is treated as a technical task in the final project phase, while data-quality analysis is a business responsibility that should run parallel to the configuration. Discovering that master data is inconsistent, two weeks before go-live, is almost always a planning problem, not a data problem.

Pattern 3: a missing formal go/no-go structure

The decision to proceed with the go-live is not made on the basis of an explicit go/no-go framework, but on “the feeling that it is good enough”. When go-live problems surface afterwards, it turns out there was no moment at which open points were formally weighed against the go-live criteria.

Pattern 4: hypercare as an afterthought

The hypercare period, the four to eight weeks immediately after go-live, is the most critical moment for successful adoption. Key users are maximally available, problems are resolved directly, and employees get the guidance they need. In practice, hypercare is often reduced to a support-ticket process: report your problem, wait for a solution. That is support, not hypercare. The difference determines whether your ERP implementation becomes a successful project, or a drawn-out improvement track.

Go-live readiness check: fifteen red flags

Use this checklist to assess the readiness of your ERP implementation. Every question answered with “yes” is a signal that further analysis is needed.

#	Red flag	Dimension
1	More than 10% of test cases are still open	Testing
2	Open test findings in critical processes are not formally accepted	Testing
3	The integration test was not run end-to-end with production-equivalent data	Technical
4	There is no written sign-off from process owners on test results	Testing + Governance
5	The data-migration results have not been reviewed by the data owner	Data
6	Master data (customers/articles/suppliers) is not fully validated	Data
7	No formal rollback procedure is documented	Technical
8	Training is not yet completed for more than 20% of end users	Change
9	Key users are not available for the hypercare period after go-live	Change
10	There is no hypercare plan for the first four weeks after go-live	Change + Governance
11	Authorisations are not tested with end users in their actual roles	Testing + Technical
12	Performance tests have not been run under realistic peak load	Technical
13	No formal go/no-go structure with criteria is documented	Governance
14	The steering committee has given no explicit approval on go-live readiness	Governance
15	There is no independent assessment of the readiness status	Governance

Interpretation:

0 to 3 red flags: ready for go-live, continuous monitoring recommended
4 to 7 red flags: in-depth analysis required; go-live risk is present
8 or more red flags: postpone go-live until critical points are resolved

When should you take action?

ERP go-live readiness requires action the moment project pressure starts to overrule the readiness assessment.

Concrete signals that action is needed:

The go-live date has become politically non-negotiable, while the objective readiness does not support it
Test results are internally regarded as “good enough for now” without formal process-owner acceptance
Data-migration quality has not been formally reviewed by the responsible process owners
The steering committee decides on progress reports, not on documented readiness criteria

At that moment, an independent go-live readiness check is the most cost-effective intervention. A second opinion in the run-up phase costs structurally less than recovery work after a problematic go-live.

When is a go-live readiness check not needed?

Not every ERP project requires an external readiness check. There are situations in which your own teams can provide sufficient assurance:

You have an internal test team with proven ERP testing experience in the relevant modules
All five dimensions are structurally owned within your project organisation with designated owners
You have an external implementation partner with a track record on comparable scope and transparent reporting
Your go/no-go procedure is formally documented and consistently applied across all five dimensions
You have successfully completed a previous go-live on the same platform in a comparable context

In these situations an external review is optional, not a requirement.

Decision framework: proceed, adjust or postpone

The purpose of a go-live readiness check is not to prevent the go-live, but to create a well-founded basis for the go/no-go decision. There are three possible outcomes.

Outcome	Situation	Action
Proceed	All critical dimensions are in order. Open points are consciously accepted. Risks are documented and manageable.	Go-live as planned, while monitoring the accepted risks
Adjust	One or more dimensions require targeted action.	Adjustment focuses on concrete measures, not on postponing the entire go-live
Postpone	One or more critical dimensions are structurally insufficient. Proceeding leads to operational disruption.	Postponing is a board-level decision based on facts, not a project failure

ERP Company supports organisations in all three scenarios. Our role is to provide an independent judgement, not to take over the steering committee’s decision.

Have your go-live independently assessed before you confirm the date

You can have the go-live readiness of your ERP implementation assessed by a specialist with no stake in the outcome of your go-live date. ERP Company performs independent go-live readiness checks, followed by a concrete recommendation to your steering committee: proceed, adjust or postpone.

Plan an independent go-live readiness check

Frequently asked questions about ERP go-live readiness

When is an ERP system ready for go-live?

An ERP system is ready for go-live when the critical business processes have been tested and accepted by process owners, the master data has been validated by the data owner, end users have been trained, and a formal go/no-go decision has been made on the basis of documented criteria.

Technical readiness is a necessary but not a sufficient condition. Data quality, user acceptance and governance structure determine in equal measure whether your go-live succeeds.

How long does a go-live readiness check take?

An independent ERP go-live readiness check usually takes two to five working days, depending on the size of the project and the availability of documentation.

The check covers documentation analysis, interviews with the project team and process owners, and an assessment across the five readiness dimensions. The result is a concrete recommendation to the steering committee.

What are the most common causes of go-live problems?

The most common causes are incomplete test coverage on critical processes, incorrect or incomplete master data, insufficient user acceptance and the absence of a formal go/no-go structure.

From 265+ specialists we see that go-live problems rarely have a single cause. Almost always it is several signals that were visible weeks before the go-live, but were not formally addressed.

Can a go-live always be postponed if readiness is insufficient?

Not always. Postponing a go-live has commercial consequences, contractual impact and organisational effects. The trade-off is always: what does postponing cost, and what does proceeding cost?

In most situations, targeted adjustment on the critical dimensions is a better outcome than postponing or proceeding without measures. An independent readiness check makes that trade-off objective.

ERP go-live readiness: how to keep your implementation from stalling at the finish line