Planning an SAP transformation? Uncover custom code cost, complexity, and risk—free.
How to analyze SAP custom code at scale, retire what is never used and move the rest toward Clean Core, with smartShift founder Stefan Hetges.
This on-demand session shows how to analyze SAP custom code at scale, retire what is never executed, classify what remains against Clean Core levels A to D, and transform it with deterministic automation ahead of, during or after an S/4HANA move.
Recent research shows that 44% of organizations identify “too many customizations” as their biggest SAP S/4HANA migration challenge. According to the smartShift Benchmark, the average SAP ECC system contains around 22,000 custom objects and 2.7 million lines of code, often with hundreds of thousands of technical, security and performance issues. Addressing this technical debt manually is time-consuming, costly and risky.
In this session, Stefan Hetges goes beyond theory to show how to systematically analyze, decommission and automate custom code. You will gain a practical, data-driven roadmap to a stable, S/4HANA-ready Clean Core.
The session runs in eight parts, followed by live Q&A. Figures are from the smartShift Benchmark unless a customer is named.
Watch from 05:30
SAP ECC mainstream support ends in 2027, and every month of delay adds cost and disruption risk to the move. Technical debt compounds because past upgrades changed only what was mandatory, leaving the rest of the custom code untouched.
Manual approaches are too slow, too expensive and too error-prone to keep pace. For the upgrade path, see S/4HANA Version Upgrade.
Watch from 10:50
SAP is building a governed data foundation for AI, including its acquisitions of Reltio for entity resolution, Prior Labs for tabular AI and a zero-ETL live data access capability. That investment matters, but a data foundation only delivers trusted AI outcomes if the code that reads from and writes to it follows the same rules.
Most SAP customers run thousands of custom programs built for ECC. Many bypass SAP standard APIs, read directly from database tables and write to custom structures the data layer cannot see. These programs run in production every day and quietly undermine the foundation.
An AI agent can only be trusted to reason correctly when both layers are in place.
Watch from 13:00
Across more than 3,000 customer systems analyzed, the smartShift Benchmark profile of a typical SAP ECC system is:
| Custom objects | About 22,000 |
| Lines of custom code | About 2.7 million |
| Issues found | About 300,000, covering mandatory S/4HANA changes plus ABAP standards, performance, security, stability and resilience |
A significant share of that code is never executed in production, and unused code typically carries even more technical debt and security exposure than the code in use. Retiring it before the move means it is never analyzed, remediated or tested again. See Code Analysis and Code Decommissioning.
Watch from 14:25
SAP extended its Clean Core guidance with a framework that classifies existing custom code by its impact on upgrade stability. Once every object is classified, the modernization priorities follow.
| Level A | Built with ABAP Cloud and released APIs. Runs on SAP BTP and in private cloud. Includes key user apps, custom fields and RAP business objects. |
| Level B | Uses well-defined classic APIs that are not released for cloud development but that SAP considers stable. Acceptable in SAP S/4HANA Cloud Private Edition. |
| Level C | Conditional Clean Core. SAP provides transparency through change logs, but stability is not guaranteed. |
| Level D | Modifications, implicit enhancements, direct table updates and direct calls to standard function modules. These violate Clean Core principles and should be removed or redesigned. |
In one anonymized customer analysis, about 4,000 function modules sat at level A, 4,200 at level B, 5,200 at level C and 12 at level D. The same system had 413 maintenance views, 3 level D user exits and 619 implicit and explicit enhancements to address. See Clean Core Analysis and ABAP Cloud Enablement.
Watch from 16:40
Manual remediation fails at scale because a bucket of hours covers critical fixes only. Decommissioning, optimization and security improvements are left out, latent issues go undetected, and qualified ABAP developers are getting harder to find every year.
Basic automation that makes syntax-level fixes only scratches the surface. After the effort and expense, most organizations are left with the same custom code challenges they started with and no progress toward Clean Core.
A Clean Core program needs four things in place:
See Code Transformation.
Watch from 20:40
The platform sits outside the SAP system and works in five stages:
For Procter & Gamble's mission-critical supply chain system, the platform made 1.3 million changes for HANA and S/4HANA compatibility, performance, security and stability, with about 20 tickets raised in QA. AI is used for recommendations, not for rewriting code. See How It Works.
Watch from 26:35
During an S/4HANA transformation, ECC and S/4HANA run in parallel. Developers keep making hotfixes and new changes in ECC while functional work continues in S/4HANA, and a code freeze would stop the business.
Dual Maintenance takes the objects changed in ECC each month, typically 100 to 1,000, runs them through the same platform, then compares, resolves conflicts, merges and remediates them into S/4HANA using abapGit. Both landscapes stay aligned without a code freeze. See Dual Maintenance.
Watch from 39:15
Clean Core is a journey, not a single project. The framework breaks it into phases:
The next step is a free Rapid Code Analysis, which shows your main issue categories and their volume.
Results from enterprise S/4HANA transformations delivered with smartShift.
Stefan Hetges is the founder of smartShift. He started the company in 2002 and led its focus into SAP custom code transformation in 2006. He is a co-inventor of the patents underlying smartShift’s automation platform, developed with a team of architects, friends, and longtime collaborators. Every fixed-price, fixed-timeline SAP transformation project smartShift has delivered across nearly two decades has come in on time and on budget, and delivered guaranteed outcomes.
Learn more about smartShift and its founder
The six smartShift solutions this session covers.
Questions raised in the session and its live Q&A.
Yes. Clean Core is the next step after S/4HANA, so the work starts with a fresh code analysis and a Clean Core analysis. Customers who moved manually often still have HANA and S/4HANA issues that were left as warnings, and these are fixed in the same pass.
The platform turns source code into data: dependencies, call flows, data flows and usage. Decisions such as which objects can be retired are based on that data rather than on assumptions, for example when an object SAP reports as unused is still called by a program that is in use.
Usage data from SAP sources such as SCMON, UPL or ST03N is loaded into the meta model and combined with call-flow and data-flow analysis. The result shows what can technically still be called, and business owners confirm before anything is removed. Where there is doubt, a tracking statement can be inserted so any call to a flagged object is logged.
Level A is ABAP Cloud with released APIs, level B uses stable classic APIs, level C is conditional Clean Core without guaranteed stability, and level D covers modifications, implicit enhancements and direct table updates. Level D objects should be removed or redesigned first.
Only to a limited extent. In smartShift Clean Core analyses, just 1% to 2% of existing custom code is loosely coupled enough to consider moving to BTP, because the ABAP available there is more restricted. Most Clean Core work happens on stack.
No. smartShift can provide technical support around Fiori, but it does not convert reports into Fiori apps.
The analysis identifies issues such as transactions with no authority check and directory traversal risks, and about 20 security rules can fix them. Adding security rules does not lengthen the automated run, only the QA effort slightly.
It runs as a series of bounded projects. A Clean Core analysis identifies a business area, smartShift transforms it, your developers complete the remaining manual changes, and the next area follows. Customers with multiple systems often use a frame contract.
In most projects, the automated transformation and QA are completed in four to six weeks, delivered at a fixed price and on a fixed timeline. The free Rapid Code Analysis is the usual first step to size the work.
Get the latest insights on S/4HANA, Clean Core, custom code, and AI delivered to your inbox.