Architect / Cross-trackIntermediate

SAP Custom Code Migration: Triage Custom Objects for Clean Core (Part 3)

Key takeaway

Classify custom code by actual usage, business criticality and dependency risk so S/4HANA modernization targets the objects that truly need retirement, remediation, replacement, redesign or side-by-side relocation.

Explanation

A clean-core program should treat custom code as a portfolio, not a flat backlog. The first step is to prove whether an object is still used. Unused programs, obsolete interfaces and dead enhancements should normally be retired rather than remediated.

For used objects, separate business value from technical risk. A frequently used report built only on released APIs may be low risk, while a small implicit enhancement reading internal SAP tables can be high risk because it depends on implementation details.

A useful classification model is KEEP, REMEDIATE, RETIRE, REPLACE, REDESIGN or SIDE-BY-SIDE. KEEP means the object is still valid and sufficiently upgrade-stable. REMEDIATE addresses specific incompatibilities or unreleased dependencies. REPLACE uses standard S/4 capability. REDESIGN applies when the requirement remains but the existing architecture is no longer suitable. SIDE-BY-SIDE is appropriate when the capability benefits from loose coupling and an independent lifecycle.

Combine ATC findings with runtime usage, owner input and business criticality. Do not make decisions from static code counts alone.

Every decision should record rationale, owner and target release so modernization remains auditable.

Make a decision record for each candidate

Capture the object and owner, observation period, business-calendar exceptions, target deployment and release, relevant ATC findings, dependency risk, proposed outcome and evidence for that outcome. Keep an explicit unknown state when the evidence is incomplete.

Usage helps define scope; it does not certify correctness or upgrade compatibility. Static findings identify technical concerns; they do not establish whether a process is still required. Combine both with business confirmation before committing modernization effort.

For retirement candidates, define a reversible decommissioning plan and monitor the affected process. For remediation candidates, define the smallest supported change and its acceptance tests. Do not claim that every retained object is ABAP Cloud compliant merely because the project accepted its risk.

References and further reading
SAP custom code migration guide: https://help.sap.com/doc/9dcbc5e47ba54a5cbb509afaa49dd5a1/202110.latest/en-US/CustomCodeMigration_EndToEnd.pdf

Continue learning
Clean Core Extension Decision Framework: https://erpclimb.com/lessons/clean-core-extension-decision-framework
Released APIs and Release Contracts in ABAP Cloud: https://erpclimb.com/lessons/rap-abap-cloud-released-apis-release-contracts

Code example

ABAP Code

"Example classification record"Object    : ZSD_ORDER_BLOCK_EXIT"Usage     : High"Business  : Critical"Risk      : Implicit enhancement + internal table dependency"Decision  : REMEDIATE"Target    : Released BAdI + service class"Owner     : SD Technical Lead

Real project scenario

Illustrative exercise: a report has no recorded executions in a 60-day sample, but Finance identifies it as a year-end control. Do not retire it from that sample alone. Extend the evidence to the relevant business cycle and confirm dependencies with the owner. Compare it with a daily interface that has an incompatible target-release dependency: the latter may need earlier remediation even if its codebase is smaller.

Common mistakes

Remediating unused code.
Ranking objects only by ATC finding count.
Treating all Z objects as equally risky.
Replacing stable code without business value.
Recording decisions without owners or rationale.

Best practices

Prove productive usage first.
Combine business value and technical risk.
Use a small explicit decision taxonomy.
Record owner and rationale.
Prioritize unsupported dependencies and high-change areas.

Interview angle

Explain how you classify custom code for S/4HANA rather than simply rewriting everything.

Practice this lesson

Quick check

1. Scenario — A conversion assessment found more than a thousand custom objects. Which response best addresses the design or operating risk in Classifying Custom Code for Clean Core?

2. Which custom code pattern is high risk for Clean Core?

3. Scenario — A company wanted a save-time compliance validation. Which response best addresses the design or operating risk in Clean Core Extension Decision Framework?

Interview questions

1. ATC shows usage of unreleased SAP objects in custom code. What would you do?

Answer it in your own words first, then compare.

2. Using this SAP project situation — A conversion assessment found more than a thousand custom objects — explain Classifying Custom Code for Clean Core. What should happen, which concepts or process steps matter, and what common mistake would you avoid?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.