Remediate Custom Code for S/4HANA with AI Explanations

Tier: Core · Workflow area: ERP Development & Testing · ~40 minutes

Custom-code remediation is the perfect AI workload because it is high-volume, pattern-heavy and evidence-rich: the Custom Code Migration app tells you exactly which objects break, ATC names the simplification item, and the fixes cluster into a dozen recurring shapes — MATNR field-length extension, KONV replaced by PRCD_ELEMENTS, VBFA navigation changes, deprecated function modules with released successors. What AI compresses is the understanding step, which is where remediation projects actually burn their hours.

When to use

• A brownfield S/4HANA conversion with a four-digit finding counttriage and explanation at scale is precisely where per-finding AI assistance compounds into weeks saved.
• Findings your team reads three times and still argues aboutsimplification-item notes are dense; an AI explanation grounded in the note text plus your actual code usually settles what's really affected.
• Post-conversion cleanup wavesthe findings deferred at go-live come due; the same loop clears them with less ceremony.

When NOT to use

• Bulk auto-applying fixes without per-object verificationa wrong remediation compiles fine and corrupts pricing data quietly. Volume is an argument for a verified pipeline, never for skipping verification.
• Objects that should die, not be fixedusage data routinely shows 30–60% of custom code unused. Remediating dead code is polishing furniture in a house you're demolishing; decommission first.
• Modification adjustments in SPDD/SPAU without deep reviewchanges inside SAP-object adjustments have system-wide blast radius; AI can explain, but drafting belongs to your most senior hands.

The recipe

1. 1.

   Get the finding inventory with usage data. Run the Custom Code Migration app (or ATC with the S/4HANA readiness variant against your custom namespace) and export findings to a spreadsheet: object, check ID, simplification-item note number, line. Join in usage statistics (SUSG/SCMON aggregates). Sort into: unused (candidate for deletion), used + quick-fixable, used + judgment-needed. AI works the third pile; ADT quick fixes clear much of the second.

2. 2.

   Explain each judgment-needed finding with full grounding. The prompt carries three ingredients — finding, note context, and your actual code:

   Copy

   S/4HANA readiness finding, ATC check: S4HANA_READINESS_2023.
   Simplification item: SI2: Data model change in pricing —
   KONV replaced by PRCD_ELEMENTS (Note 2220005 summary pasted below).
   
   Our code (ZSD_PRICING_REPORT, lines 118-142) pasted below reads
   KONV directly with SELECT ... WHERE KNUMV = ...
   
   Explain:
   1. Exactly why this breaks or degrades in S/4HANA.
   2. The remediation options (compatibility view vs. redesign to
      released API) with the trade-off in one paragraph each.
   3. Which option you recommend given this code path runs in a
      month-end batch job over ~2M documents, and why.
   

   The recommendation-with-context question is what separates this from reading the note yourself: performance-sensitive batch paths often flip the answer from "compatibility view is fine" to "redesign."

3. 3.

   Draft the remediation diff, constrained to released objects.

   Copy

   Write the remediated version of the pasted routine for S/4HANA
   on-premise 2023. Constraints: use PRCD_ELEMENTS (or the released
   API you recommended), keep the routine's interface unchanged,
   preserve existing behavior for the KAPPL/KSCHL filtering exactly,
   and add an inline comment on each changed line citing the
   simplification item. Output as before/after blocks.
   

   Read the diff like a hostile reviewer. The classic AI mistakes here: quietly changing selection scope (KONV vs PRCD_ELEMENTS key differences), dropping a FOR ALL ENTRIES guard against an empty table, and inventing field names that existed in ECC. Every changed line must trace to the simplification item or be rejected.

4. 4.

   Prove behavior equivalence, not just syntax. For each remediated object: syntax check and ATC re-run (finding gone, no new ones), then an equivalence check appropriate to the object — for reports, run old and new against the same test data in a converted sandbox and diff the output; for routines with pb-45-style unit tests, green suite on both sides. An output diff of zero rows on representative data is the sentence your sign-off stands on.

5. 5.

   Batch by pattern, and industrialize the checklist. Findings repeat: once the KONV pattern is verified twice by hand, process the remaining objects of that pattern in batches — same prompt scaffold, same diff review, same equivalence check, logged per object in the inventory sheet. The sheet becomes the audit trail: finding → explanation → diff → evidence → reviewer → transport.

6. 6.

   Exit through the transport, with paperwork. Each remediation transport bundles: the changed objects, the updated inventory rows, and the equivalence evidence reference. Human reviewer releases; nothing ships on the model's confidence. The deferred and exempted findings get formal ATC exemptions with justifications — also draftable by AI, also human-approved.

Make it yours

• SAP with Joule ABAP AIJoule's explain-and-fix sits directly in ADT against ATC findings, which shortens steps 2–3; keep steps 4–6 unchanged, because in-IDE convenience is exactly what tempts teams to skip equivalence proof.
• Oracle E-Business Suite → Fusionthe analogue is CEMLI remediation: inventory customizations, AI-explain each against Fusion's extension model, redesign to sanctioned extensibility (OTBI, App Composer, PaaS) rather than porting; the used/unused triage cuts even deeper here.
• Dynamics AX → D365 F&Ooverlayering must become extensions; the Customization Analysis Report is your finding inventory and the explain-diff-verify loop applies per class with SysTest as the equivalence gate.

Quality check

• Usage data was consulted before any remediation effortevery hour spent fixing unused code is the project's most preventable waste.
• Each diff was traced line-by-line to its simplification itemuntraceable changes are scope creep wearing a migration badge.
• Equivalence evidence exists per object, not per patternthe third KONV object can still hide the one bespoke twist; patterns speed the work, they do not inherit the proof.
• New ATC findings introduced by fixes were checkedremediation that trades one finding for two is net negative; always re-run the full variant, not the single check.
• The inventory sheet is complete enough to hand to an auditorfinding, decision, evidence, reviewer, transport. That row structure is the project's real deliverable.