S/4HANA Conversion

This blog post will give quick overview for S/4HANA conversion.

Overview

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 perfect option for you…!!!
Overall journey for conversion to S/4HANA looks like as below –

(reference from SAP-Press book “ADM328 SAP S/4HANA Conversion and SAP System Upgrade)
S/4HANA conversion journey divides into pre-conversion, conversion and post-conversion phases.
In short, we should be aligned with these phases throughout S/4HANA journey. In pre-conversion phase, we are performing all pre-steps which are required to start conversion. This will help us to find any issue in early phase of project. In conversion, we are converting system to new world of SAP S/4HANA. This phase includes adaptation to new business process, validation etc… And final phase is post-conversion, here we are performing follow-up activities to make sure we get maximum use of SAP S/4HANA for our business.

Pre-Conversion

These checks will help to find out what mandatory steps we must carry out before converting S/4HANA system. The checks are divided into category such as –

• System Requirement
• Maintenance Planner
• SI-Check
• Custom-code analysis

System Requirement

We need to evaluate 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 legacy system is not Unicode, then at first place perform Unicode conversion
• Dual stacks are not supported on SAP HANA. So, perform dual-stack split, if required
• ECC system should be >= 6.0.
• Check minimum required version of DB/OS for conversion into S/4HANA

(reference from SAP-Press book “S4H100 SAP S/4HANA Implementation Scenarios)

Maintenance Planner

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.

Business function

Business function can have 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 the SAP SAP S/4HANA target release, then a system conversion is not possible with this release
• If 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 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, remains active in target release.

(reference from SAP Note – 2240360, 2240359)

Add-ons

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.

(reference from SAP Note – 2214409)

SI-Check

SI-CHECKS will identify simplification items relevant to conversion. It means that it checks data inconsistency or missing mandatory preparation activities.

Tip - Do run this report early in the project.

Procedure

For performing SI-CHECKS, follow 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 over 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

(reference from SAP Note – 2399707)
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 project
• Stay up-to-date with the latest check and check content versions early in project. But 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 runtime and the data cleanup effort.

Custom – Code Analysis

The Custom Code Migration process describes the tools and necessary activities that help you to migrate 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 –

(reference from SAP-Press book “ADM328 SAP S/4HANA Conversion and SAP System Upgrade)

Custom Code Evaluation

ECC system contains a large amount of custom development objects (Z-Objects, enhancements and modifications) that are not used productively. Therefore, monitor system for longer period and do some housekeeping and eliminated 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 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 most important step for custom ABAP code on the way to system conversion to SAP S/4HANA.

• Native SQL of the predecessor database and these 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 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 table need to be removed from custom ABAP code

Tools – ABAP Test Cockpit (ATC)

Hana Sizing

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 estimated amount RAM, disk size etc.
The following workflow will help to size HANA hardware.

Conversion

The actual conversion is started with SUM tool. Sum tool performs execution part including Database migration (DMO) and SAP S/4HANA conversion.


(reference from SAP-Press book “ADM328 SAP S/4HANA Conversion and SAP System Upgrade)
SUM tool segregate activities as uptime processing and downtime processing.
The uptime processing is the migration of the shadow repository. It can be migrated during uptime, because no changes are done any long – since the repository was locked at the beginning of the SUM procedure (dev lock). The shadow repository is built up from upgrade media (upgrade DVDs) + the maintenance planner download + additional files (files in the download directory, transport requests, add-ons etc).
The downtime processing is the migration of the application data, customizing data, and user master records. It can be migrated during downtime only, because it would be changed continuously during uptime. New standard customizing and new data, delivered by SAP, is imported.
The migration to SAP HANA DB takes place partially in uptime (UT) processing and partially in downtime (DT) processing of SAP up.

(reference from SAP-Press book “ADM328 SAP S/4HANA Conversion and SAP System Upgrade)

Overall Procedure at a Glance

SUM tool has too started on Primary application server. After some basic configuration setting, such as stack.xml, the SAP up will start to create shadow system. It contains the basic tables and some customizing tables. The system is still running, and end user may work in the system and use functionality that may change application data into database. In this phase, the system is running and available for end users (uptime processing), but the development environment is locked. Then the ramping down phase will start which includes, locking users, cleaning up queue etc.
The technical downtime phase is started. It migrates data from the source database into the target database. After this application tables are updated to the target release. Then validation will take place and go/no-go decision. After go decision from business owner, ramping up phase will start which includes reconnecting landscape, unlocking users etc. and finally system will be live on target release and available for end user.
The system is now migrated to the target database and updated to the target release.

Post – Conversion

(reference from SAP-Press book “ADM328 SAP S/4HANA Conversion and SAP System Upgrade)

Custom Code Adaptation

• Need to adapt any modification and enhancements using the standard transactions SPDD, SPAU, SPAU_ENH
• Need to fix any issues due to SAP S/4HANA simplification

Functional Adaptation

Once system conversion to SAP S/4HANA is completed, need to carry out functional adaptation based on the ATC results.
Adjust modifications and enhancements – To adapt the modifications and enhancements, use the standard transactions SPDD, SPAU, SPAU_ENH
Fix SAP HANA and SAP S/4HANA findings – Adapt custom ABAP code, using the findings of the SAP HANA and SAP S/4HANA checks (ATC results). Findings of SAP S/4HANA checks are related to S/4HANA Simplifications. Each simplification requires a different approach to solve findings. Therefore, findings of SAP S/4HANA checks refer to a SAP Note which describes how you can solve them.
Tool – ABAP Test Cockpit (ATC)

Performance Tuning

Once system conversion to SAP S/4HANA is completed, then need to look which business processes can be optimized on SAP HANA database. As we can make use of full power of SAP HANA regarding performance. Therefore, we need to look which SQL statements can be optimized.
ABAP SQL Monitor allow us to get performance data for all SQL statements executed in production. SQL monitor will help to understand what are the most expensive and most frequently executed SQL statements.  SQL Monitor allows you to link the monitored SQL statements to the corresponding business processes including various aggregation and drill-down options.
Tool – ABAP SQL Monitor

Cleaning up Obsolete Data after the Conversion

To delete obsolete data that may remain after the conversion of your SAP ERP system to SAP S/4HANA.

Cross Application Follow-on Activities

• Adapting Database Extension to SAP S/4HANA
• Adapting the User Interface
• Output Management

Application – Specific Follow-on Activities

• Finance
• SAP Credit Management
• Human Resources
• Sales – Order and Contract Management
• Retail
• Environment, Health and Safety
• Product Safety and Stewardship
• Integration

Conclusion

The conclusion is that – for successful converting to S/4HANA system, you can align with the sequence given in the blog.


Source: https://blogs.sap.com/2019/06/24/s4hana-conversion/