ERP go-live readiness: the evidence sponsors need before approval

Consider a release review where the implementation team reports completion, but a process owner cannot confirm that users can handle exceptions and the partner has not confirmed who will support live operations. The sponsor should not treat delivery completion as permission to start operating.

Authorize ERP go-live when business owners can demonstrate operating readiness and the support team can accept responsibility for unresolved risks. Defer when a critical process depends on unprepared users, unavailable specialists or an untested escalation route. Conditional approval belongs between those choices only when its conditions are explicit and enforceable.

This ERP go-live readiness checklist addresses authorization to enter live operation. It complements, rather than replaces, technical cutover approval, data reconciliation and recovery planning. It also comes after the decision to improve or replace the ERP: the question now is whether the organization can operate the release being delivered.

Separate process-owner acceptance from delivery completion

Ask each critical process owner to submit an acceptance statement covering the actual release scope. It should identify the workflows reviewed, the users involved, outstanding limitations and any workaround the owner is willing to operate. A project manager’s report that testing is complete should inform this statement, not substitute for it.

The distinction is responsibility. A functional consultant can explain how the configured process works; the business owner should decide whether the proposed operating procedure is acceptable. Require both perspectives where the business depends on a handoff between teams.

For example, in a hypothetical order-management review, ask users to demonstrate the normal workflow and an exception requiring intervention. Then ask who recognizes the exception, who authorizes the response and who confirms that work can resume. This is an operational acceptance exercise, not a complete integration or reconciliation test.

Record dissent rather than converting it into a green status. If a process owner cannot accept the workflow, establish whether the obstacle is missing preparation, an unresolved defect or an unacceptable operating procedure. The next action should address that obstacle specifically. Another demonstration by the implementation team is not the answer if the missing evidence is user capability.

Test user preparation, not just training attendance

ERP practitioner Francesco Perrotta identifies underestimated training as a recurring problem in his experience, linking it to ineffective system use and reduced implementation benefits. The implication for approval is practical: ask for evidence that users can perform their work, not merely evidence that training was delivered.

Have the training lead map affected roles to the tasks they must perform at launch. Review attendance alongside observed practice, unresolved questions, catch-up arrangements and access to current instructions. Include deputies and users outside the main project group. A prepared key user should not be used as a proxy for an entire operating team.

The strongest evidence is a task demonstration by the people expected to do the work, using the procedure and permissions intended for live operation. Ask them to explain when they would stop, seek approval or raise a support request. A slide deck and attendance register remain useful records, but they do not answer those questions.

Set acceptance criteria around the consequences of failure in each role. For a critical task, require the process owner to identify the remaining preparation gap and its operational consequence. If users need coaching, assign it and verify the result before approval. If a workaround is proposed, check that the people operating it understand its limits and that its owner accepts the additional workload.

Confirm support capacity and rehearse escalation

Perrotta also cautions that some partners face personnel-allocation problems because they have too many projects, leaving customers without the person they need when support becomes necessary. This is not a reason to reject a partner by size. It is a reason to verify actual availability at the release gate.

Request a support roster showing named internal and partner contacts, responsibilities, coverage periods and deputies. Ask line managers to confirm that internal specialists have time reserved for support alongside their normal duties. Ask the partner to identify the functional and technical people covering this release, rather than accepting a general assurance that a support team exists.

If the original proposal leaves those responsibilities unclear, revisit the team and availability checks used in partner selection. At go-live, the issue is no longer the supplier’s overall capability. It is whether the required people can respond to this operating scope.

Rehearse an escalation using a hypothetical business interruption. Have a user raise the issue, the service desk route it and the responsible specialists explain their next steps. Confirm who assesses business impact, who authorizes a workaround and who communicates with affected operations. Do not equate a ticket being assigned with ownership of business recovery.

For handover, ask the receiving support lead to accept the procedures, access, known-issue register and escalation contacts. An email saying that documentation has been sent is weaker than confirmation that the receiving team can use it. If ownership remains disputed, resolve it before asking the sponsor to accept the risk.

Reserve capacity for stabilization and continuing updates

Define stabilization as work with accountable owners, not simply a period on the project calendar. Identify who will triage live issues, provide user coaching, approve changes and maintain the operating instructions. Separate urgent recovery work from enhancement requests so that the same people are not implicitly committed to both without prioritization.

Continuing ownership also extends beyond the initial release. In a Microsoft Dynamics community discussion, Steve Goodwin described conversations needed to help senior leaders understand the platform update process, feature management and the capabilities available to their organization. This is a context-specific customer account, not evidence of a typical ERP outcome.

Its useful implication is that executive understanding should include what happens after launch. Ask who will review relevant updates, assess business impact, coordinate testing and prepare users for accepted changes. Reserve capacity for those responsibilities rather than assuming that finishing implementation also finishes the need for business participation.

Agree on evidence for moving from intensified stabilization support into normal operations. Useful questions include whether critical issues have an accepted disposition, support ownership is functioning and process owners can manage the remaining workload. Choose criteria appropriate to the release; do not substitute an arbitrary elapsed period for an acceptance decision.

Put named owners and unresolved risks in the approval record

Use the following worksheet as a sponsor-facing decision aid. Replace role labels with actual names, link the evidence and state the unresolved exposure. Do not turn the rows into a score that allows a serious operational gap to disappear inside an average.

A useful recording mechanism appears in the Go-Live Readiness Decision Template: conditional approval records the condition, owner, deadline, verifier and consequence if the condition is unmet. Use that mechanism to distinguish a genuine conditional authorization from an informal promise to finish later.

Approve when the evidence supports live operation and the remaining risks have accountable acceptance. Use conditions for bounded gaps whose closure can be verified before the affected activity begins. Defer when a critical operating responsibility remains unsupported. Record the reason, corrective action and evidence needed for the next decision, not just a replacement date.

Before the approval meeting, ask every critical process owner and the receiving support lead to submit their evidence and unresolved risks in the same decision record. If you need functional or technical capacity to close those gaps, talk with Digiventi’s ERP specialists about the release scope and support responsibilities.