Custom Code Migration for S/4HANA

Custom code migration for S/4HANA is the project workstream that takes every Z and Y object in a customer system - reports, includes, function modules, BAdI implementations, user exits, enhancements - and works out which ones will break, behave differently, or become pointless on the target release, then fixes them before or during the technical conversion. The structural fact that causes most confusion: this is not one activity, it is three overlapping ones running on different clocks. There is remediation forced by simplification items (data model changes such as the extended material number, or table restructuring in inventory management and CO-PA), there is HANA-specific remediation (removed pool and cluster tables, native SQL against structures that no longer exist), and there is general ABAP hygiene that ATC flags but that the platform does not force anyone to fix before go-live. Projects that lump all three into a single backlog and a single deadline consistently blow their estimates.

This work is mandatory ahead of any technical conversion from ECC to S/4HANA, and it recurs on every upgrade afterward because SAP continues to retire APIs and tighten simplification rules. It is the right lens whenever the question is 'will this custom object still run correctly after the release change'. It is the wrong lens for deciding whether a piece of custom logic should exist at all - that is an extensibility and clean core question, not a migration question, and answering it purely from ATC output produces a fix-everything backlog that ignores business value. It is also the wrong tool for functional testing: ATC and the migration workstream tell you code will compile and run, not that the business result is still correct after a simplification item changes underlying logic. That verification belongs to functional testing, not to the migration team.

Below the migration workstream sits the ATC run itself, driven off the SAP Readiness Check and the simplification item database, plus usage tracking data that shows which objects are actually executed in production rather than merely present in the system. Above it sits the conversion project plan and cutover schedule, which decide when each finding must be closed - before the technical conversion, during the SPDD/SPAU adjustment phase, or parked for post-go-live cleanup. It replaces the older, ad hoc practice of relying on a handful of Note-driven fixes and manual code review at upgrade time. It does not replace SPDD and SPAU, which handle dictionary and program adjustments for objects modified against SAP standard; custom code migration runs alongside that step and often surfaces conflicts between a custom enhancement and a simplified standard object that SPAU alone will not catch.

A logistics customer has a custom report that reads material master data directly, builds an internal table keyed on the material number field, and passes that key into several other custom function modules and an interface file layout with a fixed-width output column. On conversion, MATNR's length changes because the extended material number simplification item is active in the target release. ATC flags every place where the field length is hardcoded or where the value is truncated for display or file output. The fix touches three layers: the internal table declarations need to reference the data element rather than a literal length, the interface file format needs a decision on whether the receiving system can accept a longer field or needs a mapping table, and the function modules need regression testing with a real 40-character material number, not just the padded 18-character values used in the original test data. None of this shows up by running the report once in a sandbox with legacy master data - it only surfaces once a genuinely long material number is created and pushed through the full chain.

The real decision is not whether to fix a finding, it is what to do with it, and that decision belongs to an architect working with usage data, not to whoever is fastest through the ATC worklist.

Most of the damage in these projects comes from treating the ATC report as the finish line rather than the starting point.

In ECC, custom code accumulated with little pressure to keep it aligned with standard, because the underlying data model was stable for years at a time. S/4HANA removes that stability, and clean core guidance treats every conversion as an opportunity to reduce the custom footprint rather than carry it forward unchanged. Direct table access, use of removed structures, and reliance on now-obsolete BAdIs are discouraged going forward, with the expectation that remediated logic moves toward released APIs and supported extension points where one exists. Carrying the same modification-heavy code across a conversion without addressing this is technically possible but stores up the identical remediation cost for the next upgrade cycle.

Development executes the remediation. Architecture decides scope, prioritization, and whether a finding is a fix, a rewrite, or a retirement, using usage data as evidence rather than ATC severity alone. Functional owners validate that the business result is still correct after a simplification-driven change. The handover to functional testing should include which objects changed and why, not just a closed ATC worklist.

Read the ATC page for how the checks themselves are configured and run inside a conversion project. Read the clean core page before deciding whether a finding should be fixed in place or replaced with a released API or side-by-side extension. The ABAP SQL performance page is worth reading before closing any performance-category finding, since a fix that passes ATC can still be wrong at HANA volume.