ATC Checks in an S/4HANA Conversion

The ABAP Test Cockpit is a static and semi-dynamic code analysis engine that runs a configured check variant against a scope of custom objects and reports findings by priority. In a conversion project it is pointed at a check variant that SAP ships specifically for S/4HANA readiness, which layers simplification-item checks, obsolete object usage, and syntax that no longer compiles on top of the generic code quality checks the tool always runs. The one structural fact that causes most confusion: ATC does not know what your code actually does at runtime, only what it references statically. A finding means the object touched something that changed or disappeared in the target release, not that the code will fail in production. Two custom programs referencing the same deprecated table can carry the same finding and have wildly different real-world risk, one dead since 2014, one running in a nightly batch job that posts financial documents.

Run the conversion-specific ATC check variant as soon as the custom code scope is fixed, ideally well before the technical conversion window, so remediation happens against a stable baseline rather than in the middle of a cutover weekend. It is the right tool for finding syntax breaks, removed data elements, and simplification-item collisions across the entire Z and Y namespace at once, something no amount of manual code review reaches reliably. It is the wrong tool for judging whether code should exist at all — that is a usage and business-relevance question, answered by usage statistics and functional owners, not by a static scanner. It is also the wrong tool to run once and forget; code keeps changing during a multi-month project, and a check run six months old tells you nothing about the current state of the codebase.

Above ATC sits the overall custom code migration process for the conversion project: scoping which objects are in play, deciding remediation priority, and tracking sign-off. ATC itself sits above the raw compiler and syntax check, extending them with rule sets that understand S/4HANA-specific deprecations that a plain syntax check would miss entirely. Below it, results depend on the check variant definition and on the object list fed in, usually derived from a where-used or usage analysis so that dead code does not inflate the worklist. It supersedes ad hoc manual review of custom code against a list of simplification items, and it complements, rather than replaces, functional regression testing — a program can pass every ATC check and still produce the wrong result once the underlying business logic has changed in the target release.

A custom finance report reads material valuation data directly from a classic MM table using a native SQL statement, then does arithmetic assuming a specific field length. Running the conversion check variant against this program produces two findings: one flags the direct table read against an object affected by a simplification item, since the underlying data model moved and the old table is now a compatibility view with different semantics; the other flags the field-length assumption as a data type change risk. The developer traces both findings to the same root cause, rewrites the read using the released access method for that data, and adjusts the arithmetic to use the new field definition. Re-running ATC on that single object clears both findings. The remediation is logged against the object in the worklist, the functional consultant re-tests the report against a converted sandbox, and the finding is closed only after that functional check passes, not merely because ATC shows green.

ATC with the conversion-specific check variant is the standard way custom code gets validated for an S/4HANA on-premise conversion, and it remains relevant afterward as part of ongoing custom code governance, since new simplification items and deprecations can appear with later releases even after go-live. For ABAP Cloud and steampunk-style extensions, the equivalent discipline shifts toward checking against the released API surface rather than against a conversion-specific variant, because the custom code in that model is already constrained to supported interfaces by construction. Using ATC as a one-time gate rather than a recurring governance check is increasingly discouraged as organizations move toward a clean core posture, where custom code volume and risk are tracked continuously rather than only at conversion milestones.

The ABAP developer runs the check variant, triages findings, and fixes code. The technical architect or conversion lead defines check variant scope, exemption policy, and remediation priority across the worklist. The functional consultant confirms that a code fix has not changed business behavior. Handover to functional test includes the object list, the fix description, and confirmation that ATC shows the finding closed, not just suppressed.

Custom code migration for S/4HANA is the umbrella process this fits inside, covering scoping and usage analysis that feeds the ATC run. ABAP SQL performance rules that still matter on HANA overlaps with some of the checks the conversion variant runs, since native SQL and buffering assumptions are flagged by both. Clean core explained for ABAP developers gives the governance framing for why ATC findings should be tracked continuously rather than only at conversion time. ABAP unit testing and test doubles is the natural next read for confirming a remediation did not break behavior beyond what ATC can see.