Inside What Actually Breaks in Large-Scale S/4HANA Conversions (And How to Prevent It)

Broken Custom ABAP Code in S/4HANA

From an engineer’s perspective, one of the first headaches in a brownfield S/4HANA migration is custom ABAP code that no longer runs correctly. Unlike a simple upgrade, S/4HANA introduces a new architecture with a simplified data model and revised logic. Many classic SAP ECC tables and transactions either vanish or behave differently in S/4HANA, meaning some Z-programs that worked fine in ECC may now short-dump or produce incorrect results.

Common breakage patterns include:

• Direct SELECT/UPDATE on Obsolete Tables: S/4HANA has eliminated numerous aggregate, index and status tables that existed in ECC for performance reasons. 
• Use of Deprecated Transactions or Modules: S/4HANA marks the end of certain classic transactions and techniques. 
• Hard-Coded Assumptions (Field Lengths, Formats): S/4HANA introduces subtle data type changes that break code assumptions.

Data Model Shifts: ACDOCA and MATDOC (Goodbye, Familiar Tables)

Perhaps the most profound technical change in S/4HANA is the radically simplified data model in Finance and Logistics. Many tables have been merged or replaced by new consolidated tables, which often breaks custom SQL logic. Two of the biggest changes are:

Universal Journal (ACDOCA)

In Finance, S/4HANA consolidates dozens of traditional finance and controlling tables into the Universal Journal table ACDOCA. This single table contains what used to be separate ledgers and sub-ledgers: general ledger entries, controlling (CO) postings, asset accounting, material ledger, and more are all recorded as line items in ACDOCA. The upshot is that classic tables like BKPF/BSEG, COEP, GLT0, MLIT/CKMLCR etc., either no longer exist as physical tables or are not the primary source of truth in S/4HANA. Custom ABAP reports that perform SQL joins on BKPF and BSEG, for example, will break or return incomplete data in S/4 because the real data has moved to ACDOCA. Consider this legacy ECC query that joins BKPF and BSEG:

* ECC-era code (will not work correctly in S/4HANA):
SELECT bkpf~bukrs, bkpf~belnr, bkpf~gjahr, bkpf~bldat,
       bseg~koart, bseg~wrbtr, bseg~shkzg
  FROM bkpf INNER JOIN bseg
    ON bkpf~bukrs = bseg~bukrs AND 
       bkpf~belnr = bseg~belnr AND 
       bkpf~gjahr = bseg~gjahr
  INTO TABLE @DATA(it_fi_docs)
  WHERE bkpf~bukrs = '1000'
    AND bkpf~gjahr = '2023'
    AND bseg~koart = 'K'.

In S/4HANA, a query like the above would need to be rethought. ACDOCA now holds the line items for both GL and sub-ledger accounts, so a custom report might simply SELECT from ACDOCA. SAP provides CDS views and compatibility views to ease this transition, but the main point is that reading financial data now often means reading ACDOCA directly rather than joining BKPF/BSEG. The old index tables for open items and totals tables like GLT0 are gone HANA’s in-memory engine can aggregate on the fly, so totals are calculated in real-time rather than stored redundantly. This means custom programs that used those tables for performance need to be rewritten to aggregate from line items.

Material Documents and Inventory (MATDOC)

On the logistics side, inventory and material movement data undergo a similar consolidation. In ECC, inventory documents were split between a header table MKPF and an item table MSEG and there were many secondary tables for stock quantities and history tables for material movements. S/4HANA replaces much of this with the New Simplified Data Model for materials management a single table MATDOC that stores all material document line items. During system conversion, SAP actually migrates the historical MKPF/MSEG records into MATDOC. Many classic MM tables become either views or are no longer updated.

This means custom programs that joined MKPF and MSEG, or that tried to directly update inventory tables, will fail or return no data in S/4. To illustrate, an ECC-era report might do something like:

* ECC-era inventory query (joins material doc header & item):
SELECT mkpf~mblnr, mkpf~budat, mseg~matnr, mseg~menge, mseg~werks, mseg~lgort
  FROM mkpf INNER JOIN mseg
    ON mkpf~mblnr = mseg~mblnr AND mkpf~mjahr = mseg~mjahr
  INTO TABLE @DATA(it_matdocs)
  WHERE mkpf~budat BETWEEN '20220101' AND '20220131'
    AND mseg~matnr LIKE 'FG%'.

In S/4HANA, the above returns nothing useful because MKPF and MSEG are no longer the primary tables storing that data. All those fields now reside in MATDOC. The custom code must be adapted to query MATDOC (and related structures) instead. For example, the equivalent in S/4HANA could be a single-table select on MATDOC:

* S/4HANA: single-table query on MATDOC
SELECT mblnr, budat, matnr, menge, werks, lgort
  FROM matdoc
  INTO TABLE @DATA(it_matdocs_s4)
  WHERE budat BETWEEN '20220101' AND '20220131'
    AND matnr LIKE 'FG%'.

This simple query pulls the same fields directly from MATDOC. The key point is that engineers need to familiarize themselves with the new table structures. What used to be a join across MKPF/MSEG is now a single MATDOC read, and what used to be multiple tables for financial postings is now largely in ACDOCA. The project team should review the official Simplification List to learn which old tables are replaced by which new tables or views.

Interface and Integration Breakpoints

A large-scale S/4HANA conversion not only impacts internal code, but also disrupts interfaces between SAP and other systems. Changes in data structures and APIs can cause integrations to fail if they aren’t adjusted. Some frequent integration breakpoints are:

• IDoc Structure Changes: Many companies exchange IDocs with EDI partners or other systems. When converting to S/4HANA, you must be vigilant: IDoc message definitions can change in subtle ways even if the message type name remains the same. S/4HANA might introduce new segment versions, longer field lengths, or new optional segments in standard IDocs.
• Output Management Changes (NAST vs. BRF+): SAP S/4HANA introduced a new output management framework based on BRF+ (Business Rule Framework Plus), replacing the classic NAST-based output mechanism for many applications. In ECC, developers often used NAST user exits or custom print programs to trigger outputs. In S/4, the output determination for Sales, Purchasing, Finance, etc., is by default handled by the BRF+ rules and Adobe Forms. The traditional NAST approach is disabled by default for new documents.
• Business Partner Integration (Customer/Vendor): As mentioned earlier, S/4HANA consolidates customer and vendor master data into a unified Business Partner (BP) model. This has ripple effects on interfaces that create or update business master data. If you have external systems or custom web services that call older BAPIs or IDocs to create customers or vendors need to adjust them for BP.

Changed Semantics and Data Assumptions

Even when certain structures remain present in S/4HANA, the meaning or usage of data can shift, breaking implicit assumptions in custom code. It’s important to review these semantic differences:

• Extended Field Lengths and Types: As discussed, fields like material number have longer lengths. Another example is general ledger account numbers while the standard length of GL account hasn’t changed by default, S/4 allows longer account codes if configured. Also, fields like document numbers or new UUID fields in some tables, can appear where old code assumed a purely numeric or fixed-length key.
• Mandatory Fields and Default Values: S/4HANA introduced new mandatory relationships and data requirements in certain processes.
• Deprecated or Changed APIs: A number of classic SAP user exits and BAPIs have been replaced by newer frameworks in S/4HANA.

Strategies to Prevent and Mitigate Breakages

Knowing what breaks is half the battle the other half is proactively preventing these issues and efficiently fixing them. Here are practical strategies from the trenches to ensure a smoother S/4HANA conversion:

Prioritize and Refactor Systematically

Not all findings are equal – prioritize remediation based on business impact and complexity. It’s wise to classify your custom objects into critical, important, and nice-to-have, and tackle them in that order. For critical processes, perform proofs-of-concept early: for example, if you have a heavily customized order processing program, convert that program in a sandbox first to see what issues arise. This early refactoring can de-risk the project. Key refactoring tasks include replacing SELECTs on removed tables with new logic (as we illustrated for MATDOC, ACDOCA, etc.), swapping out obsolete function modules for new ones or for standard APIs, and adjusting any hard-coded logic. If you plan to run ECC and S/4 in parallel for testing, consider feature flags or switches in the code to handle both modes, although generally it’s better to branch the code.

Use Quick Fixes and Automated Tools

Modern ABAP development tools offer some automation to ease the remediation effort. If you use ABAP Development Tools (ADT) in Eclipse or ABAP in SAP Business Application Studio, certain ATC findings come with quick fixes – semi-automated code changes.

Thorough Testing of Interfaces and Reports

Testing cannot be overstated in an S/4HANA conversion. Once you refactor the code, unit test each critical program with realistic data in an S/4HANA environment. Does that custom report still produce the same totals as it did in ECC. Also, perform integration testing for all interfaces: send test IDocs from external systems, run inbound/outbound flows, and see if anything is rejected or mis-posted. It’s wise to involve the non-ABAP teams here too middleware experts, business analysts, Basis, etc.

Leverage SAP’s Simplification Notes and OSS Knowledge Base

When ATC or other checks flag an issue, SAP often has an OSS Note or Knowledge Base Article with the official guidance. Make use of these resources – they are basically the accumulated wisdom of SAP support for conversion issues.

Conclusion

A large scale S/4HANA conversion is a bit like renovating the foundation of a house while living in it. The house might look the same from the outside to end users but under the floors and behind the walls, almost everything is new. Custom ABAP code breaks because the foundation has changed. Interfaces break because the wiring is different. By understanding what typically breaks such as custom SQL on replaced tables, obsolete transactions, hard coded assumptions, IDoc and output format changes and master data model shifts you’ve won half the battle.

The other half is preparation and adaptation. With thorough analysis, proactive remediation, and diligent testing, you can address these issues before they impact business. Use the tools SAP provides to find problems early, and follow the recommended practices to fix them.