The remediation problem: why custom code stalls conversions

Every ECC-to-S/4HANA conversion has a custom code workstream, and in most programs it's the one that slips first. Contoso's numbers are typical. Its ECC production system EP1 held about 11,800 Z objects. Usage data showed that roughly 40% were never used, and 4,300 were deleted in scoping. That left 7,500 objects in scope, and Kenji's first scoped ATC run against them produced 3,900 findings, about 1,700 of them with a quick fix. This course asks what AI changes about that workload, and what it doesn't.

The SAP process in four phases

SAP's Custom Code Migration Guide for SAP S/4HANA 2025 splits the work into preparation before the technical conversion and adaptation after it. The tools are mature and deterministic; AI arrives on top of them, not instead of them.

The checks and the variant

The checks compare custom code against the Simplification Database, which lists every SAP object simplified in S/4HANA and points to the SAP Note that explains each simplification item. You download it as a ZIP (SAP Note 2241080) and import it in transaction SYCM in the check system. Product-specific global check variants pick the target release. For S/4HANA 2025, the guide lists S4HANA_READINESS_2025 (material number length 40, extended amount fields enabled) and S4HANA_READINESS_2025_NO_FLE (material number length 18, extended field lengths disabled). After conversion, the local variant S4HANA_READINESS adds the check for S/4-related syntax errors. SAP recommends focusing on priority 1 and 2 findings first and points to SAP Note 3735015 for adjusted priorities.

Why remediation stalls

• Volume without triage. 3,900 findings arrive as one list. Without priorities and usage, teams fix in list order and burn time on code nobody runs.
• Knowledge gaps. Each finding points to a simplification item and a note. Reading the note, finding the right replacement and understanding legacy code written fifteen years ago is slow, and the original authors are gone.
• Fixes that compile but change behavior. Replacing a VBUK read with fields on VBAK compiles; whether the report still selects the same orders is a different question.
• Testing debt. ATC is static. SAP's guide states that ATC can't find all issues, such as dynamic code, so testing has to cover what checks can't.
• Repeated cycles. Fixes made in the sandbox and CMD are transported and applied in CMQ, Mock 1, Mock 2, the dress rehearsal and CMP. A bad fix travels through every cycle.

The clean core picture adds a second lens. Contoso classified the 7,500 objects by SAP's extensibility levels: 1,200 level A, 4,000 level B, 2,000 level C and 300 level D, the last grouped in 37 extensions. Level D code is where AI help is most tempting and most dangerous: it touches SAP internals, and a plausible fix can hide a deep dependency.

One more number from Contoso's real conversion belongs in the picture. SCMON and SUSG had collected usage in EP1 for thirteen months before the conversion; after go-live, a second usage review (SUSG in CMP) found about 960 of the 7,500 objects in scope still never called. Some of those were year-end or audit programs that simply hadn't run yet; others were dead. The lesson for remediation is uncomfortable: a large share of the effort goes into code that might never run, so cheap, deterministic fixes and good scoping matter as much as any AI. Spending agent runs and senior review time on objects with no recorded usage is the most common way to waste both.