Skip to Content
Technical Articles

System Conversion to SAP S/4HANA: downtime-optimized Conversion

This blog describes the approach to reduce the technical downtime for a System Conversion to SAP S/4HANA. Readers should be familiar with the general concept of a System Conversion (see sap-s4hana-system-conversion-at-a-glance/) as well as with details on the Software Update Manager for the technical conversion part (see blog system-conversion-to-sap-s4hana-sum-is-the-tool).

For the System Conversion of an existing SAP ERP 6.0 system to SAP S/4HANA (on-premise), the technical downtime is influenced not only by a migration of the application tables from source database to SAP HANA database (if the source is not yet SAP HANA based), but also by the Data Conversion of the application tables from old to new data model.

Approaches for System Conversion

We will offer three approaches for the System Conversion:

  • Standard
    • Using Software Update Manager (SUM)
  • Downtime optimized
    • Using SUM, and reducing downtime by moving data conversion partly to uptime
  • Customer specific approach
    • Allowing further reduction of downtime, as a consulting service project (NZDT)
    • Check SAP Note 693168 for details

This blog explains the downtime-optimized conversion approach only.


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 migration has to be executed after the SUM has finished by respective IMG activities (e.g. FI customizing, FI data migration). The downtime-optimized approach will even move the FI data migration (partly) into the SUM uptime processing.

SUM activites on application tables during uptime may interfere with user activites on these tables. So any changes by endusers on the tables are recorded by the SUM and handled by a replay mechanism. This replay will consider the table changes by endusers which happend after the table content was e.g. already converted by SUM.

The following image shows the general concept.

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 datamodel of SAP ERP but not part of the new datamodel 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, it is possible to move the migration of selected big application tables (which are not affected by the new data model) to SUM uptime processing as well. [This is the downtime-optimized DMO approach, see ]


“Downtime-optimized Conversion” is currently available for pilot projects. Such projects are driven by SAP consulting, and require a registration, and get direct support from SAP development. Requirements, restrictions, and registration process is described in SAP Note 2293733.

Project aspects

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.

The downtime-optimized conversion run will execute the FI data conversion by SUM partly in uptime. To enable this, the SUM needs the FI customizing. So prior to the downtime-optimized run, a standard run is required in which the FI customizing is created, and this customizing has to be put into a customizing request. This request can then be fed to the SUM for the downtime-optimized conversion run.

Important investigations for the project will be the estimation of the change rate on the affected tables.

The approach requires a system restart for a consistent status of the relevant application tables (sync point). This restart is part of the SUM uptime processing, and it will typically be planned one weekend before the actual downtime. The replication will then run until the next weekend.


SUM activities on application tables require that any end user activity on these tables is considered. SUM is using it’s own record-and-replay technology for this. The activities of SUM are listed for the case of a source system not yet on SAP HANA database:

  • System restart to have a sync point for application data
  • Initial migration of relevant tables from source database to SAP HANA database
    • Migration of additional tables, if selected
  • Revert of migrated data to sync point
    • so only a consistent set is handled afterwards
  • Conversion of migrated data to new data model
  • Delta migration of changed application data on relevant tables
    • changes due to end user activity in uptime
  • System entering downtime
  • Final migration of relevant table delta
    • remaining changes by end users are reflected
  • Remaining  data conversion of delta
  • Migration of other tables
  • Remaining SUM activities
  • System back in uptime

Keep in mind that this approach is not yet generally available. We hope to offer it generally in the future, but can’t predict when this may be, as it depends on the results of the ongoing pilot projects.

This blog may be updated and/or extended, so stay tuned.

Kind regards,

Boris Rubarth, Product Manager for SUM




Be the first to leave a comment
You must be Logged on to comment or reply to a post.