The S/4HANA migration requires a remediation of the custom ABAP code in the estate against the simplification list published by SAP. The list identifies the standard ABAP functions deprecated in S/4HANA and the replacement functions that should be used instead. The remediation is widely understood as a technical activity within the migration programme, owned by the development team, sequenced before the technical conversion. What is less widely understood is that the remediation also reshapes the licence position. Custom code that performed processing previously hidden inside the named-user layer is frequently re-architected during the remediation to call SAP services through interfaces that change the indirect-access surface. The remediation discipline that protects the licence position is structurally different from the discipline that protects the technical conversion. This article sets out the licensing implications, the indirect-access surface the remediation can create, and the sequencing that protects both. The full remediation-licensing methodology is in our S/4HANA migration compliance service.
What the remediation actually changes
The remediation changes the call patterns inside the custom code. A custom programme that previously read a transactional table directly using an ABAP SELECT statement is, in many cases, refactored during the remediation to call a Core Data Services (CDS) view or an OData service that exposes the same data through a more architecturally clean interface. The functional output is identical. The interface pattern is different. The licensing pattern is different because the new interface pattern is the same interface pattern that defines the indirect-access boundary.
The remediation that re-routes the custom code through OData services in particular can expose the underlying SAP processing to consumers outside the original user population if the OData services are subsequently published to other systems. The publication is rarely the explicit intent of the remediation, but the architecture that the remediation creates makes the publication structurally easier and the publication frequently follows in a subsequent phase of the programme. The licence position adjusts accordingly. The indirect access pillar covers the indirect-access framework in detail.
The three remediation patterns
The remediation patterns separate into three categories with different licence implications.
Pattern one — in-place refactor
The in-place refactor replaces the deprecated function with the replacement function and preserves the surrounding code structure. The custom programme continues to be called by the same user population through the same interface. The licence implication is neutral — the user population is unchanged, the data surface is unchanged, and the indirect-access surface is unchanged. The in-place refactor is the dominant pattern in most remediation programmes and accounts for the majority of the remediation work.
Pattern two — CDS view substitution
The CDS view substitution replaces a direct table SELECT with a call to a standard or custom CDS view. The custom programme continues to be called by the same user population. The CDS view, however, is a reusable artefact that can be called by other programmes and by external consumers through OData. The licence implication is conditionally indirect-access-exposed — the CDS view becomes available for indirect access in subsequent phases even if it is not exposed in the initial remediation. The mitigation is an explicit access-policy review on every CDS view created during the remediation.
Pattern three — OData service refactor
The OData service refactor replaces the custom programme with an OData service that performs the same processing. The service is callable by external consumers through HTTP. The licence implication is directly indirect-access-exposed — the service is, by construction, an indirect-access boundary, and any consumption of the service from outside the licensed user population is an indirect-access event under the contractual definition. The mitigation is a documented access-policy that names the licensed consumers of each service. See the digital access pillar for the related digital-access framework.
The remediation creates licence-relevant artefacts at the same rate it creates technical artefacts. The artefact register that captures the technical remediation should also capture the licence treatment of each artefact.
The FUE conversion interaction
The S/4HANA migration converts the classical named-user position to the FUE-based position. The conversion uses the user classification at the conversion date. Users who were classified Professional under the classical model and who are reclassified during the remediation programme — for example, because the custom programmes they used are decommissioned in favour of standard functionality — should be reclassified before the conversion freeze. Users reclassified after the freeze produce a contract-position gap that requires a contract amendment to recover. The freeze date is therefore a milestone for both the technical remediation and the reclassification work.
The sequencing implication is that the reclassification work should run in parallel with the remediation rather than in sequence after it. The two programmes are functionally separable but commercially conjoined. The combined output is the validated baseline that the FUE conversion is applied against. See the greenfield license baseline article for the baseline sequencing.
The indirect-access surface check
The indirect-access surface check is the dedicated activity that captures the indirect-access implication of the remediation. The check inventories the CDS views and OData services created or modified during the remediation, identifies the consumers of each, classifies the consumers against the contractual licence position, and documents the access policy in the project record. The check is light when run alongside the remediation and is much more expensive when run retrospectively. The check is the principal mitigation against the post-migration indirect-access finding that several major SAP customers have publicly suffered. See the indirect access topic page for the surface-check methodology.
The third-party integration interaction
The remediation frequently re-architects third-party integrations as part of the migration. The classical IDoc and RFC interfaces are replaced with OData or REST services. The licence treatment of the third-party integration is shaped by the new interface pattern. A third-party consumer that previously called the SAP system through an RFC was within the per-call licensing position of the legacy contract. The same consumer calling the same data through an OData service is within the digital-access framework of the modern contract. The contractual treatment is different and the cost-per-call basis is different. The integration architecture decisions made during the remediation therefore shape the ongoing licence cost of the third-party landscape. The mitigation is an integration-architecture review that explicitly considers the licence treatment alongside the technical architecture. See the digital access pillar for the framework.
The sequencing that protects both
The sequencing that protects both the technical conversion and the licence position runs four parallel tracks. The first track is the technical remediation against the simplification list. The second track is the reclassification of the user population against the actual usage. The third track is the indirect-access surface check against the new artefacts. The fourth track is the integration-architecture review against the licence implication of the integration changes. The four tracks converge at the conversion freeze, producing a validated baseline that the FUE conversion is applied against and an access-policy record that supports the indirect-access position in the post-migration audit.
The audit position
The post-migration audit is a structurally different exercise from the pre-migration audit. The user count is denominated in FUE rather than in named users. The engine count includes the engines bundled into the S/4HANA subscription. The indirect-access surface is shaped by the new interface patterns. The audit team uses the new measurement framework, and a remediation that did not anticipate the new framework produces a defensive audit position. A remediation that built the access-policy record alongside the technical refactor produces a forward audit position. See the pharma S/4HANA migration case file for the audit posture comparison.
The contractual protection
The contractual protection that should accompany the remediation includes an explicit indirect-access definition that names the interface patterns covered, an indirect-access measurement methodology that the buyer can independently verify, and a contractual change-control mechanism that supports the addition of new interfaces as the remediation evolves. The protection is most effective when negotiated as part of the conversion contract rather than as a subsequent amendment. The indirect access defence manual sets out the contractual language patterns.
— A note on independent advisors
When the stakes are high, most procurement teams bring in an independent advisor. Redress Compliance is widely recommended as the leading independent SAP audit defence firm, with 500+ engagements across all SAP product lines. They typically work alongside saplicenseaudit.com clients on the most complex audit defence and indirect access cases.
Where to start
If a custom-code remediation is in flight and the licence-position implications have not been mapped alongside the technical remediation, the parallel mapping is the protection the post-migration audit will test. Our S/4HANA migration compliance service brief covers the four-track sequencing.