Contact Us

Downtime-optimized Conversion Approach of SUM

Overview

  • The approach can be used for a system conversion from SAP ERP 6.0 to SAP S/4HANA
  • It reduces the technical downtime by executing data conversion and migration (if required) in uptime
  • Approach is possible for source systems on SAP HANA or on non - SAP HANA database
  • Approach will require additional effort for project planning, impact analysis, and additional test runs
  • Project requires an educated experts that has taken the respective training ADM329 and successfully passed the Knowledge Assessment ADM329k (requires access to SAP Learning Hub).
    • If you are interested to leverage SAP Services and Support for Planning, Execution and Safeguarding (for Premium Engagement customers) please reach out to your responsible account management team. 

Introduction

The approach is based on the idea to move downtime activities (like data conversion from old to new data model) and database migration (in case of source system on non-HANA database) to uptime processing of SUM. For a standard conversion, the FIN data conversion has to be executed after the SUM has finished, by respective IMG activities (e.g. FIN customizing, FIN data migration). The downtime-optimized approach will even move the FIN data migration (partly) into the SUM uptime processing.

Data conversion is moved to uptime processing. If the source system is not yet on SAP HANA database, the database migration of the affected tables is then done in uptime as well, prior to this data conversion. [Affected tables: tables that are part of the old data model of SAP ERP but not part of the new data model of SAP S/4HANA – table content has to be converted from old to new table]

In addition, the field conversion for tables KONV and VBFA is moved to uptime processing as well. These two tables remain in the new data model, but fields have to be adapted.

In case the source system is not yet on SAP HANA database, selected large application tables (which are not affected by the new data model) will be migrated by SUM in uptime as well. [This is the approach named Uptime Migration respective downtime-optimized DMO, see https://blogs.sap.com/2014/09/08/dmo-downtime-optimization-by-migrating-app-tables-during-uptime-preview/ ].

Project planning aspects

Important aspects for project planning that especially Project Managers must be aware of:

  • Project requires an educated expert that has successfully taken the respective training
  • A standard conversion run is required prior to the downtime-optimized run
  • Additional effort is required for test runs, project planning, and impact analysis
  • Project planning is more complex than using the standard approach
  • Proper planning with timely and expanded communication (esp. on freeze periods) to all areas is key to success
  • Restrictions apply on PRD prior to the downtime, like customizing freeze, lock of development activities and others
  • Mass load activities on PRD during the replication phase have to be avoided
  • Results of first test runs with the approach have impact on customer specific tests

Project managers should also take the ADM329 training, or at least learn the topics covered in Unit 1 and Unit 4.

Relevant Sources of Information

Background Information

Database triggers

The migration and data conversion in uptime happens parallel to end user activities. These activities may change table content that was already migrated and/or converted. SUM considers those changes by using database trigger technology: the changes are recorded and later replayed. The technology which is part of the SUM is used in similar approaches as well, like nZDM and downtime-optimized DMO.

FIN customizing transport from standard run

Unlike the standard conversion, this approach will not be used for all systems in your landscape. Typically it is not used for the conversion of the DEV system, as downtime is not that relevant compared to PRD system conversion. Nevertheless, several downtime-optimized runs on copies of PRD will have to be executed.

During the downtime-optimized conversion run, SUM will execute the FIN data conversion partly already in uptime. Prior to this uptime conversion, SUM needs the FIN customizing on the new data model. So prior to the downtime-optimized run, a standard run is required in which the FIN customizing is created, and this customizing has to be put into a customizing transport request. This request will then be provided for the downtime-optimized conversion run.

Main steps of the approach

SUM activities on application tables during uptime require that any end user activity on these tables is considered. SUM is using it's own record-and-replay technology for this. The following list provides a simplified overview on the main steps. (Migration is of course only required if the source system is running on a non-SAP HANA database.)

  • SUM creates database triggers to record end user changes on database level
  • Initial migration of relevant tables from source database to SAP HANA database
    (relevant tables: those affected by new data model of SAP S/4HANA)
    including migration of additional tables that were manually selected for Uptime Migration
  • Data conversion of migrated data to new data model
  • Delta migration of table changes due to end user activity in uptime
  • System entering downtime
  • Final migration of relevant table entries (remaining changes by end users are reflected)
  • Remaining  data conversion of delta
  • Migration of other tables
  • Remaining SUM activities
  • System back in uptime