Understanding the Concept of Downtime-optimized Conversion

The downtime of a system conversion run from SAP ECC 6.0 to SAP S/4HANA is dominated by the migration part (if required) and the data conversion. Please note that downtime does not only consists of the technical downtime required by the Software Update Manager and manual data conversion for Finance (FI) and Material Ledger (ML), but also of all activities around ramping the system down, manual post activities such as import of customer transports, testing and validation and ramping the system back up. Reducing technical downtime of course benefits the reduction of the overall downtime.

Downtime-optimized Conversion aims to drastically reduce the downtime for a system conversion to SAP S/4HANA. This is achieved by executing former downtime activities already in Software Update Manager uptime, like data migration to a new database (if required) and data conversion. Software Update Manager uptime refers to phases in which the Software Update Manager is already running in parallel to production activities. End user activity in those uptime phases is considered by Software Update Manager and replayed, partially already in uptime, partially in downtime.

The standard conversion starts with uptime phases of Software Update Manager. Here, the tool prepares as much as possible for the target release with production operation continuing in parallel. To do so, it leverages the concept of shadow system (SHD) operation. The shadow system is a minimal skeleton of the target system, setup automatically by Software Update Manager, in which certain preparation activities are done. After all uptime activities are finished, the system is ramped down manually and Software Update Manager continues with the downtime activities, which are data migration in case of a database change, software stack update and data conversions. These are followed by post activities of the Software Update manager as well as project-specific activities. To finalize data conversion, manual conversion activities for Finance (FI) and Material Ledger (ML) are needed for a system conversion to SAP S/4HANA. After that, the business validation and testing may happen to finally ramp up the system to release it to business again.

Downtime-optimized conversion moves part of data migration and data conversion to uptime. Delta data (indicated by the triangle) that is created by end user activity is replicated by Software Update Manager. In addition to the SHD system operation, the same mechanism of a skeleton is reused, called temporary system (TMP). During Software Update Manager downtime, only a delta has to be migrated and converted.

An additional benefit lies within the automation of the former manual FI and ML data conversion. To automate this, Software Update Manager requires information on the required activities which needs to be provided via Customizing transport.

Software Update Manager requires information on how to execute the former manual conversion activities in uptime. This includes executing the FI data conversion as well. To achieve this, a standard conversion to SAP S/4HANA is required on a sandbox system which is a copy of production. As a result, a customer transport containing the customizing information is available, which can be provided to Software Update Manager for a downtime-optimized conversion run.

In the screenshot, you can see the Implementation Management Guide (IMG) activities for manual data conversion. The activities within the first bracket have to be executed in the standard conversion run that precedes a downtime-optimized conversion. This middle part is covered by Software Update Manager in a downtime-optimized conversion run, the status can be monitored in transaction FINS_MIG_STATUS.

• Software Update Manager executes data conversion in uptime phases for FI, Material Ledger, Material management - Inventory Management (MM-IM):
  • PARRUN_SMIG_SFIN (FINS_MIG_STATUS) covers FIN incl. Material Ledger.
  • PARRUN_SMIG_UT_MKPF*_S4 for MM-IM.
• Software Update Manager executes additional conversions in downtime, like for Sales&Distribution (SD).
• After Software Update Manager, manual IMG activities like Credit Management Migration are required.

During a system conversion to SAP S/4HANA, data needs to be migrated to a new database, end user activity during uptime needs to be replicated to the target system and data needs to be converted to simplified data models. Examples for data conversions are the merge of tables GLT0, FLAGLFLEXT and FAGLFLEXA into new table ACDOCA or the merge of MSEG and MKPF into new table MATDOC.

Shadow Field Migration is a concept that reduces the impact of structural changes to a table. Normally, those changes might lead to longer downtime, but with shadow field migration, the data migration and conversion can be moved to uptime. This is especially relevant for typically large tables like KONV and VBFA. With shadow field migration for selected tables, all fields that are adapted or new, are attached to the table as so-called shadow fields with the new format. Shadow fields are created on the target database only. For source database SAP HANA, the table with shadow fields is renamed, and a view with the original table name is created. This view only exposes the original fields of the table to the source system.

The shadow fields are initially filled via batch jobs, any delta is captured via database triggers on the original table. In downtime, no delta activities are required and the original fields are dropped and replaced by respective shadow fields.

Another mechanism of reducing downtime, is the move of XCLAs to uptime. XCLA stands for execution of class after import, which were introduced with SAP S/4HANA to optimize data conversions. These automatic programs are executed by Software Update Manager in phase XPRAS_AIMMRG during downtime. When using downtime-optimized conversion, specific XCLAs can be moved to uptime. For more information see SAP Note 2778832.