Teams often underestimate how much legacy custom code depends on old system assumptions. That code may not function cleanly in the new environment, and fixing it can require extensive assessment and redevelopment. If organisations treat custom code as a simple lift-and-shift item, they risk broken processes, hidden access issues, and delays that ripple through the migration.
Why custom code becomes the real migration work
Custom code is often where SAP S/4HANA migrations become more than a technical platform move. The hardest issues are usually not syntax alone, but the business assumptions embedded in exits, enhancements, interfaces, and report logic. When those assumptions no longer match the target environment, teams discover that apparently small code changes can carry outsized process, data, and control implications.
Legacy code tends to accumulate dependencies on obsolete tables, transaction flows, authorization checks, and integration patterns. During migration, those dependencies are easy to miss if the review is limited to whether the code compiles. A more reliable lens is to ask which business process, data path, or control point each custom object actually supports, because that is where functional breakage usually appears.
One useful way to frame the problem is that custom code is both an application issue and an access issue. A report, interface, or batch job may still run, yet fail because it assumes a role, credential, or system path that no longer exists in the new landscape. That is why code assessment should be paired with dependency mapping and runtime validation, not treated as a one-time remediation queue. For teams dealing with wider secrets and credential sprawl in enterprise software, NHIMG’s Guide to the Secret Sprawl Challenge is a useful companion perspective, and the broader SAP risk pattern is illustrated in SAP Breach.
What teams usually underestimate in the assessment phase
The common mistake is assuming custom code can be categorised quickly as keep, replace, or retire. In practice, many objects need deeper inspection because they depend on data structures, performance behaviour, or authorisation logic that has changed under S/4HANA. Even when the functional intent is still valid, the implementation may need refactoring, interface redesign, or replacement with standard capability.
Teams also underestimate the volume of code that is not truly bespoke but is still business-critical. Enhancements, wrappers, user exits, and local modifications can be scattered across multiple modules and environments, which makes ownership unclear. If no one can say which process a custom object protects, whether it is still used, and who signs off on its retirement, migration risk rises quickly.
The strongest assessment approach is to prioritise by business criticality and dependency depth, not by code size. Large codebases are not automatically the highest risk; the small object embedded in a finance close, a goods movement, or a compliance report may matter more than a much larger utility that is rarely executed. That is why discovery, usage analysis, and process owner validation need to happen together.
Practitioner Guidance
What to prioritise: Start with code that sits on critical process paths, uses outdated data structures, or performs privileged system actions. Those objects create the highest probability of business disruption if they fail quietly after cutover.
What to verify: Confirm actual runtime usage, downstream integrations, and any embedded access assumptions before classifying an object as low risk. A custom program that “looks dormant” in the repository may still be invoked by jobs, variants, or external interfaces.
Decision rule: If the code exists mainly to preserve an old process assumption, treat migration as a redesign problem rather than a technical conversion. If the code still supports a current control or business outcome, preserve the outcome first and then decide whether the implementation should be rewritten, retired, or replaced.
Practitioner takeaway: The migration risk is rarely the custom code itself, it is the hidden business logic and access dependency carried inside that code. Teams that assess code by runtime role and process impact will usually find the real work earlier, with fewer surprises at cutover.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
