Custom-code assessment for S/4HANA: classify, retire, remediate

Most ECC systems carry years of custom ABAP: Z-reports, enhancements, user exits, BAdI implementations, copies of standard code that quietly diverged. Before an S/4HANA move, someone has to decide what happens to all of it. The first instinct is to count it. But a number is not a plan, and this is where custom-code assessment usually goes wrong.

Why is a count of custom objects not enough?

A count tells you how big the estate is, not what to do with it. Two systems with the same number of custom objects can carry completely different amounts of work, because a large share of any estate is dead, duplicated, or replaceable by standard functionality that now ships with S/4HANA.

Headline numbers also flatter the wrong effort. "12,000 objects to remediate" turns into a budget line, when the real question is which objects are still used, which break on S/4HANA, and which ones a change to one will ripple into ten others. Without that, teams remediate code nobody runs and miss the handful of objects that block go-live. The unit of a real assessment is not the estate. It is the object.

What is the disposition framework for custom code?

Every custom object should land in one of four dispositions. This is the heart of the assessment, and it is what turns an inventory into a work plan.

• Retire. Code that is dead or unused. If no one has run it in a representative period and nothing depends on it, it does not travel to S/4HANA. Retiring it is the cheapest remediation there is.
• Replace. Code that duplicates something standard SAP now does natively. Many Z-reports and custom pricing routines exist only because the older release lacked a feature that S/4HANA ships. These get retired in favour of standard, not ported.
• Refactor. Code that is still genuinely needed but breaks Clean Core: it reads tables directly, modifies standard objects, or relies on structures that changed. This is the real remediation work, moving logic onto released interfaces and proper extension points.
• Retain. Code that is used, compatible and low-risk. It moves as-is. Recognising it quickly matters as much as flagging problems, because it keeps the team focused on the objects that actually need attention.

The discipline is that nothing sits outside these four buckets. "We'll look at it later" is how estates stay bloated across three migrations.

What data do you need to assign a disposition?

You cannot classify an object from its name. Each disposition depends on three kinds of evidence, and all three have to come together per object.

Usage. Whether the object actually runs, and how often, comes from execution data such as SCMON and workload statistics gathered over a representative window. A report that looks important but has not executed in a year is a retirement candidate, regardless of how it reads. This is the single most common thing a naive assessment skips.

Compatibility. Whether the object still works on S/4HANA comes from ATC checks run against the simplification database, the same mechanism behind SAP's Custom Code Migration app. This surfaces the direct-table reads, changed field lengths, and removed transactions that will break at compile or runtime.

Dependencies. What an object calls, and what calls it, decides how much a change costs and whether it is safe. Where-used and call relationships across the estate turn a list of isolated findings into a graph, so you can see that fixing one enhancement quietly touches a dozen downstream reports.

Usage plus compatibility plus dependencies is what lets you say, with evidence, that a specific object is "unused, retire" rather than "flagged by a check, someone go and look." The assessment stands or falls on having all three per object, not one across the estate.

How does remediation get prioritized?

Once every object has a disposition, priority falls out of two axes: does it block the migration, and how much does it cost to fix. You sequence the work so the critical path clears first.

• Blockers first. Objects that fail ATC and sit on a used, high-dependency path are what stop go-live. They get remediated before anything cosmetic.
• Free wins next. Retire and replace items remove scope at almost no cost. Clearing dead code early shrinks everything downstream, including test effort.
• Refactor by blast radius. Among the code that must be refactored, dependency weight decides order. Low-dependency fixes are quick; the deeply-connected ones need care and expert review.
• Retain and revisit. Compatible, used code moves as-is, with a note for the next cleanup rather than effort now.

Common findings in a real estate

Assessments across large ECC systems tend to surface the same pattern. A meaningful slice of custom objects has not executed in the measurement window and can be retired outright. Another slice duplicates standard S/4HANA capability and can be replaced. A hard core reads or modifies standard tables directly and needs genuine refactoring for Clean Core. And a large, reassuring remainder is simply fine. The value of the assessment is telling these apart with evidence, so effort lands where it changes the outcome.

How C16 does it

C16 inventories and classifies every custom object in the estate, read-only. It scores each one for Clean Core readiness against the simplification database, ties the classification to real usage and dependency data so the disposition is evidence-based rather than a guess, and flags dead code that can leave the estate before anyone spends a day on it.

For the objects that need work, C16 drafts the remediation as a candidate: the refactored approach, the released interface to move to, the objects a change will touch. That candidate is for an expert to review, not to apply. Nothing is changed automatically. Any accepted change is built in a development environment, approved by a person, and promoted through the customer's own change process. C16 is read-only by default across your systems, and nothing it drafts ships without your approval.

The result is not a bigger spreadsheet of counts. It is a per-object plan, with the reasoning attached, that a team can act on and defend.

For where custom-code assessment fits in the wider picture, see the S/4HANA readiness assessment guide. Related: how C16 can reverse-engineer a functional spec from ABAP when the original intent is lost, and why released SAP APIs beat direct table access when you refactor toward Clean Core.

See your custom estate classified, not just counted. C16 assesses your ABAP for S/4HANA and shows you the disposition per object, on ECC or S/4HANA. Book a walkthrough.

C16 reads SAP through standard interfaces and the permissions you grant, and is read-only by default. It queries the system on demand and does not retain your business data or use it to train models. Remediation is drafted as a candidate for a person to approve; any change is built in a development environment and promoted through your own change process. Nothing C16 drafts ships without your approval.