HANA News Blog

SAP ERP Extended Maintenance until 2033 - but with conditions

Jens Gleichmann • 7. Februar 2025

More time to switch from BSoH to S/4HANA

Recently handelsblatt released an article with a new SAP RISE option called SAP ERP, private edition, transition option. This option includes a extended maintenance until the end 2033. This means 3 years more compared to the original on-prem extended maintenance. This statement was confirmed by SAP on request of handelsblatt, but customers receive more details, such as the price, in the first half of the year. This is a quite unusual move of SAP without any official statement on the news page. Just to raise more doubts? Strategy? However a good move against the critics and the ever shorter timeline. Perhaps it is also a consequence of the growing shortage of experts for operating and migrating the large number of systems.


A short summary of the article

  • introduction of a new RISE option: "SAP ERP, private edition, transition option"
  • old systems (e.g. ECC) can be used until the end of 2033 if the option is part of the RISE contract
  • details will be announced soon (in the first half of the year)
  • no other change for on-prem customers - end of maintenance is 2027 with extended maintenance to 2030
  • a tradeoff: time exchanged for RISE


This raises some questions

  1. Which OS / DB combinations are supported? It will lead to new lifecycle discussions with other vendors
  2. Why it is not offered for the on-prem customers due to nearly the same maintenance effort? (the reason is obvious but the answer maybe interesting)
  3. Can customers who signed the RISE transition option contract directly jump to a possible successor of RISE and S/4HANA? 


As SAP provided further details in its fourth quarter results release:

  • the new option is only for a very few large customers
  • it's not about the extension of on-premise maintenance
  • all cloud solutions will run on HANA Cloud?!


The statement regarding HANA Cloud is a little bit misleading and can also be a slip of the tongue. However, all cloud solutions would imply also RISE and GROW. The heart of HANA 2.0 still beats under the hood of RISE and GROW. HANA Cloud is a separate product with its own line of code and its own lifecycle that cannot (yet) be used for S/4HANA.


Here the original transcript from seekingalpha:

Some assumptions

  • Only ERP 6.0 EhP8 will be supported until 2033 to reduce maintenance effort (release and kernel)
  • Only HANA systems will be supported until 2033 to raise the HANA revenue
Product RTC EoM Lifetime
ERP 6.0 2006 31.12.2025 / 27 / 30 / 33 19 / 21 / 24 / 27 years
S/4 HANA 2015 31.12.2040 25 years
Product version RTC EoM Lifetime
ERP 6.0 EhP 0 2006 31.12.2025 19 years
ERP 6.0 EhP 6 2012 31.12.2027 / 2030 15 / 18 years
S/4 HANA 2023 2023 31.12.2030 7 years
S/4 HANA 2025 2025 31.12.2032 7 years

The single product versions with ERP 6.0 had longer runtimes compared to S/4HANA. In summary the complete product ERP has 19 - 27 years depending on the version and extension option.

Ten years before (2030) S/4HANA will go out of maintenance (2040) they have to release a successor or extend the EoM date of S/4 to 2042 or 2043 to give customer enough time to migrate. Is it like a football or chess game and we see the result only at the end and not in the first half of the game?

SAP HANA News by XLC

Is the effort for NSE worth it?

von Jens Gleichmann • 18. April 2025
Is NSE worth the effort or is the better question: Do you know your cost per GB of RAM?
Buch: SAP HANA Deepdive

Buchtipp: SAP HANA Deepdive: Optimierung und Stabilität im Betrieb

von Jens Gleichmann und Matthias Sander • 30. März 2025
Unser erster Buch mit dem Titel "SAP HANA Deepdive: Optimierung und Stabilität im Betrieb" ist erschienen.
Performance degradation after upgrade to SPS07

Ongoing HEX performance issues with SPS07

von Jens Gleichmann • 3. Februar 2025
With SPS06 and even stronger in SPS07 the HEX engine was pushed to be used more often. This results on the one hand side in easy scenario to perfect results with lower memory and CPU consumption ending up in faster response times. But in scenarios with FAE (for all entries) together with FDA (fast data access), it can result in bad performance. After some customers upgraded their first systems to SPS07 I recommended to wait for Rev. 73/74. But some started early with Rev. 71/72 and we had to troubleshoot many statement. If you have similar performance issues after the upgrade to SPS07 feel free to contact us! Our current recommendation is to use Rev. 74 with some workarounds. The performance degradation is extreme in systems like EWM and BW with high analytical workload.
Optimize your SAP HANA with NSE

Smart SAP HANA Optimization: Applying NSE for Better Efficiency

von Matthias Sander • 15. Januar 2025
When it comes to optimizing SAP HANA, the balance between performance and cost efficiency is critical. I am happy to share a success story where we used the Native Storage Extension (NSE) to significantly optimize memory usage while being able to adjust the sizing at the end. The Challenge: Our client was operating on a 4 TB memory SAP HANA system, where increasing data loads were driving up costs and memory usage. They needed a solution to right-size their system without compromising performance or scalability. The client wanted to use less hardware in the future. The Solution: We implemented NSE to offload less frequently accessed data from memory. The activation was customized based on table usage patterns: 6 tables fully transitioned to NSE 1 table partially transitioned (single partition) 1 table transitioned by specific columns
SAP HANA NSE - a technical deepdive with Q&A

HANA NSE - technical details Q&A

von Jens Gleichmann • 6. Januar 2025
SAP NSE was introduced with HANA 2.0 SPS04 and based on a similar approach like data aging. Data aging based on a application level approach which has a side effect if you are using a lot of Z-coding. You have to use special BADI's to access the correct data. This means you have to adapt your coding if you are using it for Z-tables or using not SAP standard functions for accessing the data in your Z-coding. In this blog we will talk about the technical aspects in more detail.
The SAP Enterprise Cloud Services Private Cloud Customer Center (PC3) - a new digital delivery

3 years of RISE with SAP: ECS realignment

von Jens Gleichmann • 5. Januar 2025
The SAP Enterprise Cloud Services Private Cloud Customer Center (PC3) - a new digital delivery engagement model dedicated to manage service delivery for RISE with SAP S/4HANA Cloud, private edition customers.
Proactive maintenance for SAP RISE will start now in 2025

SAP RISE: Proactive Maintenance

von Jens Gleichmann • 5. Januar 2025
Proactive maintenance for SAP RISE will start now in 2025 with minor tasks like updating SPAM/SAINT and ST-PI / ST-A/PI. For those companies which are familiar with frequent maintenance windows, they are good to have such time frames to hold the systems up-to-date and secure. However, for larger companies where such frequent maintenance windows are not common because every minute of downtime is costly and may only really be necessary once, the situation is quite different.
Dynamic Aging for NSE - combined with Threshold and Interval option

Range Partitioning - Dynamic Aging for NSE

von Jens Gleichmann • 28. Dezember 2024
Dynamic Aging makes it possible to automatically manage at which point in time older partitions can be moved to the 'warm' data store. The data in a new OTHERS partition is 'hot' data, that is, stored in memory with the load-unit attribute implicitly set to COLUMN LOADABLE. As an extension of the Dynamic Range Partitioning feature Dynamic Aging makes it possible to automatically manage when older partitions can be moved to the 'warm' data store (Native Storage Extension) with the load-unit attribute for the partition set to PAGE LOADABLE. Warm data is then stored on disk and only loaded to memory when required. Dynamic Aging can be used with both THRESHOLD mode (defining a maximum row count number in partition OTHERS) and INTERVAL mode (defining a maximum time or other numeric interval between each new partition). For example, for a partitioned table which is managed by dynamic partitioning and containing date/time information, you can specify an age limit (for example six months) so that when data in an ol
automatic maintenance of the 'others' partition

Dynamic Range Partitioning - Interval Option

von Jens Gleichmann • 28. Dezember 2024
You can create partitions with a dynamic others partition by including the DYNAMIC keyword in the command when you create the partition, this can be used with either a THRESHOLD value to define a maximum row count number or an INTERVAL value which can be used to define a maximum time or other numeric 'distance' value. The partition can be either a single level or a second level RANGE partition and dynamic ranges can be used with both balanced and heterogeneous partitioning scenarios.
HANA Range Partitioning details

Dynamic Range Partitioning - Threshold Option

von Jens Gleichmann • 23. Dezember 2024
For heterogeneous partitioning schemas Dynamic Range Partitioning is available to support the automatic maintenance of the 'others' partition. When you create an OTHERS partition there is a risk that over time it could overflow and require further maintenance. Using the dynamic range feature the others partition is monitored by a background job and will be automatically split into an additional range partition when it reaches a predefined size threshold. The background job also checks for empty partitions and if a range partition is found to be empty it is automatically merged to neighboring empty partitions (the others partition is never automatically deleted).
more