SAP Note

3388323 - Executing and Monitoring Downtime-Optimized Conversion to SAP

S/4HANA with SUM 2.0 SP 19
Component: BC-UPG-DTM-TLA (Basis Components > Upgrade - general > Downtime Minimization >
Downtime Minimization for ABAP), Version: 7, Released On: 21.03.2024

Symptom
You want to use the Software Update Manager 2.0 for the downtime-optimized conversion to SAP S/4HANA, that is, you want
to significantly reduce the technical downtime for the conversion of your SAP system to SAP S/4HANA (on-premise edition).
This Note contains important information about executing and monitoring the downtime-optimized conversion such as
specific preparation activities, and known errors in the conversion process and their fixes. The Note also gives the most recent
and additional information to the downtime-optimized conversion guide that is available in the SAP Help Portal
at Downtime-Optimized Conversion To SAP S/4HANA Using SUM 2.0 - SAP Help Portal.

Other Terms
SUM, Software Update Manager, S/4HANA, conversion, downtime-optimized

Reason and Prerequisites

The downtime of the system conversion procedure is influenced by the size of the source system, and by the time it takes to
convert the table content from the old tables to the new tables of the simplified data model of SAP S/4HANA. The downtime-
optimized conversion procedure conducts a part of the data conversion in the uptime processing, which significantly reduces
the overall business downtime.
The downtime-optimized conversion procedure will partly move the data conversion to uptime, especially:
Table conversion for FIN, MM-ML, MM-IM is moved to uptime
Field conversion for KONV and VBFA table is moved to uptime
For the case that a database migration is part of the procecure, the downtime-optimized conversion procedure builds on the
approach of the downtime-optimized DMO. For more information about the downtime-optimized DMO, see SAP Note
2547309 - Downtime-optimized DMO with SUM 2.0.
General Prerequisites

Source system Unicode only (just as for standard syste

m conversion)

If the source system is already on SAP HANA SAP HANA 2.0 SPS 05 rev 52 or higher

Target product version SAP S/4HANA 2021 FPS00 or higher sta

cks or releases

The downtime-optimized conversion supports the following source database types. The SAP Kernel requirements for each supported database type
are listed in the following SAP Notes:

SAP HANA SAP Note 2706055

Oracle SAP Note 2698521

IBM DB2 for LUW (DB6) SAP Note 2700555

IBM DB2 z/OS SAP Note 2723627

MS SQL SAP Note 2728988

 For a source system on Oracle, Oracle 12 or higher is required.
For a source system on SAP HANA, the Software Update Manager 2.0 SPS 18 allows a homogeneous migration to
SAP HANA (for targeting SAP S/4HANA) also for downtime-optimized conversion. We recommend that you use
this migration for a better performance of the downtime-optimized conversion approach.
The technical procedure requires that you execute a complete standard conversion run at least on the very first system of
your landscape for example a sandbox or development system in order to get customizing transports for FIN, MM-ML,
MM-IM as an input for the downtime-optimized procedure. (As the purpose of this run is to create the customizing
transports, it can also be a doDMO run.)
The procedure can be executed by all educated persons that have successfully taken the ADM329 training and have
passed the related assessment.
Restrictions and Limitations
Source Product Version
SAP Simple Finance 1503 and SAP S/4HANA Finance 1605 are not supported as source product version for a downtime-
optimized conversion.
Source system on SAP HANA database
If your source SAP ERP system is already running on a SAP HANA database, we strongly recommend using the
homogeneous migration: You install and configure a new target SAP HANA database onto which the data are migrated
as part of the approach. This keeps the impact on the productive system as low as possible and it further reduces
downtime, compared to the case of executing the approach on only the source SAP HANA database.

Corrections or Amendments to the doC Guide

Correction to chapter "Planning" section "Downtime and Business Restrictions", paragraph "Caution":
"Additionally, starting with the Asset Accounting lock, the Software Update Manager locks the following transactions in the
source system till the end of the downtime:
SARA
KA12
KA16
AS91
AJRW
AJAB"
Interference with Other SUM Scenarios
"DMO with System Move" is not possible for a downtime-optimized conversion.
"DMO Move to SAP S/4HANA (on Hyperscaler)", aka DMOVE2S4, is supported for downtime-optimized conversion.
For more information, see sub-section "DMO Move to SAP S/4HANA (on Hyperscaler)" in the DMO guide on SAP Help
Portal.
Data transition validation (DTV) can be used for a downtime-optimized conversion run. This is a tool that allows you to
compare business data before and after a system conversion from SAP ERP to SAP S/4HANA. DTV is available as part of
the standard license. For more information about the DTV tool, see SAP Note 3117879.
Application-Specific Restrictions
Account-based CO-PA (account-based profitability analysis) must not be used in the source system.
Source systems with MFLE / DIMP-LAMA active are not supported
For more prerequisites and restrictions for MM-IM, see SAP Note 2281657- S/4HANA MM-IM migration by SUM with sMIG
feature.
For more prerequisites and restrictions, see the downtime-optimized conversion guide that is available on the SAP Help
Portal:
Downtime-Optimized Conversion To SAP S/4HANA Using SUM 2.0 - SAP Help Portal

Solution
Preparation and Execution of the Downtime-Optimized Conversion to SAP S/4HANA
For all preparation steps, follow the instructions under the Preparation section of the "Downtime-optimized DMO with SUM
2.0" SAP Note 2547309 - Downtime-optimized DMO with SUM 2.0.
Prior to starting the downtime-optimized conversion run on the source system, it is required that the SUM Toolbox is
installed on the source system, and the file ZDIMPANA.ZIP from the impact analysis is provided in the download directory.
Impact Analysis
Impact Analysis is mandatory for the execution of downtime-optimized conversion as described in SAP Notes 2481983 -
SUM Impact Analysis for downtime-optimized DMO / downtime-optimized Conversion and 2402270 - Export of Table
Statistics for SUM Impact Analysis.
Archiving
Before the conversion:
Before the conversion of the production landscape starts, do archive as much as possible of your data due to the following
reasons:
To reduce the data volume that needs to be converted
Previous booking periods might contain inconsistant data that can lead to increased effort during the SAP S/4HANA
conversion project
During the conversion:
For more information about all archiving objects, see the attached PDF document.
CAUTION: The archiving objects listed in the attached PDF document must not be used for archiving during the conversion.
Otherwise, migrated and converted data might be archived and deleted that must be replicated and converted again during
the downtime!
Delta Load and Replication Test
In order to test the Change Record & Replay mechanism and the delta processing within the technical downtime, we
recommend that you simulate productive activity in your sandbox environment. For this purpose, we recommend that you
use software testing tools or database scripts of your choice.
Delta Load Verification Requires Virtualization and Isolation of Clone
The concept of Delta Load Verification (as explained in the ADM329 training) aims to simulate the downtime of the
downtime-optimized conversion approach on production-like hardware. A clone of the production system is created at the
time of the downtime dialog. This only works if the clone is created using virtualization, so that the clone is identical from
perspective of the SUM tool (for example same host names). In addition, the clone must be completely isolated from the
network of the production system.
Performance of Phase SQLRUNTASK_FDCT_TRANSFER_DIRECT on SAP HANA
The Fast Data Copy transfer, which is executed in the phase "SQLRUNTASK_FDCT_TRANSFER_DIRECT" has a high
impact on the performance of the SAP HANA database. Especially the I/O performance of a productive system needs to be
monitored during the execution of this phase.
A good starting point for a health check of your SAP HANA database is SAP Note 1999993 - How-To: Interpreting SAP HANA
Mini Check Results, which describes how to use and interpret the results of the SAP HANA mini checks.
To ensure a stable and consistent data copy, as of SUM 2.0 SP10 patch level 4, SUM by default sets the number of processes
for the execution of the SQL statements of the phase "SQLRUNTASK_FDCT_TRANSFER_DIRECT" to 2, which has been
tested and validated by SAP.
In case you have serious business requirements to minimize the runtime of the phase
"SQLRUNTASK_FDCT_TRANSFER_DIRECT" and a performance analysis of the productive system’s SAP HANA database
shows that more parallel processes can be used without impacting the performance and stability of the SAP HANA database,
the number of parallel DDL processes can be increased:
Create the file <DIR_PUT>/abap/bin/SAPup_add.par if it does not exist already and add the following line to increase the
number of DDL processes:
/SQLRUNTASK_FDCT_TRANSFER_DIRECT/HDB/parprocs/DDL = <number of parallel processes>

Remark: Please also consider the load on the productive system during this analysis. Setting the number of DDL processes to
a higher value can lead to a massive impact on the productive system and a significant database slowdown.
Start of Application Servers on IBM DB2 for LUW or IBM DB2 for z/OS
On systems running with IBM DB2 database, application servers must not be started or restarted between the
phases "MODPROF_IUUCHOOK" and "SQLRUNTASK_RRC_HOOK".
Problems During the Conversion
-----------------------< D029945 21/MAR/2024 >--------------------------
Impact analysis for source system on SAP BASIS level < 7.40
For source systems based on SAP BASIS 7.31 or lower, you must set the following parameter in file
SUM/abap/bin/SAPup_add.par
IMPACT_ANALYSIS_STBX=OFF
Only then, the impact analysis works as required, and the phase RUN_IMPACT_ANALYSIS_DODMO is executed

-----------------------< D029945 12/MAR/2024 >--------------------------

Missing entries in table MATDOC_EXTRACT
The program NSDM_MIG_FILL_EXTRACT does not generate entries in table MATDOC_EXTRACT for some materials. To
solve the problem, set a breakpoint in the phase CHECK4NOTES_READTOOL_TEMP and implement SAP Note 3384094 in
the temporary system. For more information, see this SAP Note.
----------------------< I536880 27/JUL/23 >-----------------------------
SUM fails in phase "EU_CLONE_REV2SNAP_RUN"
Symptom: During the conversion to SAP S/4HANA using the downtime-optimized approach, the SUM fails in phase
EU_CLONE_REV2SNAP_RUN with an error message such as:
"A1EEIMP 008 Task failed with error: (IMP) DbSlExeModify failed in insert for table 'BSIK_BCK~' with #26
A1EEIMP 008 (IMP) SQL error = 301
A1EEIMP 008 (IMP) unique constraint violated"
where the corresponding table (in this case BSIK_BCK~/BSIK_BCK) has a unique secondary index.
Solution:
1. Delete the secondary unique index on the table.
2. Repeat phase EU_CLONE_REV2SNAP_RUN.
3. Recreate the secondary unique index.
4. Continue with the SUM run.
----------------------< D037566 17/JUN/22 >-----------------------------
SAP HANA 2.0 SPS 05 or Lower Only: SUM fails in phase “RUN_RSPTBFIL_NZDM_CLASSIFY”
Symptom: During the conversion to SAP S/4HANA using the downtime-optimized approach, the SUM fails in phase
"RUN_RSPTBFIL_NZDM_CLASSIFY with an error message such as:
"Last error code set:
1 error during parallel execution of processes, check 'PHASE_PARRUN.ELG' for
details
ERROR:
The following errors were detected in the log files:
A4 ENZDM 036 SFM classification for table KONV started
A4 ESFM 068 Table KONV has a new tablename and will be renamed to PRCD_ELEMENTS
A4 ESFM 017 Table KONV is defined as primary SFM Table
A2EESFM 070 Table KONV cannot be handled by SFM due to active SLT trigger on table KONV"
Reason: SLT triggers on ShadowField tables cannot be handled in uptime.
Solution: Possible mitigations are
1. Suspend SLT scenario which contains the effective table during SUM uptime, so that SLT trigger is dropped
2. Reset SUM and disable Shadow Field Handling. This will require additional downtime as tables are converted in
technical downtime
add the following line to SUM/abap/bin/SAPup_add.par
IOC_OPTION=OFF
----------------------< D039661 26/OCT/21 >-----------------------------
SUM fails in phase “PARRUN_SMIG_SFIN”
Symptom:During Conversion to S/4HANA 2021 FPS00, SUM fails in phase "PARRUN_SMIG_SFIN" with an error message
like this:
"Last error code set:
1 error during parallel execution of processes, check "PHASE_PARRUN.ELG" for
details
ERROR:
The following errors were detected in the log files:
# Find the detailed information in log 'FINS_MIG_FULL_001.CJF':
A4 EUPGBA 041 Report name ...: "FINS_UPG_MIG_START" Component: "FIN-MIG" "(SAP Simple Finance data
migration)"
A4 EFINS_FI_MIG 608 Migration run started by user "DDIC" at "29.07.2021" "10:05:00"; mode: "FULL"
A4 EFINS_FI_MIG 602 Migration activity "AAA" started at "29.07.2021" "10:05:00"
A4 EFINS_FI_MIG 602 Migration activity "CCS" started at "29.07.2021" "10:05:41"
A4 EFINS_FI_MIG 607 The following errors have occurred ("1" error messages in total):
A2EEFINS_ACDOC_CUST 307 Make sure that ledger "**" and ledger group have the same name"**""**""**"
A4 EFINS_FI_MIG 603 Migration activity "CCS" ended at "29.07.2021" "10:06:09"
A2EEFINS_FI_MIG 605 Migration run stopped by errors in activity "CCS"
Solution: Implement SAP Note 3087400 - Mass Data Framework: Performance issues when accepting high number of
errors in your SAP system.

----------------------< D037566 5/JAN/24 >-----------------------------

SUM fails in phases “PARRUN_SMIG_SFIN”, “PARRUN_SMIG_UT_MKPF1_S4”,
“PARRUN_SMIG_UT_MKPF2_S4” or “RUN_SMIG_UT_MKPF3_S4” with new errors during Load
Verification run
Symptom: During the execution of the Load Verification run in the productive environment, the Uptime Conversion fails with
new errors in the phases PARRUN_SMIG_SFIN, PARRUN_SMIG_UT_MKPF1_S4, PARRUN_SMIG_UT_MKPF2_S4 or
RUN_SMIG_UT_MKPF3_S4, which have not been observed in the previous doC runs.
The errors indicate that some tables are not in a transactional consistent state.
Solution: Open an incident on BC-UPG-DTM-TLA and describe the observed errors. Use the following line for the incident
header
“doC Uptime Conversion: Inconsistency during Load Verification in phase <enter phase PARRUN_SMIG_SFIN,
PARRUN_SMIG_UT_MKPF1_S4, PARRUN_SMIG_UT_MKPF2_S4 or RUN_SMIG_UT_MKPF3_S4>”

and ask for development support with reference to SAP Note 3388323

Chronological Summary

Date................Section...........Short description
-----------------------------------------------------------------------
21/MAR/2024...Impact analysis for source on SAP BASIS < 7.40
12/MAR/2024...Problems During the Conversion
05/JAN/2023 ... Handling of Conversion erros during Load Verification
06/SEP/2023 ... Recommendation for source on SAP HANA DB
27/JUL/2023 ... Reason and Prerequisites ... Data Transition Validation
27/JUL/2023 ... Solution ... Problems During the Conversion
17/JUN/2022 ... Solution ... SAP HANA 2.0 SPS 05 or Lower Only: SLT trigger handling on Shadow Field Tables like KONV
and VBFA
12/JUN/2023... Reason and Prerequisites ... Target product version SAP S/4HANA 2021 (or higher)
26/OCT/2021 ... Solution ... Problems During the Conversion
07/OCT/2021 ... Solution ... List of archiving objects updated
30/JUN/2021 ... Solution ... Comment on Delta Load Verification
22/JUN/2021 ... General ... Initial release of SAP Note
 This document refers to
SAP Component Title
Note/KBA

3347255 BC-UPG-DTM- Executing and Monitoring Downtime-Optimized Conversion to SAP S/4HANA with SUM 2.0
TLA SP 18

3301507 BC-UPG-DTM- Executing and Monitoring Downtime-Optimized Conversion to SAP S/4HANA with SUM 2.0
TLA SP 17

Attachments
File Name File Size Mime Type

Archiving Objects during the Downtime-Optimized Conversion.pdf 159 application/pdf