In an S/4HANA migration project, custom code (the ABAP objects in the customer namespace, commonly called Z code) is rarely on the agenda of the first steering committees. A few months later, it is often one of the main reasons the schedule and budget slip. This guide compares the four strategies for handling custom code, then the tools that let you decide object by object, and closes with a recommendation by company profile.
Why Custom Code Drives the Timeline and Cost of an S/4HANA Project
Maintenance deadlines set the frame. According to SAPinsider, mainstream maintenance for SAP ERP 6.0 and the other core Business Suite 7 applications ends at the close of 2027, with optional extended maintenance from early 2028 to the end of 2030 at a premium on the maintenance fee. For a mid-sized company still on ECC, the decision window is narrowing, and custom code is precisely what stretches the preparation phase.
Three mechanisms explain its weight:
- The data model changes. S/4HANA simplifies several database structures (financial documents, business partners, inventory management). Any program that reads or writes those tables directly must be reviewed. SAP provides dedicated checks for this in the ABAP Test Cockpit (ATC), including “S/4HANA readiness” check variants.
- The code is rarely documented. Developments are ten or fifteen years old, their authors have left, and the specifications are gone.
- Every object you keep must be tested. The cost of an object is not limited to fixing it: it includes testing, business acceptance and future maintenance.
The consequence is simple: the more code you keep, the longer remediation and testing take. Conversely, every object retired before the project is one you do not fix, test or maintain. This logic is at the heart of SAP’s Clean Core doctrine, which aims to keep the ERP core as close to standard as possible.
Step 1: Measure Before You Decide
No strategy can be chosen without an inventory. Three measurements are needed, in this order.
Measure Real Usage
The first step is to know what actually runs in production. SAP offers two mechanisms. Usage and Procedure Logging (UPL) relies on SAP Solution Manager. Its successor, the ABAP Call Monitor (transaction SCMON), records calls to ABAP units in production and, besides their frequency, the calling process. It is available natively from AS ABAP 7.50, and through the ST-PI add-on for earlier releases from 7.00.
A point of method: collection must cover at least one full business cycle, including monthly, quarterly and year-end closings. A program run once a year for the fiscal close looks “dead” over a three-month window.
Identify Obsolete Objects
Once usage is known, classify the inventory: objects never called during the period, objects called only by users who have left, duplicates of functions now covered by standard, and data migration or conversion programs used only once. These objects are the natural candidates for deletion.
Estimating the Share of Dead Code: A Hypothesis, Not a Statistic
You often hear that a large share of custom code is never executed. The idea is plausible, and rough orders of magnitude appear in tool vendors’ documentation, but they come from the vendors’ own customer bases and do not transfer to your system. Treat the famous “80/20 rule” as a working hypothesis to verify by measurement: the purpose of step 1 is precisely to replace that intuition with a figure specific to your scope. In some systems dead code will be marginal; in others it will make up a considerable part of the inventory.
The 4 Strategies for Handling Custom Code
Once the inventory is qualified, each active object falls into one of these four routes.
1. Retire
The object is no longer used, or its purpose is now covered by standard functionality. You delete it (or deactivate it before final deletion). It is the cheapest and most profitable route, but it requires confirming with the business that the need has truly gone away.
2. Keep and Adapt
The object is useful, its scope is stable and the fix is mechanical (replacing access to simplified tables, syntax adjustments). You correct it so that it runs on S/4HANA. This is the fastest route for objects with little differentiating value, but it preserves debt if the object reaches deep into the ERP core.
3. Rewrite with In-App Extensibility
The business need remains, but it must be reimplemented with S/4HANA’s official, stable extension mechanisms (custom fields and logic, BAdIs, key user extensions, extended CDS models). The upfront cost is higher than for a simple adaptation, but the object becomes compatible with future upgrades.
4. Move Side-by-Side to BTP
The function is extracted from the core and rebuilt as a decoupled extension on SAP Business Technology Platform, communicating with S/4HANA through APIs and events. This is the route most aligned with Clean Core, suited to large developments, applications with a dedicated user interface, or functions shared across several systems. It does, however, require new skills (cloud development, integration) and governance of BTP running costs. The technical options are detailed in our guide to BTP extensions and Clean Core.
Decision Criteria Table
| Criterion | Retire | Keep and adapt | Rewrite in-app | Move to BTP |
|---|---|---|---|---|
| Observed usage | None or negligible | Regular | Regular | Regular, high value |
| Proximity to the core (standard tables) | Not applicable | High, mechanical fix | High, to be replaced by API/extension | Low once decoupled |
| Upfront cost | Lowest | Low to medium | Medium to high | High |
| Residual technical debt | None | High | Low | Low |
| Upgrade compatibility | Not applicable | Uncertain | Good | Good |
| Skills required | Business analysis | Classic ABAP | Modern ABAP, S/4HANA extensibility | BTP, APIs, cloud |
| Good candidate if | Need has disappeared or is covered by standard | Stable, barely differentiating object | Differentiating need close to core processes | Large, cross-functional or user-facing function |
Rule of thumb: start with the left-hand column. Each object must “earn” its place in a more expensive column.
Comparing Custom Code Analysis Tools
The tools fall into two families: those supplied by SAP, often sufficient for technical analysis, and third-party solutions that add business impact analysis, testing and security. The descriptions below reflect what vendors publish on their own sites; ask for a demonstration on your own system before deciding.
SAP Tools
- ABAP Test Cockpit (ATC). A quality-check tool built into ABAP, it runs S/4HANA compatibility check variants and lists the deviations to fix, according to SAPinsider. It is also used continuously to enforce Clean Core development rules.
- Custom Code Migration app. A Fiori application built on the remote ATC infrastructure, offered by SAP to analyze custom code as part of an S/4HANA conversion, according to an SAP blog post. It consolidates analysis results and helps track remediation.
- SAP Readiness Check. An assessment tool for S/4HANA readiness that includes a view of custom code; it gives a first picture of the effort, to be completed by a detailed analysis.
- SCMON / UPL. Not meant for compatibility analysis but for usage measurement, and essential upstream, as seen above.
Third-Party Tools
- Panaya. An impact analysis and testing platform for SAP. According to the vendor’s documentation, it analyzes custom code based on actual usage, proposes automatic fixes and supports deactivating unused code.
- Tricentis LiveCompare. An impact analysis tool comparing the current state with the target state. Its documentation describes dedicated apps: Impacted Custom Code (code to fix because of changed SAP dependencies) and Code Guard (comparison of custom versus standard code usage, identification of unused code).
- Onapsis. A specialist in SAP security. According to its website, it analyzes new or migrated ABAP code to check that it is “clean and safe” before go-live, and builds these checks into DevSecOps pipelines, including for BTP.
Comparison Table
| Tool | Scope | Strengths | Limits | Customer profile |
|---|---|---|---|---|
| ATC (SAP) | Technical compatibility and code quality checks | Native, no specific additional license, foundation of all other tools | No business impact analysis or test plan | Any mid-sized company, mandatory starting point |
| Custom Code Migration app (SAP) | Code analysis for conversion, via remote ATC | Centralized result tracking, avoids installing analysis on every system | Still code-centric, light on processes and testing | Mid-sized company with an in-house ABAP team |
| SAP Readiness Check | Overall readiness assessment, including a custom code view | Quick view to frame the project | Not detailed enough to steer remediation | Scoping phase of any mid-sized company |
| Panaya | Impact analysis, remediation, testing | Combines real usage, suggested fixes and tests | Commercial solution to budget for; payback tied to code volume | Heavily customized company, integrator in support |
| Tricentis LiveCompare | Impact analysis and test prioritization | Compares current and target state, useful for test scope | Same cost and onboarding caveats | Multi-system group, heavy test programs |
| Onapsis | Security of ABAP code and transports | Detects flaws that compatibility checks miss | Does not address S/4HANA compatibility as such | Regulated sectors, exposed code |
These tools are not mutually exclusive. A common combination: SCMON and ATC for inventory and compatibility, a third-party tool if volume justifies automation, and a security check on the code you keep.
Recommendation by Profile
Mid-sized company with a modest custom code estate. If the inventory stays limited (in the order of a few thousand objects, a threshold you should define with your team rather than take as a norm), SAP’s tools are enough. Start with SCMON over a full cycle, run ATC with the S/4HANA variants, delete dead code and adapt the rest. Reserve rewriting for genuinely differentiating objects.
Heavily customized company. When code touches every process (finance, logistics, production), manual analysis becomes the bottleneck. A third-party impact analysis and assisted remediation tool becomes defensible, provided you justify it with an estimate comparing its cost with the development and testing hours avoided. This is also the moment for some real soul-searching: a heavily modified legacy application may argue for a Greenfield approach, which we compare in our Greenfield, Brownfield and SDT decision guide.
Multi-system group. Several ECC systems often share copied, slightly diverging developments. Deduplicate first, harmonize next, then handle a common repository. Impact analysis and testing tools at scale (LiveCompare, Panaya) are at their best here, and side-by-side on BTP lets entities share extensions.
Governance: Avoiding Recreating the Debt After Migration
Cleaning up code is pointless if new non-compliant developments reappear eighteen months later. Four measures structure governance.
- An extension design board. Every development request goes through a body that first checks whether standard functionality, configuration or a key user extension covers the need. Custom development becomes the argued exception. For simple needs, low-code approaches avoid opening an ABAP workstream.
- Written Clean Core development rules. Stable interfaces only, no modification of standard, no direct access to unreleased tables. These rules are enforced automatically by ATC in the transport pipeline.
- An extension register. Each object has a business owner, a documented purpose and a review date.
- Tracking indicators. For example: number of active custom objects, share of objects without an owner, number of open ATC findings, split of extensions between in-app and BTP. Pick few indicators and review them every quarter.
Budget and Planning: Where Custom Code Adds Time
Without quoting figures that would vary from one project to another, we can pinpoint where custom code weighs on the schedule:
- The inventory and analysis phase, often underestimated, especially if usage collection (SCMON) starts late: a full business cycle cannot be shortened.
- Remediation, which depends directly on the number of objects kept. This is the line item step 1 reduces the most.
- Testing, generally the longest item: every object kept or rewritten must be replayed by the business.
- Rewriting and BTP extensions, which require scarce skills and a ramp-up of the team.
- The development freeze, during which routine ECC changes must be limited so as not to move the target.
For the schedule, start usage measurement as soon as the migration decision is made, well before choosing the integrator: it conditions the estimate. For the budget, present the steering committee with a cost per strategy (retire, adapt, rewrite, move) rather than a global “custom code” envelope.
Going Further
DigitsLane offers a custom code audit: inventory, usage measurement, classification of objects across the four strategies and a remediation estimate, so you arrive at the steering committee with figures specific to your system. Contact DigitsLane to scope this audit.
To dig deeper into choosing your path, read our Greenfield, Brownfield or Selective Data Transition guide and our analysis of the Clean Core strategy and BTP extensions.
