Explore how to evaluate custom code dependencies, prioritize ABAP remediation, choose clean core extension approaches, and reduce migration risks.
Years of custom ABAP development can complicate a move from SAP ECC to SAP S/4HANA. Existing programs may rely on data structures, interfaces, or SAP objects that have changed in the target system. Even technically compatible code may create upgrade risks when it depends on unsupported objects or interfaces.
Custom code remediation helps organizations address these dependencies while preserving the functionality their business processes still require.
Quick answer: Assess custom developments using production usage data, dependency analysis, and SAP S/4HANA compatibility checks. Based on the findings, decide which objects to retire, replace with standard functionality, retain, remediate, or redesign as supported extensions. SAP Readiness Check and ABAP Test Cockpit (ATC) can support the assessment, while functional testing confirms that the selected changes work as intended.
What Does Clean Core Mean for Custom Code Remediation?
SAP's clean core approach aims to keep ERP systems standardized and upgrade-stable through supported extensibility practices. Although the strategy also covers processes, data, integrations, and operations, its relevance to custom code remediation lies primarily in how extensions interact with SAP standard functionality.
SAP classifies custom extensions into four clean core levels, based on the SAP objects and development technologies they use.
|
Level |
Classification |
Architectural implications |
|
A |
Clean core |
Uses released APIs and extension points designed for upgrade-stable development |
|
B |
Clean core |
Uses established classic APIs and extension points recognized by SAP |
|
C |
Conditional clean core |
Uses internal SAP objects that are not released and not explicitly classified as not recommended; requires upgrade-impact checks |
|
D |
Not clean core |
Uses non-recommended SAP objects or techniques, such as modifications to the SAP standard, implicit enhancements, or unsupported direct writes to SAP tables |
This classification helps teams distinguish code that follows supported extensibility practices from developments that require additional risk management or architectural changes.
A remediation decision does not automatically determine the clean core level. An existing program can be adapted without reaching Level A, while some classic ABAP developments may already qualify for Level B.
How Do You Decide What to Do With Custom ABAP Code Before Migration?
The options for handling custom ABAP code depend on the target SAP S/4HANA edition and migration approach. During a system conversion to SAP S/4HANA on-premise or SAP Cloud ERP Private, organizations can retain or adapt compatible classic ABAP developments. SAP Cloud ERP Public follows a different extensibility model, requiring business-specific functionality to be evaluated against supported extension options rather than transferred as traditional classic ABAP code.
1. Retire unused customizations
Developments with no confirmed business purpose or recorded execution may be removed. However, infrequently executed processes, such as annual closing routines or exception-handling programs, can appear unused during a limited observation period. Retirement requires confirmation that the functionality and its dependencies are no longer needed.
2. Replace custom functionality with SAP standard
Some ECC customizations address requirements that SAP S/4HANA can now support through standard functionality. For example, an existing custom report might be replaced with standard analytical capabilities, provided they cover the required business rules and reporting needs.
3. Retain compatible code
In SAP S/4HANA on-premise and SAP Cloud ERP Private environments, existing classic ABAP developments may be retained when they serve a valid business purpose, remain technically compatible, and present acceptable maintenance risks. Their continued use should be assessed against the target system's extensibility capabilities and long-term clean core objectives.
4. Remediate incompatible code
During a system conversion, existing ABAP developments may require adjustments to data access, application logic, or interfaces affected by SAP S/4HANA simplifications. Remediation preserves the required functionality through targeted code changes, where the target environment supports the underlying development approach.
5. Rebuild functionality as a supported extension
Redesign may be preferable when existing customizations rely heavily on modifications to SAP standard objects, introduce substantial technical debt, or no longer meet business requirements. The replacement should use an extensibility approach appropriate to the target architecture and application dependencies.
SAP S/4HANA Custom Code Remediation Roadmap
For an SAP ECC-to-SAP S/4HANA system conversion, custom code activities span three phases: preparation before technical conversion, adjustments during conversion, and functional adaptation afterward, as outlined in SAP's system conversion guidance. The sequence below focuses on system conversion; greenfield implementations and Selective Data Transition projects require different execution plans.
Before technical conversion
1. Establish the custom code baseline. Create an inventory linking custom objects to business processes, owners, execution history, interfaces, and technical dependencies. Identify gaps in usage data and developments that may no longer be required.
2. Assess and plan remediation. Run SAP S/4HANA compatibility checks, review simplification impacts, and agree on the treatment of in-scope customizations. Identify modifications and enhancements requiring adjustment during or after conversion, alongside code that will need functional adaptation.
During technical conversion
3. Adjust ABAP Dictionary modifications. Where applicable, use transaction SPDD to adjust customer modifications to ABAP Dictionary objects during the conversion process.
After technical conversion
4. Complete modification adjustments and functional adaptation. Use SPAU and SPAU_ENH where required to adjust repository modifications and enhancements. Run SAP S/4HANA-specific ATC checks in the converted environment, address remaining incompatibilities, and apply the approved custom code changes. If ECC development continues in parallel, coordinate subsequent changes with the target landscape.
5. Validate business functionality. Test adapted developments and their integrations, resolve critical defects, and obtain business acceptance before production deployment. Record any accepted residual risks and confirm post-go-live support responsibilities.
SAP Tools for Custom Code Assessment
SAP provides complementary tools for evaluating custom ABAP developments before an SAP S/4HANA migration. They help teams understand the overall impact, identify technical incompatibilities, and determine which code is still used.
SAP Readiness Check
SAP Readiness Check provides an overview of migration-related requirements, including potential custom code adaptation. Its findings help estimate the impact on the existing landscape and identify areas requiring further analysis.
The level of detail depends on the analysis method used. ATC-based checks provide more granular findings for investigating individual custom developments, as explained in SAP's Readiness Check guidance.
ABAP Test Cockpit (ATC)
ATC performs static checks on custom ABAP developments, identifying issues such as references to incompatible SAP objects and code affected by SAP S/4HANA simplifications.
Findings help developers locate affected code and investigate required changes. Where supported, Quick Fixes can automate specific adaptations, depending on the finding type and available correction functionality.
For example, an ATC check may flag custom ABAP code that accesses the legacy KONV table, which is replaced by PRCD_ELEMENTS in the SAP S/4HANA pricing data model. Developers must review the affected logic and adapt it to the new data structures. SAP provides Quick Fix support for certain KONV-related findings, although not every adaptation can be automated.
ATC can also run checks related to ABAP Cloud development requirements, supporting the assessment of existing extensions against modern extensibility practices.
Custom Code Migration and Analyze Custom Code
These SAP applications use ATC-based analysis and collected usage information to help teams review findings and define the custom code migration scope.
Starting with SAP S/4HANA 2025 and the corresponding supported cloud releases, SAP separates the migration and general analysis use cases into the Custom Code Migration and Analyze Custom Code apps. Earlier releases may provide these capabilities through a single application.
The tools support filtering findings by scope, usage, and Quick Fix availability. They can also help identify unused developments and prepare their exclusion from a system conversion.
The available functionality and setup depend on the SAP release and analysis environment. SAP describes the supported scenarios in its Custom Code Analysis documentation.
SCMON and UPL
ABAP Call Monitor (SCMON) and Usage and Procedure Logging (UPL) collect information about custom code execution in the source system. This data helps identify actively used developments and potential retirement candidates.
SAP recommends collecting usage data for 6–18 months, ideally covering at least one full year and an annual closing cycle. A shorter observation period may miss seasonal, year-end, or other infrequently executed processes.
Transaction SUSG aggregates and retains usage data collected by SCMON, whose detailed records are stored only for a limited period. Aggregated data can then support custom code migration scoping and decisions about which developments require further analysis.
SAP explains the recommended monitoring period and aggregation process in its guidance on collecting usage data for custom code.
How Should You Prioritize the Custom Code Remediation Backlog?
Custom code remediation priorities should reflect business impact, technical severity, and dependencies, rather than the number of ATC findings alone. A single incompatibility affecting order processing may demand more attention than numerous warnings in a low-impact application.
A practical approach is to distinguish three priority groups:
-
Conversion blockers. Address incompatibilities that prevent required functionality from operating in SAP S/4HANA or threaten critical migration activities. These issues need resolution before the affected processes can be approved for production use.
-
Business-critical dependencies. Prioritize developments that support high-volume transactions, regulatory processes, or interfaces used by multiple applications. For example, a custom pricing enhancement may require early attention because changes could affect order processing across several business units.
-
Nonblocking improvements. Schedule lower-risk corrections and architectural improvements according to their maintenance value, implementation effort, and impact on future upgrades. Some can be completed after go-live if the remaining risks are acceptable.
Dependencies and lead times can change this order. A complex enhancement requiring changes across several systems may need to start earlier than a higher-severity issue with a straightforward fix.
The SPDD and SPAU/SPAU_ENH adjustment sequence applies specifically to system conversion scenarios where the relevant modifications or enhancements exist. Greenfield implementations follow a new development and configuration process, while Selective Data Transition projects require a project-specific approach to transferring and adapting custom code.
When Should Custom Code Move to SAP BTP Instead of Staying in SAP S/4HANA?
The choice between on-stack and side-by-side extensibility depends primarily on how closely custom functionality interacts with SAP S/4HANA transactions, data, and application processes.
On-stack extensibility is generally better suited to functionality that requires close integration with ERP processes or access to business data within the same transaction. Depending on the requirement, organizations can use key-user extensibility for supported, smaller adaptations or developer extensibility for more complex ABAP-based solutions.
Side-by-side extensibility on SAP BTP is typically appropriate for loosely coupled applications, external integrations, and functionality requiring an independent development and deployment lifecycle. These extensions communicate with SAP S/4HANA through supported APIs and, where appropriate, business events rather than executing directly within the ERP system.
For example, an approval application combining SAP purchasing data with external risk scores may be a candidate for SAP BTP. However, custom logic that must participate directly in an SAP purchasing transaction may be better implemented through an available on-stack extension point.
Side-by-side development also introduces architectural considerations, including API availability, network latency, data consistency, security, and additional platform costs. The available options depend on the target SAP S/4HANA deployment model and its supported extensibility capabilities.
Custom Code Remediation Across SAP S/4HANA Migration Approaches
The migration approach determines how much existing custom code enters the target landscape and whether remediation focuses on adapting legacy developments or recreating required functionality. These differences reflect the broader trade-offs between Brownfield and Greenfield SAP S/4HANA migration.
Brownfield (system conversion)
Existing custom developments generally remain in the converted system, making compatibility assessment and code adaptation major preparation activities. Unused developments can be identified for retirement or excluded from the relevant custom code adaptation scope through supported preparation and scoping procedures. The treatment of these objects depends on the conversion approach and tooling.
Greenfield (new implementation)
Custom code is not transferred automatically into the new system. Instead, teams identify which business capabilities still require custom development after evaluating standard SAP S/4HANA functionality. The effort shifts from adapting existing programs toward defining and implementing the required functionality.
Selective Data Transition
Organizations can preserve selected elements of their existing landscape while redesigning others. The treatment of custom developments depends on the transformation scope, target architecture, and migration tooling, so code transfer and remediation requirements must be assessed for each project.
Consider a custom order-processing enhancement. Brownfield conversion may require adapting its existing code, while a greenfield implementation may call for redevelopment after reassessing the business requirement. Under Selective Data Transition, the treatment depends on the agreed-upon transformation scope and tooling.
What Can SAP Custom Code Analysis Miss?
Static analysis cannot identify every issue that may arise when custom ABAP programs run in SAP S/4HANA. For example, dynamically constructed calls and object references may be difficult to resolve without runtime information. SAP's Runtime Check Monitor (SRTCM) complements static analysis with specific runtime checks, such as detecting empty internal tables used with FOR ALL ENTRIES or missing explicit sorting after SELECT statements. It does not provide comprehensive detection of dynamic dependencies.
Custom Code Validation Before SAP S/4HANA Go-Live
Validation should confirm that remediated developments preserve the required business behavior across transactions, interfaces, authorizations, and representative workloads.
Functional regression testing should cover normal operations, exceptions, and period-end activities. For example, an adapted financial posting program must produce the expected accounting entries and reconciliation results, not merely execute without errors. Integration testing should also verify that connected systems exchange data correctly after changes to interfaces, data structures, or processing sequences.
Security and performance require separate attention. Existing authorization restrictions must remain effective, while resource-intensive programs should be tested under realistic transaction volumes. Extensions built on SAP BTP also need validation of API interactions, error handling, monitoring, and data consistency between systems.
Acceptance criteria should specify the expected business results, required test coverage, and conditions for approving unresolved defects. Business process owners and technical teams can then assess whether the remediated functionality meets the requirements for production use.
Custom Code Modernization in Practice: LeverX Projects
Custom code modernization can take different forms depending on the existing ERP landscape and transformation objectives. Two LeverX projects illustrate how code assessment supports both SAP S/4HANA migration and the adoption of clean core architecture.
Eurasia Group: custom code review during SAP S/4HANA migration
Eurasia Group, an agricultural equipment distributor in Kazakhstan, partnered with LeverX to migrate from SAP ECC to SAP S/4HANA. The project included reviewing existing custom developments and outdated business processes to identify opportunities for improvement.
Completed in 8.5 months, the migration resulted in a 15% improvement in data consistency, supported by the review of business processes and custom code. Eurasia Group also reported a 10% reduction in system maintenance costs as an outcome of the broader ERP transformation.
Multinational apparel company: modernizing ABAP extensions with SAP BTP
A multinational apparel company faced increasing maintenance costs and upgrade disruptions caused by traditional ABAP customizations in its SAP S/4HANA environment.
LeverX assessed the existing codebase, performed ATC checks, and evaluated available SAP APIs and released objects. Selected custom programs were then rearchitected using SAP BTP ABAP Environment and the ABAP RESTful Application Programming Model (RAP).
The three-month project helped reduce upgrade-related downtime and maintenance overhead. It also introduced modern ABAP development practices that the client's technical team could apply to future extensions.
Evaluating a Custom Code Remediation Partner
A remediation proposal should define the assessment scope, expected deliverables, and responsibilities for work that crosses project boundaries. Estimates based solely on the number of custom objects can be misleading when developments differ significantly in complexity and business impact.
Before selecting a partner, clarify how remediation effort will be estimated, which activities are included in the quoted scope, and who will resolve dependencies involving other teams or third-party systems. The agreement should distinguish responsibility for technical fixes from business acceptance and specify how defects discovered during testing will be handled.
LeverX supports custom code assessment, ABAP remediation, and extension modernization as part of SAP S/4HANA transformation programs. These activities can be coordinated with migration and integration workstreams where responsibilities overlap.
Conclusion
The scope of custom code remediation depends on the existing ERP landscape, business requirements, and target SAP S/4HANA architecture. A focused assessment helps establish a realistic development effort and identify dependencies that could affect the migration schedule.
Contact LeverX to discuss your custom code landscape and plan the remediation work required for your SAP S/4HANA transition.
