Classifying Custom Code for Clean Core

Explanation

A Clean Core assessment starts by classifying existing custom code. Not every Z program needs migration. Some code is unused and should be retired. Some code is still needed but must be remediated because it uses obsolete syntax, unreleased objects or old data model assumptions. Some code can be replaced by standard S/4HANA functionality. Some logic can be moved into released BAdIs or APIs. Some loosely coupled scenarios can move side-by-side to BTP. This classification avoids wasting time fixing unused code and helps the project focus on business-critical custom logic.

Code example

* Custom code classification model:* KEEP       -> Still valid and upgrade-safe.* REMEDIATE  -> Still needed but has ATC findings or obsolete usage.* RETIRE     -> Not used and not required anymore.* REPLACE    -> Standard S/4HANA functionality now covers it.* REDESIGN   -> High-risk custom logic needs new architecture.* SIDE-BY-SIDE -> Better outside core on BTP/integration layer. * Example decision record:* Object: ZSD_ORDER_BLOCK_EXIT* Usage: High* Risk: Uses implicit enhancement and direct table read* Decision: Remediate into released BAdI + service class* Owner: SD technical team

Real project scenario

During S/4HANA conversion, a company found 1200 custom objects. Usage analysis showed 35% unused, 40% needed minor remediation, 15% replaced by standard and 10% required redesign.

Common mistakes

- Trying to fix every Z object without usage analysis. - Ignoring unused code. - Not involving functional team in replace/retire decisions. - Treating all ATC findings with same priority.

Best practices

- Use usage data where available. - Prioritize business-critical code. - Retire unused custom objects. - Replace custom code with standard where possible. - Track decisions clearly.

Interview angle

A good answer should explain that Clean Core migration is not only technical remediation; it includes usage, business value and risk classification.