Two years ago, “AI for custom code remediation” meant a vendor demo where a chatbot explained a MOVE statement. It is not 2024 anymore.
SAP now ships a purpose built ABAP model, an MCP server that lets agents work directly against a live ABAP system, AI assisted analysis inside the Custom Code Migration app, and agentic capabilities in Joule for Developers that reached general availability for S/4HANA Cloud Private Edition this year. SAP’s own stated target is a 40% efficiency gain on custom code transformation work. Independent integrators are reporting figures in the same neighbourhood on real conversions.
That is a genuinely large number when your inventory is 20,000 objects. It is also, importantly, not 100% — and the gap between those two figures is where the interesting engineering and all of the risk lives.
What the machine is actually good at
It helps to be specific about the work, because “refactoring ABAP” describes at least five different jobs with wildly different automation profiles.
Comprehension. This is the highest value, most under appreciated capability. Most custom code in a twenty year old ECC system has no documentation, no original author still employed, and no test coverage. Before AI, understanding a 4,000 line Z program meant a senior developer spending two days reading it. Now you get a structured explanation of intent, data flow, dependencies and side effects in minutes. SAP built this deliberately as the first step in its agent design — explain before you change — and that ordering is correct. The bottleneck in custom code programs was never typing. It was understanding.
Triage and classification. Pointing a model at a full ATC finding set and having it group, deduplicate, rank by business impact, and cluster objects into remediation patterns compresses weeks of analyst work. It is also the least dangerous application, because the output feeds a human decision rather than a transport.
Mechanical remediation. The deterministic S/4HANA simplification issues — MATNR field length extension, missing ORDER BY on SELECTs, direct access to eliminated aggregate and index tables, Business Partner replacing the old customer and vendor masters. Rule based quick fixes already handled a meaningful share of these before AI entered the picture; SAP’s own guidance puts standard ATC quick fixes at roughly 40–60% of typical simplification use cases. AI extends that reach into the cases where the fix requires reading surrounding context rather than pattern matching a syntax form.
Modernization to ABAP Cloud. Translating classic ABAP into released API, clean core compliant equivalents — swapping direct table reads for the right CDS view, replacing a deprecated function module with its released successor, restructuring toward RAP. This is where AI is genuinely impressive, because the mapping knowledge is vast, tedious, and exactly the kind of thing a model trained on the SAP corpus holds better than any individual developer does.
Test scaffolding. Generating ABAP Unit tests against legacy code that has never had any. Partial, imperfect, and still transformative, because it converts an untestable estate into a partially testable one.
Where it breaks
Every one of those capabilities has a failure mode, and they are not evenly visible.
The model optimizes for compiling, not for correct. An AI remediated object that activates cleanly, passes ATC, and produces subtly different numbers is the worst possible outcome — worse than an object that fails loudly. Legacy ABAP is full of behaviour that looks like a bug and is load bearing: a rounding order that matters, an implicit sort dependency, an intentional short dump used as flow control, a currency conversion done at the wrong step for a reason nobody wrote down. A model refactoring for cleanliness will “fix” these.
Comprehension output is confident regardless of accuracy. The explanation of a 4,000 line program is plausible prose. When it is wrong about a branch that fires twice a year at fiscal close, nothing signals the error. Developers who treat generated explanations as documentation rather than as hypotheses to verify will inherit those errors permanently.
Hallucinated APIs and near miss method signatures. These usually fail at activation, which makes them cheap. The dangerous variant is a real, released API with almost the right semantics — a method that returns a slightly different set, or handles a null case differently.
Clean core is a judgment call, not a rule. Whether a given piece of logic should be remediated in core, rebuilt as an in app extension, moved side by side to BTP, replaced with standard functionality, or deleted outright depends on business criticality, ownership, change frequency, and roadmap — none of which is in the code. Ask a model and it will answer anyway, and its default bias is to preserve and modernize rather than to delete. Left unsupervised, agentic remediation will faithfully carry your dead code into S/4HANA in beautiful clean core form.
There is no test oracle. This is the deepest problem. You cannot verify a refactor against a specification, because no specification exists. The only available oracle is the behaviour of the legacy system itself, which means parallel runs against production shaped data — and that is a human designed, human interpreted exercise.
Why a human signs off
Set aside the engineering for a moment. The sign off requirement is not primarily technical.
Accountability doesn’t distribute. If a remediated tax determination routine misapplies HST across a quarter, the CRA does not accept “the agent proposed it.” Someone in your organization attested that the change was correct. That attestation has to attach to a person who understood it.
Financial controls assume a reviewer. ICFR and SOX style control frameworks are built on segregation of duties and evidenced review of changes to financially relevant systems. An AI generated transport with no substantive human review is a control gap that your external auditor will find, and it will not matter how good the code was. “Reviewed” also has to mean reviewed — a rubber stamp approval on a 900 object batch is a documented control failure, not a satisfied one.
Some domains carry asymmetric downside. Tax determination, payroll, revenue recognition, statutory reporting, safety critical process control in utilities and mining. A 2% error rate is fine for a report layout and unacceptable for T4 generation. The review intensity has to scale with consequence, not with object count.
Provenance and licensing matter to your legal team. What was sent to the model, where it was processed, what data residency applies, and what indemnity your vendor offers on generated code are contract questions, not developer questions. In Canadian regulated environments they are also privacy questions.
And the knowledge has to land somewhere. If the AI understands your custom code and your team does not, you have replaced one dependency you couldn’t maintain with another. The review step is where organizational understanding gets rebuilt.
A workable model: tiered sign off
Reviewing everything with equal rigour is how organizations conclude that AI saved them nothing. The answer is to grade the objects before the work starts.
Tier 0 — Delete. Objects with no production execution over a full business cycle, including year end. No refactoring, no review of code, just a documented decommissioning decision by an owner. Cheapest win in the program.
Tier 1 — Mechanical, low consequence. Deterministic simplification fixes on reports, layouts, and non financial utilities. AI proposes, ATC and unit tests gate, a developer reviews the diff. Batch approval is defensible here.
Tier 2 — Business logic, standard consequence. Interfaces, custom transactions, workflow. AI proposes with its explanation attached; a developer who understands the process reviews object by object; functional testing required. No batch approval.
Tier 3 — Regulated or financially material. Tax, payroll, statutory output, anything hitting the GL. AI is used for comprehension and drafting only. Parallel run validation against legacy behaviour with production shaped data. Sign off by named functional and technical owners, evidence retained for audit.
Three governance rules make the tiers work. First, the human reviewer must be able to explain the change without the AI’s explanation — if they can’t, it isn’t reviewed. Second, every AI touched object carries provenance: which model, which prompt or agent flow, what was reviewed and by whom. Auditors will ask, and reconstructing it later is miserable. Third, measure escape rate, not acceptance rate. Track defects that reach test and production per tier. If Tier 1 stays clean, promote more objects into it. If Tier 2 leaks, tighten. The tiering should be evidence driven, and it should move.
The honest framing
AI does not remove the human from ABAP remediation. It moves the human up the stack — from writing the fix to deciding whether the fix is right, and from reading code to designing the validation that proves behaviour was preserved.
That is a real productivity gain, and against a December 2027 deadline it may be the difference between converting and buying extended maintenance. It is not a substitute for having someone in the room who understands what the code was supposed to do.
Buy the tools. Instrument the estate. Tier the inventory. Then staff the review, because the review is now the job.
The tiered model above is exactly what 2iSolutions applies in practice. AI handles the comprehension, the triage, and the drafting. A senior SAP consultant reviews and signs off at every gate before anything reaches the transport path. On August 5, Aditya, Praveen and Richard walk through this workflow live against a real SAP landscape, including the governance model and the audit trail it produces.
If your organization is carrying legacy ABAP into an S/4HANA move, this is a practical session worth attending.
Reserve your seat for the live session on August 5. https://events.teams.microsoft.com/event/cf188334-1430-4c35-b369-c06c3f013749@285ec7f4-9284-406f-a32a-c2a386222076
