One of the most consequential differences between pre-RISE on-premise S/4HANA and RISE is the customisation model. On-premise S/4HANA permits a broad range of custom development inside the application core, with the buyer’s ABAP developers extending objects, modifying behaviour, and integrating peripheral systems through bespoke code. RISE constrains the customisation model materially. Custom code is permitted only inside defined patterns; the legacy code in the existing estate does not transfer untouched; and the build options available to extend RISE differ both technically and commercially from the on-premise alternative. This article walks through the customisation model, the technical patterns that are permitted, and the contractual hooks that help manage the transition. It is one of the engagement patterns underneath our contract negotiation service.
The customisation model
Under RISE, customisation runs through three patterns. First, key-user extensibility, which permits configuration-style changes by business users within SAP-defined boundaries. Second, in-app extensibility through SAP Build, which permits technical users to extend specific application objects within defined scaffolding. Third, side-by-side extensibility on BTP, which permits full custom development running outside the RISE tenant and integrating through approved APIs.
The three patterns together cover most extension requirements but they do not cover all of them, and they are not equivalent in cost or in operational implication. A pre-RISE custom-code estate of any maturity will include code that does not map cleanly to one of the three permitted patterns. The mapping exercise is the most important pre-sign technical assessment in any RISE move. The RISE topic page covers the broader architectural context.
Where key-user extensibility works
Key-user extensibility covers configuration-style changes: adding custom fields to standard objects, defining custom logic on those fields, building simple custom reports and forms, and similar low-complexity adjustments. The pattern is well-suited to changes that are operationally light, that follow the standard application structure, and that do not require code outside the configured boundaries.
The pattern covers a meaningful slice of the typical extension portfolio (commonly 30 to 50 per cent of the extension count) but a smaller slice of the extension value (because the operationally important extensions tend to be more sophisticated than key-user extensibility can support). The RISE operational limits article covers the broader operational constraint frame.
Where in-app extensibility fits
In-app extensibility through SAP Build is the middle pattern. It permits technical users to extend specific application objects with code-level changes that run inside the RISE tenant but in a controlled wrapper that survives SAP’s upgrade cycles. The pattern is well-suited to moderate-complexity extensions: modifying behaviour of standard transactions, building custom workflows on top of standard objects, and adding meaningful application-level logic.
The pattern requires the buyer’s developers to be retrained on the Build environment, which is a non-trivial up-front investment. The pattern also has limits: not every standard object is extensible through Build, and the wrapper structure constrains what can be done within an extension. Pre-sign, the buyer’s extension portfolio should be mapped to specific objects and the Build-coverage confirmed.
Where side-by-side extensibility fits
Side-by-side extensibility on BTP is the most flexible pattern. Custom code runs outside the RISE tenant, on the BTP platform, with the integration to RISE going through approved APIs. The pattern can replicate effectively unlimited custom logic, and it is the route for extensions that exceed key-user and in-app capabilities.
The pattern carries two costs. First, BTP credit consumption (which is a recurring cost across the contract life and varies with the extension complexity and the runtime). Second, the integration overhead (which is an architectural cost: the extensions integrate at a network boundary rather than as native in-tenant code, with implications for performance, transaction integrity, and operational support). The pattern is the right answer for extensions that justify the costs; it is not the right answer for extensions that could have been built inside the tenant if a different pattern had been chosen pre-sign.
The customisation cost gap between on-premise S/4HANA and RISE is most acute for estates with deep custom-code investments. The conversion exercise can absorb fifteen to twenty-five per cent of the original custom-code value, with the absorbed portion replaced by side-by-side extensions or by adopting the SAP standard. The conversion cost belongs in the RISE business case alongside the subscription cost.
The code-inventory exercise
The pre-sign code-inventory exercise is the technical assessment that drives the customisation strategy. The exercise enumerates the existing custom code, classifies each piece against the three RISE extensibility patterns (key-user, in-app, side-by-side), identifies the pieces that do not map (requiring redesign or sunset), and quantifies the conversion effort.
The inventory is most effective when conducted by the buyer-side team rather than by the SAP-supplied implementation consultancy, because the buyer-side team is more likely to challenge the prevailing SAP-side framing (which tends to optimise toward the SAP-standard adoption rather than toward the buyer’s actual extension preservation). The custom-code remediation article covers the inventory methodology in detail.
The ABAP Cloud question
ABAP Cloud is the modern, RISE-compatible variant of the ABAP development environment, with a constrained API surface designed to be forward-compatible across SAP’s release cycles. ABAP Cloud is the language and pattern of the in-app extensibility pattern within Build. The buyer’s ABAP developers have a learning curve to ABAP Cloud, but the underlying syntax and tooling are familiar.
The ABAP Cloud approach is the recommended in-app pattern for new extensions and for extensions being rewritten from the legacy environment. The constraint surface is documented and stable. The pattern is the safest route for extensions intended to survive the full contract life and beyond, because forward-compatibility is the design goal.
The third-party dimension
Estates carrying third-party add-on products (industry-specific modules from independent software vendors, integration packs, niche-process extensions) face an additional layer in the customisation question. The third-party products may or may not be RISE-certified, may or may not have a RISE-compatible deployment path, and may or may not be priced to make the RISE move commercially viable.
The pre-sign exercise should review each third-party product against the RISE certification list, identify the deployment route, and confirm the commercial path. Where the third-party route is closed (the product is not RISE-certified and the vendor has no roadmap), the buyer faces a sunset decision: replace the product with a RISE-compatible alternative or accept the loss of the functionality. Both routes carry cost. The manufacturer RISE conversion case file documents the third-party transition in practice.
The contractual hooks
Several contractual provisions help manage the customisation transition. The first is the BTP-credit allocation, which should be sized to the projected side-by-side extension volume rather than to the SAP-recommended default. The second is the in-tenant extensibility credit (a separate allocation for Build usage), which should be sized to the projected in-app extension volume. The third is the implementation-services scope, which should explicitly include a custom-code remediation work-package.
Each hook is negotiated at deal sign. The buyer-side leverage is greatest before the contract closes; after sign the leverage narrows substantially. The RISE contract checklist sets out the full hook list, and the RISE renewal leverage article covers the renewal-stage extensibility provisions.
The steady-state view
Once the transition is complete and the estate runs steady-state on RISE, the customisation model settles into a different rhythm than on-premise. New extensions are built using one of the three patterns from the outset. The maintenance burden is lower (because the patterns survive SAP’s upgrade cycles where legacy custom code does not), and the change-control overhead is reduced.
The steady-state benefit is real but it accrues only after the transition cost has been paid. Estates that under-prepare for the transition therefore face a peak of cost and disruption in years one and two of RISE before the steady-state benefit begins. The preparation removes the peak rather than the steady-state benefit, which arrives in either case. The RISE pricing model article covers the broader economic frame.
— 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
Inventory the existing custom code before signing the RISE contract. The inventory is the input to every subsequent extensibility decision. The contract negotiation service brief covers the engagement frame.