Downtime-optimized conversion approach of Software Update Manager

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
  • Approach will require additional effort for project planning, impact analysis, and additional test runs
  • Project requires an educated experts that has taken the respective training Minimizing Downtime of System Conversion to SAP S/4HANA with Downtime-optimized Conversion of Software Update Manager(opens in new tab)
  • If you are interested to leverage SAP Services and Support for Planning, Execution and Safeguarding (for Premium Engagement customers) please reach out to your responsible account management team. 
Introduction

The approach is based on moving downtime activities (like data conversion from old to new data model) and database migration (if Database Migration Option (DMO) is used) to uptime processing of Software Update Manager.

For a standard conversion, the finance (FIN) data conversion has to be executed after Software Update Manager has finished, by respective IMG activities (e.g. FIN customizing, FIN data migration). The downtime-optimized conversion will even move the FIN data migration (partly) into the Software Update Manager uptime processing.

In case the source system is not yet on SAP HANA database, downtime-optimized conversion is combined with Database Migration Option (DMO) to migrate to SAP HANA. It is strongly recommended to utilize DMO even if the source system already runs on SAP HANA, as the full bandwidth of features of downtime-optimized conversion is only available in case of a database migration.

If DMO is used, 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] 

Selected large application tables (which are not affected by the new data model) will be migrated by Software Update Manager in uptime as well. [This is the approach named downtime-optimized DMO,]

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.

Project planning

Important aspects for project planning that especially Project Managers must be aware of:

  • Project requires an educated expert that has successfully taken the respective training
  • A standard conversion run is required prior to the downtime-optimized run
  • Additional effort is required for test runs, project planning, and impact analysis

Project managers should also take the ADM329 training, or at least learn the topics covered in Unit 1 and Unit 4.

  • Project planning is more complex than using the standard approach
  • Proper planning with timely and expanded communication (esp. on freeze periods) to all areas is key to success
  • Restrictions apply on production system prior to the downtime, like customizing freeze, lock of development activities and others
  • Mass load activities on production system during the replication phase have to be avoided
  • Results of first test runs with the approach have impact on customer specific tests

Additional information

Background

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. Software Update Manager considers those changes by using database trigger technology: the changes are recorded and later replayed. The technology which is part of Software Update Manager is used in similar approaches as well, like near-Zero Downtime Maintenance (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 development system, as downtime is not that relevant compared to production system conversion. Nevertheless, several downtime-optimized runs on copies of production will have to be executed.

During the downtime-optimized conversion run, Software Update Manager will execute the FIN data conversion partly already in uptime. Prior to this uptime conversion, Software Update Manager 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

Software Update Manager activities on application tables during uptime require that any end user activity on these tables is considered. Software Update Manager 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.)

  • Software Update Manager 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 Software Update Manager activities
  • System back in uptime