Custom Code Adaptation and ATC Readiness Check

In ECC, custom code had almost unrestricted access to the data dictionary. Developers wrote direct SELECTs against transparent tables such as MSEG, VBAP, KNA1 or LFA1, called internal function modules that were never released for external use, and built ALV reports and interfaces on top of table structures that had not changed meaningfully in a decade. The Code Inspector (SCI) existed and some shops ran it, but it was rarely mandatory, and its checks were about performance and syntax hygiene rather than forward compatibility. Programs accumulated over fifteen or twenty years of enhancements, upgrades and consultant turnover, with no reliable record of which reports were still used by the business and which were dead weight kept alive by fear of deleting something. Field lengths for material number, document number and similar keys were fixed and everyone coded against those fixed lengths, including in interfaces to non-SAP systems. Nobody needed to think about any of this changing, because in ECC it never did.

S/4HANA restructures or removes a large number of the tables, function modules and data elements that ECC custom code relied on. Some tables became compatibility views that mimic the old structure but read from a redesigned base table (for example the material and business partner areas), some function modules were declared obsolete in favour of new BAPIs, and key fields such as material number were extended in length, breaking any custom internal table, database table or interface field defined to the old fixed length. ATC, run with the S/4HANA readiness check variant, scans every custom object against the simplification database and reports a finding for each hit: obsolete object used, direct access to a table that is now a compatibility view, field length mismatch, removed data element, and so on. Findings are categorised by severity, from information through warning to error, and the check can be run centrally against a remote system so an ECC landscape can be assessed before any conversion project formally starts. The check is code-static, not runtime, so it finds what could break, not what will definitely break in every execution path.

The blast radius is wider than most projects expect going in, because custom code touches every module and every interface simultaneously.

Custom code remediation is not a parallel workstream that can slip against a fixed conversion date; the error-level findings are a technical gate the conversion cannot pass without.

Technical: ABAP developers own the actual code fixes and re-testing. Functional: process owners must confirm whether a flagged program, transaction or interface is still needed, since deleting the wrong 'unused' object is a functional decision with functional consequences. Basis sets up the central check system and remote scans. No single owner can clear the gate alone.

The check gives a static, code-level view; it does not guarantee runtime correctness, and several classes of failure only appear once real data and real volume hit the system.