Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 2 of 5

Remote ATC

11 min

Listen to this lesson

0:00 / 8:14

Your custom code lives in ECC, but the knowledge of what changed lives in SAP S/4HANA. SAP's conversion guide says you need to check custom code against the SAP S/4HANA simplifications in a system on the target release. The ABAP Test Cockpit (ATC) solves this with remote checks: a central check system holds the checks and the simplification database and inspects code in other systems over RFC.

How remote checks work

Central check systemA system on the target release, or the Custom Code Migration app in SAP BTP ABAP environment; holds ATC, the check variants and the simplification database
RFC connectionTrusted connection from the central system to each checked system
Checked systemThe ECC system (at Contoso, ED1, the development system); remote stubs supplied by SAP Notes return the code and metadata to be checked
ResultsFindings by object, priority and simplification item, with links to SAP Notes
Remote ATC: the checks run centrally; the code stays where it is.
The Sign-Off Table · thesignofftable.com/academy/sap-s4t-301

The checked ECC system needs the remote stubs that SAP delivers through notes, so it can return code and metadata to the central system. The central system needs the current simplification database, which SAP updates over time and which you download and load (the conversion guide points to SAP Note 2241080). An out-of-date simplification database means missing findings, so refresh it before each major analysis run.

Where SAP Readiness Check fits. SAP Readiness Check for SAP S/4HANA conversions gives a high-level view of custom code impact early, which is what the business case needs. Remote ATC gives the object-level findings, with the SAP Note behind each one, that developers actually work through. Contoso used the readiness check in the assessment and remote ATC from the scoped run onward, and kept both on the same simplification database date so the numbers told one story.

One remote ATC run: the central system holds the knowledge, ED1 only answers with code and metadata through the stubs.
The Sign-Off Table · thesignofftable.com/academy/sap-s4t-301

Setting up the central check system, step by step

  1. Central system: SAP_BASIS 7.52 or higher; an SAP S/4HANA system qualifies. Implement the notes listed in SAP Note 2436688 (recommended notes for the SAP S/4HANA custom code checks in ATC).
  2. Checked system (ED1): implement the remote stub notes, such as SAP Note 2270689. The exact list depends on ED1’s SAP_BASIS level, so take it from the guide rather than from a blog.
  3. Create an RFC destination from the central system to ED1 in SM59, with a technical user that has only the authorizations the stubs need.
  4. In transaction ATC, set the system role of the central system, then create an object provider: a system group that points to ED1 through the RFC destination.
  5. Load the simplification database (SAP Note 2241080) and make sure the readiness variant for the target release exists.
  6. Schedule a run series with the readiness variant, the object provider and the in-scope packages. Read the results in ATC or in the ATC Problems view of ADT.

Check variants

ATC runs a check variant, a named set of checks. SAP delivers two kinds of readiness variant. S4HANA_READINESS_REMOTE checks custom code against every item in the simplification database. Release-specific variants such as S4HANA_READINESS_2023 or S4HANA_READINESS_2025 check only the items relevant to that target release; SAP delivers each through its own SAP Note, so the newest one may need a note before it appears. After the conversion, the conversion guide uses S4HANA_READINESS in the converted system itself. Take the exact names from the Custom Code Migration Guide for SAP S/4HANA 2025, and confirm that every check in a variant is remote-enabled before you run it remotely: a check that is not remote-enabled stops the run.

Finding typeExampleTypical fix
Data model changeCode reads sales status tables that were merged, or pricing condition data that moved to a new tableRead the new table or a released API
Field length extensionMaterial number moved into a field of the old 18-character lengthAdjust the data types; often a quick fix
Removed or replaced functionCalls to transactions or function modules that are not available any moreUse the successor, or redesign
SAP HANA relatedCode that relies on implicit sort order of SELECT resultsAdd ORDER BY or sort explicitly
PerformanceReads of old totals tables now answered by compatibility viewsAccept, or read the new structure directly

Common kinds of readiness findings. The SAP Note attached to each finding explains the change.

Run, read and track

  1. Load the latest simplification database into the central system.
  2. Restrict the run to the scope from lesson 1, so retired code does not inflate the findings.
  3. Run the readiness variant against the development system, which holds the same code as production.
  4. Group findings by simplification item and SAP Note, and by priority.
  5. Assign packages to developers and track open findings as a burn-down for the PMO.
  6. Re-run after fixes and after each refresh of the simplification database.
  1. AssessmentFirst remote runRough effort estimate; feeds the business case
  2. Before sandboxScoped runFindings on in-scope code only; work packages assigned
  3. Before conversionPre-conversion fixesFixes that work on both releases made in ECC
  4. After each converted systemLocal ATC runReadiness variant run in the converted system; remaining findings fixed
When Contoso runs the readiness checks during the program.
The Sign-Off Table · thesignofftable.com/academy/sap-s4t-301

Priorities and exemptions

Every finding carries a priority: 1 (error), 2 (warning) or 3 (information). Contoso’s rule is that priority 1 and 2 findings in scope are fixed or formally exempted before the CMQ conversion; priority 3 items, often performance hints, are scheduled. When a finding is a false positive, the developer requests an ATC exemption with a reason, and an approver (Kenji) accepts or rejects it. The exemption is recorded, so the finding stays closed on the next run instead of reappearing and inflating the burn-down.

A finding is closed only by a clean re-run or an approved exemption, never by a developer’s say-so.
The Sign-Off Table · thesignofftable.com/academy/sap-s4t-301

Some fixes can be made in ECC before the conversion, because they work on both releases: an explicit sort, a corrected data type. Others only make sense in the converted system, where the new tables exist. Splitting findings into before and after early helps the plan: before-fixes reduce the work on the critical path after the sandbox conversion.

Key points
  • Remote ATC checks ECC code from a central system on the target release or from the BTP-based app.
  • The checked system needs SAP's remote stubs; the central system needs a current simplification database.
  • Use the SAP-delivered readiness check variant named in the guide for your target release.
  • Restrict runs to scope, group by SAP Note, track a burn-down, and split before and after fixes.
  • Fix or formally exempt priority 1 and 2 findings; dynamic code needs targeted tests because ATC cannot see it.

Check your understanding · not graded

Lesson check

  1. 1. Why are S/4HANA readiness checks run from a central system?

  2. 2. What happens if the simplification database is out of date?

  3. 3. Which check variant does the conversion guide name for a local ATC run in the converted system?

  4. 4. What is the best way to estimate effort from 3,900 findings?

  5. 5. A readiness finding turns out to be a false positive. What should the developer do?