Contractual Differences Between RISE with SAP and BYOL Models

Contractual Differences Between RISE with SAP and BYOL Models

SAP’s RISE offering fundamentally transforms how enterprises license and contract for SAP ERP.

Instead of buying perpetual software licenses and separately managing infrastructure and support (the traditional “bring your license” or BYOL model), RISE with SAP bundles software, cloud infrastructure, and support into one subscription contract.

This article examines the contractual changes between RISE and traditional licensing, highlighting financial implications, control trade-offs, and key considerations CIOs and CTOs should be aware of when negotiating these agreements.

Read Mapping Legacy SAP ERP Licenses to S/4HANA User Roles.

RISE vs. BYOL – A New Licensing Paradigm

RISE with SAP (introduced in 2021) is often described as “business transformation as a service.” It packages SAP S/4HANA (the latest ERP) with cloud hosting and support under a single contract and fee.

In a RISE deal, SAP provides the software as a subscription, provisions and manages the cloud infrastructure (through hyperscaler partners or SAP’s data centers), and includes standard support and maintenance.

SAP also bundles extras, such as limited SAP Business Technology Platform (BTP) credits and business network starter packages, to sweeten the deal.

The result is an all-in-one offering where SAP is your primary vendor for software and operations.

Bring Your Own License (BYOL), by contrast, refers to the traditional model: you purchase perpetual SAP licenses and then deploy them on the infrastructure of your choice (on-premises data centers or cloud platforms like AWS/Azure).

In BYOL scenarios, the enterprise owns the software license indefinitely and pays annual maintenance for support and updates.

Infrastructure and hosting are contracted separately (or handled in-house), and you are responsible for managing the environment or hiring partners to do so.

Essentially, BYOL means you carry your existing SAP licenses into whichever deployment model you prefer, retaining more direct control over how systems run.

Key difference: RISE shifts SAP software to a cloud subscription service, whereas BYOL maintains the classic ownership model.

This shift has wide-ranging contractual implications – from the structure of costs to the amount of flexibility and risk retained.

Read S/4HANA Digital Access Considerations for Indirect Use Compliance.

All-in-One Subscription vs. Perpetual Licensing

With RISE, licensing and ownership move from a perpetual model to a time-bound subscription.

Traditionally, buying SAP software meant a large upfront capital expenditure (CapEx) investment to own the license, after which you could use the software as long as you needed.

Under RISE’s OpEx model, there is no upfront license purchase – you pay an annual (or quarterly) subscription fee for the right to use S/4HANA during the contract term.

You do not own the software license; if the subscription ends, your usage rights will also end.

This is a fundamental contractual change: in a BYOL scenario, even if you stop paying maintenance, you still retain the license (you could continue running the software without support).

In RISE, stopping payments means losing access entirely – a true SaaS-like arrangement for core ERP.

What RISE includes:

The RISE subscription fee covers the S/4HANA software, standard support services, and the underlying cloud infrastructure needed to run it. SAP essentially becomes both the software vendor and the cloud service provider.

By contrast, in a BYOL model, you would have separate agreements: one with SAP for the software license and support and another with a data center or cloud provider for hosting. RISE rolls these into one package.

For example, instead of buying 1000 user licenses and then contracting with a cloud provider for servers, under RISE, you might simply contract for “120 Full Usage Equivalents” (a metric explained below), which already factors in users and comes with a certain size of cloud resources managed by SAP.

Perpetual vs. Subscription Rights: 

In a perpetual license model, companies have greater ownership certainty – they can run the software for decades if needed (albeit with limited support if they drop maintenance).

RISE’s subscription grants temporary usage rights aligned with the contract term (typically 3–5 years). SAP has also indicated that many new S/4HANA features will debut in the cloud editions.

In practice, this means that an ECC or on-premises S/4 customer often cannot access new capabilities without migrating to RISE or another cloud offering.

CIOs should recognize that RISE is not just a different payment plan – it is a different licensing regime, where SAP aims to continuously deliver innovation via cloud subscriptions, potentially leaving on-premise holders with older feature sets unless they transition.

Financial Implications: CAPEX vs. OPEX and TCO

One of the most immediate changes in RISE is the shift from a capital expenditure to an operating expenditure model.

Under traditional licensing, enterprises pay upfront for software (e.g., millions for an ERP license) and then about 20% of that price each year for maintenance.

They also invested in hardware or paid for cloud infrastructure separately. This created large spikes in spending (license purchase, hardware refresh cycles) followed by steady maintenance and infrastructure costs.

With RISE, those costs are blended into a uniform yearly subscription. There’s no big upfront license fee – instead, you commit to a regular subscription payment that includes software, hosting, and standard support.

For budgeting, RISE can be attractive, as it converts the ERP into a predictable service fee. CFOs may favor a smoother expense line and the avoidance of depreciating a large license asset. It can also expedite project approval since the initial outlay is lower.

From a cash-flow perspective, RISE often looks easier on year-one budgets.

However, long-term costs must be examined. A multi-year subscription, when summed over, say, 5 or 10 years, can equal or exceed the cost of a one-time purchase plus annual maintenance.

SAP often touts that RISE can reduce the total cost of ownership (TCO) by ~20% compared to an on-premises deployment.

This estimate typically assumes you would otherwise be spending significantly on infrastructure, upgrades, and high-cost operations. In reality, results vary widely:

• Suppose your current SAP environment is high-cost or due for an upgrade (e.g., aging hardware, expensive data center contracts, a large IT staff). In that case, RISE’s bundle might indeed save money by offloading those costs to SAP’s economies of scale.
• Suppose you already run a lean, optimized operation (e.g., low-cost cloud hosting, automated management, or minimal need for SAP support). In that case, you might find the RISE quote is higher than continuing with BYOL. Some companies report that initial RISE proposals come in at a higher cost than their current status quo, prompting negotiations.
• SAP incentives: SAP is highly motivated to encourage customers to migrate to RISE. They have offered incentives like credits or discounts – for example, crediting a portion of your existing maintenance or giving a one-time break that effectively lowers first-year costs – to make the TCO comparison favorable. Such incentives can tip the scales, but they are often time-limited or contingent upon signing a longer contract.

TCO modeling:

CIOS must conduct a multi-year TCO analysis comparing RISE to BYOL. Consider 5-year or 10-year horizons. Factor in all costs, including software fees, support, infrastructure, personnel, and even intangibles such as downtime risk and agility benefits.

In some scenarios, RISE might show savings (especially if you avoided infrastructure investments). In other cases, owning the license and using a cloud platform directly could be cheaper.

Don’t assume that a subscription always costs less – it often shifts costs around. The cumulative subscription fees over many years could end up higher, especially if your usage grows.

Accounting impact:

Additionally, note the accounting difference – RISE fees are OpEx (which some companies prefer for flexibility), whereas a perpetual license could be considered CapEx (an asset on the balance sheet). Depending on financial strategy, this could influence preferences for one model over the other.

Contract Duration, Renewals, and Lock-In

The contractual commitment in RISE differs significantly from traditional licensing.

In a BYOL model, your software license never expires. You typically renew maintenance annually, but you are not forced to keep paying to use the software.

If budgets tighten, you could even drop maintenance for a while (albeit at the cost of support and updates) and still run the system.

You also have the freedom to switch infrastructure providers or support vendors if needed since those are separate components.

RISE contracts, on the other hand, are fixed-term subscription agreements – commonly 3, 5, or even 7-year commitments. During that term, you are locked into paying for the subscription whether you use it fully or not.

Early termination is generally not permitted without hefty penalties (essentially, you’d owe the remaining contract value). This means less flexibility if business priorities change mid-term.

For example, suppose a merger or divestiture reduces your need for SAP.

In that case, you still must fulfill the RISE contract for its duration (though negotiating a mid-term down-scaling might be possible in some cases, it’s not standard).

Renewal time:

At the end of a RISE term, you must renew (or transition off) to keep using SAP. This gives SAP significant leverage – if you have fully migrated to RISE, you either accept the renewal pricing or face losing your core system.

In contrast, a traditional license holder could choose not to renew maintenance and still have a running system (albeit frozen in-state) as a fallback. Negotiating renewal caps in the initial RISE contract is critical.

CIOs should strive to include clauses that limit the increase in subscription price at renewal time (e.g., capping it to a percentage or tying it to a benchmark).

Without such protection, there’s a risk of a steep price hike after the initial term, when switching away is difficult.

Vendor lock-in considerations:

RISE effectively bundles you into SAP’s ecosystem, not just technically but contractually.

If the service under-delivers, your options are limited until the end of the term. You cannot, for example, move your production environment to another cloud on a whim – the SAP-managed infrastructure is a key component of the deal.

This one-throat-to-choke approach simplifies accountability (no finger-pointing between SAP and your cloud provider), but it also means reduced negotiating leverage during the term.

You’ve surrendered some control and must rely on the contract SLAs and SAP’s responsiveness to ensure service quality.

Exit strategy:

Given the lack of perpetual rights with RISE, enterprises should plan an exit strategy upfront. Ask questions like: If we choose not to renew RISE after 5 years, what then?

Since you won’t have an on-prem license for S/4HANA (unless you kept your old ones in parallel, which would be outdated by then), you might have to negotiate a new deal to continue running SAP – either another subscription or buy licenses anew.

In some cases, SAP may allow a conversion of the subscription into a traditional license at the contract end (for a fee), but this isn’t guaranteed.

It’s wise to at least document internally what a reversion would entail (e.g., the cost to re-license S/4HANA on-prem for your user count) so you understand the stakes at renewal time.

Also, ensure the contract grants you the right to retrieve your data and customizations from SAP’s cloud in a usable format at the end of the term – that way if you need to transition to another solution or revert to on-premises, you can.

Operational Control: Infrastructure, Updates, and Customizations

Moving to RISE also means changing how you manage your SAP environment on a day-to-day basis.

In a BYOL scenario, you (or your chosen partners) are responsible for system administration, including deploying servers, applying patches, tuning performance, scheduling upgrades, and other related tasks.

With RISE, much of that responsibility shifts to SAP and is governed by the contract.

Infrastructure & SLAs:

Under RISE, SAP provides the infrastructure as part of the service. This means you no longer sign a contract with (for example) AWS or Azure – SAP does it on your behalf and abstracts it in your subscription fee.

SAP’s contract will include Service Level Agreements (SLAs) for uptime (commonly around 99.7% uptime for production) and possibly other aspects like disaster recovery.

For CIOs, this is a double-edged sword: you get a formal uptime commitment and one party accountable if things go wrong (SAP), but you also relinquish direct control over infrastructure decisions.

Do you need to scale up the system, add capacity, or change regions? – Those actions must go through SAP’s contract terms (often only feasible at renewal or via contract change requests).

By contrast, if you manage your environment in a BYOL model, you could scale your cloud resources or switch providers on your terms as needed.

Support model: In RISE, support and maintenance are bundled in – you cannot opt out of SAP support to save money nor choose a third-party support provider for a discount.

The upside is that SAP’s support is integrated (and you should get all updates as part of the service); the downside is a loss of flexibility.

Some large enterprises in the traditional model save costs by using third-party support (such as Rimini Street) or by dropping maintenance on stable systems; however, these tactics aren’t possible with RISE.

You’ll be on SAP’s standard support (or premium support if negotiated) throughout. Ensure the support SLAs (response times, etc.) in the contract meet your operational needs, as you will be relying on SAP’s responsiveness for both application and infrastructure issues.

Customizations and upgrades:

Technically, RISE with SAP comes in two flavors: a public cloud (multi-tenant S/4HANA Cloud) and a private cloud edition (single-tenant, essentially your instance managed by SAP).

The public cloud version is more restrictive – it’s standardized SaaS, which means very limited customization and quarterly automatic upgrades pushed by SAP.

Many large enterprises opt for the private cloud edition under RISE, allowing them to carry over their existing custom ABAP code and more tailored processes.

In the private RISE model, you can still customize SAP like you did on-premise and even control when major version upgrades occur (to an extent).

SAP will handle routine patching and minor updates, but you’ll coordinate with them on big upgrades, and you’re responsible for testing your custom code against new releases.

Key difference:

In a BYOL scenario, you have full control over when to upgrade (you can decide to stay on a given version for years if it isn’t broken, although you may fall out of support after a point).

Under RISE, especially if using the public cloud or even in the private edition, there is a cadence of updates you’ll need to accept to stay within SAP’s support umbrella.

SAP’s roadmap is cloud-first, meaning RISE customers often receive new features continuously, while on-premises customers must initiate their upgrades to catch up.

CIOs should weigh this: RISE can keep you more current with less effort, but it imposes a discipline of regular updates (and possibly constraints on heavy modifications if you choose the public cloud).

Companies that highly value control might prefer BYOL to dictate their upgrade timelines; companies that value having the latest functionality (and less upgrade project burden on internal teams) might lean toward RISE.

User Licensing Metrics: FUE vs. Named Users

Another important contractual change is how user licensing is counted.

Historically, SAP perpetual licensing involved Named User licenses in various categories (Professional, Limited Professional, Employee Self-Service, etc.), each with different price points.

You had to buy enough of each type and remain compliant by not exceeding those counts.

It was complex and often inflexible – if you misjudged the number of a certain user type needed, you might end up with shelfware or shortages.

RISE simplifies this with a unified metric called Full Usage Equivalent (FUE).

Instead of micromanaging user categories, you contract for a total number of FUEs, and all user types consume some fraction of an FUE. For example, a heavy power user might be considered 1.0 FUE, a light user might be 0.1 FUE, and so on.

You don’t purchase “Professional” vs “Limited” users separately; you just ensure your total usage (in FUEs) stays within the contracted amount.

This model is more flexible – as your user mix changes, you can allocate FUEs as needed without buying new licenses for a different category.

It also typically covers indirect access more straightforwardly (SAP often bundles some document access in the FUE metric, reducing the separate “indirect use” license issues that plagued on-prem contracts).

For CIOs, the FUE model means license negotiations focus on total capacity rather than individual license types. It’s essential to accurately analyze and map your current users to FUE equivalents.

If you over-estimate and over-subscribe FUEs, you’ll pay for unused capacity; if you under-estimate, you might face adding more FUEs mid-term at potentially higher rates.

In the end, while FUE is a different metric, it aligns with RISE’s theme of simplicity (and locks all your users into one subscription pool).

By contrast, BYOL licensing means continuing with named user counts and the possibility of true-ups if you outgrow your licenses, as well as compliance audits if indirect use isn’t properly licensed.

Each approach has its nuances, but be aware that moving to RISE likely means converting your existing user licenses into this FUE construct as part of the deal.

Summary Comparison Table: RISE vs. Traditional BYOL Contracts

To recap the key contractual differences, the table below outlines how RISE with SAP compares to a traditional perpetual license model across major dimensions:

Both approaches have pros and cons. RISE offers simplicity, a faster path to cloud value, and offloads a lot of technical heavy lifting to SAP.

Traditional BYOL offers maximum control, potentially lower cost for well-run IT shops, and independence from SAP’s pace.

Neither is inherently “better” for every situation; the right choice depends on the organization’s priorities, existing investments, risk tolerance, and strategic roadmap.

Recommendations

When weighing RISE vs. BYOL or negotiating a RISE contract, CIOs and CTOs should consider the following advice:

• Perform a Detailed TCO Analysis: Model out all costs of staying on traditional licensing vs moving to RISE over a 5-10-year period. Include software fees, infrastructure, personnel, upgrade projects, etc. Use this analysis to drive negotiations – don’t just take SAP’s word for cost savings; verify it with your data.
• Align with Business Strategy and Needs: Decide based on your company’s direction. If you have a cloud-first mandate and need rapid innovation, RISE aligns well. If you require full control due to regulatory reasons or have custom processes that you’re not yet ready to standardize, BYOL might be a better fit. Involve business stakeholders to see which model supports their objectives and risk appetite.
• Leverage SAP’s Incentives: SAP is eager to transition customers to cloud subscriptions – use that as leverage. Engage multiple options (including staying on-premises or using hyperscalers with Bring Your Own License or BYOL) to encourage SAP’s best offer. Ask about incentives like migration credits, discounted first-year fees, or bundling deals if you’re also considering other SAP products. Make SAP compete for your business.
• Negotiate Contract Safeguards: If pursuing RISE, negotiate key terms upfront to ensure a favorable outcome. Examples: cap annual price increases and renewal rates, secure the right to adjust your user counts (FUEs) downward if usage drops, and include clear exit provisions (such as data extraction, assistance, and potential conversion to an on-premises license if possible). These clauses can save millions or prevent future headaches.
• Phase Your Transition (if possible): You don’t have to go “all-in” at once. Consider a phased move to RISE – maybe start with a smaller landscape or a non-mission-critical system as a pilot. Negotiate so you only start paying for parts of RISE when they’re actually in use (e.g., don’t pay a full production subscription until your production system is live). Phasing can reduce risk and allow for learning before a major cutover.
• Assess Internal Capabilities: Look at your IT team and partner ecosystem. If you have strong SAP basis and cloud engineers, you might handle BYOL on the cloud efficiently. If not, RISE could fill a skills gap by offloading tasks to SAP. Also, consider if a third-party provider could offer similar managed cloud services – sometimes partners can run SAP in the cloud with comparable benefits to RISE. Compare these options to ensure you choose the model that your team can support.
• Plan for the Long Term: Regardless of the route you choose, maintain flexibility. If you choose RISE now, keep an eye on an exit strategy for the future (e.g., what if, in 5 years, you want to bring it back in-house or switch to another SaaS?). If you stay on-prem now, keep your system modern and cloud-ready (so a future move to cloud is easier if needed). Avoid contractual clauses that restrict your future choices, such as prohibitions on switching deployment models.
• Focus on Change Management: Adopting RISE (especially a SaaS-like model) isn’t just a technical shift; it’s an operational change. Prepare your organization for more frequent updates, a new support process (logging tickets with SAP), and potentially reduced hands-on control for your administrators. Invest in training and change management so your IT staff and end-users adapt smoothly to the new model. This will help you realize the benefits of RISE faster.
• Monitor Value Delivery: If you go with RISE, establish KPIs and governance to track whether it’s delivering as promised. Are you getting the uptime and performance stated? Are costs staying within budget? Are new features being adopted by the business? Regularly review these. If issues arise, engage SAP early – as part of RISE, you should have customer success or account managers who can help address service concerns. Holding SAP accountable through the contract and relationship will ensure you maximize the value of the subscription.

Read Budgeting for SAP S/4HANA License Transition Without Surprises.

FAQ

Q1: What’s the primary difference between RISE with SAP and a traditional SAP license (BYOL)?
A1: The primary difference is in the licensing and service model. RISE with SAP is a subscription service – you pay an annual fee that bundles the S/4HANA software license, cloud infrastructure, and SAP support into one contract (SAP essentially operates your ERP for you). In a traditional BYOL model, you buy a perpetual license for the software (own it outright) and separately manage hosting and support. RISE is like renting the ERP as a service, while BYOL is like owning the software and handling the logistics yourself. This leads to differences in cost structure, contract terms, and the level of control vs. convenience you have.

Q2: How does moving to RISE affect my existing SAP licenses and contracts?
A2: If you’re an existing SAP customer with perpetual licenses (for ECC or S/4HANA), transitioning to RISE typically means those licenses become unused (you won’t be using your on-prem license when the same software is provided under subscription). SAP often offers credit for this – for example, they might offset some of your RISE subscription cost, recognizing past investments. Contractually, you’ll sign a new cloud subscription agreement (SAP’s Cloud contract) and likely terminate or sunset your old license maintenance agreements. It’s important to negotiate how your investment is recognized: ask for migration credits or reduced fees based on the licenses you already paid for. Also, clarify if you retain any rights to revert to those perpetual licenses if the RISE contract ends (in many cases, once you move to RISE, the old contract is gone, so you’d have to negotiate anew to go back).

Q3: Which is more cost-effective in the long run – staying with perpetual licenses (BYOL) or switching to RISE?
A3: It depends on your situation. RISE can be cost-effective if you would otherwise incur high costs for infrastructure upgrades, staffing, and frequent updates – SAP’s bundle might drive efficiencies in these areas. SAP often pitches RISE as lowering TCO by around 20%, including those factors. However, if you already operate SAP at a low cost (perhaps you have a cheap cloud contract and minimal support costs), RISE might initially appear more expensive. The best approach is to do a detailed cost comparison over several years. Include all relevant costs for BYOL (hardware or cloud fees, IT personnel, maintenance fees, downtime risks) and compare to the RISE subscription quote over the same period. Also, consider intangible benefits (speed, innovation) as part of value. Many firms find that, after negotiation, RISE can be made financially attractive; however, you should never assume it’s automatically cheaper – verify with numbers and drive the price discussion accordingly.

Q4: What key contract terms should we watch out for or negotiate in a RISE with SAP agreement?
A4: Some of the most important terms to focus on are: Contract length and renewal terms (avoid an overly long initial term unless you get great pricing; ensure there are provisions about renewal notice and reasonable price increase caps at renewal), price protection (negotiate caps on any annual price escalators and especially the renewal price – you don’t want a giant surprise increase after year 5), volume flexibility (if you commit to a certain number of users/FUEs, try to include rights to reduce or adjust if your needs drop or grow, such as a grace to true-down at renewal or pre-agreed pricing for additional FUEs if you need more), exit clauses (make sure you have clarity on data extraction, and try to get an option – even if informal – on what happens if you don’t renew, such as an option to purchase a license to continue running or assistance migrating out), and service performance SLAs (ensure the uptime, support response, and disaster recovery terms meet your requirements; negotiate remedies like service credits or even termination rights if SAP fails to meet critical SLA targets consistently). Essentially, ensure the contract has both flexibility and protection because once you’re in RISE, you’re relying on that contract for everything.

Q5: Can we switch back to on-prem or leave RISE if we change our mind after a few years?
A5: Moving out of RISE is not trivial – there is no automatic “switch back” clause in most cases. If you terminate RISE (after fulfilling the term), you will no longer have the right to run S/4HANA unless you procure new licenses or keep an older system. Some companies negotiate an option to obtain a perpetual license at the end of the term, but this isn’t standard and would likely incur additional costs. Practically, if you leave RISE, you’d have to either strike a new deal with SAP (perhaps another subscription or purchase licenses outright) or migrate to a different solution. That’s why it’s critical to go in with an exit strategy: ensure you can retrieve your data and any custom developments from SAP’s cloud and keep track of what it would take (in terms of time and money) to set up an alternative. In short, you should treat RISE as a long-term commitment – you can change course at renewal time, but it requires planning, so you’re not caught without an ERP. Always discuss contingencies with SAP and internally before signing so you are aware of your options.

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