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

Broken Custom ABAP Code in S/4HANA

From an engineer’s vantage point, one of the first headaches in a brownfield S/4HANA conversion is custom ABAP code that no longer runs correctly. S/4HANA isn’t a mere upgrade; it introduces a new architecture with a simplified data model and revised logic. Many classic tables and transactions simply vanish or behave differently. As a result, existing Z-programs can dump or produce wrong results what worked fine in ECC may outright fail in S/4HANA, potentially breaking core business processes.

Common breakage patterns include:

Direct SELECT/UPDATE on Obsolete Tables

S/4HANA has eliminated numerous aggregate and index tables (like totals or status tables). For example, finance and controlling totals tables such as GLT0 or COEP are gone, and status tables like VBUK/VBUP are no longer updated. A custom report that used to select status from VBUK will now find nothing useful, because status moved into the sales order header/item tables themselves in S/4HANA. Many of these obsolete tables remain as empty stubs or compatibility views; they exist so that old code doesn’t short-dump on a missing table, but the data is either read on-the-fly or not populated at all. In practice, this means custom code that relied on such tables must be rewritten to pull data from new sources.

Use of Deprecated Transactions or Modules

S/4HANA marked the end of certain classic transactions and techniques. For instance, creating customers/vendors now goes through the Business Partner (BP) transaction rather than legacy XD**/XK** codes. If you have a batch input (BDC) or call transaction for XD01 in a custom upload program, it will fail in S/4. Likewise, classic credit control has been replaced by FSCM Credit Management; any custom logic reading KNKK needs adjustment to new tables or new APIs. Engineers must identify such deprecated calls and switch to the S/4 equivalents (often new function modules, CDS views, or Fiori APIs).

Hard-Coded Assumptions (Field Lengths, Formats)

S/4HANA introduced subtle data type changes that break code assumptions. A prime example is the material number length extension from 18 to 40 characters. If a custom program concatenates material IDs or assumes an 18-character fixed length, it will misbehave or truncate data in S/4. 

In practical terms, assignments of a 40-character material to an 18-character variable will lose data, and string comparisons or concatenations may yield incorrect results, leading to logical errors. The solution is to adapt all custom definitions and adjust logic (comparisons, loops) to handle longer keys.

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

The S/4HANA conversion famously brings a radically simplified data model in Finance and Logistics. This is where many large-scale projects hit technical snags: custom code that accesses underlying tables must contend with tables that have been replaced, merged, or dramatically changed in structure.

Universal Journal (ACDOCA)

In finance, S/4HANA consolidates many traditional tables into the universal journal table ACDOCA. This single-line-item table now contains fields from what used to be separate ledgers and sub-ledgers (FI, CO, AA, ML, etc.). Custom ABAP reports with SQL on BSEG/BKPF break or return incomplete data because the source of truth moved. Consider this legacy query:

* 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'.

Material Documents and Inventory (MATDOC)

The logistics side sees a similar overhaul. ECC’s materials management used a separate header (MKPF) and item (MSEG) tables for material documents, plus various stock tables (MARD, etc.) and history tables. S/4 replaces much of this with the New Simplified Data Model (NSDM): a single table MATDOC that stores all material document items (with header fields included). During conversion, SAP literally migrates MKPF+MSEG data into MATDOC. Many traditional MM tables become views or are calculated on the fly.

This means custom programs that joined MKPF and MSEG or tried to update inventory tables will break. A query 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/4, this returns no useful data because MKPF and MSEG are no longer the primary tables — all that data now resides in MATDOC. The fix is to query MATDOC (which contains both the timestamp, plant, etc., and material, qty, etc.), possibly joined with a small extract table for performance (MATDOC_EXTRACT). Custom code must be adapted to use MATDOC’s structure; for example:

* 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%'.

Interface and Integration Breakpoints

A large-scale S/4HANA conversion not only affects internal code but also disrupts interfaces between SAP and other systems. Incompatible interfaces are a frequent pain point because S/4HANA’s changes extend to IDoc formats, APIs, and integration frameworks.

IDoc Structure Changes

Many companies have EDI or other systems exchanging IDocs with SAP. When you convert to S/4HANA, you must be vigilant, as IDoc message definitions may change even if the message type name stays the same. S/4HANA can introduce new segment versions, longer field lengths, and even deprecate old segments. 

For instance, an IDoc type like ORDERS05 might gain new fields or change a segment’s format. If your middleware or trading partner expects the exact ECC format, mappings will break potentially silently. Imagine an extra 10 characters on a field: the map might truncate or shift subsequent fields without immediate errors. The result is broken EDI transactions. To mitigate this, integration engineers should compare all IDoc type versions between ECC and S/4. Update your EDI mapping rules to the new format and test with partners before go-live. SAP community reports confirm that after conversion, IDoc segment version mismatches will cause middleware to reject messages until you import the updated definitions.

Output Management (NAST vs. BRF+)

Another technical shift is how SAP handles output. ECC’s output control is replaced in S/4 with BRF+ based output management. If you had custom logic triggering EDI or printouts via NAST user-exits, note that S/4 might not call those at all once BRF+ is active. Many companies initially struggle with this, sometimes opting to re-enable legacy NAST output for critical flows until they can implement BRF+ fully. The key is to reconfigure outputs in S/4: rebuild your output determination in BRF+ or decide to keep using NAST for specific outputs. 

Not doing so can mean, for example, that after conversion, your invoices no longer send because the old output condition records aren’t being processed. Early identification of all custom output routines and a plan to migrate or adapt them is essential.

Business Partner Integration

S/4HANA consolidates customer and vendor master data into a unified business partner (BP) model. Technically, this means any interface that creates or updates customers/vendors must account for BP. If your integration or custom web service tried to create a customer by directly calling BAPI_CUSTOMER_CREATE, you now need to ensure the BP is created (with the appropriate role) and linked. Many semantic mismatches can occur. A concrete case: a partner system sending in a vendor number via an IDoc might now need to send a BP number, or the IDoc needs a mapping to the BP. Prevention strategy: perform a master data alignment. Use the CVI (Customer-Vendor Integration) tools during conversion to ensure every customer/vendor gets a BP with the same number and that all relevant roles are assigned. Then, update external interface documentation: inform partners if any identifier formats changed, and test all integrations involving business partner data.

Changed Semantics and Data Assumptions

Even when structures remain in place, S/4HANA can subtly alter the meaning or usage of data in ways that break assumptions in custom code. We’ve touched on some, but let’s summarize a few semantic shifts that can bite engineers:

• Extended field lengths and types: Besides material codes, consider GL account numbers, cost center, and profit center IDs, etc. If any custom code used fixed-length constants or performed string operations assuming old lengths, it needs review. For example, concatenating a document number and fiscal year into a 10-character string might fail if document numbers increase in length in S/4. The prevention here is straightforward: use dictionary types rather than hardcoding lengths, and test edge cases with new max lengths.
• Mandatory fields and defaults: S/4 introduced new mandatory master data relationships. If custom programs were populating data through BAPIs or direct updates and not setting these now-mandatory fields, they will error out. In S/4, credit data is managed by FSCM and tied to BP and the credit segment; custom code must now deal with objects like UKMBP_CMS_SGM and often a Credit Check class or BAdI instead of a direct table read. Not adapting means your custom credit checks will always say no credit data because KNKK isn’t updated. Always check the Simplification Items for each functional area to see if any behavioral changes impact your enhancements and adjust accordingly.
• Deprecated or changed APIs: Some classic function modules or user exits have been replaced by new frameworks. For instance, if you used a user exit to influence MRP in ECC, in S/4, that exit might be gone due to MRP enhancements; you’d need to use a BAdI. Custom code calling those FM/exits will either do nothing or cause a short dump. Identifying these is part of custom code adaptation. SAP usually lists the new equivalent.

Strategies to Prevent and Mitigate Breakages

Finally, let’s talk about prevention and remediation. A successful large-scale conversion has a dedicated track for custom code and technical fixes. Here are practical strategies from the trenches:

Comprehensive Custom Code Analysis

Early in the project, use SAP’s tools to scan custom code for S/4HANA issues. The ABAP Test Cockpit with S/4 checks is a must-do; it will identify where your code uses obsolete transactions, tables, or bad practices. Also consider the ABAP Call Monitor to find unused code. You might discover, as SAP’s internal benchmarks show, that half of your custom code is unused or already incompatible. Deleting or archiving unused Z-programs upfront reduces the remediation workload. For the rest, create a catalog of fixes needed.

Prioritize and Refactor Systematically

Not all broken code is equal. Prioritize by business criticality. Start refactoring early, adjust SELECTs on removed tables, swap out obsolete FM calls for new ones, and ensure every change is feature-flagged or toggleable if you need to keep ECC running in parallel during testing. Adopt a mindset that the sooner you clean the code, the smoother the conversion cutover will be. In fact, companies that did early custom code remediation reported 40% less downtime during the migration cutover window.

Use Quick Fix and Automated Tools

Modern ABAP development in S/4HANA offers some automation. ADT in Eclipse provides quick fixes for certain findings. Third-party solutions exist that can scan and transform custom code in bulk. These tools can be a force multiplier if you have thousands of reports, but even with them, plan time for manual review and testing of the transformed code.

Thorough Testing of Interfaces and Reports

Once code changes are done, test, test, test. This cannot be overstated. Unit test your ABAP changes with realistic data to ensure they produce the same results as before. Then, run end-to-end integration tests in the S/4 sandbox: send EDI orders, run your custom billing programs, generate financial statements, etc. In large projects, it’s wise to involve key technical team members from middleware, BI, and basis in these tests, since performance or connection issues might appear. 

For EDI, use partner test networks or simulations to verify that, say, your ORDERS IDoc still maps correctly with the new fields. Catching an IDoc mapping issue in testing is far better than having trucks stuck at the dock because ASN IDocs stopped flowing after go-live.

Leverage SAP’s Simplification Notes and OSS

When ATC or other tools flag an issue, SAP often has an OSS Note or a Simplification Item explaining how to handle it. 

For example, there are SAP Notes detailing the replacement of KNKK fields for credit management. Reading these can give you the official solution. Make sure to install the latest Simplification Database and apply relevant Notes to your system, so that your checks are up-to-date on the newest S/4 version changes.

Consider Clean Core Principles

As a forward-looking strategy, minimize how much custom code you bring over unmodified. S/4HANA is an opportunity to clean up technical debt. If some old customization no longer makes sense, consider dropping it. The idea of “Clean Core” is to keep the S/4 system as standard as possible and put custom logic in extensions where feasible. This reduces future breakage when you apply S/4 upgrades. It might not prevent issues in the immediate conversion, but it will prevent future ones.

Conclusion

A large-scale S/4HANA conversion is a bit like renovating a house’s foundation while living in it. From an engineer’s perspective, the “house” your SAP system will look the same from the outside, 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. Knowing what typically breaks custom SQL on replaced tables, hard-coded assumptions, IDocs and outputs, and master data links is half the battle. 

The other half is preparation and adaptation, using the right tools to find issues early and applying sound engineering practices to fix them. For the hands-on engineer, it’s a challenging but rewarding exercise. You’ll modernize decade-old code, learn the new S/4 technologies, and ensure that when your company throws the switch to S/4HANA, the only thing that breaks is a bottle of champagne to celebrate a successful cutover.