Custom code in SAP systems is kind of a double-edged sword – while it provides you with the flexibility to address even very specific tasks, it also creates complexity that can lead to various issues. Arguably the biggest such issue comes around when it’s time to upgrade your system, as your move to SAP S/4HANA can be massively hampered by endless lines of disorganized code.
Luckily, there is a methodology that can help you tackle this problem, which is the concept of a “Clean Core”. SAP Clean Core aims to decouple customizations from the core system, making future updates simpler, faster, and more secure.
But how do you get there?
Let’s dive deep into the roadmap of Clean Core as well as the solutions that put it into practice.
What Does “Clean Core” Really Mean?
Over the years, SAP environments (especially those running on ECC) tend to accumulate layers of custom code, most of which are deeply embedded in the core. This makes upgrades to S/4HANA extremely difficult, as every line of code needs to be checked, modified, and tested.
On the other hand, we have the SAP Clean Core concept – an alternative method that is about keeping your core system well-organized and as close to standard as possible while still allowing for customizations.
According to Clean Core, you need to isolate your custom code from the core and run it in SAP’s extensibility frameworks such as key user extensions, RAP (Restful ABAP Programming Model) and CAP (Cloud Application Programming). This keeps the core clean, reducing the impact of customizations during upgrades and helping smoother adoption of new SAP features.
The Process: Moving to a Clean Core SAP System
But how do you achieve this alluring Clean Core?
In this section, we’ll dive into what we at smartShift believe to be the most optimal process.
Step 1: Making Sense of Your Custom Code
The path to a Clean Core starts with taking a detailed inventory of all custom objects, from user exits to Z-programs, and evaluating their purpose in your current environment. This is where you must analyze all the dependencies between your custom and standard objects, and understand the business logic behind each customization.
This analysis must be done in a way that takes into account both technical and functional aspects of the code. Remember that just because a piece of code hasn’t been used recently doesn’t mean it’s not critical during specific operational cycles – like financial closes or end-of-year reporting.
So, in the end, you should produce a clear plan, outlining what code is critical, what can be decommissioned, and what needs modernization. This kind of plan tends to become very convoluted and complex very quickly, which is why we strongly recommend using assisting solutions here – for example, a powerful Clean Core X-Ray.
Step 2: Remediation and Optimization
The next step is to address any compatibility issues between your legacy custom code and S/4HANA. SAP S/4HANA introduces fundamental changes in database structure (moving to HANA), user interfaces (Fiori), and core functionality (such as the new data models for finance and logistics). As a result, custom code written for older SAP environments is unlikely to function correctly in S/4HANA without modernization.
That’s what remediation is for – you rework the underlying logic of the code so that it works in the new environment. This is especially relevant in cases when the code interacts with areas that have undergone significant change in S/4HANA, such as material ledger or asset accounting.
The remediation process should also include an assessment of how the custom code affects system performance. Since the HANA database is designed to handle data-intensive tasks in-memory, legacy code that was optimized for older database architectures may not perform well and may need to be remediated.
Also note that traditional code remediation may take months, which can be far from optimal. However, there is a range of advanced solutions like smartShift’s Intelligent Automation that can help expedite this process to as little as a couple of weeks.
Step 3: Automating Dual Maintenance
Meanwhile, as the SAP upgrade is taking place, the existing production system must also remain fully operational. This creates a need for dual maintenance – making sure that both the current ERP system and the new system always stay in sync.
That’s why you should set up processes in a way so that every change made to the custom code in the current system is mirrored in the new S/4HANA environment. And smartShift’s dual maintenance automated solutions can assist in this process, helping you merge and reconcile changes in real-time.
Step 4: Security and Compliance
A crucial step – as part of the Clean Core process, you must also perform a full security audit of your custom codebase. Any security or compliance issues found during this audit should be remediated before the code is moved into the S/4HANA environment.
Specifically, you should look for any code that interacts with sensitive data, such as financial information or personal customer data, and assess if the necessary security measures are in place. It should also look for compliance issues, particularly in highly regulated industries.
Step 5: Realizing Clean Core in S/4HANA
The final step in the SAP Clean Core roadmap is to decouple as much custom code as possible from the core SAP system. This is the central idea of this concept: keeping the core SAP system untouched, while running custom business logic externally, such as in key user extensibility. This way, future updates and upgrades become far simpler.
Decoupling needs adapting that code to operate in a new modular, service-based architecture. And this means rethinking how your custom business processes are implemented, so that they interact with the SAP core via APIs, rather than being deeply embedded in the core itself.
Conclusion
Custom code optimization and achieving a Clean Core in SAP systems is not a simple task, but with the right solutions and strategy, it’s entirely achievable. With the help of solutions like smartShift’s Clean Core X-Ray, you can easily make sense of your existing codebase in detail, then remediate and modernize that code, and finally decoupling it from the core SAP.
In the end, you will get a modernized and scalable SAP environment that is ready for whatever comes next.
