Series of Technology Essentials for Moving to SAP S/4HANA – tip #3: Don’t Just Rework Custom Code. Rethink it.
This is a series of blogs written by SAP subject matter experts to prepare you for your journey to SAP S/4HANA. Ready? Let’s go!
Topic #3 is about Custom Code.
You’re probably familiar with one set of tools for adapting custom code – ABAP test cockpit checks. Here are a few other things to remember when dealing with custom code.
Automated and manual code adaptation
Correcting ABAP statements in custom code to re-establish compatibility with the new data model or APIs for SAP S/4HANA is called custom code adaptation. The only tools you need to identify the required corrections and adapt the code are the Custom Code Migration app and ABAP development tools in Eclipse. Rely on the quick fixes feature of ABAP tools in Eclipse to automatically resolve the majority of findings. Correct the rest manually, focusing on priority one (errors) and two (warnings) findings.
Contrary to popular belief, you need to correct findings in both unused and used code to avoid system dumps and data inconsistencies.
Check out this blog about quick fixes for more details.
Rethink, not just rework
Adaptation is the most straightforward approach for custom code, yet not always the right one:
- If you can redesign a custom development with new technological options, you can save adaptation efforts and reduce future maintenance.
- You can replace some custom extensions, including modifications, with the in-app extensibility features of SAP S/4HANA; others may be candidates for side-by-side extensibility.
- Custom developments with complex code increase maintenance costs. Use code complexity as a metric to prioritize which developments to redesign. The Custom Code Migration app helps you spot the most complex developments, which often also experience the most frequent changes. These have the biggest savings potential.
Another candidate for redesign is “orphaned” custom functionality – developments without proper documentation or owner. Avoid moving orphaned developments into SAP S/4HANA. System conversion is the right time to reassess such developments.
Review of modifications, clones, and implicit enhancements
Many SAP ERP systems contain a high number of obsolete modifications where the code is identical to the standard. In fact, during several reviews of customer systems, the vast majority of modifications were classified as either obsolete or dispensable. There is no reason to move these to SAP S/4HANA as you can revert them without impact.
Analyze all modifications and classify them into the categories below. Don’t be deterred by numbers; the actual modifications are much fewer. Include clones (custom programs created as copies of SAP code) and implicit enhancements and treat both as modifications.
|Obsolete – Object identical to the SAP version||Revert|
|Unused – According to code usage statistics||Revert|
|Dispensable – Modifications that become irrelevant on SAP S/4HANA, or standard objects belonging to deprecated application components||Revert|
|Replaceable – When you can fulfill business requirement with standard SAP functionality, in-app extensibility, or partner solution||Revert and redesign upon conversion|
|Required – Modification that supports critical business process||Document business requirements and contact SAP to get advice on those modifications|
For more details, read this white paper.
Check out all topics of the series:
tip #1: Check Your Add-ons. Now.
tip #2: Check Your Finance Data Quality
tip #4: How to Build Custom Extensions
tip #9: Understand the Functional Impact
tip #11: Optimizing Downtime in Conversions
tip #12: Find Relevant SAP Notes
tip #14: Implementing SAP Fiori