Conversion to SAP S/4HANA using SUM: ABAP Systems on UNIX and Linux

The DMO Concept

This section describes the idea behind the database migration option of the Software Update Manager.

The DMO feature helps you avoiding landscape changes (SID, host name) and allows the combination of all relevant steps for the in-place migration to the target database (Unicode Conversion, Update, and Migration) in one tool.

A further benefit of DMO is its comfortable and fast reset functionality, provided that the source database remains consistent throughout the procedure.

Assuming that you run your SAP system on anyDB, and you want to update the SAP system and to migrate the anyDB to the wanted target database, several steps such as

  • Dual-stack split

  • Database update of anyDB

  • Update of your SAP software

  • Database migration to target database

can be necessary. The processing sequence is based on the shadow system functionality of SUM. A shadow system basically consists of a shadow instance and a shadow repository:

  • The shadow instance is an additional ABAP instance that is created by SUM on the application server on which the SUM was started. It is used to prepare steps executed during the downtime.

  • The shadow repository exists on target product version level. This means that the shadow instance must use the target kernel to create the shadow repository with potentially new object types.

The most important steps of the processing sequence are as follows:

  1. During the uptime, the target database is being set up (such as tenant, schema) on the target database host.

  2. Also during uptime, the shadow repository is being created on the target database.

  3. The downtime starts. The application tables are migrated from the source database host to the target database host by means of R3load processes.

  4. The SUM switches from the SAP source system kernel to the SAP kernel for the target system.

  5. After the migration of the application data (including data conversion), the update is finalized and the SAP system runs again in uptime on the target database.

    The source database continues to run, remains consistent, and application tables are not modified. It remains as a fallback database for the Reset Option throughout the complete DMO procedure. After the successful DMO procedure however, it cannot be used anymore as a productive database for an SAP system in parallel with the target database.

DMO at a Glance. The following figure shows the different phases of the DMO during the procedure.
For more information about the DMO, see the following blogs in the SAP Community: