Skip to main content
smartShift onDemand

De-Risking SAP S/4HANA: Custom Code and Clean Core

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.

Session at a Glance

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.

  • Recorded: June 11, 2026
  • Runtime: 56 minutes, on-demand replay
  • Speaker: Stefan Hetges, Founder, smartShift
  • Who it's for: SAP leaders and architects planning or running an S/4HANA transformation

Jump to a Chapter

About the Webinar

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.

Key Takeaways

  1. Decide what to retire from usage data, not opinion. Usage data from SCMON, UPL or ST03N, combined with call-flow and data-flow analysis, shows which objects can technically still be called. Business owners confirm before anything is removed.
  2. Size the problem before you plan it. The smartShift Benchmark puts a typical SAP ECC system at about 22,000 custom objects, 2.7 million lines of code and roughly 300,000 issues, most of them beyond the mandatory S/4HANA changes.
  3. Classify every object against Clean Core levels A to D first. Level D (modifications, implicit enhancements, direct table updates) is where the work sits. In one anonymized customer analysis, just 12 of roughly 13,400 function modules were level D, while 619 enhancements needed attention.
  4. Do the manual math before choosing an approach. At 5 to 15 minutes per change, the 1.3 million changes made for Procter & Gamble would take years of developer effort. Automation completed them with about 20 tickets raised in QA.
  5. Agentic AI needs trusted code as well as trusted data. Custom programs that bypass SAP standard APIs or read raw tables undermine the governed data foundation SAP is building for AI.
  6. Start Clean Core work on ECC. Much of the ABAP Cloud syntax can already be adopted in ECC, and around 80% of database access patterns can be replaced automatically during the move to S/4HANA.
  7. Plan for on-stack work, not a move to BTP. In smartShift Clean Core analyses, only 1% to 2% of existing custom code is loosely coupled enough to consider moving to SAP BTP.

Inside the Session

The session runs in eight parts, followed by live Q&A. Figures are from the smartShift Benchmark unless a customer is named.

SAP Timelines Are Tightening and Technical Debt Is Compounding

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.

SAP Agentic AI Needs Two Layers: Trusted Data and Trusted Code

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.

  • Data layer: SAP is solving this with its governed data foundation.
  • Code layer: custom code is retired where it is no longer needed, transformed to use governed APIs where possible, and preserved where it carries business logic built up over decades.

An AI agent can only be trusted to reason correctly when both layers are in place.

An Average SAP ECC System

Watch from 13:00

Across more than 3,000 customer systems analyzed, the smartShift Benchmark profile of a typical SAP ECC system is:

Custom objectsAbout 22,000
Lines of custom codeAbout 2.7 million
Issues foundAbout 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.

Modernize Your SAP Landscape with Confidence
Patented automation. Fixed price, fixed timeline, guaranteed delivery. Talk to a smartShift expert about your transformation.
Get in Touch →

Clean Core Levels A to D Explained

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 ABuilt 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 BUses 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 CConditional Clean Core. SAP provides transparency through change logs, but stability is not guaranteed.
Level DModifications, 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.

Manual Remediation Is Labor-Intensive, Slow and Risky

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:

  1. Define Clean Core goals: set targets for cloud upgradeability and metrics to measure success.
  2. Get visibility: identify every customization, its attributes and its critical issues.
  3. Stay clean: set development standards, a governance process and developer training.
  4. Get cleaner: retire unused code, replace custom code with SAP standard where possible and move objects up from level D toward A.

See Code Transformation.

The smartShift Intelligent Automation Platform

Watch from 20:40

The platform sits outside the SAP system and works in five stages:

  1. Extract: a simple ABAP report extracts custom code only, never business data, into a neutral XML format. Usage data from SCMON and UPL and, for S/4HANA, SAP Readiness Check results are added.
  2. Model: a proprietary ABAP parser loads the code into a language-independent meta model enriched with usage, dependencies, data flow and CRUD operations.
  3. Transform: more than 250 deterministic transformation rules cover HANA and S/4HANA compliance, performance, security, code standardization and ABAP Cloud syntax. Each rule analyzes, rewrites and documents the change the same way every time.
  4. Load back: transformed code returns to the target system through standard SAP transports, ready to move to QA and production.
  5. Quality assurance: syntax checks, extended program checks, ATC checks and initial runtime tests, plus semi-automated changes for corner cases SAP does not allow to be changed automatically.

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.

Dual Maintenance: Keeping Innovation Moving Without a Code Freeze

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.

The Clean Core Recommendation Framework

Watch from 39:15

Clean Core is a journey, not a single project. The framework breaks it into phases:

  • Before and during the move to S/4HANA: replace obsolete syntax, optimize database access patterns (around 80% can be replaced automatically) and adopt ABAP Cloud syntax, much of which is already possible in ECC.
  • On S/4HANA: replace table appends with custom fields, move classic custom fields to key user fields and adopt CDS views and released APIs.
  • Clean Core analysis: map every application area by how tightly it is coupled to the core, then build a roadmap that starts with loosely coupled areas or with whatever the business needs first.

The next step is a free Rapid Code Analysis, which shows your main issue categories and their volume.

Key Terms from the Session

  • Clean Core: SAP's approach to keeping the ERP core close to standard so upgrades are easier and new SAP innovation can be adopted continuously. It spans extensibility, data, integration and business processes; this session covers custom code extensibility.
  • Clean Core levels A to D: SAP's classification of custom code by its impact on upgrade stability, from level A (ABAP Cloud and released APIs) to level D (modifications and direct table updates).
  • ABAP Cloud: SAP's development model for upgrade-stable extensions, using a restricted ABAP language version and only released APIs and extension points. It applies on stack in S/4HANA and side by side on SAP BTP.
  • Dual Maintenance: keeping ECC and S/4HANA aligned while both run in parallel during a transformation, so ECC changes reach S/4HANA without a code freeze.
  • Technical debt: the accumulated cost of shortcuts and minimal fixes in custom code, such as obsolete syntax, performance problems and security gaps, which grows with every upgrade that changes only what is mandatory.
  • Code decommissioning: identifying custom code that is never executed in production and retiring it, so it is never remediated, tested or maintained again.
  • RISE with SAP: SAP's subscription offering for moving to SAP S/4HANA Cloud, which has accelerated the push toward Clean Core.
See What's Actually Inside Your SAP Custom Code
Get a free Rapid Code Analysis. Uncover compatibility issues, security risks, and modernization opportunities across your entire ABAP codebase.
Get My Free Analysis →

About the Speaker

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

stefan-hetges
Modernize Your SAP Landscape with Confidence
Patented automation. Fixed price, fixed timeline, guaranteed delivery. Talk to a smartShift expert about your transformation.
Get in Touch →
FAQ

Frequently Asked Questions

Questions raised in the session and its live Q&A.

Can smartShift help if we are already on SAP S/4HANA?

Why is it called a data-driven approach?

How does smartShift identify custom code that is not used in production?

What sits at each Clean Core level?

Can custom code be moved to SAP BTP as part of Clean Core?

Does smartShift convert reports into SAP Fiori apps?

What does ABAP security transformation cover?

Is a Clean Core program a one-time project or ongoing?

How long does a transformation take?

Stay ahead of SAP modernization.

Get the latest insights on S/4HANA, Clean Core, custom code, and AI delivered to your inbox.