SAP Custom Code Assessment Before S/4HANA: Which Code Has Earned the Right to Move?
A large ECC estate can contain years of Z-programs, enhancements, exits, reports, forms, interfaces, and modifications. Some still protect real business requirement. Some duplicate capabilities now available in standard SAP. Others remain in the repository even though the process, user group, or regulatory reason behind them disappeared years ago.
A SAP custom code assessment should decide which of those objects have earned the right to move forward before the enterprise finalizes its SAP S/4HANA migration plan.
The useful question becomes: “Which code would we choose to build again for the S/4HANA operating model we are creating?”, especially during SAP ECC to S/4HANA migration planning.
That question changes the migration plan.
Why Does Custom Code Distort S/4HANA Timelines So Early?
Custom code rarely creates a single workstream. One affected object can trigger code adaptation, process validation, interface testing, regression testing, business sign-off, transport sequencing, and production support preparation.
The migration impact therefore depends on the role of the code, rather than its object count.
A rarely executed year-end program may be more critical than a frequently used internal report. A small enhancement inside pricing or ATP may create a wider test surface than dozens of standalone utilities. A technically compatible report may still deserve retirement if S/4HANA standard functionality now covers its purpose.
This is why S/4HANA custom code remediation should be scoped before detailed project estimates are treated as reliable.
SAP’s current migration guidance separates custom code work into preparatory scoping and analysis, followed by adaptation after technical conversion. SAP also recommends using usage information to reduce the code scope before adaptation begins.
Every object removed from scope can reduce more than coding effort. It can also remove tests, defects, documentation, ownership questions, and future maintenance.
What Should an ABAP Code Assessment Prove Before Code Is Kept?
Keeping code should require evidence.
A practical ABAP code assessment can apply five tests to each material custom object:
- Usage: Is there evidence that the object is still executed?
- Business purpose: Does an accountable owner confirm that the requirement still exists?
- Standard replacement: Can S/4HANA or an approved extension pattern cover the requirement without retaining the object?
- Technical survivability: Does the code depend on changed or simplified SAP objects?
- Test burden: What business processes, interfaces, controls, and data conditions must be retested if it survives?
An object that passes all five tests has a defensible reason to continue. An object that fails one test needs a decision. An object that fails several tests should not enter remediation automatically.
This creates a stronger assessment than a red, amber, green compatibility report. Compatibility describes technical impact. It does not establish business entitlement.
How Can Enterprises Identify Code That Is Truly Unused?
Unused code analysis should start with production evidence rather than repository age.
SAP supports usage collection through ABAP Call Monitor, transaction SCMON, with aggregated usage managed through transaction SUSG. SAP specifically positions this data as a way to identify obsolete custom code and reduce adaptation effort during an S/4HANA conversion.
Current SAP guidance also recommends collecting usage information over a long enough period to capture infrequent business activity, which is why choosing the right SAP service provider matters for readiness assessment and remediation planning. Its Custom Code Migration guidance recommends at least one year where possible so quarter-end and year-end functions are represented.
That matters because “not used last month” is weak evidence.
Before code is marked for retirement, teams should check for:
- Period-end and year-end execution
- Background jobs
- Emergency or exception processes
- Regulatory reports
- Low-frequency maintenance transactions
- Indirect calls from other custom objects
- Interfaces triggered by external systems
- Development or test-only tools that still have a valid purpose
Unused custom code analysis should therefore produce candidates for retirement rather than automatic deletion decisions.
The final call needs an owner. If no owner can be found, that is useful evidence too. Orphaned code carries migration cost without clear business accountability.
How Do You Separate Obsolete Code from Incompatible Code?
Unused, obsolete, and incompatible describe different problems.
Unused code has no observed execution within the evidence window. Obsolete code may still run, but the business requirement behind it has expired or should disappear in the target design. Incompatible code still serves a valid purpose yet depends on SAP objects or behavior changed by S/4HANA.
Combining these categories creates poor estimates.
Obsolete code should be challenged by process owners. Incompatible code should be analyzed technically. Unused code should be investigated through usage evidence and dependency checks.
For incompatibility analysis, SAP uses the ABAP Test Cockpit to identify critical use of simplified SAP objects in customer developments. SAP’s documentation also describes use of the SAP simplification database, imported into the check system, as an input for S/4HANA custom code checks.
The SAP Readiness Check can provide an early view of simplification-related custom code impact during conversion preparation. Detailed analysis then has to connect those findings with the actual code scope and intended target release.
The target release matters because findings need to be interpreted against the S/4HANA version the programme plans to adopt.
Which Findings Actually Increase Remediation Effort?
Finding counts are easy to report and easy to misuse.
Ten ATC findings inside one low-risk report may require less effort than a single finding inside an enhancement that influences order creation across several sales channels.
Remediation effort should be estimated through consequence.
For each object, assess:
- Severity and type of S/4HANA impact
- Availability of a quick fix or straightforward code correction
- Number of dependent custom objects
- Process criticality
- Interface dependency
- Data-model dependency
- Required functional redesign
- Regression test scope
- Business validation effort
- Availability of a knowledgeable owner
SAP’s Custom Code Migration and Analyze Custom Code capabilities use ATC-based analysis and allow findings to be filtered by factors such as scope, usage data, and quick-fix availability. Current SAP documentation also shows that these applications support scoping custom code for S/4HANA migration based on collected usage.
This is where an ABAP remediation strategy should move beyond “fix all critical findings.”
Some findings indicate a code correction. Others expose a design decision that belongs with finance, sales, manufacturing, procurement, or another process owner. Those decisions should enter the migration backlog separately because their lead time may exceed the coding work.
When Should Code Be Kept?
Keep code when the business requirement remains valid, standard S/4HANA capability does not adequately cover it, the object is actively used, and the technical impact is acceptable.
“Keep” should still identify an owner and a test scope. Surviving code becomes part of the future S/4HANA estate.
This distinction matters. Keeping custom code is an architectural decision with a maintenance consequence. It should receive the same scrutiny as building a new extension.
When Should Code Be Fixed?
Fix code when the requirement remains valid but S/4HANA simplifications, syntax changes, data-model changes, or other compatibility issues require adaptation.
This is the core of S/4HANA custom code remediation, but it should apply only after the code has passed the business-value test, supported by SAP implementation services that manage remediation, testing, and validation.
A repair estimate without a business-value decision can consume development effort on functionality the target operating model no longer needs.
When Should Code Be Replaced?
Replace code when the requirement remains valid while the custom implementation no longer has a strong reason to exist.
The replacement could be standard S/4HANA functionality or an approved target-state extension approach. The decision should compare functional coverage, integration impact, control requirements, user change, and future maintenance.
Replacement deserves particular attention because technically repairable code can still be strategically weak code.
A successful ATC result should never become the sole reason to preserve an old design.
When Should Code Be Retired?
Retire code when usage evidence, business ownership, process redesign, or replacement analysis shows that it no longer belongs in the target environment.
SAP’s custom code migration tooling supports scoping based on usage data and can create deletion transports for unused ABAP source code during system conversion.
Retirement still needs control. Dependencies, audit requirements, fallback needs, and transport timing need to be understood before removal.
The strongest retirement case combines technical evidence with a business decision. “Nobody remembers this program” should trigger investigation. It should not serve as the deletion policy.
What Should a Custom Code Decision Register Contain?
A SAP custom code assessment should end with decisions that can be planned, costed, and governed.
A useful Custom Code Decision Register can contain:
| Field | Decision value |
|---|---|
|
Custom object |
Identifies the code under review |
|
Business capability |
Shows which process depends on it |
|
Usage evidence |
Confirms observed use and evidence period |
|
Business owner |
Establishes accountability |
|
S/4HANA impact |
Records relevant ATC or simplification findings |
|
Standard alternative |
Shows whether custom code is still necessary |
|
Disposition |
Keep, fix, replace, or retire |
|
Remediation effort |
Estimates technical work |
|
Test surface |
Identifies processes and integrations needing validation |
|
Dependency |
Shows upstream and downstream effects |
|
Decision deadline |
Connects the object to migration planning |
Disposition determines whether remediation effort belongs in the migration plan at all.
A team can estimate a difficult fix and still decide that the object should disappear. Without that decision layer, technical assessment tends to convert the current custom estate into the future backlog.
How Should Custom Code Cleanup Change the Migration Plan?
Custom code migration to S/4HANA affects more than the development schedule.
The disposition register should feed at least five parts of the programme plan.
First, it changes scope. Retired objects reduce adaptation and test volume. Replacements introduce process design and adoption work. Fixed objects create technical remediation tasks.
Second, it changes sequencing. Code that depends on process redesign cannot be completed before the process decision. Interfaces may depend on target data structures. Some retirement decisions may need archival or replacement capabilities in place first.
Third, it changes testing. Test scope should follow surviving business behavior rather than the historical size of the custom repository.
Fourth, it changes ownership. Every kept or replaced object should have a business owner, technical owner, and validation path.
Fifth, it changes the cost baseline. Estimates should distinguish code repair from functional redesign, replacement implementation, regression testing, and retirement controls.
This is where an ABAP remediation strategy becomes part of migration governance rather than a development cleanup exercise.
What Should Leadership Know Before Custom Code Enters the S/4HANA Roadmap?
Leadership needs to know how much custom behavior the future ERP is choosing to carry, rather than receiving another repository count.
A useful assessment should answer:
- Which custom objects still support approved business requirements?
- Which objects have no credible usage or owner?
- Which requirements can move to standard S/4HANA capability?
- Which surviving objects are affected by simplifications?
- Which remediation decisions sit on the migration critical path?
- How much testing and business validation does the surviving estate create?
This is the real purpose of a SAP custom code assessment.
The objective is to reduce the future custom estate to code the business can justify, own, test, and maintain.
An S/4HANA programme gets a valuable opportunity to challenge years of accumulated custom development before that code becomes part of the next ERP baseline. Treating every active object as migration scope wastes that opportunity.
TechPoint, A Cygnet.One company, helps enterprises connect usage evidence, SAP compatibility findings, business ownership, and target-state process decisions before remediation begins. The result is a smaller, explainable custom code portfolio and a migration plan built around code the future business has deliberately chosen to keep.