A recurring date on the SAP calendar deserves considerably more attention than it typically gets, precisely because missing it does not produce an obvious, immediate consequence, only a quiet, automatic renewal at whatever terms are currently in place. SAP support contracts auto-renew every January, and to give notice of a change in strategy or to exit at year end, customers must provide three months’ written notice, a requirement SAP has publicly confirmed, which makes September 30 the practical decision point every single year. If your organisation did not actively review its support strategy before that date passed this year, the contract has now quietly rolled into another twelve months on its existing terms, and it is worth understanding exactly what that means before the same window arrives again.
Why This Deadline Is Easy to Miss Entirely
The mechanics of this deadline make it genuinely easy to overlook, since nothing dramatic happens on September 30 itself if an organisation takes no action. The contract simply renews for another twelve months on its existing terms, cost structure, and any embedded uplift, exactly as it would if someone had actively chosen to renew it. That silence is precisely the problem. An organisation weighing whether to change its support strategy, whether by moving to a third-party provider, restructuring which parts of its landscape carry premium support, or beginning a broader renegotiation, only has real leverage to act on that decision if it moves before the notice deadline. Missing it does not simply delay the decision. It removes the option to make it at all for another full year.
Why This Matters More in the Current SAP Environment Specifically
This deadline carries particular weight in the current commercial environment, given how actively SAP has been reinforcing its own roadmap timelines at recent events. At SAP Sapphire 2026, SAP doubled down on the shift toward AI-led platforms, reinforced fixed ECC end-of-support deadlines, and tightened the commercial linkage between cloud adoption and access to innovation, particularly around AI capability.
An organisation still weighing whether to remain on ECC a while longer, migrate to RISE or GROW, or explore third-party support for at least part of its landscape is making exactly the kind of decision this September 30 notice period governs. If this year’s window has already closed without a deliberate choice being made, the organisation is now locked into another year on its current terms regardless of how that broader migration planning is actually progressing, which makes the next twelve months the right time to prepare properly rather than repeat the same pattern.
What Keeping ECC in Place Actually Requires
It is worth being direct about what staying on ECC while this broader decision plays out actually involves, since choosing not to migrate yet is not the same as choosing to do nothing. Preserving the freedom to keep running a current release, protecting existing perpetual licence value, and controlling the pace of any future move all depend on the support contract itself remaining in a state the organisation has actively chosen, rather than one it has simply allowed to continue by missing the notice window.
Building the Discipline for Next Year’s Window
Given how automatic this renewal is, the practical response now is building a standing calendar reminder well ahead of September 30 next year, not simply noting the date once, since the same three-month notice requirement recurs annually regardless of whether the organisation acted on it the year before. Confirming the exact notice period specified in your own contract directly, since terms can vary, and using the months in between to decide deliberately whether to renew, renegotiate, or begin an exit process, rather than letting the date arrive again without a plan, is the discipline that keeps this specific date working for the organisation’s own timeline rather than against it.
Why RISE and GROW Customers Are Working Under a Different Clock Entirely
It is worth being precise about which SAP customers this specific September 30 mechanic actually applies to, since organisations that have already migrated to RISE or GROW with SAP are operating under a genuinely different contractual structure. RISE with SAP consolidates licensing, cloud infrastructure, and technical managed services into a single subscription governed by its own service level agreement, with SAP itself provisioning infrastructure and providing technical operations rather than the traditional standalone support contract this notice period governs, and the standard RISE uptime commitment excludes planned maintenance windows of up to eight hours a month from its availability calculation entirely.
That means an organisation that has already moved to RISE or GROW is not tracking the same September 30 notice deadline described above, since its support and infrastructure commitments now run on the subscription’s own renewal cycle rather than the separate maintenance contract this specific mechanic governs. What it should be tracking instead is exactly what its own RISE or GROW agreement’s SLA actually commits to, since the headline uptime figure quoted at signature typically excludes several categories of downtime, planned maintenance chief among them, that a customer migrating from a traditional on-premise support relationship may not expect to see carved out of an availability guarantee.
The RACI Gap That Catches Organisations Mid-Migration
Organisations currently in the process of migrating from a traditional support contract toward RISE or GROW face a particular risk worth naming directly: a period where the old notice-period mechanics and the new subscription-based SLA structure both apply to different parts of the landscape simultaneously, and where responsibility for a given system’s uptime, patching, or incident response can genuinely sit in an ambiguous space between SAP, an implementation partner, and the organisation’s own team. Confirming explicitly, in writing, exactly where that responsibility boundary sits for every system still mid-migration, rather than assuming RISE’s own standard responsibility matrix covers a scenario it was not originally designed for, is worth doing before, not after, an incident exposes the gap.
Conclusion
SAP’s annual support renewal cycle, requiring three months’ written notice ahead of a January auto-renewal, makes September 30 the genuine, recurring decision point for any organisation weighing a change to its SAP support strategy, and the absence of any dramatic consequence for missing it is exactly what makes it so easy to let pass without a deliberate choice, as many organisations will have just done this year.
Confirming exactly what your current contract now locks in for the next twelve months, and building a standing, recurring reminder well ahead of next September’s window, are the practical steps that turn this year’s missed decision into a properly planned one when the date comes back around.
