I am S/4HANA evangelist and support customers on their HANA journey. Recently I completed a project for S/4HANA conversion and through this blog series I want to take you through my project life-cycle; How to start, plan and execute; What to keep in mind and watch out for. This is topic #6 of 10 part blog series.
As you are proceeding to further read this blog series, it means you have decided that in-place system conversion is the right option for you and you have executed and resolved the SI Pre-Checks, completed CVI activation and SUM DMO Downtime and are now ready to start custom code remediation.
Custom code remediation in a system conversion project will involve the usual activities of ‘Load Based Procedure‘ as well as SPDD/SPAU/SPAU_ENH and custom code remediation for 1) HANA DB compliance (as it is columnar database with no implicit sort, no cluster tables and no implicit requirement of HINTS) and 2) S/4HANA Simplification compliance (towards the impact to custom code because of Simplification Items). So lets attack each of these items one by one.
Figure 1 : SAP Custom Code Assessment and Remediation (Source SAP)
1) First step of custom code remediation is Executing ATC (ABAP Test Cockpit) Checks. Refer to the blog to understand why to execute ATC checks, how to execute ATC checks and issues faced while executing ATC checks. Like SI Pre-Checks, custom code checks too have been simplified over the years (starting from SYCM and then SCI and now ATC). ATC checks are executed based on the Simplification Database (This contains the details of the SCI check classes and the reference data that need to be executed for the SIs that have potential custom code impact too).
Unlike SI Pre-Checks, ATC Checks have a minimum system requirement e.g. >NW7.52 is required to execute ATC Checks for S/4HANA 1909 conversion custom code impact (this is standalone NW system and does not require SAP_APPL components so you can use SOLMAN system too if that meets the requirement). To remove the dependency of setting up a new NW7.52 system SAP now supports to execute these checks from cloud too.
Custom Code checks can be executed in 3 modes 1) ATC Local (if the development system is >=NW7.52); 2) ATC Remote (where a >=NW7.52 system is available in the landscape but is different from the system being evaluated) and 3) SYCM Offline (where a >=NW7.52 system is not available in the landscape; download the repository info from development system and upload the same to offline >=NW7.52 system for analysis). Usually you will use the ‘Remote‘ mode for first assessment and once the system is converted to S/4HANA, you can run ATC checks ‘Local‘.
Finally to execute the checks, SAP provides you with multiple Check Classes (embedded in the SCI framework) and Check Variants (S4HANA_READINESS or S4HANA_READINESS_REMOTE) and results can be displayed within 1) ATC, 2) Eclipse ADT ATC Result Browser or 3) Custom Code Migration FIORI App. It is also important to identify the namespaces/packages that are relevant for custom code remediation. Please also ensure that repository statistics are up-to-date while executing ATC check to get accurate results (via program SAPRSEUC and RS_ABAP_INITIANALYSIS).
While you are not required to remediate SAP code but you are responsible for your custom code and the 3rd party software you have installed. Sometimes you might be using specific namespaces other than Z* or Y* for your custom development or you would have imported small set of programs from 3rd party vendor who does not provide regular support. All this code must be considered for ATC scope.
Once the ATC results are available, analyze them for patterns and check messages referring to the Simplification Item Catalog Custom Code instructions and build a solution set that developers can follow while remediating the code (I do not recommend each developer to do their own analysis).
2) Now the actual custom code remediation is done in S/4HANA post SUM DMO but SPDD/SPAU/SPAU_ENH are the first technical activities done in the conversion project wherein 1) Old SPAU/SPDD entries cleared from the system, Open transports are released and Inactive Objects are activated before SUM DMO start, 2) SPDD happens during SUM DMO Uptime and 3) SPAU/SPAU_ENH happens immediately after the SUM Downtime completion. These steps are same as in any upgrade project so I will not go into additional details. Additionally, CMOD repairs too must be handled during this stage.
3) Once SPAU is complete, next activity is Finance Conversion (more on this in TOPIC 07) followed by custom code remediation for S/4HANA. Before Finance conversion can start, the syntax errors in SAP programs due to impacted enhancements must be remediated first e.g. vbtyp length change, VBUK/P replacement etc. Once all the SAP programs are remediated for syntax errors, the system is handed over to FI team for finance conversion. Once that is complete, the development team works on the custom code remediation in the development system OR transports are imported in the post-development systems.
Automation is now available towards code remediation. SAP ADT Quick Fix is one option (In my experience, Quick Fix expects good programming standards in the existing code otherwise the assumptions for quick fix are invalidated and auto remediation might not work but this is improving every quarter). Another option is 3rd party tools. My organization too has built a tool that is successfully able to remediate upto 95% of HANA DB Issues and upto 70% of S/4HANA custom code issues. It is also recommended to decommission the unused custom code before you start the remediation to save efforts. Custom Code Migration FIORI App too has an option to remove the unused code that will be automatically dropped during the SUM phase.
During custom code remediation, please note while ATC results are mostly accurate but do not provide 100% coverage. Additional OSS Notes are required for correction of ATC results (like exclusion of generated code, exclusion of false positive for field length impact, inclusion of routines, report painters, area menu etc). Keep in mind other impacted areas like iDocs, translations, Screen Changes and deletion of customization in SAP namespace etc.while baselining the scope for custom code remediation. ATC results are prioritized as P1, P2 & P3 and while it is mandatory to remediate P1 and P2 issues, remediation of the P3 issues is optional. In addition, you can execute FUNCTIONAL_DB_ADDITION and PERFORMANCE_DB check variants too for other optional impact.
You will notice custom code objects reported in ATC results due to Mandatory innovation areas too. As most of the remediation will be dependent on the final design for the mandatory innovation areas, it is recommended to de-prioritize such remediation till the design is complete (more on this in TOPIC 08).
4) Next core activity for technical team is to setup the Retrofit Strategy as you will need to merge the changes from production into the project’s parallel landscape. As S/4HANA has a completely different architecture and data model compared to ECC, you need to be careful about importing ECC transports into S/4HANA. For workbench request, you will need to redo the remediation if the custom code in retrofit transport is overwritten. For the customizing request, especially for mandatory innovation areas, if the customizing table has been deprecated then the same will need to be manually replicated. Evaluate the PROD transports and possibly categorize them as following:
- Re-Implement; DO NOT RETROFIT
- SAP Notes, SP Updates
- 3rd Party SP Updates
- Workbench & Customizing Objects for Mandatory Innovation
- Manual RETROFIT
- Workbench – Objects not allowed as per HANA Architecture
- WorkBench – Repairs
- WorkBench – Data Dictionary & Programs for Manual Remediated Objects
- Customizing – Functional
- Transport RETROFIT followed by Auto Remediation
- WorkBench – Data Dictionary & Programs for Auto Remediated Objects
- WorkBench – Data Dictionary & Programs which were NOT remediated
- WorkBench – Others
- Customizing – Others Including Security
If possible, create a small utility to help with the above analysis and possibly warn the developers if they try to modify the S/4HANA remediated objects.
Based on my experience, less than 10% of the transports fall in the ‘Do Not Import‘ or ‘Manual Retrofit‘ category and rest can be handled via direct retrofit transport import. It is important to identify the ‘DO NOT IMPORT’ or ‘MANUAL RETROFIT’ scenarios correctly to avoid corrupting the instance.
5) Last core activity by development team is ‘System Release Checklist‘ wherein the development team 1) validates all transport logs, 2) executes basic checks on the critical transaction codes (no short dump while launching), 3) reviews system logs (SM21, ST22, Work Process Logs), 4) monitors the queues during the slow rampup and 5) validates setup of file system for interface directories.
In TOPIC 07 we will discuss “Finance Conversion”.