Lesson 2 of 6
Release cadence by edition
8 min
How often SAP S/4HANA changes, and who decides when, depends on the edition. That sets the rhythm and the size of the test window, so the regression approach has to match it.
On-premise and Cloud Private Edition
In 2022, SAP announced a release strategy for SAP S/4HANA with a new release every two years starting with SAP S/4HANA 2023, so the next release after it is SAP S/4HANA 2025. During roughly the first two years of each release, SAP plans feature packs about every six months, which add innovations without a full upgrade; later, support packages deliver corrections. Each release receives seven years of mainstream maintenance. Between these, SAP Notes deliver individual corrections, and SAP publishes security notes on a monthly patch day.
The key point for the business: in on-premise and Private Edition, the customer decides when to apply a release, feature pack or support package, within the maintenance rules and, for Private Edition, in agreement with SAP as the operator. That allows a test window sized to the change: weeks or months for a release upgrade, shorter for a feature pack or support package stack. Check the current schedule and maintenance dates for your release on the SAP Help Portal and in the upgrade guide.
Cloud Public Edition
SAP S/4HANA Cloud Public Edition is software as a service. SAP upgrades every customer on a fixed schedule: two major releases a year, in February and August (named by year and month, for example 2602 and 2608), with smaller continuous feature deliveries and regular corrections in between. Customers cannot skip an upgrade. SAP typically upgrades the test system first and production about two weeks later, which gives a short, fixed regression window. The exact dates for each tenant are published by SAP in advance; check them in the upgrade and maintenance schedule rather than assuming.
| On-premise / Private Edition | Cloud Public Edition | |
|---|---|---|
| Major releases | Every two years (2023, 2025, …) | Two per year (February and August) |
| Between majors | Feature packs about every six months in the first two years; support packages; SAP Notes | Continuous feature delivery and regular corrections |
| Who decides timing | Customer, within maintenance rules and (Private Edition) with SAP | SAP, on a published schedule |
| Typical test window | Planned by the customer; weeks to months for a release | Short and fixed: between test and production upgrade, often about two weeks |
| Regression approach | Larger, planned cycles; deeper per change | Lean, repeatable, often automated core pack run twice a year |
Notes, support packages and feature packs
Not every SAP change is equal. An SAP Note is a single correction, sometimes with prerequisite notes, applied to a specific problem; its regression scope is usually narrow and can be read from the note's description of affected objects. A support package stack bundles many corrections and is applied as a unit. A feature pack adds new functions as well as corrections. A release upgrade moves to a new product version with simplifications, deprecations and new features. The regression scope grows with each step, and so should the test window.
| Change type | Content | Typical regression scope |
|---|---|---|
| SAP Note | One correction | Targeted scenarios around the corrected objects; core pack if the area is critical |
| Security note (patch day) | Security correction | Targeted checks on affected components; often a smoke check |
| Support package stack | Bundled corrections | Core pack plus targeted tests for changed areas |
| Feature pack | New functions and corrections | Core pack, targeted tests, new feature tests where adopted |
| Release upgrade | New version with simplifications and deprecations | Full regression cycle, role and custom code checks, new feature tests |
Your own changes count too
SAP's calendar is only half of the change. Contoso's own transports, role changes, master data rule changes and interface updates also need regression. Many companies bundle their own changes into regular release trains, such as monthly, so regression runs on a predictable schedule instead of after every transport.
- MonthlyContoso release trainBundled transports; targeted regression plus a small core pack
- MonthlySAP security patch dayAssess security notes; apply relevant ones with targeted regression
- About every six monthsFeature pack or support package stackCore regression pack plus targeted tests for changed areas
- Every two years (optional timing)Release upgradeFull regression cycle, new feature tests, role and custom code checks
What would you do?
Contoso is evaluating whether a future subsidiary should run on Cloud Public Edition. Grace asks what changes for regression testing. What is the most accurate answer?
- On-premise and Private Edition: a release every two years from 2023, feature packs about every six months early on, seven years of mainstream maintenance.
- The customer chooses timing in on-premise and Private Edition, so test windows can be sized to the change.
- Public Edition: SAP upgrades everyone twice a year with a short, fixed test window.
- Your own transports and role changes need regression too; release trains make it predictable.
- Put SAP dates, release trains and business peaks on one calendar.
Check your understanding · not graded
Lesson check
1. How often does SAP plan a new SAP S/4HANA on-premise release under the strategy announced in 2022?
2. Who decides the upgrade timing in Cloud Public Edition?
3. How many major Public Edition releases are there per year?
4. Why do many companies bundle their own transports into release trains?