Inside the S/4HANA Custom Code Migration Agent: A Technical Walkthrough (Series 3, Part 3)

[DEEPA_DORAIRAJ]

Inside the S/4HANA Custom Code Migration Agent: A Technical Walkthrough

By Deepa Dorairaj | SAP AI Solution Architect | Series 3, Part 3 of 6 | Published September 2026

TL;DR: This part covers the real prerequisites, the exact workflow, and where SAP itself says the agent should not be trusted to decide alone.

Series Context

Part 2 was the manual path. This part is what SAP automated — same underlying ATC mechanics, now orchestrated by an agent that knows when to stop and ask.

---

SECTION 1 — PREREQUISITES: WHAT YOU ACTUALLY NEED INSTALLED

This is a real setup checklist, not a "just enable AI Core" wave-of-the-hand:

• SAP S/4HANA target system running at least version 2023
• SAP Joule for Developers, ABAP AI capabilities enabled
• The latest build of ABAP Development Tools for Eclipse, with MCP server capability turned on (this is the ADT MCP server — see Part 1's mention of it as the foundation for the MCP Gateway pattern showing up across SAP's tooling this year)
• A GitHub Copilot Pro license or an Amazon Q Developer Pro license — worth noting explicitly: this agent doesn't run inside a standalone SAP chat interface. It runs through your existing coding assistant, with ADT as the tool provider via MCP.
• One of the supported Eclipse Marketplace plugins installed and enabled for your chosen assistant
• SAP Note 3751537 if you're using GitHub Copilot — adds the custom instructions the agent needs
• SAP Note 3751829 if you're using Amazon Q Developer — adds the equivalent rules
• SAP Note 3757335, optionally, if you want the agentic workflow to also cover object sets created in the Object Set Playground, not just packages

SECTION 2 — THE ACTUAL WORKFLOW, STEP BY STEP

1. The agent begins by executing comprehensive ATC checks using the SAP S/4HANA readiness check variant, run against your specified package and all its sub-components. This is the same check variant category covered in Part 2 — the agent isn't inventing new checks, it's orchestrating the ones already built into ATC.
2. Confirmation gate, before anything runs: before the agent triggers the ADT MCP tool for ATC analysis, it explicitly asks you to confirm. This is the human-in-the-loop design showing up at the very first step, not just at the end — the agent doesn't get to unilaterally decide to start scanning your codebase.
3. Results come back structured: a summary of errors, warnings, and informational findings from the ATC run, plus — critically — a breakdown of how many findings have an available deterministic quick fix versus how many will need an AI-generated fix proposal. This split matters: it tells you upfront what proportion of the work is mechanical versus judgment-requiring, before any code changes anything.
4. You provide a transport request — and it has to be a single, dedicated TR covering all sub-packages and (sub-)objects in the migration package. This isn't a style preference; it's a hard requirement for the agent's continuous processing flow to work correctly. Get this wrong and the agentic loop breaks partway through.
5. Deterministic quick fixes apply automatically. These are the mechanical, unambiguous corrections — the equivalent of what a senior developer would fix without a second thought.
6. AI-powered remediation kicks in for the more complex findings — and this is where the design principle SAP built in matters most: the agent is required to explain the existing code before proposing a change to it. Not "here's a diff, take it or leave it" — an explanation of what the code currently does, then a proposed fix. Uncontrolled mass modification of production custom code was explicitly treated as the wrong design, not an oversight.
7. You review and approve every AI-generated fix. This step doesn't disappear even as the tooling matures — it's structural, not a temporary limitation.

SECTION 3 — WHERE SAP SAYS NOT TO TRUST THE AGENT ALONE

Three categories are explicitly flagged as needing a human, not an automated pass:

• Objects touching deprecated SAP infrastructure — older BAPIs, outdated ALE/IDoc structures — where the actual replacement requires an architectural decision, not just a code edit. The agent can identify the problem; it shouldn't be trusted to pick the new architecture.
• Objects encoding integration logic with external systems, where S/4HANA's changed interface behavior can't be fully assessed through ATC alone. ATC checks what's inside your system. It doesn't know what your external partner's system expects on the other side of that interface.
• AI-generated fix proposals themselves, categorically — regardless of the efficiency numbers. SAP's own early-evaluation figure is a 40% efficiency gain in custom code transformation work. That number comes with an honest caveat worth repeating: it's SAP's internal evaluation, and no independent third-party benchmark exists yet. Treat it as a plausible early signal, not a settled fact.

SECTION 4 — WHY THIS MATTERS BEYOND THE MIGRATION ITSELF

The architecture here is worth studying independent of the specific use case. The agent is a genuine orchestrator, not a single LLM call: it sequences ATC execution, structures the findings, applies deterministic logic where deterministic logic is sufficient, and only reaches for generative fix proposals where the problem actually requires judgment — with an explicit checkpoint before every consequential action. That's the same pattern worth applying to any agentic tooling you build yourselves, ABAP or otherwise: separate what's genuinely mechanical from what needs reasoning, and don't let the agent skip the confirmation step just because it's capable of moving faster without it.

SECTION 5 — WHAT'S NEXT

Part 4 addresses the failure mode that automation like this doesn't fully solve on its own: what happens to the objects the agent correctly identifies as needing human judgment, and how to govern side-by-side extensibility so that judgment work doesn't just relocate the same debt into BTP.