RISE with SAP vs Traditional Licensing: Contractual Flexibility Comparison

RISE with SAP vs Traditional Licensing: Contractual Flexibility Comparison

Contractual flexibility is a critical factor when evaluating RISE with SAP (SAP’s cloud subscription model) versus traditional on-premise perpetual license agreements.

In essence, RISE contracts lock organizations into multi-year subscriptions with fixed user counts, making it easier to scale up but difficult to scale down or exit early.

Traditional SAP licensing offers more long-term flexibility – you own the software indefinitely, can adjust support commitments, and avoid strict time-bound lock-ins, albeit with higher upfront costs.

CIOs and CTOs must weigh these differences in scaling users, lock-in period, and contract terms to align with their business’s agility and financial strategy.

Cloud Subscription vs. Perpetual License Basics

RISE with SAP consolidates SAP software and infrastructure into a single subscription contract. You pay a recurring fee (OpEx) for the right to use S/4HANA and related services during a fixed term. B

y contrast, a traditional perpetual license model involves a one-time capital expenditure (CapEx) purchase of SAP software usage rights, plus annual maintenance for support and updates.

This fundamental difference means:

• Ownership: Perpetual licenses are owned indefinitely, while RISE only grants access for the term of the subscription.
• All-in-One Contract: RISE bundles software, cloud infrastructure (via SAP’s chosen hyperscaler), and standard support into a single agreement with a monthly or annual bill. On-premises licensing separates these – you manage the infrastructure (or choose a hosting provider) and pay support as a percentage of the license cost.
• Vendor Management: With RISE’s single contract, SAP becomes your primary vendor for everything (software and cloud operations). Traditional licensing gives you more control to manage pieces separately – you could host on your servers or a preferred cloud and even consider third-party support.

Read RISE with SAP Tiers and July 2025 Premium Packaging Changes.

Contract Length and Lock-In Commitments

One of the biggest differences is contract term and lock-in:

• RISE Contract Term: Typically a 3 to 5-year commitment. During this period, you are locked into paying for the subscribed capacity (e.g., number of users) for the full term. Early termination is generally not allowed without hefty penalties – if you try to exit mid-term, you effectively owe the remaining subscription fees (much like breaking a lease). After the term, you must renew the software or lose access to it. This creates a hard end date: if you don’t renew, your SAP system will be turned off unless you negotiate a new contract or revert to on-premise licensing.
• Perpetual License Term: A perpetual license has no expiration – you own the rights to use the SAP software indefinitely. There is no concept of a contract end date for usage. You do sign annual support agreements (typically renewing each year). However, you can choose not to renew maintenance and continue using the software legally (you will, however, no longer receive updates or support). There’s no need to “give the software back” – it’s yours permanently. This means no forced renewal, just to keep your business operations running smoothly.

Lock-In: RISE’s multi-year subscription inherently increases vendor lock-in.

Once you’ve migrated to RISE, switching away is difficult – not only would you need to license the software anew or migrate to another platform, but your entire SAP environment (infrastructure, services) is tied up in that contract.

In contrast, traditional licensing has less contractual lock-in: you can stop paying SAP maintenance and even switch to third-party support or alternative hosting if desired, while continuing to use the software.

If, after, say, 5 years, you decide to leave SAP entirely, with perpetual licenses, you simply stop using the software (no ongoing cost once the maintenance is dropped).

With RISE, stopping after 5 years means losing access to the software unless you have negotiated a conversion or have an alternative system in place.

Real-World Example – Lock-In:

One enterprise signed a RISE deal for 5 years at an annual subscription of approximately $5 million for their SAP S/4HANA environment.

Midway through, they realized some cloud services in the bundle were not needed, but they were unable to remove or reduce those services until the contract ended.

By contrast, another company, on a traditional license, had purchased SAP licenses upfront; after five years, when they decided to switch off an SAP module.

They simply gave SAP a 3-month notice to stop maintenance on that module’s licenses, avoiding further support costs while keeping the option to use the software they already owned.

Scaling Users and Usage Flexibility

Scaling up or down is an area where perceived cloud flexibility meets contractual reality:

• Scaling Up (Increase Users): Both models allow increasing users but in different ways. With on-premise licensing, you’d purchase additional user licenses as needed (a new license purchase, which is a negotiation and capital expense). In a RISE subscription, you can usually add more users (or extra capacity) during the term – SAP will happily upsell you. These additions are typically co-terminus with the original contract (e.g., if you add 100 users in year 2 of a 3-year term, you pay the prorated subscription for those 100 users for the remainder of the period). Scaling up in RISE is relatively straightforward: it may be as simple as issuing a contract addendum for the extra users, since it’s one contract covering everything. In on-premises environments, adding users may involve a separate purchase order and possibly additional infrastructure setup, but you have the freedom to time those purchases as needed.
• Scaling Down (Reduce Users or Usage): This is where contractual flexibility truly diverges. Under a perpetual license model, if your user count drops or certain licenses become unused “shelfware,” you cannot return licenses for a refund. Still, you can reduce costs by stopping maintenance on the unused licenses. (SAP typically allows customers to terminate maintenance on specific licenses with notice before the annual renewal. You save 22% per year on maintenance for those unused licenses in the future, effectively “shelving” them. You keep the rights to use the software you bought, just not paying support on the ones you don’t need.) With RISE, however, you commit to a set number of users (or capacity) for the entire term. If your usage needs drop, you cannot reduce the subscription fee mid-term. You continue paying for the originally contracted number of users until the end of the term. Only at renewal could you attempt to adjust the quantity (and even then, SAP’s standard posture is that reductions are not guaranteed or may be limited). This rigidness can lead to paying for idle capacity if your business downsizes or divests parts of its operations.

Mid-Term Adjustments:

Standard RISE contracts generally lack flexibility for mid-term changes. For example, if you divest a business unit that had 200 SAP users, you must keep paying for those 200 users until the term is up – you’re “stuck” with the cost of those now-unused licenses in your subscription.

In a traditional model, you’d simply stop using those licenses (since you have already paid for them) and could drop their maintenance at the next renewal to save money.

Similarly, suppose you decide to swap one SAP product for another (say, you want to drop one cloud service and start another). In that case, RISE doesn’t easily allow swapping components unless you negotiated that right up front.

Real-World Example – Scaling:

Consider a company that committed to 1,000 users in a RISE contract. Following the reorganization, only ~800 users were required. Because the contract locked in 1,000 users, the company continued paying for all 1,000 for the remainder of the term (paying roughly 25% for the capacity they didn’t use).

Had this been a perpetual license scenario, the company would have initially purchased 1,000 user licenses; however, upon needing only 800, they could reallocate some licenses elsewhere and halt maintenance on 200 licenses, saving roughly 200 × 22% of the license cost per year in support fees.

In other words, the on-premises model absorbed the downturn by allowing them to avoid ongoing costs for unused licenses, whereas RISE’s model provided no such relief until contract renewal.

Negotiating Flexibility in RISE Contracts

Because the default RISE terms are inflexible, savvy CIOs and procurement leaders should negotiate provisions up front to introduce some flexibility.

Key areas to negotiate include:

• Contract Term & Renewal Clauses: Aim for a term length that balances risk and discount. A shorter term (e.g., 3 years) provides an earlier opportunity to adjust or exit if needed, whereas SAP may push for 5 years or more with larger discounts. Insist on renewal protections: negotiate caps on price increases at renewal time (for example, no more than a 5% increase, or even pre-agree on renewal pricing). Additionally, seek the right to reduce scope at renewal – for instance, if you have fewer users or no longer need a component, you should have the option to renew for a lower quantity. SAP’s standard contract might not allow it, but this is a critical task to avoid being locked into paying for growth that never materialized.
• Swap Rights: Include a clause that allows you to swap or substitute products or services of equivalent value. If your business priorities change (maybe you want to drop one cloud service and pick up another in SAP’s portfolio), swap rights give you some agility. Standard RISE contracts don’t allow for easy swaps (they’d prefer to sell more). Still, you may negotiate the ability to trade unused elements – for example, converting unused Ariba Network transactions toward additional analytics services or exchanging some user licenses for another SAP cloud product. Even limited swap flexibility can save money if your needs shift.
• M&A and Divestiture Adjustments: If you plan to make acquisitions or might divest parts of the company, include terms for those scenarios. For example, if you acquire a company, can you add their users at a pre-negotiated rate (avoiding a price hike when SAP knows you’re forced to add)? Conversely, if you divest a division, consider allowing a pro-rated reduction in user count or fees. While SAP is reluctant to offer a mid-term reduction, framing it as a known business event clause (such as a merger, acquisition, or divestiture) can sometimes secure a concession that would otherwise not be standard.
• Shelfware Protection: In traditional licensing, the concept of shelfware (unused licenses sitting on the shelf) exists, and customers often negotiate the ability to terminate maintenance on that shelfware. For RISE, you may negotiate a commitment that allows you to drop or swap certain users or modules if they remain unused for a specified period. It’s not a given in SAP’s contract, but raising this concern signals to SAP that you need some safety valve for overestimated usage.
• Future Technology Inclusion: SAP’s offerings will evolve over your contract term. You don’t want to be stuck with yesterday’s bundle if a new solution (say, a new AI-based module or analytics cloud service) comes out that you need. Ask for a technology refresh clause – an agreement that you can incorporate new SAP products or services into the contract at a pre-negotiated discount or under similar terms. This keeps your deal a bit more future-proof.
• Hyperscaler Flexibility: With RISE, SAP chooses or manages the cloud infrastructure (e.g., AWS, Azure) on your behalf. If a multi-cloud strategy is important, clarify if you can switch the underlying cloud provider or region. Perhaps you start on Azure but want to move to AWS – can that be done at renewal? It likely requires SAP’s involvement and could be complex, but if it matters to you, document how such a change could occur. You may also want assurances that if you have existing cloud commitments (credits with a provider), SAP can take those into account.

These clauses aim to inject flexibility into an otherwise rigid agreement. Use your negotiating leverage before signing because once you’re in a long-term contract, your ability to change terms is practically nil until renewal.

Companies have found that negotiating upfront, with the help of SAP licensing advisors or benchmarks from other deals, can secure concessions such as price protections and some flexibility to adjust, which are lifesavers later on.

It’s far better to have these options and not need them than to need them and be trapped without any contractual escape hatch.

Vendor Lock-In and Exit Considerations

Moving to RISE with SAP means entrusting SAP with not only your software licensing but also your production infrastructure and technical management.

This bundled model increases vendor lock-in risk in several ways:

• All-in-One Bundle: In a traditional model, you might separately negotiate your database, infrastructure, and support. For instance, you could run SAP on cheaper cloud hardware or switch your infrastructure provider if you find a better deal, and you could shop around for support (even third-party support for SAP) if SAP’s terms weren’t favorable. With RISE, all components are tied to SAP under one fee. You can’t just peel off the infrastructure portion or switch support providers – it’s a single-packaged service. Suppose you’re unhappy with any aspect (performance, support quality, or cost). In that case, your only real leverage is to escalate within SAP or, ultimately, to plan an exit from RISE entirely at the end of the contract.
• Switching Costs: Exiting a RISE contract at the end of the term can be costly and complex. Since you don’t own a S/4HANA license in RISE (it’s subscription-based), if you decide not to renew RISE but still need SAP, you would have to buy new licenses for an on-premises S/4HANA or another cloud arrangement. That could mean a large one-time cost in addition to years of paid subscriptions. Additionally, moving off RISE means migrating your systems – either by relocating your SAP workloads to a different infrastructure (which may require reimplementation or at least a migration project) or by migrating to a different ERP vendor (a significant undertaking). Essentially, leaving RISE isn’t just a matter of flipping a switch; it involves significant effort, data migration, and re-licensing. SAP is aware of this, which unfortunately strengthens their hand at renewal time – they know customers will be reluctant to incur the cost and disruption of switching, so SAP has less incentive to offer generous renewal discounts once you’re dependent on RISE.
• Loss of Flexibility in IT Strategy: By locking into SAP’s cloud, you may lose some flexibility to optimize. For example, if you have a strategic partnership or better pricing with a particular cloud provider, you can’t directly leverage it – you’re paying SAP’s rates embedded in RISE. If you wish to delay an upgrade for stability reasons, in RISE, you generally cannot (SAP controls the upgrade schedule in cloud editions). If you wanted to carve out a part of the SAP workload to handle differently (say, keep a dev/test system on cheaper hardware or pause usage of a module), those nuances are harder to accommodate under the one-size RISE contract. In short, RISE consolidates control with SAP, which has benefits (simplicity, having a single point of contact) but at the expense of your flexibility and negotiating leverage across your IT landscape.

Despite these concerns, many CIOs still choose RISE for its promised simplicity and faster deployment. The key is to go in with eyes open: treat it as a long-term partnership with SAP.

Ensure you have an exit strategy from day one – whether that’s a contractual clause about data extraction assistance or a plan that, if RISE doesn’t work out by 2027, you have budgeted to possibly purchase licenses or move elsewhere.

Being mindful of the lock-in risk will help you proactively mitigate it (for example, by not overly customizing within SAP’s cloud in ways that make it even harder to leave).

Comparison Snapshot: RISE vs. Traditional Contracts

The table below summarizes key differences in contractual flexibility between traditional SAP licensing and RISE with SAP:

Recommendations

• Assess Your Business Stability: If your user counts or business units fluctuate, be cautious with a long RISE term. Consider a shorter term or ensure the contract includes provisions for adjusting the scope in response to business changes.
• Negotiate Flexibility Upfront: Do not accept the standard RISE contract as-is. Negotiate key clauses – e.g., price increase caps at renewal, rights to reduce users or swap services, and protections if certain licenses remain unused. Get any promised flexibility in writing.
• Start with Conservative Commitments: For RISE deals, err on the side of committing slightly less and adding later. It’s easier to purchase more capacity later than to pay for excess you don’t use. Avoid overestimating user or cloud resource requirements in your initial contract.
• Plan an Exit Strategy: Even as you enter a RISE contract, plan for how you would transition after it ends. Ensure you have contract terms for data extraction and consider negotiating options to convert to on-premises licenses at the end of the term if needed. This prepares you in case you don’t want to renew on SAP’s terms.
• Benchmark Total Costs: Model the 5-10 year TCO for both RISE and traditional approaches. Include all factors (subscription fees + likely renewals vs. license + maintenance + infrastructure costs). Use these numbers to inform negotiations and ensure any promised savings are real for your situation.
• Leverage Third-Party Expertise: Engage SAP licensing experts or consultants to review contracts. They often know what flexibility other customers have obtained. This insight can strengthen your position when requesting similar terms or identifying potential red flags in the contract.
• Protect Against Lock-In: If you opt for RISE, mitigate lock-in by avoiding over-customization and retaining some skills in-house. Retain copies of configurations and data in formats you control. The more you treat SAP’s cloud as a black box, the harder it is to leave – so maintain transparency and internal know-how.
• Align Term with Strategy: Match the contract length to your confidence in SAP’s roadmap. If you anticipate significant changes (like a possible switch of ERP or a major re-org) in 3 years, don’t sign a 5-year deal without escape clauses. It’s better to renew a shorter deal than to be trapped in an overly long commitment.
• Monitor Usage vs. Contract: Continuously track your usage of SAP licenses and cloud services. If you’re in a RISE deal, perform internal “true-ups” quarterly to see if you’re on track or overpaying for unused capacity – this will inform your strategy at renewal (and you can address under-utilization internally by increasing adoption to get value for what you pay).
• Maintain Some Perpetual Footing (if feasible): Some large enterprises adopt a hybrid approach, keeping certain SAP components on-premises (with perpetual licenses) while using RISE for others. This allows for a level of flexibility and a fallback option if needed. While SAP’s goal is to transition everything to a cloud subscription, you may want to preserve key legacy licenses (and associated rights, such as perpetual use and third-party support) as a contingency.

FAQ

Q1: How long are RISE with SAP contracts, and can we negotiate a shorter term?
A1: Most RISE contracts are 3 to 5 years. You can negotiate the term length – a 3-year term offers more flexibility to reassess or change course sooner, whereas SAP may push for a 5-year term by dangling higher discounts. If you’re unsure about long-term needs or SAP’s performance as a provider, opting for a shorter initial term (or including a mid-term checkpoint and renewal option) is wise, even if it means a slightly higher annual price. Always balance the offered discount against the risk of being locked in longer than you’d like.

Q2: Can we reduce the number of users or SAP services in the middle of a RISE contract if our needs drop?
A2: Not under standard terms. Once you commit to a certain number of users (or services) in a RISE subscription, you are obligated to pay for that level for the entire term. You generally cannot scale down until the end of the contract period. The only exceptions would be if you negotiated specific provisions (e.g., a one-time reduction clause or an M&A adjustment) upfront. Otherwise, you must wait until renewal to attempt a reduction in licenses, and even at renewal, SAP may not allow a large decrease without some penalty or repricing. This is why it’s crucial to start with a realistic (even slightly conservative) user count in the contract.

Q3: Is it easier to add more SAP users in RISE compared to on-premise licensing?
A3: Yes, generally. Adding users in RISE is usually straightforward – you contact SAP to amend the contract, and additional users (or extra capacity) can be provisioned with an increase in subscription fees (often prorated for the remaining term). It’s administratively simpler since it’s all under one agreement, and the infrastructure scales as needed behind the scenes. In contrast, with on-premise, adding a large number of users means purchasing additional perpetual licenses (a separate negotiation and capital expense) and ensuring your hardware or cloud infrastructure can handle them. However, the flip side is that in RISE, those added users become part of your locked-in subscription – once added, you’re paying for them for the term. On-premise additions, you pay upfront, but you at least own those licenses thereafter.

Q4: What happens if we want to exit RISE with SAP after the term or if we decide not to renew?
A4: If you reach the end of your RISE contract and choose not to renew, your access to SAP software and services provided under RISE will be turned off. Because you don’t own the S/4HANA licenses in a subscription, you legally cannot use the system once the contract ends. Exiting RISE typically means having an alternative ready, either by migrating to a different ERP platform or negotiating a new arrangement with SAP. One option is to convert to on-premise licenses – in some cases, companies negotiate at the outset or during renewal the ability to apply some of their subscription fees toward a perpetual license purchase (allowing them to “keep” the software on-prem after a cloud subscription). However, this isn’t standard and would likely incur an additional cost. Essentially, to exit RISE, you must plan a significant project: extract your data, set up a new environment (which could be a new SAP on-prem system or another vendor’s system), and go live there. It’s a major consideration, so have a plan for it well before your term expires.

Q5: Does RISE with SAP allow us to stop paying for unused licenses (like we can stop maintenance on unused on-prem licenses)?
A5: No, not during the term. In an on-prem scenario, if you have unused licenses (e.g., after a layoff, you have 50 SAP user licenses not being used), you can give notice and drop those from your maintenance contract so you don’t pay annual support on them in the future. In RISE, since it’s a subscription, you’re paying for a service bundle that includes those user licenses for the duration. You can’t selectively drop users or stop paying for a portion of the subscription until the term is up. At best, you might negotiate at renewal time to adjust the number down; however, during the active subscription term, you’re paying for the full bundle, regardless of whether all users actively use it.

Q6: Can we still purchase new perpetual SAP licenses after signing a RISE contract?
A6: Generally, when you move to RISE, SAP intends that new needs are fulfilled via cloud subscriptions rather than perpetual licenses. SAP has been steering customers away from new on-premise licenses, and some RISE agreements even stipulate that you won’t expand on-premise usage. While, in theory, nothing prevents a company from purchasing a separate perpetual license for a different SAP product, SAP sales teams typically package additional requirements into the RISE subscription. Practically speaking, if you’re all-in with RISE, any net-new SAP software you need (say, a new SAP cloud module) will likely be added to your subscription rather than sold as a stand-alone perpetual license. It’s important to clarify this with SAP – if you have certain systems you intend to keep on-premise, ensure you maintain those licenses. However, for S/4HANA and related cloud services under RISE, we expect SAP to continue with the subscription model.

Q7: How can we avoid getting locked into high costs when it’s time to renew our RISE contract?
A7: The best time to avoid a painful renewal is before you sign the initial contract. Negotiate renewal terms upfront. Specifically, consider including a cap on price increases at renewal or a predefined renewal price. For example, negotiate something like “renewal in 3 years at no more than a 5% increase over current fees, assuming similar scope.” Also, negotiate the ability to adjust the scope (user count or services) at renewal without punitive fees. When renewal time arrives, always prepare by benchmarking alternatives – even if it’s tough to move off SAP. Come to the table with data on the costs of staying on-premises or moving to a competitor, to give SAP an incentive to offer a fair renewal price. Engage your executive sponsors as well: if the renewal quote is high, involve your CIO or CFO in communicating with SAP that you need a better deal or you will consider other options. Leverage whatever negotiation power you have at renewal, which is primarily whatever flexibility you negotiated initially, plus your willingness to explore other paths.

Q8: Are we able to swap or change components in our RISE subscription if our business needs to change (e.g., exchange one SAP cloud service for another)?
A8: Not by default. A standard RISE contract is quite rigid about the components and services you signed up for. If you later decide you don’t need one piece (say, you subscribed to SAP Analytics Cloud but aren’t using it, and instead,you want to use that budget for extra SAP BTP services), SAP isn’t obligated to let you swap those in the middle of the term. However, you can try to negotiate swap rights upfront. If you secured a swap clause, it may allow you to exchange one service for another of equal value (perhaps at renewal or a one-time mid-term swap). Without that clause, you’re essentially stuck with what you bought until renewal. At renewal time, you could then drop something and add another, but SAP may treat that like a new sale for the new component. Always discuss potential future needs with SAP when crafting the contract. For example, if you suspect you’ll eventually want SuccessFactors in the cloud, consider including the option to swap some S/4HANA capacity for SuccessFactors at a certain ratio. It never hurts to ask for flexibility, even if SAP doesn’t readily offer it.

Q9: What flexibility do we have in negotiating the pricing metric or structure of a RISE deal?
A9: SAP typically prices RISE based on Full User Equivalents (FUEs) or named users and possibly other metrics (such as document counts for Ariba), rolled into an annual fee. You may have some flexibility in proposing how the deal is structured. For example, you could negotiate a ramp-up model (start with a lower number of users/capacity and increase year over year as you implement more functionality, with pricing reflecting that ramp). This can prevent paying for full capacity on day one if you won’t use SAP fully until year 2 or 3. You can also negotiate how certain add-ons are measured – perhaps you prefer a pool of generic FUEs rather than fixed numbers for each user type for simpler management. While the metric (FUE) is standard, the breakdown and included volume can be tailored. Additionally, if you have unpredictable usage in some areas, you may consider negotiating a buffer (e.g., allowing 10% extra users temporarily without incurring immediate charges, settling quarterly).

Q10: Which model is better for unpredictable growth or changes in user count – RISE or traditional licensing?
A10: It depends on the nature of the unpredictability, but generally, traditional licensing offers more flexibility for downsides, while RISE is convenient for upsides. If you expect a lot of growth, RISE can be appealing because you can add users as you go, and you’re not making huge upfront investments for licenses you might need in the future – you pay as you grow. However, suppose your user count could also shrink or fluctuate downwards. In that case, the perpetual model is safer because you won’t be stuck paying for unused licenses (you can scale down your costs by dropping maintenance on any part you’re not using). Another factor is the timing of unpredictability. In a traditional model, you can buy licenses in increments as needed (though each purchase is a negotiation). In RISE, you commit to a block for a few years. If your growth occurs well after contracting, you might find that you under-committed and have to add (which is fine); however, if you over-committed, you will overpay. For highly volatile environments, some companies prefer not to put all their eggs in the subscription basket – they might maintain a core perpetual license and supplement it with cloud subscriptions for peak loads or new projects. Ultimately, if upward scalability is the main concern (and you’re confident you won’t need to reduce), RISE’s model works well. If downward flexibility is a concern, the traditional model (or a very carefully negotiated RISE deal with flexibility clauses) will serve you better.

Read about our SAP Advisory services for Rise.

Do you want to know more about our SAP Advisory Services?

Please enable JavaScript in your browser to complete this form.

Name *

First

Last

Email *

Company

Message *

Submit