SAP custom code remediation for S/4HANA is the work of deciding what happens to every Z-object in your ECC system before conversion: delete it, replace it with standard, keep it as it is, fix it, or rebuild it as a clean-core extension. Done in that order, it shrinks the scope of the project. Done in the opposite order (fix everything the checks flag), it inflates the timeline. This playbook sets out a triage framework, the SAP tooling for each step, and the decision criteria we apply, with the claims that come from SAP or from vendors labelled as such.
Why custom code sets the conversion timeline
SAP states that mainstream maintenance for SAP Business Suite 7, including SAP ERP 6.0 enhancement packs 6 to 8, remains available through 31 December 2027. Optional extended maintenance then runs through 31 December 2030. In an October 2026 post, SAP says these dates have not changed since the 2020 announcement. For a custom code migration from ECC, 2027 is therefore the planning anchor, and extended maintenance is a fallback with its own cost, not a plan.
Custom code is usually the least predictable workstream in a brownfield conversion. Standard simplification items are documented and finite. Your Z-programs, enhancements, interfaces and reports are not: nobody outside your organisation knows how many there are, who still uses them, or what they touch. Two things follow.
- Inventory is the critical path. Usage data takes calendar time to collect, and you cannot shorten that by adding people.
- Every object you carry across is a future upgrade liability. Code that touches SAP internals is what makes later release upgrades expensive. That is the clean-core argument in one sentence.
If you are still choosing between conversion paths, start with our guide to S/4HANA brownfield migration and the comparison of brownfield, greenfield and bluefield in KSA. This post assumes the code question is already on the table.
The five-way triage for SAP custom code remediation: retire, replace, retain, remediate, redesign
Every custom object lands in exactly one of five outcomes. The decision rests on four inputs: production usage, the result of the S/4HANA readiness checks, the clean core level of what the code touches, and whether a business owner will stand behind it.
| Outcome | Typical criteria | What you do | Who signs off |
|---|---|---|---|
| Retire | No recorded usage across a full business cycle; no business owner; not referenced by objects that are used | Delete via a deletion transport during conversion; keep the usage evidence on file | Process owner and IT |
| Replace with standard | The requirement is now covered by delivered S/4HANA functionality, a released API or a standard app | Configure standard, migrate any data, retire the Z-object after cut-over testing | Process owner and solution architect |
| Retain | Used, and readiness checks return no findings relevant to S/4HANA | Carry across; schedule a regression test; no change | Development lead |
| Remediate | Used and valuable, but flagged by the S/4HANA checks (for example data model changes, simplified objects) | Fix in place, using quick fixes where available; retest | Development lead and tester |
| Redesign as extension | Used and valuable, but modifies SAP objects or writes to SAP tables, or the behaviour needs to survive future upgrades without rework | Rebuild as an in-app extension using released APIs, or as a side-by-side extension | Architecture authority |
A few rules we apply in practice. These are our own working practice, not SAP-stated thresholds.
- Retire first, and be aggressive about it. Every object you delete is an object you never analyse, fix or test. The retire decision can often do more to shorten the schedule than any remediation tool.
- Do not retire on thin evidence. Collect production usage over at least one full business cycle, including quarter-end and year-end runs. Month-end and annual jobs are exactly the objects that a short window misses. SAP does not state a minimum collection period, so this is a judgment call that the business should own.
- Replace beats remediate when standard now fits. A fix to a report that S/4HANA already delivers is cost with no benefit.
- Redesign is for the code that matters most, because it is the most expensive outcome per object.
Talk to us about your custom code scope
If you are sizing a conversion, we can talk through your usage data and readiness-check results, so the plan starts from evidence, not estimates.
Step 1: Collect usage data (SCMON, SUSG and UPL)
Triage depends on knowing what is actually used. SAP’s documentation describes the main mechanisms:
- ABAP Call Monitor (transaction SCMON) records which ABAP programs and procedures are called, and by which transactions, programs or services.
- Transaction SUSG aggregates the SCMON data over a period. Snapshots can be transferred between systems in SUSG, which is useful when you collect in production and analyse elsewhere.
- Usage procedure logging (UPL) is a second collection method for usage data, documented for SAP Solution Manager and in the SAP Readiness Check documentation.
The Custom Code Migration app uses this data to show when code was last used productively. That lets you identify obsolete code and limit adaptation to what is needed.
Two practical points. First, start collection as early as the programme is approved, before the business case is even finished, because the calendar is the constraint. Second, a usage record tells you a program ran. It does not tell you whether anyone needed the result. Pair the data with a business-owner review for the objects that are used rarely but touch statutory or financial processes.
Step 2: Run the S/4HANA readiness checks with ATC
The ABAP Test Cockpit (ATC) is the engine for the ATC readiness check on custom code. SAP provides several checks that identify critical usages of simplified SAP objects in customer code. These S/4HANA custom code checks run against the simplification database, so they tell you where your code depends on something that changes in S/4HANA.
The Custom Code Migration app wraps this in projects. According to SAP Help, it creates three project types:
| Project type | What it does | Use it for |
|---|---|---|
| SAP S/4HANA Migration Project | Runs the SAP S/4HANA custom code checks | The core conversion scope |
| SAP BTP Analysis Project | Checks readiness for the SAP BTP ABAP environment | Code you may move to a side-by-side ABAP environment |
| Custom Code Analysis Project | Runs any ATC check variant you choose | Custom governance checks, including clean core variants |
The app can scope an analysis by usage data, and it can create a deletion transport to remove unused ABAP source during the system conversion. Results can be filtered by quick-fix availability, scope and usage. That filter is what makes triage workable: start with objects that are used and fixable by quick fix, and treat the used objects without a quick fix as your real remediation backlog.
SAP’s Readiness Check documentation adds a routing note. Where the central check system is SAP S/4HANA 1809 or higher (a sandbox) or SAP BTP-based, use the Custom Code Migration app for the analysis. SAP also advises reviewing the information-level results and adjusting at least those that quick fixes support.
Step 3: Clean core levels decide what you rebuild
For the redesign decision you need a way to classify how closely code is tied to SAP internals. In August 2025, SAP described a four-level clean core concept, which it says evolved from its earlier three-tier extensibility model. As SAP presents it:
| Level | SAP’s description | Triage implication |
|---|---|---|
| A | Fully compliant extensions using only publicly released, stable SAP interfaces backed by formal stability contracts, built side-by-side on SAP BTP or on-stack with ABAP Cloud and released APIs | Target state for new and redesigned code |
| B | Compliant extensions that, in addition, use SAP’s classic APIs and technologies | Acceptable where level A is not yet possible |
| C | Partially compliant; accesses SAP internal objects (legacy scenarios). SAP plans a changelog for SAP objects | Retain only with a named owner and a monitoring plan |
| D | Not recommended; uses explicitly non-recommended objects or techniques, such as modifications, write access to SAP tables and implicit enhancements. Highest risk | Redesign candidates first |
SAP Learning adds a weakest-link rule: an extension is evaluated by the lowest-ranked technology used within it. One level D statement inside an otherwise clean program makes the program level D. SAP Learning also notes that level C and D findings can be tracked through the SAP object changelog and through automated ATC checks that detect incompatible changes.
Sources differ on how each object type maps to a level, and level B in particular is worded differently in places. Use SAP’s published classification for the objects in your landscape rather than a consultant’s summary table, including ours.
The earlier model, which SAP Learning describes as sunset in favour of the level concept, used three tiers: ABAP Cloud, cloud API enablement and classical ABAP. If you meet that vocabulary in an older design document or project plan, treat it as history. SAP Learning also says code built under the tier guidance, particularly wrapper objects, does not need to be migrated for that reason alone.
ABAP Cloud migration: when to rebuild in-app
ABAP Cloud is SAP’s approach to creating upgrade-stable custom ABAP code in both cloud and on-premise environments. Development happens on-stack in ABAP Development Tools, against local released APIs. The restricted ABAP language versions limit the language scope and limit access to other repository objects to released APIs.
For an ABAP Cloud migration of existing code, SAP’s documented route is:
- Run ATC in ABAP Development Tools with the check variant ABAP_CLOUD_READINESS.
- Work through the findings in the ATC Problems view. Each finding carries guidance, for example when code accesses an API that is not released.
- Use quick fixes where they exist for semi-automated conversion.
This is a deliberate step, not a conversion prerequisite. Many programmes convert with most retained code unchanged and move the highest-risk objects to ABAP Cloud over time. The triage question is which objects justify the cost now. Our rule of thumb: rebuild now where the object modifies SAP code, writes to SAP tables, or will be changed repeatedly. Leave stable, low-change reports alone.
Where extensions go: in-app or side-by-side
A redesigned extension has two possible homes. On-stack extensions in the S/4HANA system suit logic that is tightly coupled to core data and transactions. Side-by-side extensions on SAP BTP suit processes that span systems, need a different lifecycle from the ERP, or serve external users. SAP’s level A definition allows either route, provided released, stable interfaces are used.
The choice matters for effort and run cost, and it deserves its own decision record. We cover the platform side in our pages on SAP Business Technology Platform and SAP BTP environments. For this playbook, the point is narrower: decide where each redesigned object goes before you estimate it, because the answer changes the estimate.
Governance: keep new code clean
Remediation without governance recreates the problem within two years. SAP Help describes a clean core governance setup using ATC in the SAP BTP ABAP environment: copy the default variant ABAP_CLOUD_DEVELOPMENT_DEFAULT and extend it with clean core checks. SAP recommends checks for allowed enhancement technologies, API usage and critical statements, with an optional, licensed Code Vulnerability Analyzer. The documented steps are:
- Set up a central ATC system on SAP BTP.
- Create the clean core check variant.
- Analyse the existing custom code in the Analyze Custom Code app.
- Record exemptions and baselines for legacy code, so old findings do not block new work.
- Enforce the variant on new development, using ATC blocking mode in development for priority 1 and 2 findings.
The baseline step is the one teams skip. Without it, the first run reports a long list of legacy findings and the developers learn to ignore the tool.
AI assistants and agents for custom code: what SAP has stated
SAP has moved fast on tooling here, and the claims need careful reading. As of October 2026, SAP’s most recent statements are in an 18 August 2026 SAP News interview on AI for ABAP, SAP stated that:
- the first custom code migration agent was released in June 2026, and the first Custom Code Assistant was delivered in the second quarter of 2026, relying on the ABAP MCP server;
- a second agent for clean core transformation was planned for the third quarter of 2026. We have not confirmed that it has shipped, so check its status with SAP before building a plan around it;
- the ABAP MCP server connects third-party AI tools to ABAP systems, with Eclipse support and, per SAP’s Sapphire material, VS Code;
- ABAP AI capabilities have been extended to SAP S/4HANA Cloud Private Edition 2021 and later;
- seven agent families span the migration phases, and AI billing is moving to usage-based AI units.
SAP’s article gives no quantified effort saving. Treat any percentage you read, from any source, as a claim to test on your own code. Third-party vendors also sell remediation tooling and publish large effort-saving claims. Those figures are vendor marketing, not independent results, and you should test them on your own code.
Our position is practical. Automated fixes help most with high-volume, rule-based findings, where a deterministic transformation is safe. They help least with judgment calls: whether an object should exist at all, and what a modification was trying to achieve. Triage comes first, because it decides which findings are worth fixing. Whichever tool you use, every automated change still needs a code review and a regression test.
GCC localisation code: what to check before conversion
For Saudi Arabia, the UAE and Jordan, custom code often carries statutory logic that a generic playbook ignores. SAP built a localised KSA e-invoicing Phase One solution on SAP Document Compliance, covering ECC and S/4HANA core (FI, SD, MM), delivered through SAP Note 3095262. Phase Two integration with ZATCA covers clearance for B2B and B2G and reporting for B2C, per SAP Community. We found no SAP guidance that addresses how to treat customer Z-code around e-invoicing during an ECC-to-S/4HANA conversion, so what follows is our own practitioner guidance, not an SAP statement.
- Inventory first. List every Z-program, enhancement and form that touches invoice output, QR codes, tax determination, withholding, and payroll or end-of-service calculations.
- Prefer delivered localisation to custom. Where SAP delivers a localised solution, the default triage outcome for the custom equivalent is replace, not remediate.
- Treat statutory objects as owner-reviewed. They may run rarely, which is how a usage-only rule would wrongly retire them.
- Retest after conversion. A passing syntax check is not evidence that tax results are right. Run representative invoice, credit note and tax-return scenarios.
- Watch your support model. SAPinsider reports that customer-specific maintenance excludes new support packages and legal-change updates. Confirm the formal scope with SAP, because that matters when statutory rules change.
For the e-invoicing side, see our service page on preparing for the ZATCA e-invoicing mandate with SAP.
Sizing the effort: a worksheet, not a benchmark
We found no SAP-stated benchmark for custom code remediation effort, and we do not publish one. What you can build, in a week, is a sizing worksheet from your own data. The numbers below are illustrative only, to show the method. They are not Altivate results or industry figures.
| Step | Illustrative input | What it tells you |
|---|---|---|
| 1. Count custom objects | 10,000 objects | Total inventory |
| 2. Remove unused (usage data) | Assume 40 percent unused | 6,000 left; replace the assumption with your usage data |
| 3. Remove replaceable by standard | Assume 10 percent of the remainder | 5,400 left |
| 4. Split by check result | Assume 25 percent flagged | 1,350 to remediate, 4,050 to retain |
| 5. Split flagged by quick fix | Assume half have a quick fix | 675 low effort, 675 manual |
| 6. Redesign candidates | Objects that classify as level D under your clean core checks, or that modify SAP objects (may overlap steps 4 and 5) | Estimate individually, not by average |
Replace each assumption with a measured value, then attach effort per bucket from a sample you have actually fixed. Sample 20 to 30 objects from each bucket, fix them, and use the real time. The method matters more than the numbers: the quantity that moves the total most is the share you retire, and the one that varies most between organisations is the manual-fix bucket.
A sequence that works
- Start SCMON or UPL collection in production as soon as the programme is approved.
- Run the S/4HANA checks in a central system and size the buckets with the worksheet.
- Agree retire and replace decisions with business owners, with the usage evidence in hand.
- Remediate the used, flagged objects, starting with those that have quick fixes.
- Redesign the level D objects selected in triage, and decide in-app or side-by-side for each.
- Create the deletion transport for unused code to run with the conversion.
- Set up the governance variant, with baselines, before the first new development starts.
This sequence fits within a RISE programme or a standard conversion. See our overview of RISE with SAP and the SAP S/4HANA service page. For the business case behind the move, read should we upgrade from SAP ECC to SAP S/4HANA.
Frequently asked questions
What is SAP custom code remediation?
It is the process of analysing the custom ABAP code in an SAP system, deciding what to delete, replace, keep, fix or rebuild, and making the changes needed so the retained code runs correctly on SAP S/4HANA. It covers programs, enhancements, reports, interfaces and forms.
Do we have to fix all custom code before converting from ECC?
No. You need to deal with the used code that the S/4HANA checks flag. Unused code can be deleted, standard can replace some objects, and unflagged code can usually be retained as it is. That is why triage comes before any fixing.
When does ECC maintenance end?
SAP states that mainstream maintenance for SAP Business Suite 7, including SAP ERP 6.0 EHP 6 to 8, remains available through 31 December 2027, with optional extended maintenance through 31 December 2030 (SAP News, October 2026). SAP also describes a time-bound Transition Option for SAP ERP for large, complex customers whose transformation is already underway. Check eligibility with SAP directly.
What is the difference between ABAP Cloud readiness and the S/4HANA readiness checks?
The S/4HANA custom code checks find usages of simplified SAP objects that break or change in the conversion. The ABAP_CLOUD_READINESS variant checks whether code uses only released APIs and so can be built to the ABAP Cloud model. The first is about conversion, the second is about upgrade stability.
Which clean core level should custom code target?
SAP describes level A as the fully compliant target for extensions, using released, stable interfaces. For existing code, the realistic aim is to stop adding level C and D code, and to redesign existing level D objects where their business value and change frequency justify it.
Can AI tools remediate our custom code automatically?
Partly. SAP has stated that it released a custom code migration agent in June 2026 and has a clean core transformation agent planned. Third-party vendors also sell tooling. Quantified savings come from vendors and are unverified. Rule-based fixes can be automated safely. Decisions about whether an object should exist cannot, and all changes still need testing.
How long should we collect usage data?
SAP does not state a minimum. Our practice is to cover at least one full business cycle, including quarter-end and year-end processing, and to have business owners review rarely used objects that support statutory or financial processes before anything is deleted.
How should we treat ZATCA and VAT-related custom code?
Inventory it separately, prefer SAP-delivered localisation to custom logic where it exists, make business owners sign off on any deletion, and retest tax results after conversion. Our role is the SAP-side planning and testing, not the e-invoicing provider role.
Bring your usage data and ATC results
Bring your SCMON or UPL usage data and your ATC results, and we can discuss how to triage them, size the remediation bucket and judge where a redesign pays off.
