Before go-live, open defects are evaluated by more than status alone. Teams review severity and priority, the business process affected, frequency and likelihood, the consequence of failure, whether a tested workaround exists, who owns the residual risk, and whether a fix can be completed safely before cutover. Critical unresolved issues with no acceptable mitigation can block go-live; lower-risk items may be deferred with documented ownership and follow-up.
Start with impact, not the defect count
A defect list is useful, but the number of open defects can be misleading. Ten minor cosmetic issues may carry less business risk than one defect that prevents a critical order, payment, production or reporting process. The review should classify issues by the business capability they threaten and the consequences of failure.
Read each defect in business context
SAP Cloud ALM supports defect status, priority, assignment and links to test cases. Those attributes help organize the evidence, but the project still needs a governance decision about residual business risk. Ask what process fails, how many users or transactions are exposed, how often the issue occurs, and whether it affects financial accuracy, compliance, security or operational continuity.
Workaround quality changes the decision
A workaround is useful only if it is practical, documented and tested. A manual step that works once in a controlled test may be unsafe at production volume. The review should ask who performs the workaround, how often, what controls prevent error, and whether support teams can sustain it until the underlying issue is corrected.
Retest evidence matters
An issue should not be considered resolved merely because a change was transported or someone reports it fixed. The affected scenario needs to be rerun and the actual result recorded. Where the fix can affect previously stable behavior, the team should also consider appropriate regression testing before closing the issue or changing its go-live risk assessment.
Decide whether to fix, defer or accept
The final decision should be explicit. Some issues must be fixed before go-live because the business impact is unacceptable. Others may be deferred because exposure is limited and a tested workaround exists. A deferment still needs an owner, target date, support plan and agreement on who accepts the residual risk.
Feed the result into go-live governance
There is no universal SAP defect-count threshold that guarantees readiness. SAP Activate uses quality gates as milestone checkpoints, and project teams combine testing evidence with business, data, cutover, security and operational readiness. The defect review should therefore be one input into the broader go-live decision rather than a standalone pass/fail metric.
Consultant thinking: make residual risk visible
The professional question is not simply “How many issues are open?” It is “Which business risks remain open, what evidence supports the assessment, who owns each risk, and what happens if we go live anyway?” That framing turns a status list into a governance decision.
Continue with How Defects Move From Open to Closed, How Test Evidence Is Maintained, How Test Cycles Are Planned, How Business Readiness Is Assessed Before Go-Live, and the Consulting & ERP Projects hub.