What is SAP ATC (ABAP Test Cockpit), and how does it decide S/4HANA readiness?
ATC tells you what will break on conversion. It was never built to tell you what should survive it.
The short answer
SAP ATC — the ABAP Test Cockpit — is SAP's built-in static-analysis engine for custom code, and when you run it with the S/4HANA readiness check variant it scans every custom object against the specific language and data-model changes S/4HANA introduces, then returns each finding as an error, warning, or information message with the exact line and rule that triggered it. It answers one narrow but essential question: will this object compile and run correctly after conversion, or does it use a table, field, or syntax pattern S/4HANA removed or restructured. ATC does not tell you whether the object should exist at all — whether anyone still executes it, or whether the business rule inside it has since become standard S/4HANA configuration. That second judgment needs usage evidence and a read of the business logic, which is why ATC findings are best treated as the technical remediation gate, not the scope decision. On a reference estate (a live ECC system we analyze end to end; a customer's numbers come from their own system) roughly 44% of custom objects were re-implementations of standard S/4HANA capability — objects ATC would have correctly flagged as needing remediation, and evidence-based fit-to-standard analysis correctly reclassified as candidates for retirement instead.
What ATC actually checks
ATC is not new — SAP built it originally as a general-purpose static-analysis tool for ABAP quality, security, and performance rules, and most shops already run it as part of code review. The S/4HANA piece is a specific rule set (the S/4HANA readiness checks, delivered via SAP Note-driven content) layered on top of that same engine, applied against your custom objects.
Run against that rule set, ATC flags the concrete things that break on conversion: references to tables merged or removed in the simplified data model, obsolete function modules, direct SQL against structures that became CDS views, and syntax patterns tied to the old data dictionary. Each finding carries a priority — error (will not run), warning (behavior may change), or information (worth reviewing) — and points at the exact line, which is what makes it usable by a developer rather than just a count on a slide.
The home-inspection problem, again
ATC's blind spot is the same one every purely technical scan has: it tells you an object is affected, not whether the object deserves to exist. A credit-check enhancement sitting in a user exit will trigger ATC findings about deprecated table references. Remediate those findings and you have a working, S/4HANA-compatible copy of a rule that SAP Credit Management in FSCM may now implement natively as standard configuration. ATC did its job correctly — the object does need to change to run on S/4HANA — but 'needs remediation' and 'should be remediated rather than retired' are different questions, and ATC only answers the first.
The analogy is the same building inspection every fit-to-standard conversation eventually reaches: the inspector correctly flags that the wiring is out of code. Whether you rewire the room or knock down the wall is a design decision the inspection was never built to make.
What ATC needs alongside it to become a scope decision
Three additional reads turn an ATC finding into a retire-or-remediate decision, and all three are available as read-only queries against the live system:
- Usage evidence — where-used and execution data show whether the flagged object is still called in production. An ATC error on dead code is a zero-cost retirement, not a remediation task.
- The business rule inside the code — reading the source and summarizing what decision it actually makes, so the conversation is about the rule (a credit threshold, a pricing exception) rather than the ABAP syntax around it.
- Standard-capability comparison — checking whether the rule the object encodes is now covered by S/4HANA configuration natively. This is the step that converts an ATC-flagged object from a line item in the remediation backlog into a line item in the retirement list.
Sequencing ATC correctly in a migration
ATC belongs early, alongside SAP Readiness Check, because the hard technical blockers should be known before anyone commits to a conversion approach. Run it, get the object-level findings, and resist the urge to immediately staff a remediation backlog against the raw count.
The higher-leverage sequence is: run ATC to get the affected-object list, then layer usage and standard-capability evidence on top of that same list before pricing the work. In practice this usually removes a third to a half of the objects from the remediation backlog entirely — not because ATC was wrong about them needing change, but because the better answer was retirement, and ATC was never asked that question.
Where agents change the economics
The ATC scan itself has always been fast — it is a static analysis tool, not a manual review. What has historically been slow is everything ATC doesn't do: pulling usage evidence per object, reading and summarizing hundreds of enhancements, and mapping each rule against current standard capability. An agent connected read-only to the live system can run all three in the same pass it reads the ATC findings, turning a multi-week manual triage into a same-day object-by-object fit determination with the reasoning attached to each one.
One honest boundary: the functional-testing agent that would validate a remediated object end to end against its business rule is in build and design preview, not shipped. ATC and evidence-based triage tell you what to remediate and what to retire; validating that a remediated process still behaves correctly remains a human testing step today.
Frequently asked
Is ATC the same thing as SAP Readiness Check?
No — Readiness Check is a broader, self-service program that bundles simplification-item analysis, sizing, add-on compatibility, and a custom-code summary into one dashboard. ATC is the underlying static-analysis engine that produces the custom-code findings inside that dashboard, and it can also be run directly and more granularly against your own object list outside of Readiness Check.
Can ATC tell us which custom objects are safe to delete?
Not by itself. ATC identifies objects affected by S/4HANA's language and data-model changes, which is a compatibility finding, not a usage or business-value judgment. Pair its findings with where-used execution data and a read of the business rule the object encodes to decide which flagged objects are safe to retire instead of remediate.
Do we need to fix every error-priority ATC finding before converting?
Error-priority findings on objects you keep must be resolved — they represent code that will not run correctly after conversion. But an error-priority finding on an object nobody executes is not a remediation task at all; it is a candidate for retirement, which removes it from the backlog rather than adding work to it. Checking usage before pricing the fix is what keeps the remediation estimate honest.
See your own Clean Core Score.
Run the free S/4 readiness scan in under a minute — no system access required.
Keep reading