skill4sapAsk any Basis lead who has run a brownfield conversion what blew up the timeline, and custom code remediation is one of the first answers. Unlike data cleanup, which is at least bounded by the volume of master and transaction data in the system, custom code remediation is bounded by decades of accumulated Z-programs, user exits, and enhancements that nobody fully remembers writing. The tooling to assess this — the Custom Code Migration app, ABAP Test Cockpit (ATC), and the Simplification Item Catalog — is mature, but using it well requires understanding what each tool actually checks, and what it deliberately leaves to a human decision.
1Why Custom Code Is a Different Category of Risk
Standard SAP objects are remediated by SAP itself as part of the S/4HANA code line — you inherit the fix. Custom code (anything in the Z or Y namespace, plus modifications to standard objects) has no such safety net. If a custom program reads a table that no longer exists, calls a function module that was deleted, or relies on a field that moved as part of a simplification item, it fails at runtime in the new system — sometimes silently, producing wrong data rather than a hard error.
The silent-failure case is the one that should worry a project team the most. A syntax error is caught at activation. A program that compiles cleanly but reads the wrong table — because, for example, it was still pointing at KONV instead of using the new condition contract tables, or because it read customer/vendor master tables directly instead of going through the Business Partner API — can run in production for months before anyone notices the numbers are off.
2The Custom Code Migration App and ATC Checks
The Custom Code Migration app (accessible from Fiori, or the underlying SCI/ATC transactions in older releases) runs a static analysis of every custom object against a ruleset specific to S/4HANA. It flags three broad categories: syntax errors that will outright fail to activate, simplification-database-view issues where a program accesses a table that has been replaced by a compatibility view or removed, and SAP-recommended findings that point at deprecated APIs or patterns that still technically work but are flagged for future removal.
Running ATC once and generating a findings list is the easy part. The harder discipline is triage: not every finding is a blocker, and treating all of them as equally urgent is how remediation projects balloon. A syntax error in a program that hasn't been executed in six years and whose business function was decommissioned is a candidate for deletion, not remediation. A simplification-item finding in the program that posts goods receipts for your highest-volume plant is a go-live blocker.
This is why the remediation workload should be sized from usage data, not just the raw ATC finding count. SAP's Custom Code Usage data (via ST03N workload statistics or the Custom Code Analyzer in Focused Build/Readiness Check) shows which custom objects have actually executed in the lookback period. Cross-referencing that against the ATC findings turns an undifferentiated list of thousands of findings into a short list of objects that are both broken and actually used.
- Run the Custom Code Migration app early — ideally during the Readiness Check phase, not after the technical conversion
- Cross-reference ATC findings against actual usage statistics (ST03N / Custom Code Analyzer) before prioritizing
- Flag unused custom objects for retirement instead of remediation — don't pay to fix dead code
- Re-run ATC after each wave of fixes; remediation of one object frequently surfaces new findings in callers
3The Simplification Item Catalog: Reading It Correctly
The Simplification Item Catalog is SAP's list of every functional and technical change between the ECC code line and S/4HANA — Business Partner conversion, the Universal Journal, Material Ledger activation, and hundreds of narrower changes to specific modules. Each simplification item has a 'relevancy check' that SAP runs against your system during Readiness Check to determine whether it applies to your specific configuration and usage.
The common mistake is treating the simplification item list as purely a functional/Basis concern and not routing it through the same people who own custom code remediation. Many simplification items have a direct custom-code consequence: if a Z-program reads the old condition table structure that a pricing-related simplification item changes, that program needs the same remediation attention as an ATC finding — but it won't show up in ATC's output, because ATC checks code syntax and object references, not functional behavior changes described in a simplification item's business impact section.
The practical fix is a single remediation backlog, not two parallel ones. Every simplification item with 'relevant' status should be cross-checked against the custom code inventory for programs that touch the affected objects, in addition to the ATC findings list.
4Building a Real Exemption Process
Not every ATC finding gets fixed before go-live, and pretending otherwise is how timelines slip by months chasing diminishing-return remediation. A defensible exemption process has three components: a documented technical reason the finding is being deferred (not just 'ran out of time'), a named business owner who accepts the residual risk, and a tracked re-evaluation date — typically the next major support package or six months post-go-live, whichever comes first.
ATC itself supports formal exemptions (via the exemption management feature in newer releases) that are tied to a user and a reason code, rather than simply suppressing a finding in a spreadsheet that nobody revisits. Projects that use the built-in exemption workflow retain an audit trail that satisfies internal audit and QA review; projects that manage exemptions in an offline tracker routinely lose track of which deferred risks were ever actually closed out.
- Require a named business owner for every deferred finding, not just a technical justification
- Use ATC's built-in exemption management rather than an offline spreadsheet — it keeps the audit trail intact
- Set a hard re-evaluation date for every exemption; open-ended deferrals are how technical debt becomes permanent
- Re-test exempted objects against the next support package before assuming the exemption still applies
5What This Means for the Project Timeline
Custom code remediation should be sized and resourced as its own workstream with its own critical path, not folded into generic 'development' tasks in the project plan. The sizing inputs that actually predict effort are the number of custom objects flagged as both broken and actively used, not the raw line-of-code count or the total number of Z-programs in the system — a system with ten thousand Z-programs where only three hundred are both flagged and used in the last twelve months is a smaller remediation project than a system with two thousand Z-programs where eight hundred are flagged and actively running.
Teams that run the Custom Code Migration app and the Simplification Item relevancy check during the Readiness Check phase — months before the technical conversion window — consistently have a more accurate remediation estimate than teams that discover the real scope only after the sandbox conversion. The tooling is free and available long before the project needs to commit to a go-live date; the main constraint is making time to run it and act on the triage early enough to change the plan.
Key Takeaway
Custom code remediation is not a checklist item you clear once — it's a continuous triage discipline that runs from the Readiness Check through the last regression test before go-live. The teams that control their timeline are the ones that separate 'broken' from 'broken and used,' route simplification items and ATC findings through the same backlog, and build an exemption process with real ownership instead of a silent spreadsheet of deferred risk. Get the triage right early, and custom code remediation becomes a managed workstream instead of the thing that blows up the go-live date.