A go-live readiness review is a structured evaluation of whether the organization can safely move to production and operate the agreed business scope. It considers tested processes, accepted defects, reconciled data, rehearsal evidence, user access, training, operational support, cutover timing and residual risks. The outcome is a documented decision by designated business and technology owners—not an automatic green light because the project plan says the date has arrived.
Why the review exists
A system can be technically deployed yet remain operationally unready. A warehouse may lack trained shift supervisors, Finance may have unexplained opening balances, or the support desk may have no path to escalate blocked orders. Readiness pulls separate workstream reports into one decision about business continuity. SAP Activate describes delivery moving through Realize and Deploy, with cutover and go-live followed by support and hypercare; review gates must fit that real operating transition.
Process and test evidence
Review which end-to-end scenarios were tested, who accepted the outcomes and what remains unproven. A count of completed test cases hides the significance of a failed critical order-to-cash or procure-to-pay path. Record the severity and business impact of unresolved defects, available workarounds, accountable owner and approved treatment. User acceptance should reflect the business process, not merely that screens open without errors.
Data migration and reconciliation
Check key master data, opening balances, open transactions, interfaces and any final delta loads. Evidence should describe source totals, target totals, accepted differences, sample traceability and sign-off responsibility. A 'load completed' message is not evidence that financial balances or operational stock positions are correct. Critical variances need clear resolution or explicit risk acceptance from the appropriate owner.
Cutover rehearsal and recoverability
Confirm the cutover runbook has named task owners, dependencies, start and stop conditions, estimated durations and checkpoints. Ask what changed after mock cutover and whether the revised plan was retested. The decision should consider fallback and business-continuity options where appropriate. A rollback plan may not be straightforward once real transactions are posted; teams must understand the point after which recovery means controlled forward correction rather than a simple switch back.
People, access and support
Verify production roles for ordinary users, emergency access governance, authentication, integrations, monitoring, service desk ownership and vendor contacts. Training completion percentages are weaker than practical evidence that shift teams can carry out their critical work. Check weekend and timezone coverage, escalation channels and a staffed hypercare model. A stable launch requires accountable people as much as configured technology.
How a go/no-go decision should be recorded
A useful decision record states the scope reviewed, evidence version, open critical issues, residual risks, conditions, responsible approvers and the next checkpoint. A conditional go can be appropriate only if the conditions and their enforcement are real and accepted. Neither a sponsor's enthusiasm nor a consultant's confidence substitutes for explicit decision authority. Disagreement should be visible, not buried in a green status slide.
Example: one unresolved finance variance
Imagine a final migration rehearsal passes most checks but the general ledger and subledger differ materially. If the cause and impact remain unknown, a readiness review should expose that discrepancy, the reporting and legal risk, and the planned next action. The project may postpone a dependent transaction or the entire cutover depending on criticality. What matters is a defensible decision based on evidence, not a universal rule that every nonzero difference blocks go-live.
The consultant's role
Consolidate facts, identify cross-workstream dependencies and make missing evidence visible. Translate technical incidents into process impact and ensure each open action has an owner and deadline. Consultants can recommend mitigation, but accountable business leadership must accept operational risk through the project's governance. The readiness review is most valuable when it makes a difficult decision less ambiguous.
Read next
How Business Readiness Is Assessed Before Go-Live; How Open Defects Are Evaluated Before Go-Live; What a Mock Cutover Is; How Final Balance Migration Is Validated. Continue exploring the Consulting & ERP Projects hub.