This workstream arises because there are significant differences between both the data model and the code base between SAP ERP and SAP S/4HANA. Extensions that are deemed to be necessary and therefore retained (or extensions that are deleted but subsequently need to be restored) need to undergo an adaptation process. This process can take one of the following two forms:
- Automated Custom Code Adaptation
- Manual Custom Code Adaptation
Before differentiating between the two approaches, there is a preliminary topic that needs to be explored. In most cases, the project implementation team creates a copy of the SAP ERP production system into a special sandbox system. This sandbox is then used to test the conversion before performing it on the actual production system. This is sensible because the testing system should mimic production to the greatest extent possible. It is also sensible to make custom code adaptations in this sandbox system, and SAP generally recommends that project teams do so. However, this can lead to a complication. While the migration project to the new SAP S/4HANA is ongoing, the existing SAP ERP system still needs its normal maintenance and support activities. By the time the project team is ready to perform the system conversion in production, there may be some significant differences between the production system and the sandbox system used for testing. There are three potential solutions to solve this problem, as follows:
- Development freeze
One solution to this complication is to simply freeze development in the (soon-to-be legacy) SAP ERP system. While this option would theoretically work, the implication is that the normal maintenance, support, and most importantly innovation that would (and should) be happening would be ceased for some indeterminate amount of time. It is highly likely that the business side of the house would object to this.
- Double work
A different solution would be to simply redo all the custom code adaptation work done in the sandbox system in the newly converted SAP S/4HANA system. Once again, theoretically, this option would also work, but depending on the amount of adaptation work needing to be redone, it could also be very labor-intensive.
- Solution Manager retrofit
The preferred solution is to use the retrofit functionality with Solution Manager (version 7.2 Ehp 8 or above).
Automated Custom Code Adaptation
As mentioned previously, project teams have three options for custom code analysis: The SAP Fiori app Custom Code Migration (either on SAP S/4HANA or the same app on SAP Business Technology Platform, ABAP environment) and ABAP test cockpit available as part of ABAP development tools for Eclipse. The SAP Fiori app Custom Code Migration is integrated with ABAP test cockpit behind the scenes so therefore all three options can utilize the cockpit's Quick Fix functionality to automatically fix (and if required, activate) ABAP code to conform with SAP S/4HANA changes.
Manual Custom Code Adaptation
Code that cannot be adapted automatically must be adapted manually. The process to do this varies from project to project for different organizations, based on different factors. The following suggested process can be used as a starting point for analysis:
- Use the SAP Fiori app SAP Readiness Check Tool to get a list of the relevant SAP Notes describing custom code impact.
- After studying the SAP Notes, differentiate between those that specify technical code corrections versus those that require more specialized application knowledge. Use that differentiation to organize adaptation teams accordingly.
- In addition, if individual developers can specialize in certain types of code changes (based on the relevant SAP Notes), this can make the manual adaptation process more efficient. However, this may not always be possible.
- Determining an exact length of time that it will take to do all requested manual adaptions is unrealistic (and will most likely be incorrect). A time range estimate should be communicated to project migration stakeholders.