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

Lesson 4 of 5

Coordinating with testing

10 min

Listen to this lesson

0:00 / 5:51

A maintenance event is a change to production like any other, and often a bigger one than a month of project transports. It needs a slot in the release calendar, an agreed test scope and a sign-off. The Basis team owns the technical import; the release manager owns the calendar; the test lead owns the evidence. This lesson is about making those three line up.

  1. Week 0PlanTarget stack chosen in Maintenance Planner; release notes and side effects reviewed; test scope agreed
  2. Week 1CMDStack applied; SPDD/SPAU done; adjustment transports created; developer checks
  3. Week 2CMQ importStack plus adjustment transports applied; environment checked and handed to testers
  4. Weeks 2–4RegressionRisk-based regression and new-feature checks, in CMR since go-live (CMQ during the conversion program); defects fixed by transport
  5. Week 5Go/no-go and CMPSign-off, then production import in an agreed downtime window with fallback
A typical support package stack calendar. Real durations depend on scope and test capacity.
The Sign-Off Table · thesignofftable.com/academy/sap-bas-203

Keep the landscape in step

Two transport rules protect the process. First, transports should not move between systems on different support package levels; SAP training notes that the transport system checks component versions and warns when they do not match, and that transports from a newer SP level should not go to an older one. Second, during the window when CMD and CMQ have the new stack but CMP does not, urgent production fixes need a plan: either a separate path that matches CMP's level, or a short freeze. Decide this before the event, not during an incident.

During the maintenance window the landscape is split by SP level, so normal transports must not flow from the newer systems into CMP.
The Sign-Off Table · thesignofftable.com/academy/sap-bas-203
  1. Is CMQ on the same stack that will go to CMP?Yes → test results apply to the production change · No → align CMQ first; otherwise results are not valid evidence
  2. Do project transports need to move during the maintenance window?Yes → agree whether they wait or are retested on the new stack · No → freeze project imports for the window
  3. Could an urgent production fix be needed before CMP is updated?Yes → define the fix path for CMP's current level · No → document the assumption
Questions to settle when maintenance overlaps with project work.
The Sign-Off Table · thesignofftable.com/academy/sap-bas-203

Choosing the test scope

Testing everything after every stack is rarely affordable, and testing nothing is reckless. A risk-based scope combines three inputs: what changed (components and objects in the stack, notes reset in SPAU, re-applied modifications), what Contoso uses (the critical business processes and integrations), and what broke before (areas with a defect history). Tools such as SAP Cloud ALM or SAP Solution Manager can help relate technical changes to tested processes; the decision on scope still belongs to the test lead and process owners.

The three inputs to a risk-based regression scope for a stack; the test lead and process owners make the final call.
The Sign-Off Table · thesignofftable.com/academy/sap-bas-203
AreaWhy test it after a stackContoso example
Critical end-to-end processesMost business impact if brokenOrder to cash for Great Lakes Fleet Services; procure to pay with Lakeside Components
Re-applied modifications and custom codeMost likely to conflict with new SAP codeKenji's three modified programs and the pricing enhancement
Interfaces and outputsTechnical changes often surface here firstEDI orders, invoice output, bank file
Authorizations and Fiori appsNew or changed apps and roles may hide tiles or block stepsMaria's order management apps
Period-end and legal functionsLegal changes in the stack affect them directlyTax reporting and month-end close

A risk-based regression scope for a support package stack.

Two landscapes, two calendars

Until the ECC systems ED1, EQ1 and EP1 are retired, Contoso maintains two landscapes. The ECC support team plans its maintenance through ChaRM in SAP Solution Manager 7.2, while the S/4HANA program plans in SAP Cloud ALM. Luis keeps one combined calendar so that a support package stack on the ECC side never lands in the same weekend as a mock conversion or a CMQ test cycle on the S/4HANA side, and so that the same Basis staff are not booked twice. Test evidence for each maintenance event is attached to the release in the tool that governs that landscape.

What would you do?

Luis wants to import a support package stack into CMP the weekend after Contoso's quarter-end close, but regression in CMR is only half done. Grace asks for a recommendation. What should Sam say?

Key points
  • Treat maintenance as a release: calendar slot, test scope, sign-off, fallback.
  • Keep CMD, CMQ and CMP on matching levels; do not move transports to older SP levels.
  • Plan how urgent production fixes travel while systems are on different stacks.
  • Scope regression by what changed, what is critical and what broke before.

Check your understanding · not graded

Lesson check

  1. 1. Why must CMQ carry the same stack planned for CMP?

  2. 2. What does the transport system do when component versions differ between systems?

  3. 3. Which input belongs in a risk-based regression scope?

  4. 4. Who decides on reducing the agreed regression scope?