Lesson 5 of 5
Go/no-go for upgrades
10 min
Listen to this lesson
The go/no-go decision for a production upgrade is a business decision taken on technical and test evidence. It needs criteria agreed in advance, evidence against each criterion, a fallback plan that has been thought through, and a record of who decided what. Without them, the decision becomes a mood in a meeting room, and the first serious defect after the update becomes a search for someone to blame.
Criteria
| Area | Criterion (Contoso example) | Evidence |
|---|---|---|
| Technical | Quality update completed without open technical issues; follow-up checklist complete | Technical verification report |
| Custom code | All adjustments complete; no open priority 1–2 findings in changed code | Adjustment lists, ATC results |
| Functional | 100% of critical process tests passed; no open critical or high defects; medium defects with workarounds accepted | Test plan status in SAP Cloud ALM |
| Integration | All critical interfaces tested end to end with partners | Interface test log |
| Performance | Critical runs within agreed tolerance of pre-update timings | Before-and-after comparison |
| Data | Data Transition Validation shows no unexplained differences | DTV results reviewed by Dan |
| Runtime | Measured downtime fits the agreed window with buffer | Quality iteration runtimes |
| Readiness | Runbook final, people available, communications ready, hypercare staffed | Cutover readiness checklist from Luis |
Go/no-go criteria for a production upgrade.
Agree these criteria before testing starts, with the people who will decide. Criteria written the day before the decision tend to be written around the results.
Fallback plan
Every go needs an answer to "what if it goes wrong?". For an upgrade, the realistic fallback during the downtime is usually to restore the system to its state before the update, from a backup or snapshot, and resume business on the old release. After users have started posting on the new release, going back becomes very costly, because new transactions would be lost or need re-entry. That is why the plan defines a point of no return: the last moment at which fallback is still acceptable. Under RISE, the restore capability and timings are SAP ECS services; confirm them with ECS before the go/no-go rather than assuming them.
- Saturday 20:00Ramp-downJobs stopped, users locked, queues cleared; backup confirmed. SUM uptime has run since ECS started it the day before.
- Saturday 21:00Technical updateSAP ECS completes the downtime phases; progress reported every two hours.
- Sunday 01:00CheckpointIs the update on plan against the quality iteration's runtimes? If not, restore and reschedule while that is still cheap.
- Sunday 01:30Follow-up and smokeFollow-up activities; technical and functional smoke tests; DTV validation.
- Sunday 04:00Go/no-go and point of no returnLast moment a restore still fits before 06:00; after this, fallback means business data loss or re-entry.
- Sunday 06:00Release to usersWindow closes; hypercare monitoring and daily defect triage from the first business day.
- Has the technical update completed within the window?Yes → continue · No → decide at the checkpoint: extend, or restore and reschedule
- Do smoke tests and DTV validation pass?Yes → continue · No → fix within the window, or restore
- Are any failures in critical processes without a workaround?Yes → restore or delay release to users · No → continue
- Is the point of no return reached with all criteria met?Yes → release to users · No → execute the fallback
The decision record
Record the decision in a form someone else can read a year later. The record lists each criterion with its status and evidence, all open defects and accepted risks with owners and workarounds, the fallback plan and point of no return, and the names of the decision-makers. At Contoso, Grace chairs, Priya presents the test evidence, Sam and SAP ECS present the technical status, Luis presents cutover readiness, and Dan and the sales process owner give the business sign-off for their areas.
- Criteria and status, each with a link to its evidence.
- Open defects and accepted risks, each with owner, workaround and fix date.
- Fallback plan, point of no return and who can call it.
- Hypercare plan: who watches what, for how long, with which escalation path.
- Names, roles and the decision, with date and time.
After go: close the loop
The upgrade is not done when users log on. Hypercare tracks incidents against the upgrade, the automated regression suite runs on the new release as its new baseline, and the obsolete data left by data model changes can be cleaned up. The upgrade guide notes that obsolete data is not deleted automatically during the upgrade and that the Obsolete Data Handling tool (transaction SODH as of 2023) should be used only after the upgrade results have been tested and validated. Finally, a short lessons-learned review feeds the next update's plan.
What would you do?
At 03:00 on the production update Sunday, smoke tests pass but DTV shows a difference in open customer items for company code 1710 that nobody can explain yet. The point of no return is at 04:00. What should Grace do?
- Agree go/no-go criteria per stream before testing starts, with the decision-makers.
- Plan the fallback and a point of no return; confirm restore capability with SAP ECS under RISE.
- Record criteria, evidence, open risks, fallback, hypercare and named decision-makers.
- Process owners sign off their own areas; nobody signs on their behalf.
- After go: hypercare, a new regression baseline, obsolete data cleanup after validation, lessons learned.
Check your understanding · not graded
Lesson check
1. What is the point of no return in an upgrade weekend?
2. When should go/no-go criteria be agreed?
3. When should obsolete data from data model changes be cleaned up, per the upgrade guide?