Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 3 of 5

Maintenance events and their testing

10 min

Listen to this lesson

0:00 / 5:55

Under RISE, SAP executes most technical maintenance, but the customer still decides when it happens and proves afterwards that the business works. The R&R makes this explicit for updates: SAP implements them with standard tools, but any post-installation task that is not technical in nature, such as application settings or manual activities, must be performed by the customer. Regression testing is never part of SAP's standard service.

Maintenance typeR&R treatment (v.3-2025)Testing impact
Kernel patchesStandard; may require downtime. A Rolling Kernel Update service restarts instances one after another (needs at least two application servers)Light technical check; watch for behavior changes in custom code
Updates: support packages and Feature Package StacksStandard; requires scheduled downtime; excludes nZDT and ZDO approachesRegression of affected processes in CMR (CMQ during the program) before CMP
Updates or upgrades with the Zero Downtime OptionAdditional Service; may need extra resources and a QA or pre-production system for testingRegression plus tests of the uptime phase
Version upgrade (for example SAP S/4HANA 2023 to 2025)Technical execution standard; planning and coordination, and pre- and post-Basis tasks, are Packaged ServicesFull regression; SAP Readiness Check for upgrades is a standard service
SAP HANA database updatesStandard; additional downtime; systems with HA nodes use advanced update approaches by defaultTechnical checks and performance spot checks

Maintenance types and how SAP's R&R treats them. Confirm against your contract.

A Rolling Kernel Update restarts instances one after another, which is why it needs at least two application servers.
The Sign-Off Table · thesignofftable.com/academy/sap-bas-304

Planning the landscape sequence

  1. Week 0Release plan reviewSAP's release plan for the landscape (an R&R standard task) reviewed with Sam; target FPS chosen
  2. Week 1CMD updatedService request; SAP updates; Kenji's team fixes custom code and SPAU
  3. Week 3CMQ and CMR updatedSame procedure, same stack; Priya's regression cycle starts in CMR, the pre-production copy of CMP
  4. Week 5Regression sign-offProcess owners sign; open defects triaged
  5. Week 6CMP updatedDowntime in an agreed window; post-update smoke test; users released
An illustrative update cycle for Contoso. Durations depend on scope and the regression suite.
The Sign-Off Table · thesignofftable.com/academy/sap-bas-304

Three rules keep the sequence trustworthy. First, the same stack moves through CMD, CMQ, CMR and CMP; a production update with a different target than the one tested invalidates the regression. (CMR is the optional pre-production system Contoso added after go-live: a masked copy of CMP, client 100, where release regression now runs; during the conversion program regression ran in CMQ client 100.) Second, the regression starts only after the customer's own post-update steps are done in CMR, such as modification adjustment and application settings. Third, the CMP downtime is booked through the service request process with enough lead time, and communicated to users. SAP Cloud ALM's Business Service Management can show planned downtimes of private cloud systems against business services, so users see which functions are affected.

Kernel patch, low exposureTechnical check and short smoke test
FPS in a non-critical areaTargeted regression of affected apps and processes
Security note on a core processTargeted regression of that process plus authorizations
Version upgradeFull regression, performance check and business sign-off
Scale the regression to the change and its business exposure.
The Sign-Off Table · thesignofftable.com/academy/sap-bas-304

Not every maintenance event can wait for a full cycle. A critical security fix or a kernel patch for a production problem may need a shortened path. Agree that path in advance: which changes qualify, the minimum test in CMR (for example the affected process plus a smoke test of the top ten transactions and apps), who may approve the shortcut, and how the skipped regression is caught up afterwards. An emergency path written down in calm times is much safer than one invented during an incident.

The shortened maintenance path, agreed in calm times: it still has a minimum test, a named approver and a catch-up regression.
The Sign-Off Table · thesignofftable.com/academy/sap-bas-304

What would you do?

SAP's release plan suggests a Feature Package Stack update. Priya's regression on CMR is 70 percent done when SAP ECS offers an earlier CMP slot next weekend. Grace is tempted. What should Sam advise?

Key points
  • SAP executes kernel patches and updates as standard services; non-technical post-installation tasks and all regression testing are the customer's.
  • ZDO is an Additional Service and may need a QA or pre-production system for testing.
  • Move the same stack through CMD, CMQ, CMR and CMP; regress in CMR after the customer's own post-update steps.
  • Scale regression to change size and business exposure; book production downtime through service requests.

Check your understanding · not graded

Lesson check

  1. 1. After SAP applies an update, who performs non-technical post-installation steps such as application settings?

  2. 2. What does SAP's Rolling Kernel Update service require, per the R&R?

  3. 3. Why must the same stack move through CMD, CMQ and CMP?

  4. 4. Which SAP Cloud ALM capability can show planned downtimes of private cloud systems against business services?