RISE with SAP: Impact on Existing On-Premise Licenses and Shelfware

What Actually Happens to Your On-Premise Licenses

When an organisation signs a RISE with SAP contract, the outcome for existing perpetual on-premise licences is neither automatic termination nor continued parallel use. The practical result sits somewhere between: the licences are contractually mothballed for the scope covered by RISE, while residual or out-of-scope licences may continue under separate terms.

SAP's position is that once a module or system is in scope of the RISE subscription, the customer should cease paying maintenance on the corresponding perpetual licence. This avoids the so-called double-payment problem — paying both a RISE subscription fee and on-premise maintenance for the same functionality. In practice, SAP enforces this through the RISE contract terms, which typically include a clause requiring customers to cease maintenance on replaced products upon RISE go-live.

The critical distinction is between in-scope and out-of-scope licences. Any SAP product that is explicitly included in your RISE subscription — S/4HANA, SAP BTP credits, and the selected cloud services — replaces the corresponding perpetual entitlements. Products not included in your RISE scope (standalone SAP modules, certain industry-specific engines, or non-SAP tools from adjacent acquisitions) retain their perpetual status and maintenance obligations independently.

The S/4HANA Migration Baseline Reset

One of the most commercially significant but least-discussed consequences of migrating to RISE is the licence baseline reset. SAP S/4HANA uses a fundamentally different metric structure from SAP ECC. ECC relied primarily on Named User licences across categories such as Professional, Limited Professional, Employee, and Developer. S/4HANA, and by extension RISE, is priced on the FUE (Full Use Equivalent) metric — a consolidated currency that normalises different user types into a single subscription unit.

This baseline reset means your existing ECC licence counts do not transfer one-for-one. SAP constructs a new FUE baseline for the RISE deal based on a licence optimisation exercise that maps your current user population to S/4HANA role assignments. In most cases, SAP's initial FUE proposal oversizes the baseline. Independent analysis consistently shows that mapping exercises conducted without buyer-side scrutiny produce FUE counts 20 to 35 percent higher than actual requirements.

Before accepting any RISE baseline proposal, you must conduct an independent user reclassification exercise. This involves auditing actual system usage — who logs in, how frequently, which transactions they execute — and mapping those activities to the appropriate S/4HANA role categories. The output of this exercise becomes your counter-proposal to SAP's FUE claim.

Shelfware: The Underappreciated Negotiating Asset

Shelfware — perpetual SAP licences that have been purchased but are not actively deployed or used — represents one of the most nuanced elements of any RISE negotiation. Its treatment differs sharply depending on how much shelfware exists, how SAP categorises it, and how effectively the customer leverages it during commercial discussions.

How SAP Views Shelfware

SAP's official position is that shelfware carries low credit value. The argument is that since the product was never deployed, there is minimal productivity benefit to convert, and therefore minimal credit obligation. In practice, the reality is more nuanced. SAP does not want customers to carry significant shelfware into an audit cycle — particularly post-RISE — because unused licences raise questions about whether maintenance fees were being paid on non-deployed products, which creates reputational and commercial risk for both parties.

For customers with meaningful shelfware volumes, the negotiating dynamic changes. SAP will typically offer one of three approaches: absorb the shelfware into the RISE FUE baseline at a discounted conversion rate, provide a partial credit applied against the first-year RISE subscription, or agree to waive future maintenance obligations on the shelfware in exchange for a clean contract conversion. Which approach applies depends on the size of the deal, the strategic importance of the customer, and the timing of the negotiation relative to SAP's fiscal year end (December 31).

Quantifying the Credit Window

Migration credit windows have been narrowing since 2021. Early RISE adopters who converted in 2021 and 2022 could often apply credits equivalent to 80 to 90 percent of their annual maintenance spend against the first-year RISE subscription. By 2024, that window had contracted to approximately 50 to 70 percent. The 2025 and 2026 standard credit range sits at approximately 45 to 60 percent of first-year fees, depending on timing and deal size.

The financial arithmetic is straightforward. An organisation paying €4 million per year in SAP maintenance — approximately 22 percent of their net licence value — might receive a credit of €1.8 million to €2.4 million against their first-year RISE subscription. This does not reduce the ongoing annual RISE cost; it reduces the Year 1 outlay, effectively lowering the 5-year TCO by an amount that depends on the discount depth achieved.

Timing relative to SAP's fiscal year end (December 31) directly affects the credit available. Deals signed in Q4 — particularly in October through December — typically command the highest credits because SAP's regional and global teams are driving towards annual revenue targets. Deals signed in Q1 offer less leverage on credits but may yield better multi-year pricing concessions.

The DDLC Dimension: Indirect Access and RISE

Any discussion of on-premise licence impact must address the Digital Documents Licence Charge (DDLC) — SAP's metric for assessing indirect access claims in S/4HANA environments. The DDLC replaced the earlier, more opaque indirect access model that SAP used to levy audit claims worth tens of millions of pounds against companies whose third-party systems (manufacturing execution systems, CRM platforms, e-commerce systems) interacted with SAP data.

Under the DDLC metric, SAP charges per document processed by the S/4HANA system — where a document represents an order, invoice, delivery, or other transactional record created or updated via an indirect (non-named user) interface. The DDLC metric applies equally in RISE with SAP environments. Migrating to RISE does not eliminate indirect access exposure; it restructures it under the DDLC framework.

Customers who had unresolved indirect access exposure under their ECC on-premise environment face a critical decision point at RISE conversion. SAP will typically propose a DDLC allocation as part of the RISE contract, often as a bundled credit package or an included volume within BTP. However, the allocated DDLC volume is almost always calibrated conservatively from SAP's perspective. Independent analysis of your document volumes — particularly across non-SAP systems that interface with your core SAP environment — is essential before accepting any DDLC allocation in a RISE contract.

What RISE with SAP Actually Includes (and What It Does Not)

A persistent source of commercial friction in RISE negotiations is the gap between what SAP's sales teams present as included and what the contract actually specifies as in-scope. Clarity on this point directly affects how you value the retirement of your on-premise licences.

RISE with SAP (now rebranded as SAP Cloud ERP, Private Edition for the private cloud variant) includes: S/4HANA Cloud Private Edition licences (FUE-based), infrastructure hosting on the customer's chosen hyperscaler or SAP's data centres, the RISE suite of transformation services, a defined allocation of SAP BTP (Business Technology Platform) credits, and standard SAP Support (Enterprise Support) at no additional cost.

RISE does not include: SAP SuccessFactors (sold separately on PEPM pricing), SAP Ariba, SAP Concur, SAP Analytics Cloud user licences beyond a minimal starter allocation, advanced BTP services beyond the included credit package, SAP Datasphere (now sold as an add-on following the July 2025 packaging changes), third-party integration middleware costs, or any implementation and migration services. These items are routinely presented by SAP's field sales as value-adds of the RISE bundle. They are not.

The BTP Credits Trap

SAP BTP (Business Technology Platform) credits are included in RISE at a volume that SAP positions as sufficient for integration and extension use cases. In our experience across 500+ engagements, the included BTP credit allocation is almost universally insufficient for production integration environments. Customers who rely on BTP for connecting SAP to non-SAP systems — a common requirement given the breadth of third-party systems in enterprise landscapes — will exhaust their included BTP credits within 12 to 18 months of go-live and face top-up purchases at standard list prices.

When retiring on-premise licences in favour of RISE, negotiate a BTP credit allocation that reflects actual integration workloads. Require SAP to model your BTP consumption based on your current system landscape before finalising the RISE subscription. Any gap between the modelled requirement and the included allocation should be resolved in the initial contract — not through post-go-live top-ups.

Seven Principles for Managing the On-Premise to RISE Transition

1. Conduct a full licence audit before entering RISE negotiations. Understand exactly what you own, what is deployed, what is used, and what is shelfware. This forms the basis of your commercial position. Entering negotiations without this data cedes the baseline-setting power to SAP.

2. Quantify shelfware before accepting any conversion credit. If SAP's migration credit proposal does not account for your shelfware volume, challenge it. Shelfware represents real capital expenditure by your organisation. Even partial credit is better than zero.

3. Avoid double payment at all costs. Ensure the RISE go-live date and the maintenance cessation date for replaced on-premise licences are aligned in the contract. Ambiguity in this clause results in months of parallel payments that SAP will not proactively flag.

4. Map DDLC volumes independently before committing to RISE. The DDLC allocation in your RISE contract determines your indirect access exposure for the life of the subscription. Under-allocation at signing creates top-up liability. Over-allocation is expensive shelfware within the cloud contract.

5. Right-size the FUE baseline. SAP's initial FUE proposal is a commercial opening position, not an objective technical measurement. Independent user reclassification typically reduces the FUE baseline by 20 to 35 percent.

6. Negotiate BTP credits reflecting actual integration workloads. Do not accept the standard included BTP allocation without validating it against your planned integration architecture.

7. Time the negotiation for maximum leverage. Q4 negotiations, particularly October to December, maximise SAP's year-end pressure and therefore your credit and discount opportunity. SAP's fiscal year closes December 31.