I am S/4HANA evangelist and support customers on their HANA journey. Recently I completed a project for S/4HANA conversion and through this blog series I want to take you through my project life-cycle; How to start, plan and execute; What to keep in mind and watch out for. This is topic #5 of 10 part blog series.
As you are proceeding to further read this blog series, it means you have decided that in-place system conversion is the right option for you and you have executed and resolved the SI Pre-Checks, completed CVI activation and are ready to start SUM DMO Uptime and Downtime activities.
This is the most critical phase of the conversion project where a new repository with new database schema is established and the data is moved from ECC data model to S/4HANA data model. Like for all technical system activities SAP has provided a tool Software Update Manager (SUM) for this activity as well. SUM can update application release as well as system kernel and also allows you to switch database in single step with Database Migration Option (DMO)(it is not required if you are converting from Suite on HANA to S/4HANA because the DB is same). In this phase, depending on your current OS and DB and need to do data center change along with conversion, you will choose heterogeneous / homogeneous OSDB Migration and/or System Move (Data Center Change) thus the tool to be used 1) Software Provisioning Manager (SPWM) for system copy 2) SPAM/SAINT for application updates and 3) SUM for kernel updates and most of what other tools can do and possibly in single step. Also if your source system is not Unicode enabled you will need to use SPUMG. Refer to OSS Note 1803986 to understand when to use what.
SUM 1.0 and SUM 2.0 are both active tools and offer parallel exclusive scenarios (other version will reject to run).
During system conversion SUM with DMO creates a shadow repository of target application release / kernel on the source OS and DB and then this repository is moved to target OS DB followed by the data migration (refer to SUM guide for more details). During the different phases of SUM (depicted below), 3 kinds of activities are triggered by SUM; 1) JOB/RUN phases execute a background job or FM in SAP, 2) SAPup triggers the R3Trans for the transport imports and 3) SAPup triggers the R3Load processes for the bulk imports. SUM DMO (note that significant number of data load processes are ABAP based and managed by respective classes or programs) logs messages in the job logs, SM21/ST11/ST22 etc apart from SUM logs and database logs. They can be analyzed for issues. Data Migration phase is managed by the R3Load processes which can run in 3 modes 1) File Import/Export, 2) Socket or 3) Memory Pipes (used by DMO) to parallelize the extract and load steps.
In the diagram below, SUM with DMO option is indicated by 'Standard/Advanced with archiving off' thus highlights, a lot of preparation steps and build of shadow repository are achieved by SUM with DMO while the system is in live usage (this is called UPTIME phase). During UPTIME phase, the shadow repository (including configuration and repository tables) with target kernel on Source OS DB is prepared (starting SUM .20 SP6 the shadow repository is directly prepared on the target instance) and post this, during DOWNTIME phase, transaction data is migrated to new repository and transformed to new data model followed by SPAU phase (more on this in TOPIC 06). Note that post the REPACHK2 step of UPTIME phase, no more transports can be made into or out of the SAP system. This means:
More details on the SUM with DMO phases are available in SUM wiki page. Also refer to this blog to read SUM with DMO Tips and Tricks.
For the final reconciliation, SUM tool has a feature to provide detailed logs by either table row counts or field level comparison. As field level reconciliation could be costly and time consuming, it is recommended to do the detailed checks when required in the Sandbox / Development system but limit to table row counts in production (default behavior). In case some entries are dropped from SAP tables between ECC and S/4HANA (due customer namespace conflicts), the same is logged in SUM logs.
As we learnt above, major portion of the SUM with DMO UPTIME and DOWNTIME phases is executed with the help of R3Load processes. Optimized parallelization of the same along with right hardware and network setup are key to Business Downtime Optimization (read more in blog#1 and blog#2). Few recommendations based on my experience:
In addition, please note you need to have well defined backup strategy (which includes shadow instance backup, HANA DB backup and SUM directory backup) to be able to restart the conversion from the selected backup time. SUM Tool also provides 'Test cycle' option that enables the repeat of SUM DOWNTIME phase with adjusted parameters. Till the time you have reached point of no return, you can reset the SUM tool to restart any of the previous phases without the need of backup. Frequent resets can make the SUM Tool inconsistent and might force you to restore from backup (especially if done during UPTIME shadow repository creation).
There are other approaches available for minimizing the downtime 1) Advanced features of SUM Tool and 2) Services from SAP. Refer to OSS Note 693168 to read more.
In TOPIC 06 we will discuss "Custom Code Remediation".
As you are proceeding to further read this blog series, it means you have decided that in-place system conversion is the right option for you and you have executed and resolved the SI Pre-Checks, completed CVI activation and are ready to start SUM DMO Uptime and Downtime activities.
This is the most critical phase of the conversion project where a new repository with new database schema is established and the data is moved from ECC data model to S/4HANA data model. Like for all technical system activities SAP has provided a tool Software Update Manager (SUM) for this activity as well. SUM can update application release as well as system kernel and also allows you to switch database in single step with Database Migration Option (DMO)(it is not required if you are converting from Suite on HANA to S/4HANA because the DB is same). In this phase, depending on your current OS and DB and need to do data center change along with conversion, you will choose heterogeneous / homogeneous OSDB Migration and/or System Move (Data Center Change) thus the tool to be used 1) Software Provisioning Manager (SPWM) for system copy 2) SPAM/SAINT for application updates and 3) SUM for kernel updates and most of what other tools can do and possibly in single step. Also if your source system is not Unicode enabled you will need to use SPUMG. Refer to OSS Note 1803986 to understand when to use what.
SUM 1.0 and SUM 2.0 are both active tools and offer parallel exclusive scenarios (other version will reject to run).
Figure 1 : SUM Tool Versions (Source SAP)
During system conversion SUM with DMO creates a shadow repository of target application release / kernel on the source OS and DB and then this repository is moved to target OS DB followed by the data migration (refer to SUM guide for more details). During the different phases of SUM (depicted below), 3 kinds of activities are triggered by SUM; 1) JOB/RUN phases execute a background job or FM in SAP, 2) SAPup triggers the R3Trans for the transport imports and 3) SAPup triggers the R3Load processes for the bulk imports. SUM DMO (note that significant number of data load processes are ABAP based and managed by respective classes or programs) logs messages in the job logs, SM21/ST11/ST22 etc apart from SUM logs and database logs. They can be analyzed for issues. Data Migration phase is managed by the R3Load processes which can run in 3 modes 1) File Import/Export, 2) Socket or 3) Memory Pipes (used by DMO) to parallelize the extract and load steps.
In the diagram below, SUM with DMO option is indicated by 'Standard/Advanced with archiving off' thus highlights, a lot of preparation steps and build of shadow repository are achieved by SUM with DMO while the system is in live usage (this is called UPTIME phase). During UPTIME phase, the shadow repository (including configuration and repository tables) with target kernel on Source OS DB is prepared (starting SUM .20 SP6 the shadow repository is directly prepared on the target instance) and post this, during DOWNTIME phase, transaction data is migrated to new repository and transformed to new data model followed by SPAU phase (more on this in TOPIC 06). Note that post the REPACHK2 step of UPTIME phase, no more transports can be made into or out of the SAP system. This means:
- Source ECC Development system will be frozen after this phase and no more ECC transports can be created for any pre-DMO work. Hence it is very important to validate this in Sandbox conversion and capture as much tasks as possible, that will potentially create ECC transports for the conversion process. This transport freeze makes it possible to move some of configuration and repository data to shadow repository during UPTIME as no changes are allowed.
- In production system, while the users can continue to use the system (till completion of UPTIME phase), the last transport can be imported into the system before the REPACHK2 step only. Post this, the next transport can only be imported in the converted S/4HANA system.
More details on the SUM with DMO phases are available in SUM wiki page. Also refer to this blog to read SUM with DMO Tips and Tricks.
Figure 3 : SUM Tool Phases (Source SAP)
For the final reconciliation, SUM tool has a feature to provide detailed logs by either table row counts or field level comparison. As field level reconciliation could be costly and time consuming, it is recommended to do the detailed checks when required in the Sandbox / Development system but limit to table row counts in production (default behavior). In case some entries are dropped from SAP tables between ECC and S/4HANA (due customer namespace conflicts), the same is logged in SUM logs.
As we learnt above, major portion of the SUM with DMO UPTIME and DOWNTIME phases is executed with the help of R3Load processes. Optimized parallelization of the same along with right hardware and network setup are key to Business Downtime Optimization (read more in blog#1 and blog#2). Few recommendations based on my experience:
- Run the SUM Tool on standalone migration server and not on the shared conversion project landscape.
- To train the SUM Tool to process the large complex tables first and small / simple tables later, statistics from the previous phases can be fed into next SUM run (UPGANA.xml and MIGRATE_UT_DUR.XML for the uptime migration and MIGRATE_DT_DUR.XML for downtime migration are downloaded from SUM directory post conversion and stored in the SUM directory of next system conversion). Refer to OSS Note 2351294 to read more about this.
- EUCLONEDEFS_ADD.LST can be tweaked for optimizing the algorithm for table splitting
- SUM Benchmarking Tool should be executed on the Sandbox system even before the first conversion to gain any performance benefit based on the initial data analysis.
- R3Load processes can be setup earlier during SUM tool setup and then adjusted during SUM execution based on the CPU utilization which should never increase 50%. Typical guidance is to have 10 times the R3Load process for uptime and 3 times for downtime. R3Trans processes should never exceed 32.
- HANA Configuration Check Tool (additional info at 1943937 1991051) can be used to track the system performance especially for savepoints and delta merges and database parameters can be tweaked for the same.
- SGEN is executed during the downtime and after SPAU and both are downtime activities; so optimize considering the system and project requirements.
In addition, please note you need to have well defined backup strategy (which includes shadow instance backup, HANA DB backup and SUM directory backup) to be able to restart the conversion from the selected backup time. SUM Tool also provides 'Test cycle' option that enables the repeat of SUM DOWNTIME phase with adjusted parameters. Till the time you have reached point of no return, you can reset the SUM tool to restart any of the previous phases without the need of backup. Frequent resets can make the SUM Tool inconsistent and might force you to restore from backup (especially if done during UPTIME shadow repository creation).
Figure 2 : SUM Tool Activities (Source SAP)
There are other approaches available for minimizing the downtime 1) Advanced features of SUM Tool and 2) Services from SAP. Refer to OSS Note 693168 to read more.
In TOPIC 06 we will discuss "Custom Code Remediation".
- SAP Managed Tags:
1 Comment
