The second deployment option is System conversion, as the name specifies in the system conversion scenario, the customer is already having a SAP Business suite and wanted to leverage on existing business processes that already implemented in ERP and now wanted to convert to SAP on-premise S4H Edition. Once the system conversion is completed from ERP to S4H, a customer will do innovation on a new S4H system.
SAP System conversion with underlying SAP Active methodology there is 4 stages involved.
Just like new implementation scenario, in SAP System conversion also customer can experience Trail of S4H on-premise system which is available thru Amazon Web services or thru Microsoft Azure cloud. The customer can see the processes which can be adopted on top of their existing processes.
Now that customer has explored the trail and customer is convinced to go for S4H system conversion, you have to handle the Technical preparation steps and test the conversion process. Following steps are involved in technical preparation:
Once the above two technical steps are performed successfully in the development system then the actual conversion takes place. Since most the above conversion is technical in nature, they have no effect on the people’s work, so triggering of change management is not necessary when converting the system to S4H.
Simplification Database: Customer should detect the custom code compatibility with data structures, which needs to be adopted when moving to SAP S4H on-premises edition. SAP provided the simplification database which contains the information about the changes that took place between ECC systems to current version S4H.
Conversion Pre-Checks: Conversion pre-checks are shipped to S4H customers as SAP Note (2182725). Customers can use these pre-checks to find the mandatory steps that they must complete before converting to S4H by running the program R_S4_PRE_TRANSITION_CHECKS. The results need to be addressed before starting the conversion process.
Custom code check tool: custom code checks are based on the simplification database mentioned above. Before converting to S4H, we need to check custom code against SAP S4H simplifications. The simplifications are loaded to the custom code check tool, after running the tool you obtain the list of instances where your custom code does not comply with the scope of a data structure of S4H 1511, on-premises.
3.Realise Phase: Functional conversion and cutover.
The cutover takes place in the realisation phase, you use the database migration option (DMO) from the software update manager (SUM). Technically the system conversion is completed. Now customer needs to adopt the new functional features available on S4H to their existing processes.
Database Migration options: There are three data migration options from ECC system to S4H system as given below.
A: New Installation + Selective Migration:
In this approach, we leave the existing system as it is and migrate to a new S4H system. SAP Landscape Management Services offer a verity of options to reduce the effort required to build a targeted solution landscape, including shell copy, carve-out and System consolidation.
B. Classical Migration: In the classical migration, system conversion goes in a phased approach, at first we perform the upgrade (if required) and secondly the database can be replaced either in-place DB migration or direct hardware replacement (OS / DB Migration).
Main advantages are: Resulting systems are identical, Minimal impact on the functional teams.
During the planning phase, we need to user the Maintenance Planner Tool http://apps.support.sap.com/sap/support/mp, in which we choose the source ECC system to be converted and select the target S4H version. This tool gives the result file by validating all the required technical compatibility like OS version, Stack Level, DB version etc. Download the file(stack.xml) and upload the same file into SUM (Software Update Manager).
Now that the new S4H system is ready for the application server and database server connected, the data migration is the final one which will be done by Software Provisioning Manager which is used for Extracting, Transforming & Loading the data from Old DB to HANA DB.
C. One step upgrade + Migrate with DMO:
In this approach, there is only one downtime overall and one maintenance phase. Original DB server is kept, can be reactivated as a fallback for Java systems always use the classical migration, this is applicable only for the ABAP systems.
Just like the classical migration, Data Migration Option (DMO) and Software Upgrade manager are used for the one-step migration, the only difference is its carried in a single step as there is no ETL steps since it is in-place conversion.
SAP System conversion with underlying SAP Active methodology there is 4 stages involved.
- Discover Phase: Trail
Just like new implementation scenario, in SAP System conversion also customer can experience Trail of S4H on-premise system which is available thru Amazon Web services or thru Microsoft Azure cloud. The customer can see the processes which can be adopted on top of their existing processes.
- Explore Phase: Technical conversion
Now that customer has explored the trail and customer is convinced to go for S4H system conversion, you have to handle the Technical preparation steps and test the conversion process. Following steps are involved in technical preparation:
- Check the Add-Ons and Industries using the maintenance planner to ensure compatibility with SAP S4H. A de-installation tool is available in case installed Add-ons are not compatible.
- Check the custom code check tool is to identify the scope, data structures and conflicts based on the simplification database
Once the above two technical steps are performed successfully in the development system then the actual conversion takes place. Since most the above conversion is technical in nature, they have no effect on the people’s work, so triggering of change management is not necessary when converting the system to S4H.
Simplification Database: Customer should detect the custom code compatibility with data structures, which needs to be adopted when moving to SAP S4H on-premises edition. SAP provided the simplification database which contains the information about the changes that took place between ECC systems to current version S4H.
- Custom code management tools need to be included in SAP ECC Netweaver 7.5, cloud-based tool is planned in future.
- The development entities adopted in SAP S/4HANA are maintained as piece list in SAP development system and exported as file and offered on SAP service market place.
- The customer can import the file with the relevant SAP entries into the simplification database custom code management tool.
- The customer can extract the similar file from ECC system using custom code extractor tool and the same can be imported to custom code check tool.
- Custom code analysis tool is used to compare the files extracted in step 2 and 4. The results are in ALV format that lists the incompatible data structures and scope between S4H and ECC along with the SAP notes relevant and also recommendations.
- Customer will be able to navigate from custom code analysis tools to the SAP note. These notes provide the technical changes and how these changes can be adopted.
Conversion Pre-Checks: Conversion pre-checks are shipped to S4H customers as SAP Note (2182725). Customers can use these pre-checks to find the mandatory steps that they must complete before converting to S4H by running the program R_S4_PRE_TRANSITION_CHECKS. The results need to be addressed before starting the conversion process.
Custom code check tool: custom code checks are based on the simplification database mentioned above. Before converting to S4H, we need to check custom code against SAP S4H simplifications. The simplifications are loaded to the custom code check tool, after running the tool you obtain the list of instances where your custom code does not comply with the scope of a data structure of S4H 1511, on-premises.
3.Realise Phase: Functional conversion and cutover.
The cutover takes place in the realisation phase, you use the database migration option (DMO) from the software update manager (SUM). Technically the system conversion is completed. Now customer needs to adopt the new functional features available on S4H to their existing processes.
Database Migration options: There are three data migration options from ECC system to S4H system as given below.
A: New Installation + Selective Migration:
In this approach, we leave the existing system as it is and migrate to a new S4H system. SAP Landscape Management Services offer a verity of options to reduce the effort required to build a targeted solution landscape, including shell copy, carve-out and System consolidation.
- System - consolidation: Here we consolidate a number of ERP systems into one S4H system, this will reduce the TCO (Total Cost of ownerships). Here we can transfer only the open data from multiple source systems to S4H system.
- Shell Copy: Is full to full data migration from existing ERP system to New S4H System, here all the data has to be migrated.3.
- Carve-out: In this option, we move only certain modules data or certain clients of ERP system to new S4H system.
B. Classical Migration: In the classical migration, system conversion goes in a phased approach, at first we perform the upgrade (if required) and secondly the database can be replaced either in-place DB migration or direct hardware replacement (OS / DB Migration).
Main advantages are: Resulting systems are identical, Minimal impact on the functional teams.
During the planning phase, we need to user the Maintenance Planner Tool http://apps.support.sap.com/sap/support/mp, in which we choose the source ECC system to be converted and select the target S4H version. This tool gives the result file by validating all the required technical compatibility like OS version, Stack Level, DB version etc. Download the file(stack.xml) and upload the same file into SUM (Software Update Manager).
Now that the new S4H system is ready for the application server and database server connected, the data migration is the final one which will be done by Software Provisioning Manager which is used for Extracting, Transforming & Loading the data from Old DB to HANA DB.
C. One step upgrade + Migrate with DMO:
In this approach, there is only one downtime overall and one maintenance phase. Original DB server is kept, can be reactivated as a fallback for Java systems always use the classical migration, this is applicable only for the ABAP systems.
Just like the classical migration, Data Migration Option (DMO) and Software Upgrade manager are used for the one-step migration, the only difference is its carried in a single step as there is no ETL steps since it is in-place conversion.
- SAP Managed Tags:
