Automated ABAP Custom Code Remediation: How It Works
Manual ABAP remediation takes weeks. This guide explains how automated remediation works, what it can and cannot do, and how the verify-before-write model prevents hallucinated API replacements.
Custom code remediation is consistently cited as the #1 cost driver in S/4HANA migrations. Here is how automation changes the equation — and what makes the difference between useful output and hallucinated code.
What remediation involves
ABAP code written for ECC typically hits several categories of S/4HANA incompatibility:
- SQL anti-patterns — SELECT *, FOR ALL ENTRIES without initial check, JOINs on pool/cluster tables
- Deprecated table access — direct reads on MARA, BSEG, VBAK instead of released CDS views
- Internal API calls — function modules without C1 release status
- Obsolete ABAP syntax — statements removed in ABAP 7.5+
- Core modifications — Y-copies, enhancement categories not supported in ABAP Cloud
For each finding, there is a specific remediation: replace the deprecated table with the released CDS view, guard the FOR ALL ENTRIES loop, rewrite the FM call to the released BAPI or OData equivalent.
The hallucination problem
General-purpose AI code generation has a well-known failure mode in SAP: it invents object names. An LLM trained on internet data might suggest I_MaterialDocument when the correct view is I_GoodsMovement. It might suggest a BAPI with a plausible name that does not exist in the target release.
This is not a minor inconvenience. Code that references non-existent objects will activate in development but fail in quality or production — sometimes silently.
Verify before write
s4ready.ai’s A2 agent runs a verification step before generating any replacement code:
- Extract every object reference from the source code
- Confirm each object exists in the target system — correct name, type, fields, S/4HANA release status — via the SAP MCP server
- Only then generate the remediated code, using confirmed object names
If an object cannot be verified, the agent stops and reports the gap rather than guessing. Human review required.
What gets automated
| Finding | Automated remediation |
|---|---|
SELECT * FROM MARA | Replace with SELECT field1 field2 ... FROM I_Material |
FOR ALL ENTRIES IN lt_ without initial check | Add IF lt_ IS NOT INITIAL guard |
JOIN BSEG ON ... | Rewrite to I_GLAccountLineItem CDS view |
| Deprecated FM (confirmed replacement exists) | Replace with released BAPI/OData call |
SELECT * pattern | Add explicit field list from verified table structure |
What requires human decision
Some remediations cannot be fully automated:
- Core modifications with complex business logic — the logic may need to move to a BAdI or BTP extension; the right architecture decision requires business input
- Custom exits using deprecated enhancement categories — need a new extension point design
- Cross-object dependencies — when a deprecated object is referenced across 40 programs, the remediation strategy should be batched, not object-by-object
s4ready.ai flags these and produces a remediation recommendation rather than attempting a blind rewrite.
The output
For each automatically remediated object, the A2 agent produces:
- Remediated ABAP source
- API replacement report listing every substitution made
- Human-approval prompt before any write to the SAP system
- Transport-ready output
SAP, S/4HANA, ABAP and related marks are trademarks of SAP SE.