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. 


  • 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 consultant that has taken the respective training ADM329 and successfully passed the Knowledge Assessment ADM329k (requires access to SAP Learning Hub).
    • As the approach can be executed by educated customers and partners as well, you don't have to involve SAP experts; nevertheless it is a good idea to involve SAP and leverage the experience of running a downtime optimized conversion project: contact and/or (for Premium Engagement customers) for further details.


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

Relevant sources of information

  • SAP Note 3049338 on downtime-optimized Conversion with SUM 2.0 SP 11
  • 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
  • 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)
  • SAP Note 2778832 on moving long running XCLAs to uptime processing for downtime-optimized conversion

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.

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