Downtime-optimized conversion approach of SUM

With SUM 2.0 SP 10 and higher, the approach is no longer in pilot phase. This page provides an introduction. 

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
  •  Project requires an educated consultant that has successfully taken the respective training ADM329
  •  Approach will require additional effort for project planning, impact analysis, and additional test runs

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/ ].

Relevant sources of information

  • SAP Note 2443938 on downtime-optimized Conversion with SUM 2.0 SP 10
  • SAP Note 2879083 Downtime-optimized Procedures using downtime-optimized Conversion: additional information on data replication
  • SAP Note 2402270 Export of Table Statistics for SUM Impact Analysis
  • SAP Note 2481983 SUM Impact Analysis for downtime-optimized DMO / downtime-optimized Conversion
  • SAP Note 2778832 XCLA Uptime Procedure for Downtime-Optimized conversion Scenario
  • Support portal page on SUM with matrix on downtime-optimization approaches
  • The Technical Downtime Optimization (TDO) App offers a simulation for the use of the approach (SAP Note 2881515)

Project aspects

  •  Project requires an educated consultant that has successfully taken the respective training
  •  Additional effort is required for test runs, project planning, and impact analysis
  •  A standard conversion run is required prior to the downtime-optimized run (see below)
  •  Customizing restrictions apply on PRD prior to the downtime

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.