If your source system is not yet running on the SAP HANA database, use the database migration option (DMO) of the Software Update Manager to migrate your database to SAP HANA during the conversion.
SUM performs the conversion of your data into the new data structure used by SAP S/4HANA Server. This refers to the automated part of the data conversion.
Some important phases are:
RUN_RSDBSCPY clones tables from the original to the shadow repository (not with upgrade and S/4HANA Conversion).
EU_IMPORT_ALL creates the shadow repository from upgrade DVDs (upgrade and S/4HANA Conversion only).
EU_CLONE_MIG_SOT_PRP / RUN creates tables for shadow system on target database (DMO only).
DIFF* copies customer-specific objects from the original to the shadow repository (upgrade and S/4HANA Conversion only).
DDIC_UPG imports dictionary objects from the download directory to the shadow repository.
ACT_UPG activates all ABAP dictionary objects that are not delivered activated.
PARDIST_ORIG runs the distributor.
TABIM_SHADOW_UPG2 / INC imports non-dictionary objects from the download directory to the shadow repository, also copies upgrade and language data from the download directory – only if it is inserted into new tables.
RUN_SGEN_GENER8 runs SGEN – if selected.
EU_CLONE_MIG_DT_PRP / CREATE performs migration preparation steps, for example, table creation (DMO only).
DOWNCONF_DTTRANS is the beginning of downtime and changes profiles.
EU_CLONE_MIG_DT_RUN performs the downtime migration (DMO only).
KX_SWITCH switches to the new kernel.
EU_SWITCH switches to new repository.
PARCONV_UPG converts application tables.
PARMVNT_APPL_VIEWS does move nametab of application tables.
TABIM_UPG imports upgrade and language data from the download directory.
XPRAS_AIMMRG executes XPRAs and AIMs (both are ABAP programs executed to adopt data to the new release) - in case of an SAP S/4HANA conversion, this is the actual conversion.
The active SAP system (old release) is up and running with its old application server(s) (PAS and one AAS, in this example), its applications data, and the old repository.
The temporary shadow system (new release) is up and running with the shadow instance, a minimum set of customizing data, and the shadow repository, which is linked to the shadow system.
And at the end of the procedure, the PAS and AAS will be switched to the new release. The application data will be adopted to the needs of the business functions of the new release. The SAP system will be running with the former shadow repository, which is now the regular repository. The shadow instance will be deleted.
In case the SUM runs with the SOT option (Shadow on Target), the shadow repository is created on the target database. This is the case, for example, if an SAP S/4HANA Conversion to SAP S/4HANA Server 2021 is performed.
The shadow system is used for SPDD, batch monitoring, and troubleshooting during shadow phases:
DDIC user
Password copied from productive SAP system
Create additional users with transaction
SU01
No access to application tables
Only basis tables accessible
No customizing
No production operation
No tp import to shadow system
No tp mvntabs, no DDL statements
No online activation and conversion
Only 'inactive' activation in
SE11No operations in
SE14
The shadow system allows access to the target release repository during production operation on source release.
Note
When using scenario strategy Standard, the shadow instance will be finally stopped before begin downtime. With e.g. scenario strategy Downtime optimized Conversion (DoC) without DMO, the shadow system is used during downtime, also.
For the combined conversion & transition, until now only DMO with system move was available and used for projects. Disadvantage is that the approach does not allow downtime-optimization techniques like downtime-optimized DMO (doDMO) or downtime-optimized Conversion. Now with SUM 2.0 SP 17, the DMOVE2S4 approach is available as an alternative to DMO with system move.
Details on DMO and downtime reduction techniques will be discussed in a later lesson of this course. SAP ECS Private Cloud is SAP Enterprise Cloud Services Private Cloud.
Note
For SAP S/4HANA Conversion to private cloud see information on DMOVE2S4: "DMO move to SAP S/4HANA (on hyperscaler)" in blog https://blogs.sap.com/2023/05/31/two-major-news-with-sum-2.0-sp-17/.
Depending on the SUM scenario, different strategies are supported. These also depend on e.g. the source database used. Log file SELROADMAP.LOG describes, why certain stratgies are not supported in this SUM run.
The next two slides show additional downtime optimization techniques, that can be used under certain circumstances:
Near-Zero Downtime Maintenance (nZDM) and Downtime Optimized Data Conversion will be discussed in the following lessons of this unit in detail.
- Downtime-optimized Conversion is a SUM option to reduce the technical downtime.
- Data Conversion is partially executed during the uptime processing of the SUM.
- If source database is not SAP HANA, 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 assessment was successfully taken
- As in a standard conversion, the SUM 2.0 is used.
Approaches for Downtime-Optimized Data Conversion
- Table conversion: moved to uptime processing
- For FIN & Material Ledger (MM-ML) (currently manual action after the SUM run)
- For Inventory Management (MM-IM) (currently part of downtime processing in the SUM)
- 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 is possible to select big application tables for migration in uptime (tables that are not 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 source database type. The following steps are performed, if the source database is a non-HANA database.
The Obsolete Data Handling tool allows you to delete obsolete data that may remain after the conversion of SAP ECC system to SAP S/4HANA Server.
Obsolete data originates from SAP S/4HANA data model simplifications in many application areas where the related application data is migrated to new data structures. These areas include Material Management, Financials, Sales and Distribution, Environment and Health Science and others. The source data is not deleted automatically during the conversion because this would increase the business downtime and the obsolete data store may sometimes be required during or after the conversion. Therefore, after you have successfully tested and validated the conversion results, you can clean up the obsolete data with the Obsolete Data Handling tool.
Note
With SAP S/4HANA 2023 a new obsolete data handling tool is delivered. The old tool (program/transaction code ODH_Data_processing) can only be used with SAP S/4HANA 2023 to view the logs of already finished cleaning runs. It will not be available at all for future SAP S/4HANA releases. For the old tool, see SAP Note 2661837. All new obsolete data cleaning activity must be done with the new, class-based tool (transaction code SODH). For information on how to enable and use this tool in the productive SAP S/4HANA 2023 system,see SAP Note 3335020
The deletion of data is cross client, the data is deleted across all clients. In SODH, you have the choice to create a Z-table as a backup option or not. In addition, you can choose whether the deletion should be done in dialog or via background job. Application logging is accessible from SODH as well, simply select button Application Log from the menu. The log object name is SODH.