Custom code creates a scheduling problem long before it creates a coding problem.
The first SAP ECC to S/4HANA migration analysis may identify hundreds of affected objects and findings. They immediately look like an ABAP workload. Developers can inspect the code, determine what is incompatible, estimate corrections, and start remediation.
That view misses where much of the delay comes from.
A technically affected program may support a process the business plans to retire. Another may depend on an interface owned by a third party. A custom pricing enhancement may require Sales to confirm whether the underlying rule still applies before anyone can redesign it. An old report may generate findings even though production usage shows that nobody needs it.
The real S/4HANA custom code risk sits across technical impact, business ownership, dependencies, and decision time.
SAP’s own readiness tooling reflects this distinction. SAP Readiness Check groups custom-code findings by simplification item and distinguishes between areas requiring technical code adaptation and those involving functional redesign.
Custom code assessment should therefore enter transformation planning before the development backlog is fixed.
Why Does Custom Code Affect the S/4HANA Migration Timeline?
SAP S/4HANA changes and simplifies parts of the underlying SAP application and data model. SAP states that custom ABAP code may require adaptation during system conversion because SAP objects have been simplified and, in some cases, changed incompatibly.
That technical impact is only the first layer.
Consider a custom sales-order enhancement affected by an S/4HANA simplification.
The ABAP correction may take two days. Before the developer can make the right correction, the program may need answers to several questions:
- Does Sales still require the custom rule?
- Does standard S/4HANA functionality now cover part of it?
- Which downstream systems depend on the output?
- Will the target process work differently?
- Which test scenarios must prove that the new behaviour is correct?
- Who has authority to approve the change?
The coding estimate captures one part of the work.
The S/4HANA migration timeline has to accommodate all of it.
A useful planning concept is decision latency: the time between identifying a custom-code impact and receiving the business or architecture decision required to resolve it.
This is not an SAP-defined metric. It is a practical way to identify custom-code items that can sit unresolved even when the technical analysis is complete.
What Does an S/4HANA Custom Code Check Actually Tell You?
SAP uses the ABAP Test Cockpit, or ATC, to identify custom developments affected by S/4HANA changes. The Simplification Database contains relevant simplification items connected to SAP objects and forms the basis for these migration checks.
That analysis is essential.
It tells the program where custom code references affected SAP objects and where adaptation may be required.
It does not answer whether every affected object should survive.
This is where a SAP custom code assessment needs a second layer.
For each material object, ask:
- Is it used?
- Does the underlying business requirement still exist?
- Is standard functionality now sufficient?
- What dependencies does the object have?
- What needs to be tested if it remains?
Those questions separate technical findings from actual migration scope.
An ATC finding establishes impact. Scope decisions establish whether ABAP remediation should happen at all.
Why Should Unused Code Be Addressed Before Remediation Starts?
Unused code is one of the clearest opportunities to reduce the workload before adaptation.
SAP supports production usage collection through ABAP Call Monitor, or SCMON, with aggregated usage managed through SUSG. SAP states that this data can be used to identify when ABAP programs or procedures were last used productively and to find obsolete custom code.
The Custom Code Migration application can then use usage data to define which code needs to enter migration scope. SAP also provides functionality to create deletion transports for unused ABAP source code during system conversion.
This changes the economics of remediation.
If an unused report generates 20 findings, fixing those findings creates development and testing effort without improving the target system.
The better sequence is:
Establish usage → confirm business need → determine target disposition → remediate surviving code.
There is still judgement involved. Code that runs only during year-end, audit, regulatory reporting, or exception processing can appear inactive over a short observation period.
Usage evidence should inform retirement decisions. It should not replace business validation.
Which Custom Code Dependencies Create the Most Risk?
Code rarely operates alone; A custom object can depend on standard SAP tables, other Z-objects, interfaces, user exits, background jobs, reports, forms, workflow, or external applications.
This dependency radius is often more important than the number of findings.
SAP’s current Analyze Custom Code capability includes dependency and complexity analysis alongside ATC-based code assessment.
For migration planning, that means two technically similar objects can have very different implications.
A standalone internal report may be straightforward to adapt.
A custom routine involved in pricing could affect sales orders, interfaces, billing, financial postings, regression tests, and external applications.
Counting both as “one custom object requiring remediation” hides the difference.
A useful SAP custom code assessment should therefore record dependency reach alongside technical severity.
How Should ABAP Remediation Effort Be Estimated?
Finding count is a poor effort model.
A stronger estimate separates three types of work.
Technical adaptation
What code must change because of incompatible or simplified SAP objects?
This is the core ABAP remediation effort.
Functional decision and redesign
Does the original requirement remain valid, and should it be implemented the same way in S/4HANA?
SAP Readiness Check explicitly distinguishes functional redesign from technical code adaptation in its high-level custom-code analysis.
Dependency and validation effort
Which business processes, integrations, roles, reports, and downstream systems need testing after the code changes?
This is where a seemingly small code correction can expand into a much larger migration activity.
A realistic remediation estimate needs all three.
How Should Custom Code Assessment Feed Transformation Planning?
The strongest way to manage S/4HANA custom code risk is to stop treating the assessment as a development-team deliverable.
Move the findings into the transformation plan.
For significant custom objects, the program should know:
| Planning question | Why it matters |
| Is the object actively used? | Determines whether it belongs in scope |
| Who owns the business requirement? | Establishes decision accountability |
| What is the target disposition? | Retire, replace, redesign, or adapt |
| What does it depend on? | Reveals cross-workstream impact |
| What decision is still open? | Exposes schedule risk |
| What must be tested? | Defines validation effort |
| When is the decision required? | Connects code to the migration critical path |
This creates a different view of the custom estate.
The largest risk may not be the object with the most ATC findings. It may be the object with one finding, six dependencies, no confirmed business owner, and a decision required before integration testing begins.
That is why S/4HANA custom code risk belongs in transformation governance.
When Is Custom Code Ready for the S/4HANA Program?
Custom-code readiness does not mean every finding has already been fixed.
It means the program knows what deserves to move, what can be retired, which requirements need redesign, where dependencies exist, and who owns the remaining decisions.
SAP’s own Custom Code Migration Guide describes an S/4HANA migration as an opportunity to reconsider and reorganize the custom-code estate while adopting newer extensibility approaches.
That opportunity disappears when custom code enters the program as a pre-approved technical backlog.
A stronger approach uses code analysis to improve the migration plan itself.
Reduce the scope before estimating remediation. Separate technical fixes from functional redesign. Map dependencies before setting test effort. Resolve high-impact business decisions before they begin holding the S/4HANA migration timeline.
Custom code still needs technical expertise.
The program risk comes from assuming that technical expertise is the only thing required.
