Run the methodology with a senior advisor.
A senior Admodum advisor will walk the methodology through with your CIO, CFO, sourcing or SAM team on a private call. Engagements run as fixed fee, contingency or annual retainer.
Thirty pages on the SAP RISE construct, the hyperscaler decision, S/4HANA conversion accounting, Digital Access exposure, Named-User reconciliation, BTPEA commitment design, the residual on-premises estate, audit posture during migration and the seller’s migration narrative.
RISE with SAP is the commercial container inside which SAP packages the transition from on-premises SAP ERP to S/4HANA Cloud, bundled with infrastructure (hosted on a chosen hyperscaler), application managed services, integration, business process intelligence and a defined set of ancillary capabilities. The construct exists because SAP needs to drive the S/4HANA conversion across the installed base before the publicly committed maintenance end-date on legacy ERP, and because the buyer needs a migration path that does not run as a discrete on-premises programme.
The construct is structured as a multi-year subscription, anchored to a defined FUE (Full Use Equivalent) metric that consolidates the legacy Named-User counts into a single subscription denomination. The FUE metric is calibrated against the buyer’s historical Named-User entitlement, with a mapping ratio that SAP publishes and that the buyer must contest line by line. The construct also includes a defined hyperscaler footprint (AWS, Azure or GCP), an SAP managed-services scope, a defined integration envelope and an exit clause whose practical operability the buyer must read carefully.
The RISE economics are therefore not a like-for-like conversion of the legacy contract. The commercial position changes shape: from a perpetual licence anchored to Named Users with Maintenance & Support on top, to a subscription anchored to FUE with bundled infrastructure, services and a different cancellation profile. The buyer who reads RISE as a maintenance-replacement is reading the wrong construct; the buyer who reads it as a strategic vendor consolidation under a longer commitment is reading closer to the publisher’s frame.
The buyer’s posture must be set at this level. The renewal negotiation runs against the construct, not against the line items. The line items are the residue of the construct’s shape, not the substance of the negotiation.
RISE is delivered on AWS, Azure or GCP. The hyperscaler is selected at signature, runs throughout the term, and can in practice be changed only by re-papering the RISE commercial relationship. The hyperscaler decision is therefore not a deployment detail; it is a strategic vendor choice with a multi-year economic implication.
The buyer’s hyperscaler decision rests on four reconciliations. The first is the broader cloud-commitment portfolio: where the buyer has an EDP with AWS, a MACC with Azure or a Spend Commitment with GCP, placing RISE on the same hyperscaler can be accretive to the existing commitment ramp. The second is the existing on-premises infrastructure: where the buyer is currently running SAP on-premises, the hyperscaler whose data-centre footprint, integration tooling and network proximity match the existing posture has lower transition friction. The third is the broader application portfolio: where adjacent applications (data warehousing, integration platform, identity) already run on a specific hyperscaler, the RISE placement that minimises cross-hyperscaler integration is the more efficient placement.
The fourth reconciliation is the commercial overlay. SAP’s RISE commercial offer differs by hyperscaler in ways that are not always transparent: the price-per-FUE varies, the included infrastructure capacity varies, the network egress allowance varies and the support-service overlay varies. The buyer’s commercial assessment must therefore compare the RISE offer on each hyperscaler against the equivalent on the others, with attention to the components that change shape across the three options.
The S/4HANA conversion runs on three accounting lines: the transition of the legacy Named-User population to the FUE metric, the conversion of legacy ECC engine entitlements to S/4HANA equivalent entitlements, and the reconciliation of the legacy customisation footprint against the S/4HANA Public Cloud or Private Cloud delivery model.
The Named-User to FUE mapping is the largest single accounting line. SAP’s published mapping ratio (typically anchored to the Professional User as a baseline of one FUE, with Limited and Developer users mapped at fractional rates) is the seller’s opening position. The buyer’s position is a Named-User reconciliation that retires unused licences, reclassifies over-assigned licences to lower-cost types and consolidates licences across the entity-affiliate boundary before the mapping ratio is applied. The reconciliation typically reduces the FUE count by fifteen to thirty percent against the seller’s opening position.
The engine-entitlement conversion is the second material accounting line. Legacy SAP engines (BW, Solution Manager, Process Orchestration, the industry solutions) carry their own metrics and entitlements; in S/4HANA the same functionality may be delivered through native S/4HANA capability, through Business Technology Platform services, or through a continued separate-engine licence inside RISE. The reconciliation must map each legacy engine to its S/4HANA destination, with attention to functionality that has been consolidated, retired or repackaged.
The customisation footprint is the third accounting line and the largest source of programme risk. Legacy SAP estates typically carry substantial Z-code customisation, custom configuration and integration patterns that do not translate one-to-one to the S/4HANA delivery model. The conversion programme must inventory the customisation footprint, decide which elements are required, retired or replaced, and price the conversion work inside the RISE migration commitment. A RISE commercial offer that does not reconcile the customisation footprint is a commercial offer that mis-states the migration cost.
Digital Access is SAP’s indirect-access metric, introduced in 2018 to address the licensing exposure created by non-SAP applications and devices that read or write SAP data. The metric is consumption-based: SAP counts the document transactions (sales orders, invoices, purchase orders and other defined document types) that originate outside the directly-licensed SAP user population, with separate counting rules per document type.
The Digital Access exposure inside a typical mid-to-large SAP estate runs to millions of document transactions annually, generated by integrated systems (CRM, e-commerce, supplier portals, IoT, EDI, billing platforms) that the buyer may not have previously recognised as licensable. The exposure is therefore not a hypothetical risk; it is a quantifiable liability that SAP has the entitlement to enforce at audit.
The RISE construct includes a Digital Access component, sized at the FUE conversion or at a separate document-volume commitment. The buyer’s position must run a documented Digital Access measurement (using the SAP-provided Passport Insights tool, the GIB-Group methodology or an independent measurement) before the RISE commitment is sized. The measurement reconciles the actual document-transaction volume against the document types SAP counts, with attention to the indirect-static-read carve-out, the indirect-access via SAP S/4HANA carve-out and any documented historical exclusions.
The Digital Access commitment, properly sized, retires the audit exposure at signature. The Digital Access commitment, mis-sized, anchors the buyer to a multi-year over-commitment or, worse, leaves the audit exposure open inside the RISE term.
The Named-User reconciliation is the foundational exercise that anchors every other commercial line inside the RISE commitment. The reconciliation runs against the historical entitlement, the active user population, the user-type assignment and the entity-affiliate scope. The reconciliation must be closed before the RISE FUE mapping is applied, not after.
The user-type reconciliation runs across the Professional User, Limited Professional User, Functional User, Operational User, Developer User and Employee User categories, each of which carries a different price point and a different functional scope. A Limited Professional User who has been provisioned with Professional User capability for operational convenience is an over-assigned licence; the reclassification, where operationally defensible, reduces the FUE base materially.
The dormant-user retirement runs against the User Activity report. Users who have not logged into SAP for a defined period (typically ninety to one hundred and eighty days) are candidates for retirement. The retirement is sequenced against HR active-status data, with attention to maternity, sabbatical and contractor populations.
The entity-affiliate reconciliation runs across the corporate structure. Legacy SAP estates often carry licences entitled to affiliated entities that no longer exist or have been divested, and entitlements held at the corporate level that are deployed at the affiliate level inside a different licensing scope. The reconciliation must align the entitlement holder, the deployment entity and the contractual scope before the RISE FUE mapping is finalised.
The Business Technology Platform Enterprise Agreement is the consumption-based commercial container inside which SAP’s BTP services (integration, analytics, AI, low-code, security, mobile) are licensed. The BTPEA commitment sits inside or adjacent to the RISE commercial relationship and carries a separate ramp design, a separate consumption model and a separate exit profile.
The BTPEA construct runs on Cloud Platform Enterprise Agreement (CPEA) credits, drawn against a multi-year commitment with annual ramp shaping similar to the AWS EDP or Microsoft MACC. The eligible-services scope is broader than the buyer typically assumes at first read: every BTP service the buyer may consume across the term is included, with the consumption priced against the service-specific catalogue rate at consumption time.
The commitment design must reconcile against the buyer’s documented BTP use-case roadmap. SAP Cloud Integration replacing legacy PI/PO, SAP Analytics Cloud replacing legacy BW, SAP Build replacing legacy custom development, SAP AI Foundation replacing legacy custom ML: each is a use case with a defined consumption profile. The commitment is the sum of the documented use cases plus a defined headroom, not a top-down adoption target.
The interaction between BTPEA and RISE is the second material consideration. Some BTP services are included inside the RISE FUE allocation; others are consumed against the BTPEA credit pool; others are licensed separately. The buyer’s commercial reconciliation must map each BTP service to its commercial source so that the same capability is not paid for twice across the two commitments.
Most RISE conversions are not full conversions. A defined portion of the SAP estate (industry-specific solutions, custom integrations, satellite ECC instances, regional implementations) typically remains on-premises across the RISE term and beyond. The residual on-premises estate is the second commercial position the buyer must build, alongside the RISE construct.
The residual estate carries the historical perpetual licences with their Maintenance & Support obligation. SAP’s commercial posture on residual-estate maintenance has, across the engagements Admodum has run since RISE’s launch, tightened: the buyer who converts a portion of the estate to RISE is, in some commercial structures, offered preferential maintenance terms on the residual; in others, the residual maintenance is repriced upward to incentivise full conversion.
The buyer’s residual-estate commercial position must therefore be negotiated as part of the RISE commitment, not as a separate downstream conversation. The maintenance rate on the residual, the maintenance window (Standard Support, PCE-equivalent extension, third-party maintenance via Rimini Street or a comparable provider), the audit-window protection and the future-conversion economics all sit inside the RISE close, not after it.
The third-party maintenance option is a credible BATNA position. Rimini Street, Spinnaker and a handful of others provide third-party maintenance on SAP at materially lower price points than SAP’s Standard Support. The credible threat of a residual-estate move to third-party maintenance is, in many engagements, a material lever on the residual maintenance economics inside the RISE commitment.
SAP’s audit posture during migration is a distinct discipline. The migration window typically opens entitlement ambiguities (workloads moving between contracted entities, licences being consumed under transitional usage, indirect-access patterns being modified) that an SAP audit can read against the buyer if the buyer’s documentation does not pre-empt the reading.
The audit-defence preparation runs against the entitlement record, the deployment record and the migration record. The entitlement record is the historical Named-User and engine portfolio reconciled at the moment of the RISE conversion. The deployment record is the SAP Passport Insights output, the GIB-Group consumption measurement or the equivalent independent measurement that documents actual usage. The migration record is the project documentation that captures which workloads moved when, under which entitlement, with which transitional usage rights.
The audit-window negotiation inside the RISE close is the protection the buyer should secure. A documented audit moratorium of twelve to twenty-four months from the RISE Effective Date, anchored to the conversion completion, is a routine concession SAP grants where the buyer asks for it. The buyer who does not ask for it does not receive it.
SAP’s migration narrative is constructed around a small set of recurring frames. The buyer who recognises each frame, and the counter-position each frame opens to, walks into the RISE close with a different posture than the buyer who absorbs the narrative as the negotiation envelope.
The first frame is the deadline narrative: the legacy maintenance end-date is positioned as a forcing function that compresses the buyer’s decision window. The counter-position is the documented residual-maintenance pathway (SAP’s extended-maintenance options, third-party maintenance) that decouples the conversion timing from the maintenance deadline.
The second frame is the consolidation narrative: RISE is positioned as the strategic consolidation of infrastructure, services and software under a single commercial relationship. The counter-position is the reconciled cost-of-consolidation, which (in most engagements) demonstrates that the consolidation premium exceeds the saved coordination cost across the alternative best-of-breed approach.
The third frame is the credit narrative: the seller frames the legacy maintenance and Named-User entitlement as carrying a credit value against the RISE commitment. The counter-position is the documented credit accounting that ensures the legacy value is fully and transparently applied, not partially absorbed into the seller’s opening RISE pricing.
The fourth frame is the urgency narrative: the seller frames the RISE offer as time-bounded, with the implication that the negotiation window will close. The counter-position is the documented procurement timeline that runs the negotiation against the buyer’s calendar, not the seller’s.
The SAP RISE economics paper sits inside a broader enterprise software reading list. The companion papers extend the methodology to adjacent commercial mechanics:
The methodology in this paper is the methodology Admodum has applied across forty-seven SAP RISE conversion engagements inside the firm’s engagement history. Each engagement is structured as fixed fee, contingency / gainshare or annual retainer, depending on the buyer’s posture at the conversion window.
A senior Admodum advisor will walk the methodology through with your CIO, CFO, sourcing or SAM team on a private call. Engagements run as fixed fee, contingency or annual retainer.