Describing Downtime-Optimized Conversion

Objective

After completing this lesson, you will be able to explain the downtime-optimized conversion.

Downtime-Optimized Conversion

Downtime-Optimized Conversion in a Nutshell

Note

For details concerning the downtime-optimized SAP S/4HANA Conversion, see SAP training ADM329 – SAP S/4HANA Downtime-Optimized Conversion.
  • Downtime-optimized conversion is a Software Update Manager option to reduce the technical downtime.
  • Data conversion is partially executed during the uptime processing of the Software Update Manager.
  • In case of DMO, the migration is partially executed in uptime.
  • A delta replay mechanism ensures that any uptime changes are considered.
  • The benefit is reduced in downtime.
  • An approach requires higher effort and a dedicated project plan.
  • An option can only be chosen if an assessment was successfully taken.
  • As in a standard conversion, Software Update Manager 2.0 is used.
Conversion Downtime Approaches

Approaches for downtime-optimized conversion:

  • Table conversion moved to uptime processing.
  • For FIN and Material Ledger (MM-ML) (currently a manual action after the Software Update Manager run).
  • For Inventory Management (MM-IM) (currently part of downtime processing in the Software Update Manager).
  • Field conversion moved to uptime processing.
  • KONV and VBFA tables.
  • Speed up mapping of long material number.
  • Include uptime migration for big application tables.

In addition, it's possible to select big application tables for migration in uptime (tables that aren't affected by the data conversion) – approach for downtime-optimized DMO.

See SAP Note 2293733 for prerequisites and restrictions.

The procedure is slightly different, depending on the usage of DMO. The following steps are performed, in case of DMO.

Note

Even if the source database is SAP HANA DB, the downtime-optimized conversion should be used with DMO. This is to reduce the load on the productive database before downtime. With DMO, several steps take place on the target database which is then decoupled from the productive source database.
Main Blocks with DMO
[1] Software Update Manager is Started
[2] SHD Repository is Created
[3] Short-Term Lock for Asset Accounting
[4] Initial Transfer of Relevant Tables
[5] Revert2Snapshot back to Consistent State
[6] Conversion of Transferred Relevant Tables
[7] Delta Migration of Relevant Tables
[8] Remaining Delta Migration of Relevant Tables
[9] Conversion of Delta
[10] Migration of Remaining Tables
[11] Kernel Switch for PRD Instance
[12] Update of Application Tables to New Release

The procedure is slightly different, depending on the source database type. The following steps are performed, if the source database is a HANA database.

Note

Even if the source database is SAP HANA DB, the downtime-optimized conversion should be used in combination with DMO. This is to reduce the load on the productive database before downtime. With DMO, several steps take place on the target database which is then decoupled from the productive source database.
Main Blocks without DMO
[A] Software Update Manager is Started
[B] Shadow Repository is Created
[C] Short-Term Lock for Asset Accounting
[D] Copy Application Tables to Shadow
[E] Revert2Snapshot back to Consistent State
[F] Conversion of Transferred Tables
[G] Uptime Replication of Delta
[H] Downtime Replication of Delta
[I] Conversion of Delta
[J] Update of Application Tables to New Release

Note

For more information concerning the downtime-optimized conversion, see SAP training ADM329 – SAP S/4HANA Downtime-optimized Conversion.