The release calendar

Go-live is not the end of change. It is the start of a steady stream of it. SAP ships new software on a schedule, your own teams ship fixes and enhancements, and the business keeps asking for new scope. A process owner who reacts to each change as it arrives spends the year firefighting. One who can see the whole year on a single page can plan testing, protect the close, and say "not this month" with a reason.

This lesson builds that page. Contoso Motor Co. went live on SAP S/4HANA 2025 in SAP S/4HANA Cloud Private Edition. Dan owns record-to-report, Maria is the order-to-cash key user, and Priya, who led testing on the program, now runs the small quality team that supports releases. The calendar they need has two kinds of events: the ones SAP decides and the ones Contoso decides.

What SAP decides: Private Edition and on-premise

For on-premise and Private Edition, SAP moved after the 2023 release to a base release every two years (2023, then 2025). Between base releases, SAP ships Feature Pack Stacks (FPS) roughly every six months, which add non-disruptive features to the current release. Once a newer base release exists, the older one receives Support Pack Stacks (SPS) with corrections only. SAP has also extended mainstream maintenance for these releases to seven years, so a customer must move to a newer release at least once in that window to stay in mainstream maintenance.

The key point for a process owner: in Private Edition, you choose when to upgrade, within the maintenance rules. Under RISE with SAP, SAP performs the technical upgrade on request (SAP's learning material describes one upgrade per year as the entitlement), but planning, testing and business sign-off stay with the customer. Exact FPS dates and maintenance end dates change, so check SAP's release strategy pages and the Product Availability Matrix rather than relying on a slide from last year.

What SAP decides: Public Edition

SAP S/4HANA Cloud Public Edition is different. SAP upgrades every customer on a fixed schedule, twice a year, with major releases in February and August named by year and month (for example 2508 and 2602). Smaller feature deliveries and regular corrections arrive between the major upgrades. The test system is upgraded first and production follows a couple of weeks later, which is the window for regression testing. You cannot skip an upgrade. What you control is how prepared you are and which optional new scope you activate.

What Contoso decides

The second half of the calendar is internal: your own transports and enhancement releases, period-end and year-end close, audit fieldwork, peak sales seasons, plant shutdowns, holiday freezes, and the other programs competing for the same testers. Put them all on the same page. Most release conflicts are not technical. They are a release landing in the same week as year-end close or the same month the key users are on a rollout.

Notice what this calendar does. It bundles SAP's feature pack with Contoso's own enhancement release so the testers run one regression cycle, not two. It keeps releases away from close. And it books a planning slot in November, because a calendar nobody revisits is just a poster.

Building the page in five steps

1. List SAP events for the year: the feature pack or base release you plan to apply (Private Edition) or the two upgrade dates and test windows (Public Edition).
2. List business events that must not be disturbed: period-end and year-end close, audit fieldwork, peak shipping weeks, inventory counts.
3. List internal release slots: Contoso runs a quarterly enhancement release plus emergency fixes as needed.
4. Mark freeze periods and the regression window in front of each release, sized to the regression pack you will run.
5. Agree the page with the PMO lead, IT and the other process owners, then publish it where everyone can see it.

The regression window is the item most often drawn too small. Size it from the pack, not from hope: if the critical and high scenarios for record-to-report take Priya's team six working days with one retest cycle, the window is at least eight days, plus time to triage and fix what fails.