Clean Core & Migration 6 min read

ABAP S/4HANA Readiness Assessment: Rules, Risk Scoring, and Triage

How to run a credible S/4HANA readiness assessment — the 30+ compatibility rules, ATC check variants, how to read a findings report, risk scoring methodology, and the remediate vs retire vs re-architect decision.

S
s4ready.ai Team

The phrase “readiness assessment” gets applied to everything from a two-day workshop to a months-long code analysis. In the context of ABAP and S/4HANA, it has a specific meaning: a systematic analysis of every custom repository object against the compatibility rules of the target S/4HANA release, producing a prioritised list of changes required before cutover. This post covers how to do that rigorously.

The Compatibility Rule Set

SAP’s S/4HANA simplification applies at multiple layers. The ABAP-level rules — the ones that produce ATC findings — fall into six categories.

1. Obsolete Language Constructs

ABAP has accumulated deprecated syntax across 30 years of evolution. In ABAP Cloud (required for clean-core compliance), many of these cause compile errors. In classic ABAP on S/4HANA, they cause ATC warnings today and will cause errors in future ABAP language versions.

Key examples:

  • MOVE ... TO ... — replaced by assignment operator =
  • COMPUTE lv_x = ... — obsolete
  • AT SELECTION-SCREEN dynpro events in ABAP Cloud — not supported
  • CALL TRANSACTION in background processing — restricted
  • MESSAGE ... RAISING without proper exception class hierarchy
  • Old-style FORM/PERFORM should be migrated to methods

2. Deprecated Function Modules and BAPIs

Hundreds of ECC-era function modules are marked as deprecated or replaced in S/4HANA. Common offenders:

ECC Function ModuleStatusReplacement
SD_SALESDOCUMENT_CREATEDeprecatedI_SalesDocumentTP (RAP)
ME_CREATE_PODeprecatedI_PurchaseOrderTP
BAPI_MATERIAL_SAVEDATARestrictedI_MaterialTP
FI_DOCUMENT_PARSEDeprecatedI_JournalEntryTP
HR_READ_INFOTYPERestrictedSuccessFactors API (if cloud HR)

The SAP Simplification Item Catalog (available via transaction /N/LTMC or SAP Note 2227308) is the authoritative source for deprecation status by S/4HANA release.

3. Direct Access to Pool, Cluster, and Deprecated Tables

This is the single highest-volume finding in most ECC landscapes.

  • Pool/cluster tables: BSEG, KONV, STXL, KAPOL, CDPOS — these are stored in table pools or clusters, not as transparent tables. In S/4HANA, some are implemented differently or their data is partial.
  • Deprecated financial tables: Direct reads of BSAK, BSIK, BSAD, BSID (open item management tables) are problematic because S/4HANA’s Universal Journal architecture changes where and how this data is stored.
  • Removed HR tables: Several Payroll and HR Infotype tables are removed or restructured in S/4HANA for HCM.

4. Missing FOR ALL ENTRIES Guard

" Bug: if lt_orders is initial, this reads the entire table
SELECT * FROM vbap INTO TABLE lt_items
  FOR ALL ENTRIES IN lt_orders
  WHERE vbeln = lt_orders-vbeln.

" Correct
IF lt_orders IS NOT INITIAL.
  SELECT vbeln, posnr, matnr, kwmeng
    FROM vbap INTO TABLE @DATA(lt_items)
    FOR ALL ENTRIES IN @lt_orders
    WHERE vbeln = @lt_orders-vbeln.
ENDIF.

Missing guards are not S/4HANA-specific failures — they are production bugs in ECC today. ATC flags them because migration is the opportunity to fix them. In S/4HANA on HANA, a full table scan from a missing guard on a large table is more visible due to monitoring tooling.

5. SELECT * Statements

SELECT * fetches all columns, defeating HANA’s columnar storage optimisation (which skips unneeded columns at the storage engine level), breaking when tables add or remove fields, and creating dependency on the physical column order in older-style field symbol assignments.

ATC flags all SELECT * usages. The fix is always to enumerate the required fields explicitly.

6. Native SQL and Direct Database Access

EXEC SQL, ADBC calls, and direct CALL METHOD cl_sql_statement=> usage bypass ABAP SQL’s CDS integration, authorization checks, and the HANA push-down optimisation layer. These must be replaced with ABAP SQL or CDS-based access.

ATC Check Variants for S/4HANA Readiness

The ABAP Test Cockpit (transaction ATC) ships with several pre-built check variants. For S/4HANA readiness, the relevant ones are:

  • SAP_READINESS_S4 — the primary S/4HANA readiness variant; covers deprecated objects, simplification items, language compatibility
  • ABAP_CLOUD_READINESS — stricter variant for ABAP Cloud compliance; relevant if targeting Public Cloud or a clean-core mandate
  • SAP_DEFAULT — general code quality; run alongside readiness checks

To run programmatically via ADT REST API (useful for automated scanning):

POST /sap/bc/adt/atcrun
Content-Type: application/xml

<atcrun:run xmlns:atcrun="http://www.sap.com/adt/atcrun">
  <objectSets>
    <objectSet kind="inclusive">
      <adtcore:objectReferences>
        <adtcore:objectReference adtcore:uri="/sap/bc/adt/packages/ZSD_CUSTOM"/>
      </adtcore:objectReferences>
    </objectSet>
  </objectSets>
  <checkVariant checkVariantName="SAP_READINESS_S4"/>
</atcrun:run>

Results come back as XML with priority (1=error, 2=warning, 3=info), check name, object, line number, and remediation hint.

Assessment → Triage → Decision Flow

flowchart TD
    A[Extract object list\nfrom package hierarchy] --> B[Run ATC S4HANA_READINESS\nvariant on all objects]
    B --> C[Parse findings into\nstructured report]
    C --> D{Priority 1 findings\nhigh-severity?}
    D -->|Yes| E[Mandatory remediation\nbefore cutover]
    D -->|No| F[Priority 2/3 findings\nrisk scored]
    F --> G{Is object actively used?\nUsage analysis via SCI/SUIM}
    G -->|Not used / low usage| H{Business value assessment}
    G -->|Actively used| I[Assign remediation effort\nestimate]
    H -->|No business owner| J[Retire — delete or archive]
    H -->|Has owner, low complexity| K[Remediate in migration project]
    H -->|High complexity, strategic| L[Re-architect\nRAP BO or BTP side-by-side]
    I --> M{Effort vs business value}
    M -->|High effort, low value| J
    M -->|Manageable effort| K
    M -->|Core process, complex| L
    E --> N[Remediation backlog\nprioritised sprint plan]
    K --> N
    L --> O[Architecture design\nRAP/BTP scoping]

Risk Scoring Methodology

A flat list of ATC findings is not actionable for leadership. Risk scoring converts findings into a metric that can drive resourcing decisions.

A practical scoring model:

Object Risk Score = (P1 findings × 10) + (P2 findings × 3) + (P3 findings × 1)

Normalise by object size (lines of code) to get density:

Risk Density = Object Risk Score / (lines of code / 100)

Apply business criticality multiplier:

  • SD/FI/MM core process objects: ×2.0
  • Reporting and output objects: ×1.2
  • Utility programs: ×0.8

This produces a sortable risk register where the most dangerous objects — high finding density in business-critical processes — float to the top.

At portfolio level, aggregate into a Readiness Index:

Readiness Index = 1 - (Total weighted findings / Maximum possible score)

A score above 0.85 generally indicates a landscape ready for technical migration planning. Below 0.60, the code remediation effort is likely to exceed the infrastructure migration effort and should be planned as a parallel workstream.

What to Remediate vs Retire vs Re-Architect

Remediate when an object has 1–3 isolated findings, the business process is in scope for S/4HANA, and the fix is under 3 person-days. Replace deprecated objects with released API equivalents, add FOR ALL ENTRIES guards, enumerate SELECT fields.

Retire when ATC finds dozens of issues but usage analysis (SCI, application logs, SUIM) shows zero execution in 12+ months, or no business owner can confirm the requirement. Do not migrate dead code — every object that crosses into S/4HANA must be maintained and transported for the life of that system.

Re-architect when the object implements a core business process with 50+ findings, or its ECC implementation relied on internal SAP structures that no longer exist in S/4HANA (e.g., classical GL account determination logic, obsolete pricing exits). Re-architecture during migration is expensive; carrying a heavily patched object into S/4HANA only to re-architect it 18 months later under production pressure is worse.

A findings report for technical leadership should cover: executive summary with readiness index and P1/P2/P3 counts by domain; top objects by risk score with owner and effort estimate; retire candidates (quick wins); re-architecture candidates requiring separate scoping; and a dependency map of shared deprecated objects — batch remediation of shared dependencies is far more efficient than object-by-object fixes.

Keep reading

← Back to Resources