Lesson 6 of 6
Reporting and sign-off
9 min
Listen to this lesson
In a project, a late sign-off delays go-live. In Public Edition, the production upgrade happens on SAP's date regardless. That changes the purpose of sign-off: it is not permission for the upgrade to happen, it is the business's confirmation that it is ready, with known risks managed, before the new release reaches users. A sign-off that comes after the production weekend is just a record of what went wrong.
The release readiness report
Keep the report to one or two pages and send it on a fixed day, with a daily short version during the window. Process owners should be able to read it in five minutes.
| Section | Content |
|---|---|
| Scope | Release, test system upgrade date, production date, processes and interfaces in scope |
| Execution | Planned, executed, passed, failed and blocked tests by process area, automated and manual |
| Post-upgrade tests | Which ran, which passed, which were skipped and why |
| Defects | Open defects by severity and owner (Contoso, partner, SAP), with workarounds |
| Extensions and integrations | Coverage and results for each high-priority item |
| Risks and decisions | Residual risks, user communication, actions needed before or right after production |
| Recommendation | Ready, ready with conditions, or not ready (with escalation) |
A release readiness report the Contoso what-if team could reuse every release.
- Results in Cloud ALMAutomated and manual runs, defects linked to steps
- Daily statusShort update to Grace and process owners
- Readiness reportCoverage, defects, risks and recommendation
- Process owner reviewDan for finance, Maria's lead for order to cash
- Sign-off recordedBefore the production weekend, with conditions
- Post-upgrade checkSmoke test in production on the first business day
Make the numbers honest. Report blocked and not-run tests separately from failed ones; a 95% pass rate on 40% of the planned tests is not a 95% result. Show the coverage of critical processes explicitly, because that is what process owners sign for. And link each figure to its evidence in SAP Cloud ALM, so that an auditor or Grace can open the run, the screenshot and the defect behind any number in the report.
After the production upgrade, close the loop. Run the short production smoke test, collect incidents from the first week, and feed them back into the regression pack: every escaped defect is a missing test. Update the release calendar, the automates that needed maintenance and the extension inventory, so the next window starts from a better baseline.
When the answer is "not ready"
Because you cannot postpone the upgrade, "not ready" must turn into action: a workaround documented and trained, a fix raised with SAP with evidence and business impact, a temporary manual control, or a decision to delay activating an optional feature. Escalate early. A critical defect found on day three gives SAP support and your own team time to respond; the same defect found on the last day does not.
What would you do?
Two days before the production weekend in the what-if, one high-severity defect remains: the purchase order approval step is skipped for POs over $25,000. A manual approval workaround exists. What should the readiness report recommend?
- Sign-off in Public Edition confirms readiness before SAP's fixed production date; it cannot delay the upgrade.
- A short readiness report covers scope, execution, post-upgrade tests, defects, extensions, risks and a recommendation.
- Turn "not ready" into actions: workarounds, escalation, manual controls or delaying optional features.
- Record the process owner's sign-off with the evidence, then smoke test production on the first business day.
Check your understanding · not graded
Lesson check
1. What is the purpose of sign-off when SAP fixes the production upgrade date?
2. Which item belongs in the readiness report's post-upgrade test section?
3. A high-impact defect has no workaround three days into the window. What is the right move?