You have an existing ERP system, and you want to leverage your previous investment in the business processes that you already have implemented in ERP. You want to bring them to the new world of SAP S/4HANA. Then S/4HANA system conversion is a perfect option for you…!!!
This article will help you to identify your readiness to move to S/4 family.
These checks will help to determine what mandatory steps we must carry out before converting the S/4HANA system. The checks are categorized as below,
- System Requirement
- Maintenance Planner
- Custom-code analysis
We need to evaluate the system and check out its compatibility regarding OS, DB, and Stack (Single/Dual), etc.
- Unicode is needed, due to technical restriction with S/4 kernel. If the legacy system is not Unicode, then at first, perform Unicode conversion
- Dual stacks are not supported on SAP HANA. So, perform the dual-stack split, if required
- ECC system should be >= 6.0
- Check the minimum required version of DB/OS for conversion into S/4HANA
The Maintenance Planner checks the system with regards to business functions, industry solutions, and add-ons. If there is no valid path for the conversion (for example, the add-on is not released yet), the Maintenance Planner prevents the conversion.
The business function can have the following status: always_on, customer_switchable, and always_off.
- If a business function was switched on the start release system, but defined as always_off in the SAP S/4HANA target release, then a system conversion is not possible with this release
- If a business function was switched off in the start release system, but defined as always_on in the SAP S/4HANA target release, then the business function will be activated during the conversion
- If a business function is defined as customer_switchable in the SAP S/4HANA target release, it can be activated depending on the needs of the customer. Business functions that were active in source release, remain active in the target release
All add-ons must be certified for S/4HANA in order to run on S/4HANA. If you are converting from ECC to S/4HANA and have add-ons that are not certified, the conversion tool will simply stop in its tracks when Maintenance Planner identifies the uncertified add-on.
SI-CHECKS will identify simplification items relevant to conversion. This means that it checks data inconsistency or missing mandatory preparation activities.
For performing SI-CHECKS, follow the below steps
- Start report /SDF/RC_START_CHECKS in transaction SA38
- In the section Simplification Item Check Options, choose the target SAP S/4HANA version
- Choose the mode in which you want to run checks
- In Online Mode – The results are displayed immediately after the check is finished
- Background job: If the check will need a long-running time, use background mode
- Run the checks to get an overview of all irrelevant simplification items and then check system consistency with Check Consistency for All
- Check the Results and take appropriate action based on logs
SI-Check message and their meanings
In order to successfully use the Simplification Item Check as preparation for system conversion/upgrade project
- Start running the Simplification Item Check and fixing the issues found by the checks as early as possible in the project
- Stay up-to-date with the latest check and check content versions early in the project. Don’t miss to freeze the check notes and check content versions after converting your DEV system
- Archive any data which you don’t strictly need in your SAP S/4HANA system in order to minimize the check run-time and the data cleanup effort
Custom – Code Analysis
The Custom Code Migration process describes the tools and necessary activities that help you to migrate the custom code. The process consists of preparatory analysis (Custom Code Analysis) and the adaptation of the custom code (Custom Code Adaptation) after the technical conversion.
Custom Code Process:
Custom Code Evaluation
ECC system contains a large number of custom development objects (Z-Objects, enhancements, and modifications) that are not used productively. Therefore, monitor the system for a longer period and do some housekeeping and eliminate the code, which is not used anymore within your productive business applications.
For this purpose, use either UPL (usage procedure log) or ABAP Call Monitor (SCMON) in a productive system to find out which custom ABAP objects are really used within running business processes.
Tool – Solution Manager 7.2
SAP HANA Checks and SAP S/4HANA Checks
This is the most important step for custom ABAP code on the way to system conversion to SAP S/4HANA.
- Native SQL of the predecessor database and this database vendor-specific dependencies must be eliminated
- Also, in some custom code implementation, the SELECT statement without ORDER BY is used. This can lead to unexpected behavior when the database is changed (eg. SAP HANA) because the results return in a different order without ORDER BY. Therefore, you need to check your SQL SELECTs without ORDER BY statement if they are still correct
- Pool/cluster tables were removed with SAP HANA, therefore the database operations on these tables need to be removed from custom ABAP code
Tools – ABAP Test Cockpit (ATC)
Right size SAP HANA hardware to realize the maximum benefit from investment and reduce long-term total cost of ownership. SAP sizing report will provide an estimated amount for RAM, disk size, etc.
The following workflow will help to size HANA hardware.
As moving to the S/4 family is a big step, this readiness check will help to plan and provide an estimated timeline for conversion to S/4.