Why custom ABAP breaks on S/4HANA and how to prepare

Custom ABAP breaks on S/4HANA because the simplified data model changes tables and structures the code relied on. Inventory, measure usage, and remediate what is used.

Custom ABAP code breaks on S/4HANA because the simplified data model changes tables and structures the code relied on. Preparing means inventorying custom objects, measuring usage, and remediating only what is used, in line with clean core.

Why it breaks

S/4HANA simplifies the data model, so tables and field structures change. Custom code written against the old structures fails or behaves unexpectedly. The more custom code you accumulated over the ECC years, the bigger the exposure, and most estates carry far more than anyone has counted.

The four quiet killers of an S/4HANA migration

None of these show up in a sandbox demo. They surface at conversion, reconciliation, or the first close.

• Duplicate master data. Breaks reconciliation and migrates as separate records unless stopped.
• Dark data. Unused historical records that inflate volume, cost, and conversion time for no value.
• Custom code that breaks. ABAP written against the old tables fails on the simplified data model.
• Reporting that goes dark. BW models and downstream dashboards snap when the data structure changes.

Source: Thinklytics SAP data readiness practice, 2026.

How to prepare

Inventory every custom object and measure what is actually used. A large share is usually dead and should be retired, not remediated. For what remains, assess breakage risk against the new model and plan the rework, ideally toward a clean-core approach that keeps the core standard and extensions separate via BTP.

Preparing custom ABAP for S/4HANA

Most estates carry a large share of dead code. Measure before you pay to remediate.

• Inventory every custom object. You cannot remediate what you have not counted. Start with the full custom-code catalog.
• Measure actual usage. A large share is usually dead. Retire it instead of paying to fix code nobody runs.
• Remediate what is used. Assess breakage against the simplified data model and rework only the live objects.
• Target a clean core. Keep the core standard and extensions separate via BTP, so the system stays upgradable.

Source: Thinklytics SAP S/4HANA practice, 2026.

Clean core matters

A clean core keeps your S/4HANA system upgradable and lower-maintenance for the long run. Remediating blindly recreates the mess. Remediating with usage data and a clean-core target gives you a leaner, more durable system. SAP's Custom Code Migration App and ABAP Cloud are the tooling; the judgment about what to keep is the work. Start with a readiness assessment that inventories the estate before you scope the rework.

Frequently asked questions

Why does custom ABAP break on S/4HANA?

Because S/4HANA simplifies the data model, changing tables and field structures the old code relied on. Code written against the old structures fails or misbehaves.

How do we prepare custom code for S/4HANA?

Inventory every custom object, measure what is actually used, retire the dead code, and remediate the rest against the new model toward a clean-core approach.

How much custom code is usually dead?

Often a large share. Measuring usage before remediation avoids paying to fix code nobody runs.

What is clean core?

Keeping the S/4HANA core standard and extensions separate, so the system stays upgradable and lower-maintenance. It is the target for custom-code remediation.

Should we remediate everything?

No. Remediate only what is used, against the new model. Remediating blindly recreates the mess you are trying to leave.

Who should do ABAP remediation?

Senior developers who know the simplified data model. It is skilled work, and getting it wrong stalls the migration at cutover.