Release calendars and freeze periods

A release calendar sets when changes can go into production. Instead of importing each change whenever it is ready, approved changes are grouped into releases with fixed dates, a test cycle before each, and agreed windows for the import itself. Predictable dates let testers plan regression, the business plan around downtime, and auditors see a pattern.

Release types

Release type	Typical cadence	Contents	Contoso example
Major release	Two to four per year	Projects, larger enhancements, SAP feature or support pack updates	Quarterly release with a new credit management enhancement
Minor release	Monthly or every two weeks	Normal changes and non-urgent fixes	Monthly release with pricing and output form changes
Emergency deployment	As needed	Emergency changes only	Payment file fix on a Friday

Common release types. Cadences vary by organization; the point is that they are planned and published.

Freeze periods

A freeze is a period when only emergency changes may go into production. In SAP landscapes the most common freezes protect period-end close and peak business seasons. Dan wants no imports during the last three and first three working days of each month while finance closes the books, and a longer freeze around fiscal year-end. Maria wants no order-to-cash changes during the peak fleet ordering weeks before spring.

Week 1Release scope lockedApproved normal changes assigned to the release
Weeks 2–3Build and testTransports imported to QAS; functional and regression testing
Week 4, MonGo/no-goChange manager and business approvers review evidence
Week 4, SatImport windowTransports imported to PRD in sequence; post-import checks
Month-endFinance freezeLast three and first three working days: emergency changes only

A monthly minor release at Contoso, timed to finish before the finance freeze.

The Sign-Off Table · thesignofftable.com/academy/sap-rel-101

SAP-driven windows

Your calendar also has to absorb changes that SAP delivers. For SAP S/4HANA on-premise and Cloud Private Edition, SAP moved to a two-year base release cycle after the 2023 release, with feature pack stacks roughly every six months and seven years of mainstream maintenance per base release. Private Edition customers must upgrade at least once in seven years to stay in mainstream maintenance, and under RISE with SAP can request one upgrade per year; SAP runs the technical upgrade, while planning and testing remain the customer's job. Each of those updates needs a slot in the calendar, a regression test cycle and a freeze on other changes while it is tested.

Normal release windowHigher-risk change in a quiet period: deploy with full testing and CAB approval

Avoid or emergency onlyHigher-risk change during close or peak: wait for the next window unless it is an emergency

Deploy routinelyLow-risk change in a quiet period: standard or minor release

Deploy with careLow-risk change in a critical period: only if the freeze rules allow it

Matching change risk to the business calendar.

The Sign-Off Table · thesignofftable.com/academy/sap-rel-101

Building the calendar

Start from the business calendar: period-end close, fiscal year-end, peak seasons, audits, planned shutdowns.
Add SAP-driven events: feature or support pack updates, upgrades, and for Public Edition the upgrade dates.
Add project go-lives, which usually need their own freeze before and after.
Place regular releases in the gaps, with test cycles before each.
Publish it, and change it only through the same change process.

Projects and support on one calendar

While a project is building the next major release, production still needs fixes. Many SAP landscapes handle this with a separate maintenance track: a second development and quality line for production support, so that urgent fixes do not have to wait behind half-finished project work. Two tracks mean two streams of transports heading for the same production system, and every fix made in the maintenance track must also reach the project track, or the next project release will overwrite it. The release calendar is where these streams are reconciled: it shows which release carries which fixes, and the release manager checks before each project release that every maintenance fix since the last one is included and tested.

What would you do?

A key user asks to import a new invoice output form on the second working day of the month because "it's only a layout change". Contoso is in its finance freeze. What should the change manager say?

Key points