System Conversion to SAP S/4HANA: downtime-optimiz...

Boris_Rubarth · ‎03-08-2019

[Update on Feb 19 2021] With SUM 2.0 SP 10, the approach is now available for educated consultants. See this separate SAP Support Portal page for details.

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.

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 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 activities on application tables during uptime may interfere with user activities 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 happened 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 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, 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 https://blogs.sap.com/2014/09/08/dmo-downtime-optimization-by-migrating-app-tables-during-uptime-pre... ]

[Update on Feb 19 2021] Boundaries

"Downtime-optimized Conversion" is currently available for pilot projects. Such projects are driven by SAP colleagues, and they require a registration. Accepted projects get direct support from SUM development. Requirements, restrictions, and registration process is described in SAP Note 2293733. Projects will either be driven by SAP consulting, or by SAP Centre of Expertise (CoE) for Premium Engagement Customers.

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.

[Updated on Feb 19 2021] 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.

Replication

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

[Updated on Feb 19 2021] 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