CustomCodeMigrationGetsItsAgents:WhatSAPShowedatTechEd2026

Custom code is still the long pole

Every S/4HANA programme meets the same list sooner or later: thousands of custom objects, each checked against the simplification list, many of them carrying findings that someone has to read, understand and fix.

SAP’s own guidance has said for years that a large share of custom code in an average ERP system is never used, and that retiring it is the cheapest fix there is. The rest has to be adapted, tested and moved - while the business keeps asking for changes to the same code.

With mainstream maintenance for SAP ERP ending in 2027, that list is now on the critical path for many companies. So the question at TechEd was not whether AI would show up in custom code migration. It was how far it has already got.

Further than a year ago. Here is what we saw, layer by layer.

1. The Custom Code Migration app learns to explain

The first layer is understanding. In the sessions, the Custom Code Migration app on SAP BTP explained both legacy code and ATC findings in plain language.

• Code Explain summarises a program’s business purpose and processing logic.
• ATC Explain turns a finding into a short brief: what changed in S/4HANA, why the code is affected, and how to fix it - with links to the relevant SAP Notes.
• A new AI Quick Fixes filter shows which findings already have a proposed fix.

The same capability sits in ABAP Development Tools. Findings in the ATC problems view are marked when Joule can help, and a developer can ask Joule to explain the finding or apply a proposed code change, shown as a diff before it is saved.

This removes a real bottleneck. Reading a finding about VBUK or a 40-character material number is not hard for an experienced developer. Reading three thousand of them is.

2. Fixing on ECC, before the conversion

The second layer moves work earlier. With transferable quick fixes, the analysis runs in the Custom Code Migration app, the fixes are exported, and then they are uploaded and run on the ECC system itself through the ATC transaction.

Today this covers two deterministic patterns: removed SAP standard data elements and missing ORDER BY in SELECT statements. That sounds modest. In large systems these two patterns alone account for a lot of findings, and every one fixed on ECC is one less on the conversion weekend.

The principle matters more than the scope: adapt the code on the system you run today, before the conversion starts.

3. The ABAP Custom Code Migration Agent

The third layer is where the session room filled up. SAP presented, as a labs preview, an agent that takes a whole package and migrates it.

The architecture is simple to describe. A developer works in Eclipse or VS Code with an AI orchestrator - in the demo, GitHub Copilot in agent mode. The request goes through an MCP bridge to the migration agent running on SAP Business AI Platform. The agent analyses, migrates and validates, then returns a summary, a transport and proposed changes with a confidence score.

Inside, the agent runs a loop that will look familiar to anyone who has fixed readiness findings by hand:

Two design choices stand out. Deterministic quick fixes run before any AI proposal, so the model only works on what rules cannot fix. And the agent stops before activation. Changed code is saved as an inactive version, the old code stays in comments, and the developer decides what to activate.

What the live demo produced

The demo ran on a package with nine objects - three classes and six programs - and thirty ATC findings from the S/4HANA readiness check variant. After the agent finished, the migration report showed thirty AI fixes, all saved and none activated.

The most interesting part was not the number. It was how the result was organised:

• One transport, with tasks split by confidence. Deterministic quick fixes, high, medium and low confidence each got their own task. A reviewer knows where to look first.
• A confidence score per object. One object at 88 %, seven between 57 and 75 %, one at 0 %. The low one is a clear signal for a person, not a silent failure.
• Assumptions written into the code. Where the agent had to interpret, it said so in a comment - for example that a packing status read from VBUK maps to the delivery table LIKP. Review in the ABAP compare view showed each change next to the original.

That is a mature way to hand AI output to a developer. It is honest about uncertainty, and it keeps every change inside the transport system teams already trust.

4. Readiness Check: from workshop content to workflows

The fourth layer is planning. SAP Readiness Check is getting AI summaries of simplification items for the specific customer, recommendations, and Joule for natural-language questions over the results.

The line on the slide sums up the direction well: findings that today become workshop content should tomorrow become executable workflows, with human-in-the-loop integration into agent-led migration assistants. In other words, the readiness report is meant to stop being a document and start being a work queue.

5. What comes next: the road map

The session closed with a road map, marked as a labs preview and subject to change. In short, it points in three directions:

Three items are worth noting for planning purposes:

• Side-by-side review with approve and reject controls is planned for Q4 2026. Today, review happens in the transport and compare tools.
• Clean Core Adaptation (Q4 2026 MVP) and Application Modernization (Q1 2027 MVP) extend the same agent pattern beyond the S/4HANA readiness checks.
• On the planning side, decommissioning and fit-to-standard agents aim at the cheapest fix of all: code that does not need to exist.

In a separate session, SAP placed the broader Custom Code Assistant - migration, clean core adaptation and application modernization - at general availability in Q4 2026 and Q1 2027.

What we would copy tomorrow

Whatever tools a team ends up using, several patterns from these sessions are simply good engineering:

• Rules before models. Run deterministic fixes first. Use AI for what is left.
• Confidence as a first-class field. Per object, visible in the report and in the transport.
• Assumptions next to the code. If an agent interpreted something, the reviewer should not have to guess what.
• Activation stays with a person. The agent proposes. A named human activates.
• Retire before you adapt. Usage data first, then fixing.

What is still open

The sessions made one thing clear: remediating readiness findings is becoming a standard capability. That is good news. It also moves attention to the parts that the migration loop does not cover.

Proof beyond syntax and ATC

The agent loop validates with syntax checks and an ATC rerun. That proves the code is compatible with S/4HANA. It does not prove the code still does what the business expects. A report that compiles cleanly can still read the wrong status from the wrong table.

Functional tests, a run in the real system, sign-off by the owner and a record of what was checked remain the team’s job. For thirty fixes that is manageable. For thirty thousand, it is the real project.

The years after go-live

Migration tooling is built around a project with an end date. The road map we saw is about getting to S/4HANA: planning, adapting, modernizing.

After go-live, the same custom code keeps changing. Change requests, incidents, legal changes, release upgrades. In conversations at TechEd we heard the same concern more than once: the migration itself is a known problem with known tools. Running hundreds of changes a year afterwards - each one assessed, tested, transported, approved and traceable - is the part companies do not feel set up for.

Memory of why

Assumption comments in code are a good start. But the reasons behind a change - the request, the decision, the person who approved it, the test that proved it - usually live in tickets, mails and people’s heads. When the next change touches the same object two years later, that context is what makes the difference between a quick fix and a regression.

A practical checklist for 2027

If your S/4HANA move is ahead of you, this is what we would do now:

1. Get usage data for your custom code and retire what nobody runs.
2. Run the readiness checks on ECC and apply deterministic fixes there, before the conversion.
3. Try AI-assisted remediation on one package and measure: how many fixes were right, how long review took, what the low-confidence objects had in common.
4. Define what “verified” means for a change in your landscape: which tests, which system, who signs off, where the evidence is kept.
5. Plan for the change stream after go-live, not only for the migration. Size it in changes per month, not in objects.
6. Decide where the knowledge lives: why each change was made, so the next one starts from facts.

The tools for getting to S/4HANA are arriving fast. The discipline for living on it is still up to each company.