Lesson 3 of 5
Release cadence and upgrades
10 min
Listen to this lesson
The software under an SAP system changes on a rhythm. In the public edition SAP sets that rhythm; in the private edition and on-premise the customer chooses within limits. Cadence is the dimension that most directly drives regression testing, so it deserves careful reading.
Public Edition: twice a year, on SAP's schedule
SAP S/4HANA Cloud Public Edition has two major releases a year, in February and August, named by year and month (for example 2508 for August 2025). Smaller, non-disruptive features also arrive between major releases through continuous feature delivery; customers can activate them early, and otherwise they are enabled at the next major release if relevant to the customer's scope.
Customers receive notice about six weeks before an upgrade. SAP upgrades the test system first, then the development and production systems about three weeks later. Those three weeks are the regression window: partners and customers run regression tests in the test system before production is upgraded.
- Upgrade minus 6 weeksNotificationCustomer is told the upgrade dates; release information is published
- Upgrade minus 6 to 3 weeksImpact analysisReview release information and the scope-dependent impact; update tests
- Test system upgradedRegression window opensRun automated and manual regression on the upgraded test system
- About 3 weeks laterDevelopment and production upgradedSmoke test production; watch the first business days
Private Edition and on-premise: a two-year rhythm you control
The private edition follows the on-premise release cycle, because it is the same software. After the 2023 release, SAP moved to a two-year cycle: a new base release every other year, with feature pack stacks every six months that add non-disruptive features until the next base release. Mainstream maintenance for each base release was extended from five to seven years; once a newer base release ships, the older one gets support pack stacks with corrections only.
Customers decide when to upgrade, but they must install at least one upgrade every seven years to stay in mainstream maintenance. Under RISE with SAP, customers can request one upgrade per year from SAP. SAP executes the technical upgrade; planning, preparation, testing and other non-technical activities are the customer's or the partner's job.
| Aspect | Public Edition | Private Edition | On-premise |
|---|---|---|---|
| Major change | Twice a year (Feb, Aug) | New base release every two years | New base release every two years |
| In between | Continuous feature delivery | Feature pack stacks every 6 months | Feature pack stacks every 6 months |
| Who decides timing | SAP | Customer, within maintenance | Customer, within maintenance |
| Who runs the technical upgrade | SAP | SAP | Customer or its partner |
| Who tests | Customer and partner | Customer and partner | Customer and partner |
Stacks are not all the same
A feature pack stack adds new, non-disruptive functions to a base release; a support pack stack on an older release carries corrections only; a release upgrade moves to a new base release and can bring simplification items that change how processes work. Each deserves a different test response. A support pack stack calls for a focused regression of the processes it touches; a feature pack stack adds checks that new functions stay switched off until the business wants them; a release upgrade needs a full regression cycle, custom code adaptation and often a fresh look at roles and Fiori content. Writing these three responses into the test strategy saves a debate every time a stack is planned.
What cadence means for Contoso
Contoso converts to SAP S/4HANA 2025. After go-live it can stay on that release for years, applying feature pack or support pack stacks when it chooses, and plan an upgrade to the next base release when the business case or maintenance dates require it. That control is valuable, but it is not free: every stack Contoso installs needs a regression run, and every year it postpones makes the eventual jump bigger.
What would you do?
Priya, Contoso's test lead, is asked by a colleague at a public edition customer how long she gets for upgrade regression. Her colleague has about three weeks twice a year. What is the key difference Priya should point out?
- Public Edition: two major releases a year (February and August), test system first, production about three weeks later.
- Private Edition and on-premise: base release every two years, feature pack stacks every six months, seven years of mainstream maintenance.
- Under RISE, SAP runs the technical upgrade and customers may request one upgrade a year; testing stays with the customer.
- Control over timing is valuable only if the test strategy plans for it.
Check your understanding · not graded
Lesson check
1. In which months does SAP S/4HANA Cloud Public Edition ship its major releases?
2. In a public edition upgrade, which system is upgraded first?
3. How long is mainstream maintenance for a private edition base release today?
4. Who tests a private edition upgrade under RISE with SAP?