What is the "BAdI not used where available" issue in S/4HANA migration?

Custom logic in non-BAdI locations when a released BAdI exists for the same extension point. BAdIs are the clean-core approved extension mechanism. Non-BAdI extensions break upgrade stability.

How much effort does it take to fix "BAdI not used where available"?

Remediation effort is rated M — Medium (days). Severity: MEDIUM.

Which tool checks for BAdI not used where available automatically?

The s4ready.ai A1 Readiness Scanner checks for BAdI not used where available (and 29 other rules) automatically across your custom ABAP codebase. Results include object-level findings with severity and effort estimates.

MEDIUM Effort: M — Medium (days) Clean Core

How to remediate: BAdI not used where available

Custom logic in non-BAdI locations when a released BAdI exists for the same extension point.

Is this issue in your codebase?

A1 scans all 30 rules across your custom ABAP — results in minutes.

Scan your codebase free →

What changes in S/4HANA

BAdIs are the clean-core approved extension mechanism. Non-BAdI extensions break upgrade stability.

Before and after: ABAP code example

Before (ECC)

* ECC: user exit or non-BAdI enhancement
* EXIT_SAPLMF05_001 filled with custom logic
FORM EXIT_SAPLMF05_001.
  " custom GR processing
  PERFORM z_custom_gr_logic USING ls_mseg.
ENDFORM.

After (S/4HANA)

* S/4HANA: implement released BAdI MB_DOCUMENT_BADI
CLASS zcl_goods_receipt_badi DEFINITION
  PUBLIC CREATE PUBLIC.
  PUBLIC SECTION.
    INTERFACES if_ex_mb_document_badi.
ENDCLASS.
CLASS zcl_goods_receipt_badi IMPLEMENTATION.
  METHOD if_ex_mb_document_badi~mb_document_update.
    " your GR logic here — clean core compliant
  ENDMETHOD.
ENDCLASS.

Effort estimate and common pitfalls

Effort estimate

M — Medium (days)

Estimate is per affected object. Total effort scales with the number of occurrences in your codebase. Use the A1 scan to get an object-level count before estimating the full project.

Common pitfalls

! Missing related objects that contain the same pattern
! Not testing edge cases after replacing the API
! Skipping regression tests for dependent programs

Related rules to check

HIGH L

Implicit enhancements on SAP standard

Implicit enhancement points inside SAP standard programs. These survive upgrades but hide dependencies.

HIGH L

ABAP Cloud restricted object access

Access to SAP internal objects without C1 release status. These are blocked in ABAP Cloud.

CRITICAL XL

MODIFY on SAP standard tables

Direct INSERT/UPDATE/MODIFY/DELETE on SAP standard tables bypasses business logic and breaks upgrade stability.

Find every instance of this issue in your codebase

The A1 scanner checks all 30 compatibility rules — including BAdI not used where available — across your custom ABAP objects and produces a prioritised remediation backlog.

Scan your codebase for this issue free →

← All remediation rules Resources →

SAP, S/4HANA and ABAP are trademarks of SAP SE. s4ready.ai is an independent solution and is not affiliated with, endorsed by, or sponsored by SAP SE.