When you leave SAP ECC, your custom code does not automatically carry over to S/4HANA. Some of it will break, some will become redundant, and some can be adapted. The standard approach is to assess every custom object, clean up what you no longer need, and remediate or rebuild what you want to keep. This article walks through the key questions every programme manager should be able to answer before a migration starts.
What happens to custom code during an SAP ECC migration?
During an SAP ECC migration to S/4HANA, a significant portion of custom ABAP code will either stop working or produce incorrect results. S/4HANA introduces a simplified data model, replaces classic tables with new structures, and removes compatibility with certain programming techniques that were standard in ECC. This means custom code that ran without issues for years can fail the moment it encounters the new system.
The most common causes of breakage are direct access to obsolete database tables, use of deprecated function modules, and ABAP syntax that is no longer supported in the S/4HANA environment. Finance-related custom code is especially affected because the new Universal Journal in S/4HANA replaces the separate FI and CO tables that many custom reports and interfaces relied on.
Beyond technical failure, there is also the problem of relevance. ECC environments often carry years of accumulated custom objects, many of which were built for processes that no longer exist or business requirements that have since changed. Carrying that weight into a new system adds migration effort, increases testing scope, and slows down future upgrades. That is why custom code remediation is not just a technical task but a strategic decision about what the business actually needs going forward.
How do you assess which custom code is still needed?
You assess custom code by combining automated usage analysis with structured business review. Automated tools, including SAP’s own Custom Code Migration Worklist (SCMWLT) and the SAP Readiness Check, scan your system and identify which custom objects have been used recently and which have not. Objects with no usage in the past twelve to twenty-four months are strong candidates for retirement.
Usage data alone is not enough. You also need input from business process owners who understand whether a piece of custom code supports a process that still matters. Some objects may show low usage simply because they are run periodically, such as year-end reports, while others may be genuinely obsolete. A structured review process that combines technical output with business sign-off gives you a defensible list of what to keep, what to retire, and what to rethink.
Starting this assessment early, ideally before the project roadmap is finalised, gives you a much clearer picture of migration complexity and effort. This is exactly the kind of baseline work we support through our project management approach, where scoping decisions are grounded in what is actually in your system rather than assumptions.
What are the options for handling custom code in S/4HANA?
There are four main options for handling custom ABAP code when migrating to S/4HANA: retire it, remediate it, replace it with standard functionality, or rebuild it. The right choice depends on the business value of the code, the technical effort required, and whether S/4HANA now covers the same requirement out of the box.
- Retire: Remove custom objects that are no longer used or no longer needed. This reduces technical debt and simplifies the new system from day one.
- Remediate: Update existing ABAP code to work within S/4HANA’s data model and syntax requirements. This is appropriate when the business logic is sound but the technical implementation needs updating.
- Replace with standard: Check whether S/4HANA now delivers the same functionality natively. Many custom workarounds from ECC exist because standard SAP at the time could not meet the requirement. That is often no longer the case.
- Rebuild: When the business requirement still exists but the original code is too tightly coupled to ECC structures to remediate efficiently, rebuilding from scratch in S/4HANA is sometimes the cleaner option.
The split between these options varies by organisation, but most migrations find that a meaningful share of custom objects can be retired outright, which reduces the overall remediation burden considerably. Explore our full range of services to see how we support each phase of this process.
Why does custom code cause go-live failures in SAP migrations?
Custom code causes go-live failures when it has not been fully assessed, remediated, and tested before cutover. The most common failure pattern is that teams underestimate the volume of affected objects, run out of time to fix everything, and carry unresolved issues into the live system. Interfaces break, reports produce incorrect data, and critical business processes stop working at exactly the moment when the system needs to be stable.
A second failure pattern is that custom code is technically fixed but not functionally validated. Remediation ensures the code compiles and runs in S/4HANA, but it does not guarantee the business output is correct. If a custom pricing routine or a stock valuation report has been updated but not tested against realistic business scenarios, errors may only surface after go-live when real transactions are processed.
There is also the timing problem. Custom code remediation often starts later than it should because the full scope is not known until the technical assessment is complete. Organisations that begin this work early, as part of the design phase rather than the build phase, give themselves the runway to resolve issues properly rather than rushing fixes under cutover pressure.
How should custom code be tested before go-live?
Custom code should be tested through a combination of unit testing by developers, integration testing within business process scenarios, and regression testing to confirm that remediated objects behave consistently with their original intent. Testing should cover both technical correctness and functional accuracy, because code that runs without errors can still produce incorrect business results.
The testing approach should be structured around business criticality. Custom objects that support financial postings, order processing, or regulatory reporting carry more risk than standalone reporting tools. Prioritise these for early and thorough testing cycles, and ensure that business users, not just technical teams, are involved in validating the output.
Automated testing tools add real value here. They allow you to run large volumes of test cases consistently across multiple test cycles, which is important when remediated code needs to be retested after each round of fixes. Manual testing alone rarely scales to the volume of custom objects involved in a typical ECC migration. Our test management practice uses automated testing solutions specifically designed for these scenarios, helping teams maintain quality assurance across greenfield and brownfield projects without losing time to repetitive manual cycles.
The final test milestone before go-live should include a dedicated regression pass focused on custom code, run as close to cutover as the timeline allows. This confirms that nothing introduced during the final build phase has broken previously validated objects.
How Optinus helps with custom code in SAP ECC migrations
We work with organisations at every stage of the custom code challenge, from the initial assessment through to post-go-live validation. Here is what that looks like in practice:
- Custom code scoping: We help you establish a clear baseline of what exists in your system, what is still used, and what the migration impact actually is, before budgets are committed.
- Remediation planning: We structure the remediation backlog by business criticality and technical complexity, so your team works on the right things in the right order.
- Test management: We design and run structured test cycles that cover both technical and functional validation, using automated testing where it saves time and improves coverage.
- Cutover support: We manage the transition end-to-end, including hypercare and aftercare, so that any issues surfacing after go-live are resolved quickly without disrupting operations.
- SAP and Microsoft Dynamics expertise: Our consultants have hands-on experience from real ERP migrations at leading multinationals, across SAP, Microsoft Dynamics 365, and other platforms.
If you are preparing for an SAP ECC to S/4HANA migration and want to understand your custom code exposure before committing to a roadmap, get in touch with our team or learn more about what we do.
