“When can we upgrade?” is usually the wrong question.
- SAP’s cadence — a base release every two years, seven years of mainstream maintenance, feature packs roughly every six months, and at least one release in maintenance through 2040 — means support is rarely the real constraint.
- The constraint is the calendar. Treating “get current” as a one-off project compresses sandbox, evaluation and testing into the weeks before go-live — and that compression is where most of the risk sits.
- Anchor on a cutover worth protecting — often the weekend after a fiscal period close — and plan backward across DEV → QAS → PRD. The sequence holds whether SAP runs the upgrade under RISE or you own it on-premise. Release currency becomes a rhythm you schedule, not an event you brace for.
The instinct to schedule currency as a large, discrete effort is understandable — but under SAP’s current cadence it works against you. The more sustainable posture is to treat staying current as a standing rhythm rather than a periodic project, and SAP’s own release model and upgrade guidance make that entirely practical.
SAP gives you room
Since the 2023 release, SAP S/4HANA has run on a two-year base-release cycle with seven years of mainstream maintenance per release. Between base releases, feature packs arrive roughly every six months across the first two years and add new, non-disruptive capability; once the next base release ships, the prior one moves to support packs carrying corrections only. SAP has also stated that at least one release will always be in maintenance through 2040.
The practical implication is that, for most organizations, support is rarely the binding constraint. The decision to move is really about value capture and risk posture — which release or feature pack is worth landing on, and when the business can absorb it without disturbing the close — not about staying inside a support window.
The method SAP actually prescribes
SAP’s own guidance is refreshingly concrete. It distinguishes a technical upgrade — performance, security, compatibility — from a functional one that adds capability, and recommends treating either as a small project with a business case and an effort estimate rather than a background task. It points teams to the SAP Readiness Check to understand source-to-target impact before committing.
It also fixes the landscape sequence: development, then quality assurance, then production — DEV → QAS → PRD — with a transport freeze across the technical window so the test environment stays valid. For cloud landscapes, SAP issues an upgrade notification roughly six weeks ahead of the test-system upgrade, which is a useful proxy for how much runway the surrounding work needs.
RISE or on-premise: same choreography, different hands
The deployment model changes who does the work, not the shape of it. Under RISE with SAP / private cloud, SAP performs the technical upgrade and each customer is entitled to one upgrade per year; planning, preparation and testing remain with the customer and its partner. On-premise, the customer owns every step. In both cases the sequence — and the discipline of protecting the cutover — is identical.
Plan backward from the go-live
Choose the cutover you want to protect, then work backward across the landscape — and the upgrade becomes choreography rather than a scramble.
Instead of asking when there is room for an upgrade project, choose the production cutover you most want to protect — commonly the weekend after a fiscal period close — and plan backward from it: sandbox and technical trial, evaluation and Readiness Check, a clear go decision, DEV, QAS, regression and UAT, and finally the production cutover, followed by hypercare. Sequenced this way, the phases have room to breathe, and the compression that causes most go-live pain simply does not occur.
The upgrade accelerator
A short planner that does exactly this: set the cutover, choose the release or feature pack you intend to land on, and it lays the schedule backward across the landscape — flagging the two things that quietly derail plans, namely starting sandbox work before the release is available, and a cutover that collides with a period close.
Open the upgrade accelerator →Approached this way, release currency stops being a periodic scramble and becomes something closer to routine maintenance of a valuable asset: planned, unhurried, and timed to the business rather than to the support calendar.
Sources — SAP official
- Release & maintenance strategy. SAP News, “New SAP S/4HANA Release and Maintenance Strategy” — two-year cycle, seven-year maintenance, ~6-month feature packs, maintenance commitment to 2040.
- Release upgrade cadence & responsibilities. SAP Learning, “Navigating Release Upgrades” — FPS vs SPS cadence; on-premise vs RISE ownership; What’s New Viewer and SAP Road Map Explorer.
- Upgrade method & landscape sequence. SAP Learning, “Know Your Upgrade Cycle” — technical vs functional upgrade, business case and effort estimation, DEV → QAS → PRD sequence, transport freeze, SAP Activate for upgrades.
- Upgrade lead time & testing. SAP Help Portal, “Upgrade Guidance” — ~6-week upgrade notification, regression testing on the test system, transports forwarded to production promptly.
- Current release specifics. Confirm SAP S/4HANA 2025 general availability, maintenance window and 2027 planning in the release’s Release Information Note and Restriction Note via SAP for Me / SAP Support Portal.
Verify before committing a plan: SAP Note 3493301 (2025 Release Information Note), SAP Note 3059197 (SAP Readiness Check for S/4HANA upgrades), and the RISE / private-cloud release & maintenance strategy notes. SAP planning statements are subject to change without notice.