Skip to content
IT-SBO
SAP how-to

Check your custom code before you plan an S/4HANA conversion

Most conversion overruns are decided months before the project starts, in code nobody has read since 2014. Here is how to find out what you are carrying.

IT-SBO SAP practice
S/4HANA delivery team
3 min read

Every ECC system carries custom code that made sense once. Reports written for a month-end that no longer exists. Enhancements to close a gap that SAP closed in a later release. User exits nobody can explain.

None of that matters until you convert to S/4HANA. Then it matters enormously, because the data model underneath it has changed.

What actually breaks

Three changes cause most of the remediation work:

  • BSEG and BKPF no longer hold what you think. The Universal Journal, ACDOCA, replaces the old aggregate and index tables. Code that reads BSIS, BSAS, BSID or BSAD directly will compile and return nothing.
  • MARD, MSEG and MKPF are compatibility views, not tables. Reads work. Writes and native SQL do not.
  • Customer and vendor masters merged into Business Partner. Code touching KNA1 or LFA1 for updates has to be redirected.

WARNING

The dangerous failure is not the code that stops compiling. It is the code that still runs and quietly returns an incomplete result — a reconciliation report that now excludes a document type nobody notices for two months.

Getting the real number

Run the standard readiness tooling before anyone estimates the project:

" ATC with the S/4HANA readiness variant, scoped to your own packages
" Transaction: ATC → Run Series → Object Set: your Z* packages
" Check variant: S4HANA_READINESS_REMOTE

Then the custom code analysis:

Tool What it tells you Where
ATC (S/4HANA variant) Every syntax and semantic finding, by object On-premise or via SAP BTP
Custom Code Migration app Which findings sit in code that is actually executed SAP Fiori
UPL / SCMON Usage over a full business cycle Transaction SCMON

The third one changes the economics. Run usage logging for a complete business cycle — twelve months, so year-end is included — and most clients find 40% to 60% of custom objects were never executed at all.

TIP

Decommissioning unused code is cheaper than remediating it, and far cheaper than testing it. Do the usage analysis first, then estimate.

What to do with the findings

Sort every finding into one of three buckets, and do it with a business owner in the room, not only developers:

  1. Delete. Not executed in twelve months and no owner will defend it.
  2. Replace with standard. SAP now covers it. This is where clean-core discipline is won or lost.
  3. Remediate. Genuinely needed and genuinely custom — fix it, and move it out of the core so the next upgrade is not another project.

The number that matters

A readiness assessment costs a few weeks. A conversion estimated without one is guesswork, and the gap shows up as change requests halfway through the build, when you have the least room to say no.

If you want a second opinion on findings you already have, send them over — we will read them and tell you honestly what we see.

  • S/4HANA
  • ABAP
  • Conversion
  • Readiness

Have a project that looks like this?

Tell us what you are trying to fix. The first conversation costs nothing.