Lesson 4 of 6
Scheduling around SAP's cadence
7 min
Listen to this lesson
Much of the change in an SAP landscape arrives on SAP's schedule, not yours. A regression strategy that ignores that schedule is always surprised. This lesson sets out the cadence for SAP S/4HANA in the private cloud and on premise, then the different rhythm of SAP S/4HANA Cloud Public Edition, and then how to turn both into a regression calendar.
Since the 2023 release, SAP has shipped a new SAP S/4HANA base release every two years, and extended mainstream maintenance for each release from five to seven years. Between base releases, the current release receives feature package stacks (FPS) roughly every six months: corrections plus new, non-disruptive features that you can choose to use. Once a newer base release ships, the older one receives support package stacks (SPS) roughly every six months: corrections and legal changes only, until its mainstream maintenance ends. SAP S/4HANA Cloud Private Edition follows the same release cadence because it runs the same software.
- Late 2023SAP S/4HANA 2023 base releaseStart of the two-year cycle and seven years of mainstream maintenance.
- About every 6 monthsFeature package stacks for 2023Corrections plus optional new features, until the next base release.
- Late 2025SAP S/4HANA 2025 base releaseContoso's release. From now on, 2023 receives correction-only support package stacks.
- About every 6 monthsFeature package stacks for 2025Each stack is a regression event, even when you activate no new features.
- Next base release2025 moves to support package stacksCorrection-only stacks until the end of its mainstream maintenance.
Two consequences matter for testers. First, an FPS is a regression event even if the business switches on no new feature: corrections and changed objects arrive regardless. Second, the upgrade to a new base release is the largest regression event in the cycle. It brings simplification items, custom code adaptation, and the modification adjustment steps (SPDD for dictionary objects, SPAU for repository objects and implemented notes) that developers work through during and after the upgrade. Under RISE with SAP, SAP performs the technical upgrade, but planning, preparation and testing remain the customer's job, so the regression effort is entirely Contoso's to plan. Smaller events sit on top of this cycle. SAP publishes security notes on its monthly security patch day, the second Tuesday of each month, so many run teams reserve a fixed monthly window for evaluating and testing them, which turns an unpredictable stream into a routine. The table matches each kind of event to a regression depth.
| Change event | What changes | Regression scope | Plan ahead |
|---|---|---|---|
| Release upgrade (for example 2025 to the next base release) | Large parts of the standard code, simplification items, custom code adaptation | Smoke, core and extended in full, plus custom code and interface tests | Months; book key users and freeze windows early |
| Feature or support package stack | Hundreds to thousands of SAP objects | Smoke and core, plus extended tests for areas the stack touches | Weeks; align with the quarterly business calendar |
| Individual SAP Note | One or a few objects, sometimes with prerequisite notes | Smoke plus tests linked to the affected process steps | Days; part of normal change control |
| Monthly security notes | Security corrections across the stack | Smoke plus targeted tests for affected components | Monthly slot after SAP's security patch day |
| Configuration or custom code transport | Customer objects | Smoke plus targeted and affected core tests | Normal release rhythm |
Matching regression depth to the change event.
Public Edition is different
In SAP S/4HANA Cloud Public Edition, the customer does not choose when to upgrade. SAP upgrades all customer systems twice a year, with major releases in February and August. The administrator is notified by email about six weeks ahead. SAP upgrades the test system first; the development and production systems follow about three weeks later. Those weeks are the customer's regression window. Between releases, SAP delivers corrections through hotfix collections on a regular cycle of roughly every two weeks, on a published schedule. The fixed window changes the strategy. SAP takes on more of the regression risk for unchanged standard processes, but the customer owns regression for everything it has configured differently, extended or integrated. The window cannot move, so the suite must be ready before the notification arrives, and automation matters more.
- About 6 weeks beforeUpgrade notificationConfirm the suite, refresh test data, book key users, read the release information.
- Upgrade weekendTest system upgradedSAP can run its post-upgrade tests for unchanged standard processes, with customer consent.
- Next ~3 weeksCustomer regression windowRun regression on customized processes, extensions and integrations in the test system.
- About 3 weeks afterDevelopment and production upgradedSmoke test production immediately; monitor the first business days closely.
Building the regression calendar
- Put every known SAP delivery on one calendar: stacks you plan to apply, upgrade dates, monthly security notes, and Public Edition upgrades and hotfix collections where relevant.
- Mark business blackout periods: month-end and quarter-end close, peak shipping weeks, audits.
- Place each regression window so it does not collide with a blackout, and so the production import lands early in a quiet period, not on the day before close.
- Book key users by name for each window. Maria and Dan cannot test order to cash and finance during quarter-end close.
- Hold a small reserve window for emergency notes, so an urgent fix does not displace a planned regression run.
What would you do?
Contoso plans to apply the next feature package stack for SAP S/4HANA 2025. The only free QAS window places the production import on the last working day of the quarter. Dan, the finance process owner, will be busy with quarter-end close. What should Priya recommend?
- Since 2023: a base release every two years, seven years of mainstream maintenance, feature or support package stacks roughly every six months.
- Every stack is a regression event; a release upgrade is the largest one and the customer owns its testing, even under RISE.
- Public Edition: upgrades twice a year, test system first, about three weeks to regress before production, hotfix collections in between.
- Plan one regression calendar that combines SAP's cadence, business blackouts and named key users.
Check your understanding · not graded
Lesson check
1. What do feature package stacks deliver for the current SAP S/4HANA release?
2. Under RISE with SAP, who is responsible for regression testing a release upgrade?
3. In Public Edition, which system does SAP upgrade first?
4. When does SAP publish its monthly security notes?