HANA News Blog

Orientation in DMO scenarios

Dominik Fiedler • 21. Oktober 2026

The confusion of the DMO options

There are multiple DMO scenarios and use cases. We heard of many confusions and mixed up statements which we want to order:

SUM can not only update software components, but can also execute a database migration (for ABAP based systems)


DMO = Database Migration Option

  • combination of software update with the database migration
  • DMO without system update possible
  • inplace-procedure: as it keeps the Application Server level unchanged, it only changes the database
  • DMO supports the migration to target database type SAP HANA database, and (depending on scenario) to other database types as well


Details: SUM DMO documentation



SUM DMO is the basis for all the other option, but please don't mix them up. All of them have different requirements and restrictions.


DMO with System move

You can run an update with database migration including a move of the application server instance from source to target system.

Details: DMO with System move documentation


DMOVE2S4 = DMO move to SAP S/4HANA (on hyperscaler)

DMOVE2S4 allows you to convert and transition your SAP on-premise system to SAP S/4HANA (or to SAP S/4HANA foundation based products) on hyperscaler in one step.


Sources:

DMOVE2S4 and Homogeneous option for SUM DMO by Jens Gleichmann (XLC) (10/2026)

DMOVE2S4 – your one-step approach into the cloud by Mirja Kempin (SAP) (09/2024)

DMO Move to SAP S/4HANA (on Hyperscaler) - official SAP documentation


DMOVE2S4 with doDMO = DMOVE2S4 with downtime-optimized DMO

By means of the downtime-optimized DMO to SAP HANA database, you can migrate selected large application tables already in uptime to reduce the downtime. The downtime-optimized DMO procedure performs a part of the data migration in the uptime processing. This technique significantly reduces the overall business downtime. The delta record and replay technology (CRR) ensures that any changes, which users made in the uptime but during the data migration, are considered.

=> Only SAP HANA is supported as target database type

Starting with SUM 2.0 SP 18, doDMO is supported for homogeneous DMO (SAP HANA to SAP HANA) as well.

Supported source database types are listed in SAP note 2547309.


Details: SUM downtime-optimized DMO



DMOVE2S4 with doC = DMOVE2S4 with downtime-optimized conversion

Downtime-optimized conversion with database migration includes the downtime optimization features from the downtime-optimized DMO.

This option is the default and recommended approach. It offers the best possibilities for reducing downtime and supports the following features:

  • Uptime Customizing for FI Conversion (UCFC), for more information, see SAP Note 3444013
  • Uptime handling of XPRAs and SDMIs, for more information, see SAP Note 3448095
  • Optional: use of clone-based downtime-optimized SAP S/4 HANA Conversion, for more information, see SAP Note 3561365

The downtime-optimized conversion with database migration can also be used if the source system is already running on SAP HANA. In this case, the system migrates to the new SAP HANA instance. 



Details: DMOVE2S4 with doC


The central starting point is always the SAP Software Logistics Toolset (SL Toolset). All options, documentations and downloads can be found in once place.


SAP HANA News by XLC

DMOVE2S4 and Homogeneous option for SAP SUM DMO
von Jens Gleichmann • 21. Oktober 2026
DMO used to be heterogeneous (change of DB). Now you can use DMO with system move (also on-prem to target on-prem) to migrate and convert ECC on HANA to S/4 or just update/upgrade S/4 and move it to another location like other DC or other instance in one step. The DMOVE2S4 is just to move and convert to the cloud in one step. This includes also anyDB source systems and downtime-optimization techniques (doDMO and doC).
von Dominik Fiedler • 7. August 2026
SAP HANA Monitoring Views Cheat Sheet
HANA OS maintenance
von Jens Gleichmann • 27. Juli 2026
Please notice that when you want to run HANA 2.0 SPS07, you need defined OS levels. As you can see RHEL7 and SLES12 are not certified for SPS07. The SPS07 release of HANA is the basis for the S/4HANA release 2023 which is my recommended go-to release for the next years. Keep in mind that you have to go to SPS07 when you are running SPS06 because it will run out of maintenance end of 2023.
von Jens Gleichmann • 14. April 2026
KVM as alternative with low TCO
inverted individual index is a special type of SAP HANA index wich can save memory
von Jens Gleichmann • 6. April 2026
An inverted individual index is a special type of SAP HANA index which can only cover unique indexes. This includes all primary key structures. Unlike traditional column store indexes on more than one column (inverted value, inverted hash) an inverted individual index (Inv Idv Idx) doesn't need a dedicated concat.
Total NSE savings
von Jens Gleichmann • 5. April 2026
This blog presents the results of a customer case which can be used as a reference for other implementations
SAP HANA performance issues with THP on multi-NUMA node systems
von Jens Gleichmann • 30. März 2026
SAP HANA systems may experience high swap usage, hangs, or performance issues when THP (Transparent Huge Pages) is enabled with "madvise". This occurs on multi-NUMA node systems where one or more NUMA nodes are close to full memory usage while others have plenty of free memory, and counters for THP allocations, direct
Transparent Huge Pages (THP) with madvise can trigger high swap usage and performance issues
von Matthias Sander • 26. Januar 2026
Transparent Huge Pages (THP) with madvise can trigger high swap usage, performance issues, or even system hangs on multi-NUMA systems.
HANA performance degradation after upgrade to SPS07+SPS08
von Jens Gleichmann • 9. Januar 2026
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.
SAP HANA NSE - a technical deepdive with Q&A
von Jens Gleichmann • 24. November 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.
more