Transition to SAP S/4HANA with System Conversion
System Conversion is the one the transition scenario to S/4HANA. System Conversion is converting one ERP source system into one SAP S/4HANA system. Here, SAP S/4HANA means on-premise edition. Conversion to S/4HANA is neither exactly like an upgrade nor a technical migration. Some similarities exist, but it is not the case.
- Preparation phase
- Realization phase
Before starting the conversion project, the project team has to create an overall project plan and tasks. Here preparation phase activities are described.
In SAP ERP 6.0 version source system, it can have any enhancement packages (EHP xx) and it is not required to be running on the HANA database.
The Unicode Standard is an encoding system for the representation of characters in software technology. It provides a unique code point, i.e. a number, for each character or character-like sign. Here Source system has to be a Unicode system, for one-step conversion: one procedure, one down-time. However, in case of the non-Unicode source system, a two-step conversion approach can be used: Upgrade and Unicode conversion using one of the supported start releases as the target and then the migration to SAP S/4HANA.
- ABAP Single Stack
Source system like SAP ERP 6.0 runs on application server (AS). It means SAP ERP 6.0 could run of AS ABAP or AS JAVA or on both. If Source system runs on either AS ABAP or AS JAVA called as single stack. If source system runs on both AS ABAP and AS JAVA, then it is dual stack.
Here source system has to be a single stack, not dual stack. If ERP system is running with the portal on the same database with same system ID then it’s dual-stack which is not supported for conversion. In case the system is dual-stack, then need to consider dual-stack split procedure before conversion.
- SAP HANA Database
Source system doesn’t have to be run on HANA database. If it is running on the HANA database, need to consider moving to latest HANA 2.0 before the conversion process
To help customers to plan and evaluate their transition to SAP S/4HANA, SAP has issued the “Simplification List for SAP S/4HANA”. It is the list of collection simplification items, which documented functional changes i.e. what is changed, removed, or replaced between SAP ERP 6.0 version and SAP S/4HANA. Every Simplification Item contains the actions to be carried out for the transition are described in detail from a business and technical point of view. It also contains the descriptions, business impact, Recommendation and SAP note. Simplification list consists of around 600+ simplification items but only not all of them are not relevant for the source system. This list is the foundation for the tools like Maintenance Planner, SI-Check, and Custom Code Preparation. We can access to the simplification items through the Simplification Item Catalog. In Simplification Item Catalog tool, simplification items are clustered by product version, application, or functional area where we can search or browse the entire library. We must determine manually those that are critical to your system conversion. These are a requirement before starting the Preparation Phase. In the preparation phase, we do Checks especially based on simplification item list that suggests what we have to implement and consider in the source system.
SAP Readiness Check 2.0
It’s a cloud-based web interface tool kind of umbrella covering a lot of other checks. It’s partially checking all the 3 checks of preparation checks. It is an important first overview of all the things to consider on the project. So, it’s recommended to run on the source system before starting the project. It includes checks like Simplification item relevance, Custom code, Recommended SAP Fiori apps, Add-on etc.
It’s the successor of Mopz. It is a browser-based central planning tool that has access to the system data. Because the solution manager is replicating data to the SAP backbone so the maintenance planner knows the status, component level of the system and can be used to plan. It is used to check at components level and to plan. So, 2 different aspects.
- Checking source system for add-ons, business functions, Industry solution (S/4HANA license is not required).
- Planning, i.e creating a maintenance transaction means defining a target level and then we get software archives for S/4HANA and stack.xml. Planning also considers the software for the frontend and backend server.
After running the Maintenance Planner, a download files are created containing add-ons, the stack configuration file which is used during conversion. If the checks are green, then planning for conversion. If checks are red, then resolve all issues reported by the checks before getting a valid Stack.xml file.
SAP provides a variety of add-ons that you can enhance your standard SAP system. It can be Industry Solutions, plug-ins, or customer-specific development projects. Add-ons are the influencing factor for the project. For those, add-ons that are capable to be uninstalled can be planned. 3rd party add-on to be checked for compatible version availability.
Business functions can have the following status: always-on, customer switchable, and always off. The activation of a business function means that a new “feature” is enabled in SAP. Table gives an example of how to manage the different statuses of business functions. If business function in source system is ‘always on’, but in target release of SAP S/4HANA ‘always off’ then conversion is not possible or vice versa.
Simplification Item Checks/SI-Check
In Simplification Item Check, which narrows down the simplification list to what is necessary to the system. On the early stage of the project, SI-Check is executed on the source system to get relevant and required simplification items i.e. round 40~60. After running the SI-Check, the report comes with the relevant simplification items means looks for data inconsistency or missing mandatory preliminary activities. In the below Figure, we can see, SI-Check comes with the colour indicator like Green, Yellow and Red to show the severity of inconsistencies.
- Green – No technical problem or other inconsistencies.
- Yellow – No technical problem for conversion but any changes in data, functionality or necessary tasks after the conversion.
- Red – the indicate inconsistencies in the system, the risk of data loss or necessary activities after/before conversion.
So, have to execute the checks and clear up all the open issues because later SUM will run the exact same report and the same check. If the SUM tool detects the issue, then the conversion process will be stopped.
Thanks for sharing the blog.
One curious question, can we do the S/4 Conversion with selective data like for example only customizing data or configuration from ECC to S/4 Conversion?