How do you keep SAP customizations under control during an S/4HANA migration?

You keep SAP customizations under control during an S/4HANA migration by running a structured custom code analysis before the migration begins, using tools like SAP’s Custom Code Migration App or ABAP Test Cockpit to identify which modifications are still active and which conflict with the new architecture. From there, you make deliberate decisions: retire what’s obsolete, replace it with standard S/4HANA functionality where possible, and rewrite only what genuinely needs to survive the move. The sections below walk through each part of that process in practical detail.

Why do SAP customizations become a risk during S/4HANA migration?

SAP customizations become a risk during an S/4HANA migration because the underlying data model and technical architecture have changed significantly from ECC. Custom code written for older table structures, function modules, or APIs may simply stop working, or worse, run without errors but produce incorrect results. The risk is not just technical breakage — it is the operational disruption that follows when nobody anticipated the problem.

In ECC environments, years of customizations tend to accumulate quietly. Teams add Z-objects to fill gaps, modify standard programs to match local business rules, and build interfaces that rely on specific internal structures. Nobody removes anything because the cost of touching live code feels higher than leaving it in place. By the time an S/4HANA migration arrives, the custom code landscape can be enormous, and most organizations do not have a clear picture of what is actually being used.

The structural changes in S/4HANA make this worse. The introduction of the Universal Journal, the simplification of materials management tables, and the removal of aggregation tables like BSEG and BKPF as primary access points all mean that custom code hitting those structures directly will break. The question is not whether you have affected customizations. It is how many, and what they do.

What is the SAP Simplification List and how does it affect custom code?

The SAP Simplification List is an official SAP document that catalogs all the functional and technical changes made in S/4HANA compared to ECC, including removed objects, changed APIs, and deprecated functionality. It directly affects custom code because any Z-program, enhancement, or interface that relies on a removed or changed object will need to be reviewed and likely reworked.

SAP publishes the Simplification List for each S/4HANA release, and it covers areas like removed database tables, changed function module behavior, deprecated BAPIs, and Finance-specific structural changes. For a migration team, the Simplification List functions as a reference map: you cross-check your custom code inventory against it to identify what will be impacted.

The practical implication is that the Simplification List is not optional reading. Before you can make any informed decision about your custom code, you need to know which items on that list intersect with your landscape. SAP’s readiness check tooling automates much of this cross-referencing, but someone still needs to interpret the results and decide what to do with them.

How do you identify which customizations are still in use?

You identify which customizations are still in use by running a usage analysis against your production system, typically using the ABAP Test Cockpit (ATC) combined with the Custom Code Migration App in SAP Solution Manager or SAP Cloud ALM. These tools scan your custom code objects and flag which ones have been called in production within a defined period, and which ones have not been touched at all.

The output of this analysis usually surprises organizations. A significant portion of custom code in mature ECC systems turns out to be dormant — written years ago for a business requirement that no longer exists, or for a project that was later abandoned. Carrying that code into S/4HANA adds migration effort, testing scope, and long-term maintenance burden for no business value.

A useful approach is to set a usage threshold — for example, objects with no production calls in the past 12 to 24 months are candidates for retirement. Objects that are called regularly need further analysis to determine whether they conflict with S/4HANA architecture. This step is where good test management becomes important: you need a structured way to validate that the objects you keep will behave correctly in the new environment.

What are the options for handling custom code that won’t work in S/4HANA?

When custom code will not work in S/4HANA, you have four options: retire it, replace it with standard S/4HANA functionality, rewrite it to comply with the new architecture, or keep it as a managed exception with a clear remediation plan. The right choice depends on whether the underlying business requirement still exists and whether standard functionality now covers it.

Retire or replace with standard functionality

S/4HANA has expanded standard functionality significantly compared to ECC. Many customizations that were built to compensate for ECC gaps — in areas like reporting, cash management, or materials planning — now have native equivalents. Before committing to a rewrite, it is worth checking whether the business requirement can be met by standard functionality, often with better performance and lower maintenance cost going forward.

Retirement is the cleanest option for dormant or low-value code. If the usage analysis shows an object has not been called in production for two years, the default position should be to retire it unless someone can articulate a specific reason to keep it.

Rewrite or remediate

For customizations that are actively used and cannot be replaced by standard functionality, rewriting is necessary. This typically means updating direct table reads to use the new compatibility views or CDS views that SAP provides, replacing deprecated function modules with their current equivalents, and adjusting any code that relied on removed aggregation tables.

Remediation work should be tracked against the Simplification List findings, tested thoroughly in a sandbox environment, and signed off by the business owner before entering the migration cutover scope. Leaving remediation unresolved until the final weeks before go-live is one of the most common causes of delayed S/4HANA projects.

How do you prevent new customizations from creating the same problem?

You prevent new customizations from creating the same problem by establishing a formal custom code governance process that requires business justification, technical review, and approval before any Z-object is created. This process should include a check against SAP’s extensibility framework to ensure that customizations are built using supported extension points rather than direct modifications to standard code.

SAP’s recommended approach for S/4HANA is to use the clean core principle: keep the SAP core as close to standard as possible, and extend it only through defined extension points such as BAdIs, custom business objects, or side-by-side extensions on the SAP Business Technology Platform. Extensions built this way are far less likely to break during future upgrades because they sit outside the core rather than inside it.

In practice, governance means three things: a review gate before new customizations are approved, a regular audit of the custom code landscape to catch drift, and clear ownership of every Z-object so that someone is accountable for its maintenance. Organizations that skip governance after go-live tend to find themselves facing the same migration problem again at the next major upgrade.

You can explore our full range of services to see how structured program management supports this kind of governance across the full transformation lifecycle.

How Optinus helps you manage SAP customizations during S/4HANA migration

Managing custom code during an S/4HANA migration is one of those areas where experience with real migrations makes a tangible difference. We have worked on these transitions at leading multinationals, which means we have seen what happens when custom code analysis is skipped or rushed, and we know how to structure the work so that it does not become a blocker at go-live.

Here is how we support organizations through this specific challenge:

Custom code inventory and usage analysis — we help you build a clear picture of what exists in your landscape, what is actively used, and what can be retired before migration begins
Simplification List impact assessment — we cross-reference your custom objects against SAP’s Simplification List to identify conflicts early, when there is still time to address them properly
Remediation planning and execution support — we structure the rewrite and retirement work, track it through the project, and make sure it is tested before it enters the cutover scope
Clean core governance setup — we help you put the review and approval process in place so that new customizations after go-live follow a sustainable pattern
End-to-end project management — custom code is one workstream within a larger migration; we manage the full programme so nothing falls through the gaps between specialisms

We work both on-site and remotely, across the Netherlands, Belgium, and internationally, and we cover the full spectrum from project management to cutover and hypercare. If you want to talk through where your organization stands, get in touch with our team or learn more about what we do.

home|

blog|