Every custom program is an asset, a liability, or dead weight. The problem is that nobody wants to find out which category applies at go-live. SAP S/4hana Implementation projects fail this test more often than most teams expect, because the ABAP custom code estate is rarely as clean as the project plan assumes.
Canadian organisations running SAP ECC today typically carry hundreds, sometimes thousands, of custom programs. Some were written a decade ago for a business process that no longer exists. Others call obsolete function modules that S/4HANA has removed entirely. A few are genuinely valuable and need careful rewriting. Sorting them out before the migration starts is not optional. It changes the size, cost, and risk profile of the entire project.
Why Custom Code Breaks on S/4HANA
S/4HANA is not a technical upgrade of ECC. It is a different system with a different data model, and that distinction matters for every line of ABAP your team has ever written. Understanding where the breakage comes from is the first step toward controlling it.
The most common source of breakage is the Universal Journal. In ECC, financial data lived across multiple tables: FI and CO were separate, and custom reports often joined them directly. S/4HANA collapses that structure into a single table, ACDOCA. Any custom program that reads the old table structure directly will either throw a syntax error or return wrong data silently. Silent failures are worse than hard errors, because they reach production before anyone notices.
The Removed APIs and Obsolete Function Modules
SAP removed or replaced a significant number of function modules, BAPIs, and database tables in S/4HANA. Programs that call these directly will not compile. The SAP Custom Code Migration app, available through the SAP Readiness Check, flags these automatically. But the tool only identifies the technical problem. It does not tell you whether the program is worth fixing.
That decision requires human judgment, and it requires a classification system. Without one, teams default to fixing everything, which inflates cost and extends timelines well beyond what the business approved.
The Data Model Changes That Catch Teams Off Guard
Beyond the Universal Journal, the material master and inventory management areas also changed significantly. The MARA, MARC, and MARD tables still exist, but programs that relied on specific field structures or join logic may return incomplete results. Procurement custom code is another common problem area. Many organisations built workarounds in ECC for purchasing workflows that S/4HANA now handles natively. Those workarounds do not just break. They conflict with the new standard process, creating duplicate logic that is hard to untangle under time pressure.
The business warehouse extraction layer is also affected. Custom extractors built for BW on ECC often reference tables or fields that no longer exist in the same form. Teams running SAP ECC to S4HANA Migration alongside a BW environment need to audit their extraction logic separately from their transactional custom code. The two workstreams have different risk profiles and different timelines.
The Four Categories That Drive Every Remediation Decision
A structured triage is the only way to turn a raw list of custom objects into an actionable plan. The four categories are breaking, degrading, compliant, and dead. Each one demands a different response, and mixing them up wastes time and money.
Breaking code will not compile or will produce incorrect results on S/4HANA. These programs need immediate attention. The question is not just how to fix them, but whether they are worth rewriting at all.
Degrading code compiles and runs, but it performs poorly. It may bypass the new in-memory architecture of HANA by using SELECT statements that were acceptable on a traditional database but are now expensive. The program works, but it slows the system down and undermines the performance gains the organisation paid for.
Compliant code passes all checks. It uses supported APIs, reads from current tables, and performs acceptably on HANA. These programs need no changes before go-live, though they may still benefit from optimisation later.
Dead code has not been executed in months or years. Usage logs and transport histories confirm it. Nobody calls it, no job schedule triggers it, and no user runs it. Retiring dead code before the migration reduces the scope of every other category.
How Retirement Changes the Project
This is the point most project plans miss. When a team retires 30 percent of its custom objects before remediation begins, the remaining work shrinks proportionally. Testing scope drops. Transport volume drops. The cutover window gets shorter. A retirement list is not a housekeeping exercise. It is a scope management tool.
One practical approach: pull the last 24 months of SM20 and SM21 logs, cross-reference with job schedules, and flag any object with zero execution records. Then confirm with the business owner before retiring. That confirmation step matters, because some programs run only at year-end or at quarter-close. A program with zero logs in October might be essential in December.
Document every retirement decision with a business sign-off. That record protects the project team when someone asks, six months after go-live, why a particular report no longer exists.
How a Structured Scan Prevents Go-Live Surprises
The remediation process that prevents go-live surprises follows five steps: scan, triage, rewrite, review, and prove. Each step has a clear output, and nothing moves forward until the previous step is complete.
Step 1: Scan. Run the SAP Readiness Check and the Custom Code Migration app against your ECC system. Export the full object list, including usage statistics and last-run dates. This gives you the raw inventory.
Step 2: Triage. Apply the four-category framework above. Assign each object to breaking, degrading, compliant, or dead. This step requires both a technical ABAP developer and a functional consultant who understands the business process behind each program.
Step 3: Rewrite. Work through the breaking and degrading categories in priority order. Programs that support month-end close or regulatory reporting go first. Internal convenience reports go last. For each rewrite, document the original logic, the change made, and the reason.
Step 4: Review. A second ABAP developer reviews every rewrite before it enters the test system. Peer review catches logic errors that unit testing misses, particularly in financial calculations where rounding or currency handling can produce small but significant differences.
Step 5: Prove. Run the rewritten program against parallel data in a sandbox environment. Compare outputs from ECC and S/4HANA side by side. Any discrepancy, no matter how small, goes back to step three.
What the Scan Typically Reveals
Most organisations are surprised by what the scan finds. According to SAP, organisations typically find that 20 to 30 percent of their custom objects are dead code with no recent usage. Another 15 to 20 percent are duplicates or near-duplicates of standard SAP functionality that was added in later releases. That means roughly half the custom estate is a candidate for retirement or replacement before any rewriting begins.
The remaining objects split roughly between compliant code that needs no changes and breaking or degrading code that requires active remediation. The exact ratio depends on how aggressively the organisation customised ECC and how many releases it skipped before deciding to migrate.
Deciding What to Rewrite Versus What to Replace with Standard
Not every breaking program deserves a rewrite. Some custom programs exist because ECC lacked a standard feature that S/4HANA now delivers out of the box. Rewriting those programs means maintaining custom logic that competes with the standard process, which creates support overhead and upgrade risk for every future release.
The question to ask for each breaking program is: does S/4HANA standard cover this business requirement today? If the answer is yes, retire the custom program and configure the standard process instead. If the answer is no, then SAP Custom Development is the right path, and the rewrite should follow S/4HANA coding guidelines from the start.
Writing Clean ABAP for S/4HANA
Clean ABAP for S/4HANA means avoiding direct table reads on deprecated structures, using CDS views instead of custom database views where possible, and writing SELECT statements that the HANA query optimizer can handle efficiently. It also means avoiding nested loops on large datasets, which were tolerable on traditional databases but become performance problems on HANA when the dataset grows.
The ABAP Test Cockpit is the right tool for enforcing these standards during development. Teams that run it as part of their transport process catch problems before they reach the quality system, rather than discovering them during performance testing two weeks before go-live.
Managing the Custom Code Workstream Inside a Larger Migration
Custom code remediation does not happen in isolation. It runs in parallel with configuration, data migration, integration testing, and user training. The risk is that it gets deprioritised when other workstreams hit problems, because custom code feels like a technical detail rather than a business risk.
That framing is wrong. A broken custom report that a finance team uses for month-end close is a business risk, not a technical detail. Teams that treat custom code as a second-tier workstream tend to discover this at the worst possible moment.
S4hana Services engagements that go well treat custom code remediation as a parallel track with its own steering committee visibility, its own milestone dates, and its own escalation path. When a program cannot be fixed in time, the business needs to know early enough to arrange a manual workaround or delay go-live for that process area. Surprises at cutover are avoidable. They are the result of poor visibility, not technical complexity.
Rise with SAP Canada and the Clean Core Principle
Organisations exploring Rise with SAP Canada should pay particular attention to the clean core principle that SAP promotes for cloud deployments. Clean core means keeping the standard SAP codebase unmodified and moving custom logic to the Business Technology Platform instead. This is a significant shift from how most ECC systems were built, and it affects how custom code remediation is scoped. SAP’s Rise with SAP methodology dashboard guidance shows how Cloud ALM can support this methodology in practice.
For a brownfield migration, full clean core compliance on day one is rarely realistic. But the migration is the right moment to start moving in that direction. Programs that must be rewritten anyway can be rewritten as BTP extensions rather than classic ABAP modifications. That approach reduces the upgrade burden for every future release and makes the system easier to support.
Frequently Asked Questions
Q. How long does custom code remediation take for a typical SAP S/4HANA migration?
A. The timeline depends on the size of the custom estate and the percentage of breaking objects. For a mid-sized organisation with 500 to 1,000 custom objects, a thorough scan, triage, and remediation cycle typically takes four to six months when run in parallel with other migration workstreams. Starting the scan early, before the project blueprint is finalised, gives the team the most flexibility.
Q. Can we use automated tools to fix breaking ABAP code?
A. Automated tools can fix a subset of breaking issues, particularly straightforward table substitutions and deprecated API replacements. However, programs with complex business logic, financial calculations, or integration dependencies need human review. Automated fixes applied without review can introduce silent errors that are harder to detect than the original compile failure.
Q. What is the SAP Custom Code Migration app and what does it actually do?
A. The SAP Custom Code Migration app is a tool available through the SAP Readiness Check that scans an ECC system and identifies custom objects that reference deprecated tables, removed function modules, or unsupported APIs. It produces a prioritised list of objects that need attention before migration. The app identifies technical problems but does not assess business value or usage frequency, so human triage is still required.
Q. How does the clean core principle affect custom ABAP development after go-live?
A. Clean core means keeping the S/4HANA system unmodified and building extensions on the SAP Business Technology Platform rather than in classic ABAP modifications. After go-live, new development requests should be evaluated against this principle. Teams working with 2iSolutions on post-go-live support find that establishing a clean core governance policy early prevents the same custom code accumulation that made the ECC migration complex.
Q. What happens to custom code during a brownfield versus a greenfield migration?
A. A brownfield migration carries the existing custom estate into S/4HANA and remediates it in place, which means the full scan and triage process applies. A greenfield migration starts with a new S/4HANA system and rebuilds only the custom programs the business genuinely needs, which is a natural opportunity to retire dead code and replace standard-equivalent programs. Greenfield projects still need a custom code inventory from the old system to avoid rebuilding programs that S/4HANA standard now covers.
What Your Custom Code Inventory Tells You About Migration Readiness
The state of an organisation’s custom code estate is one of the most reliable indicators of how a migration will go. A team that has never inventoried its custom objects, does not know which programs are actively used, and has no coding standards from the ECC era is carrying hidden risk into every phase of the project.
Starting the custom code workstream early, before the project budget is finalised, gives leadership an accurate picture of remediation effort. That picture changes the conversation. It turns vague estimates into specific numbers: how many objects need rewriting, how many can be retired, and how many are already compliant. Those numbers feed directly into the project plan, the resource model, and the go-live date.
2iSolutions works with Canadian organisations at every stage of this process, from the initial scan through post-go-live support. Whether the organisation is planning a SAP ECC to S4HANA Migration for the first time or revisiting a stalled project, the custom code inventory is always the right place to start. It is the one workstream that touches every other part of the migration, and it is the one most often underestimated until it is too late to course-correct.
Email us at info@2isolutions.com to request a demo of AI ABAP code remediation
