CIO Playbook: RISE with SAP vs Traditional On-Premise SAP Licensing

RISE with SAP vs Traditional On-Premise SAP Licensing

Global enterprises running SAP are at a crossroads as they plan their IT and ERP strategy for the coming years.

With SAP’s push towards cloud-based solutions, CIOs and procurement leaders must evaluate whether to embrace RISE with SAP – an all-in-one cloud subscription offering – or continue traditional on-premise SAP licensing (possibly running on hyperscaler infrastructure).

This playbook compares RISE with SAP versus on-premise SAP licensing models, helping C-level IT and finance executives navigate critical cost structure, flexibility, risk, and value differences.

Key topics include what RISE entails, financial implications (CAPEX vs. OPEX), licensing models, deployment options (public vs. private cloud), differences between included services and customer responsibilities, contract and negotiation considerations, and recommendations for decision-makers.

💡 Make Smarter Licensing, Contract, and Cloud Decisions with Confidence

• Avoid overpaying for user licenses and cloud capacity by learning to right-size your SAP RISE subscription.
• Understand the true financial trade-offs: subscription fees vs. perpetual license value, infrastructure bundling, and support scope.
• Gain visibility into hidden costs often overlooked, from indirect access to BTP overages and contract renewal uplifts.
• Discover how mid-size companies have negotiated better deals, secured future flexibility, and maintained control post-transition.
• Free up IT and procurement capacity by simplifying contract management — without locking your organization into restrictive long-term terms.

Download CIO & Procurement Playbook: Transitioning to SAP RISE with S/4HANA

What is RISE with SAP?

RISE with SAP (often described by SAP as “business transformation as a service”) is a comprehensive subscription bundle designed to simplify the move to SAP S/4HANA in the cloud.

Introduced in 2021, RISE with SAP consolidates several components into a single contract and fee:

• SAP S/4HANA Cloud – The core ERP software provided on a cloud basis. Depending on the customer’s choice, this can be the public cloud edition (multi-tenant SaaS) or the private cloud edition (single-tenant managed instance) of S/4HANA.
• Infrastructure (IaaS) – Cloud infrastructure to run S/4HANA is included. SAP provisions and manages the underlying infrastructure through its chosen hyperscaler partners (e.g., AWS, Azure, Google Cloud) or SAP’s data centers. Customers no longer need to purchase or maintain hardware or separate cloud hosting contracts.
• SAP Software Support & Upgrades – RISE includes SAP’s support services and system maintenance. Software updates, patches, and new version upgrades for S/4HANA are handled as part of the subscription, with defined service-level agreements (SLAs) for system availability.
• Business Transformation Tools – RISE provides tools and services to help migrate and optimize business processes. For example, it includes SAP Business Process Intelligence (built on Signavio) to analyze and improve processes and access to the SAP Business Network Starter Pack, which provides connectivity to SAP’s cloud-based trading networks, such as Ariba and the Asset Intelligence Network. It also credits the SAP Business Technology Platform (BTP), allowing customers to build extensions, integrations, or analytics on SAP’s platform without a separate license.
• One Hand to Shake—Perhaps most importantly, RISE offers a single contract and accountable vendor. SAP acts as the primary provider for the entire stack, including applications and infrastructure, which can simplify vendor management. The goal is to de-risk the transition by providing a bundled offering where SAP is responsible for hosting and maintaining the system.

In essence, RISE with SAP shifts the enterprise from a traditional model of buying software licenses and running them on self-managed infrastructure to an all-in-one cloud subscription.

SAP positions RISE as an accelerator for digital transformation, promising faster time to value through the use of ready-to-run cloud services and best practices.

It is particularly marketed to existing SAP ERP (ECC) customers as a way to transition to S/4HANA without the complexity of managing infrastructure or multiple vendors.

Read SAP RISE Negotiations: A Guide for CIO and Procurement.

CAPEX vs. OPEX: Financial Implications

One of the fundamental changes with RISE is the shift from capital expenditure (CAPEX) to operational expenditure (OPEX) in how SAP software is paid for:

• Traditional On-Premise Licensing (CAPEX Model): Enterprises historically purchased perpetual licenses for SAP software modules and user seats. These licenses often involved a significant upfront cost that could be capitalized on the balance sheet. Customers also paid annual maintenance (typically ~20–22% of the license price) as an ongoing expense, providing support and updates. Running SAP on-premises also required capital investment in servers, storage, networking, and data center facilities (or long-term hosting contracts) and periodic hardware refresh cycles.
• RISE with SAP Subscription (OPEX Model): RISE has no large upfront license fee. Instead, customers pay a recurring subscription fee (usually annual, based on a multi-year contract) that covers software usage, support, and infrastructure. This turns the ERP system cost into a regular operating expense. The need for capital investment in hardware is eliminated – infrastructure is included as part of the service. From a budgeting perspective, costs become more predictable and spread over time rather than spiking upfront.

Accounting and Budget Considerations:

The OPEX model can be attractive for CIOs and CFOs who prefer to avoid large capital outlays and keep costs tied to usage. Since the expense aligns with the benefit period, justifying the project can be simplified.

However, it’s essential to consider the long-term cost: a subscription, by nature, continues indefinitely, and over several years, the cumulative subscription fees may equal or exceed the one-time purchase cost plus maintenance costs.

In other words, RISE can improve cash flow and flexibility, but enterprises should model the total cost of ownership (TCO) over a 5—to 10-year period. SAP has advertised that RISE can reduce TCO by up to ~20% compared to on-premise S/4HANA deployments (when factoring in infrastructure, upgrades, and operations). Still, actual outcomes will depend on the discounts negotiated and the efficiency of current operations.

Another financial implication is converting existing investments.

Many large SAP customers have sunk costs in perpetual licenses and infrastructure:

• When moving to RISE, existing S/4HANA or ECC licenses are typically transitioned to a subscription. SAP may offer credits or incentives for this conversion. For example, SAP has provided credits equivalent to a portion of the first-year RISE fees to customers who already own S/4HANA on-premises and decide to switch to RISE. These incentives can help offset cloud migration costs, providing financial relief as you move away from old licenses.
• On the other hand, if an enterprise recently invested in hardware or a hyperscaler contract, switching to RISE might make those assets redundant. CIOs should weigh the remaining value of current infrastructure and whether a phased depreciation or use-out of assets is preferable before committing fully to RISE.

In summary, RISE’s OPEX model offers a lower upfront cost and bundled infrastructure, which can accelerate projects and simplify approvals. However, careful analysis is needed to ensure it delivers long-term cost benefits.

The subscription model also places more cost risk on the vendor; SAP is motivated to keep the system efficient and up to date. In contrast, on-premise models require the customer to manage the costs of upgrades and operations internally.

Licensing Model: Full Usage Equivalents (FUE) vs Named Users

A key difference between RISE with SAP and traditional licensing is how user access is licensed. Historically, SAP on-premise software has been licensed by Named Users and sometimes by additional metrics, such as processing capacity or transactions for certain engines.

This meant that customers had to purchase specific types of user licenses (e.g., Professional User, Limited Professional, Employee Self-Service user) in specified quantities, and license compliance was tied to the number of individuals assigned to those roles.

RISE with SAP introduces a new unified metric called Full Usage Equivalents (FUE).

The FUE model essentially abstracts user licensing into a single currency. Instead of buying a fixed count of each user type, the customer contracts for several FUEs that can cover all types of users.

Each user is counted as a fraction of an FUE based on their usage level:

• An “Advanced Use” user (equivalent to a traditional professional user with broad SAP access) = 1.0 FUE.
• A “Core Use” user (with access limited to certain modules or standard transactions) = 0.2 FUE (5 such users equal 1 FUE).
• A “Self-Service Use” user (very limited usage, e.g., occasional or ESS scenarios) = ~0.033 FUE (30 such users per 1 FUE).
• A “Developer Access” user (for development and system technical roles) might count as 2.0 FUE, since they have deep system access.

In practice, SAP provides a conversion table defining how many of each user type equate to 1 FUE. The enterprise estimates its user counts in each category, and the total is summed into a single FUE number. For example, an organization with 100 heavy users, 200 moderate users, and 300 occasional users might calculate a total need for 120 FUEs to cover everyone.

The RISE subscription is then priced per FUE. During the subscription term, the customer can flexibly assign those FUEs to actual users in any mix of roles without having to re-negotiate the license types – the only constraint is the total FUE count.

Benefits of the FUE Model:

• Simplicity: It simplifies license management by avoiding the need for granular tracking of the number of each user type in use. You are compliant as long as you stay within your total purchased FUEs.
• Flexibility: If your usage pattern changes (e.g., you automate some tasks and reduce the number of heavy users while increasing occasional users, or vice versa), you can reallocate your user licenses internally without buying new licenses. This can prevent “shelfware” and unused license types.
• Transparency: FUE provides a more transparent usage metric for negotiations. Tying cost to total usage is clearer than juggling multiple user categories. It also typically bundles in digital access (indirect use) – meaning interactions from non-SAP systems via APIs or other interfaces are licensed through the FUE metric or an included document allowance, rather than requiring separate “indirect user” licenses.

Traditional Named User Licensing (On-Premise):

• Enterprises would purchase a certain number of each category of users (e.g., 500 Professional Users, 100 Limited Professional Users, etc.) based on anticipated needs. If those needs changed, rebalancing licenses or additional purchases often required. This model could be inflexible—for instance, if you under-provisioned one category and over-provisioned another, reallocation might not be straightforward without engaging SAP.
• Indirect access under traditional licensing was a notorious pain point. If third-party applications or external users accessed SAP data, those interactions needed to be covered by some license (either named user licenses for those users or the newer “Digital Access” document-based licenses). Many customers faced compliance risks or additional costs due to these scenarios.

The FUE model in RISE can be seen as SAP’s answer to these challenges by aggregating usage in a single metric. For CIOs, license discussions shift from micromanaging user types to negotiating the organization’s total volume (FUEs).

It’s still crucial to thoroughly analyze current SAP usage to accurately estimate FUE needs – for example, using tools to translate existing named user licenses into FUEs. Overestimating FUEs could lock you into a higher subscription cost than necessary, while underestimating could lead to adding more FUEs and incurring additional costs in the long term.

It’s worth noting that FUE licensing is specific to the digital core (SAP S/4HANA) in the RISE bundle. If added, other SAP cloud products, such as SuccessFactors and Ariba, remain licensed in their own ways. However, for the S/4HANA environment, FUE provides a unified licensing approach.

In summary, RISE’s FUE model offers more flexibility and simplicity than the traditional named-user model, although it requires careful upfront mapping. CIOs should fully understand how their users map to FUEs and leverage that flexibility.

Also, since FUEs are an unfamiliar metric, enterprises should request transparency from SAP on how usage is measured and reported over time to avoid surprises.

Public Cloud vs Private Cloud: Deployment Options in RISE

SAP offers RISE with SAP in two main flavors of S/4HANA Cloud deployment – Public Cloud and Private Cloud.

Both are under the RISE umbrella (subscription, SAP-managed) but differ significantly in architecture, flexibility, and cost. It’s crucial to choose the right edition based on an organization’s requirements:

S/4HANA Public Cloud (RISE) is a multi-tenant SaaS offering in which your S/4HANA instance runs in a shared environment with other customers.

Key characteristics:

• Standardization: Public Cloud edition is built on SAP’s “clean core” principle. It comes with pre-configured best practice processes. Customers are expected to adopt industry-standard processes with limited customization. Classic ABAP modifications or deep custom code are not allowed. Instead, extensions must be done via SAP BTP side-by-side or using the provided in-app extensibility and APIs. This ensures the system remains standardized for smooth upgrades.
• Continuous Updates: SAP releases updates regularly, such as quarterly. All customers on the public cloud are updated on the same schedule, which means you continuously get new features and improvements. There is little ability to delay upgrades, which is good for innovation, but it requires the business to be ready for a faster pace of change and testing.
• Lower Cost: Resources and software are shared and standardized, so the public cloud edition generally costs less per FUE. It’s optimized for cost-efficiency and scalability. Unlike private editions, SAP can offer a lower subscription price (per user or FUE). This can make the public cloud attractive for cost-conscious deployments that fit the standard functionality.
• Scope and Limitations: Historically, the public cloud version of S/4HANA has had some functional gaps compared to the full on-premise S/4HANA, especially in niche industry processes or advanced configurations. SAP has closed many gaps, but some industry-specific solutions or complex scenarios might not be fully supported. The public cloud is ideal for organizations operating with SAP’s standard best practices or implementing a “greenfield” (new) S/4HANA system without needing legacy customizations. It’s also often chosen for a “two-tier ERP” strategy (e.g., headquarters on a private cloud or on-prem, smaller subsidiaries on public cloud with standard processes).

S/4HANA Private Cloud (RISE) – Often referred to as “SAP S/4HANA Cloud, private edition,” essentially a single-tenant deployment of S/4HANA dedicated to the customer, hosted and managed by SAP in the cloud.

Key characteristics:

• Full SAP Functionality: The private edition uses the same codebase as the traditional on-premises S/4HANA. This means it includes the full range of modules and industry solutions and allows the use of existing customizations. Customers can carry over ABAP custom code and even install certain SAP add-ons or integrated third-party solutions, much like in an on-premises environment. This makes the private cloud suitable for enterprises with complex, tailored SAP environments that they want to bring to the cloud.
• Customization Flexibility: Unlike the public edition, in a private cloud, you can make modifications and conduct extensive custom development. SAP still cautions against making core modifications (to ease future upgrades), but the option is available for situations where you truly need to tailor the system. It’s your instance of S/4HANA, so you can configure it as you would on-premise (including setting your own client-specific ABAP code, custom tables, etc.).
• Managed Upgrades (Customer Influence): SAP will still handle the technical upgrade in a private cloud scenario, but the timing can be aligned with the customer. Typically, you must stay within a certain timeframe after the latest release; for example, you may be required to upgrade at least once every one to two years to remain supported. Still, you have more control over scheduling than the public cloud’s fixed schedule. This gives companies time to test and adjust when new versions roll out.
• Higher Cost: This edition provides a dedicated environment (with potentially dedicated compute resources and more hands-on management for customizations). Subscription fees per FUE for the private edition can be noticeably higher (for instance, some benchmark pricing shows a roughly 15–20% premium for private vs. public). The cost difference depends on the scale (user count and system size) and negotiated terms. Still, enterprises should anticipate a higher price tag to gain the flexibility of a single-tenant setup.
• Cloud Provider Choice: In the private edition, SAP can deploy your system on a hyperscaler of your choice (such as Azure, AWS, or Google Cloud) or their infrastructure. As part of RISE, you can often select the preferred cloud provider or region to meet compliance or performance needs. By contrast, the public cloud edition is a SaaS service where the infrastructure is abstracted (SAP decides the hosting environment, and you don’t directly interface with the cloud infrastructure).

Trade-offs: Choosing public vs private edition involves balancing cost, flexibility, and time-to-value:

• If your organization can align with standard processes and wants the lowest total cost of ownership (TCO) and fastest deployment, the public cloud edition is a compelling option. It enforces discipline in standard SAP functionality and allows quicker implementation with SAP’s model company configurations.
• If your business needs customization or migrates a heavily tailored ECC system, the private edition may be the only viable option under RISE. It lets you bring much of your existing complexity along, albeit with the opportunity to simplify.
• Many large enterprises initially opt for RISE Private Edition to ensure that nothing breaks during their transition to S/4HANA. They plan to gradually adopt more standard processes and potentially move to the public cloud in the future as the product and their processes mature.
• Both editions can scale to high workloads in terms of performance and scalability. Still, the approach differs: the public cloud can instantly leverage the elasticity of the SaaS environment (within the bounds of multi-tenant limits), whereas the private edition can be sized (and resized) to the customer’s needs but may involve provisioning dedicated hardware if capacity needs grow.

The table below summarizes some key differences between RISE Public and Private cloud options:

What RISE Includes vs. What Remains the Customer’s Responsibility

Moving to RISE with SAP does not mean SAP takes over everything related to your ERP landscape. It’s important to delineate which tasks and components are covered by the RISE subscription and which still fall to the customer (and their implementation partners or integrators):

Included in RISE Subscription (SAP’s responsibility):

• S/4HANA Software Licenses & Support: The rights to use SAP S/4HANA (and any bundled cloud services) and equivalent SAP Enterprise Support are included. This means SAP will handle standard support tickets, patches, and bug fixes in the software.
• Technical Infrastructure & Basis Operations: SAP (and its infrastructure providers) manage the servers, storage, networking, and basis-level administration of the system. SAP’s team handles tasks such as system provisioning, installation, backup, monitoring, and applying OS and DB patches. In essence, SAP’s duty under RISE is to ” keep the lights on” for the S/4HANA system day in and day out.
• Software Updates and Upgrades: As mentioned, SAP will apply S/4HANA upgrades, with customer input on the timing for the private edition. This relieves the customer from having to plan and execute major version upgrades or install support packs themselves; it’s part of the subscription service to keep the system up to date.
• SAP BTP and Other Cloud Services (Limited): RISE often comes with a certain amount of SAP BTP consumption credit (Cloud Platform Enterprise Agreement credits), which can be used for integration, extension, or analytics scenarios on SAP BTP. Tools like SAP Build Process Automation and SAP Work Zone services might also be included to enable building workflows and a modern user experience. The Signavio process analysis tools are typically included (at least as a starter package) to help model and monitor business processes. These included services add value on top of the ERP, without separate licenses.
• SAP Business Network Starter Pack: Customers gain access to limited-use editions of SAP’s business networks, including Ariba Network, Logistics Business Network, and Asset Intelligence Network. This is intended to jump-start collaboration with trading partners; however, full use may require separate arrangements once the included transactions are exhausted.
• SLA for Availability and Performance: The RISE contract includes Service Level Agreements — a standard uptime commitment, typically around 99.7% availability for production environments. If SAP fails to meet these SLA targets, the customer may be entitled to service credits or other remedies as defined in the contract. This formalizes reliability expectations, which are now SAP’s responsibility to manage in the cloud environment.

Remains Customer’s Responsibility (not included in base RISE):

• Implementation and Configuration: RISE does not magically implement S/4HANA for you. The hard work of planning the deployment, configuring business processes in S/4HANA to fit your needs, migrating data from legacy systems, and testing everything still lies with the customer and their chosen system integration partners. SAP provides tools and guidance, but project execution (e.g., using the SAP Activate methodology, designing the actual process, and loading data) is a separate effort not included in the RISE subscription fee.
• Functional Management and Enhancements: While SAP runs the infrastructure, the customer’s IT or business analysts still need to manage how the system is used. Creating new reports, adjusting configuration for changing business needs, managing user access roles, training end-users, and providing internal helpdesk support are all tasks that remain with the customer (or their consultants). RISE relieves technical overhead but not the functional ownership of the system.
• Custom Development (Build and Maintenance): If you use SAP BTP to build extensions or have custom code in a private edition, you are responsible for developing and maintaining that code. SAP ensures the platform is available, but it’s up to the customer to adapt customizations to new upgrades or to ensure custom apps (on BTP or in S/4) are working correctly. For example, if a new upgrade deprecates an API your custom extension uses, your team must adjust the extension.
• Integrations to Third-Party Systems: Most SAP customers have an ecosystem of other applications (CRM systems, supplier portals, legacy databases, etc.) that must exchange data with S/4HANA. Under RISE, SAP provides the integration platform (and possibly some pre-built connectors on BTP), but designing, building, and testing the integrations are customer activities. Additionally, managing the interfaces (monitoring IDocs and troubleshooting integration errors) often remains joint – SAP ensures the S/4 system is up. Still, if an external system sends a bad data payload, it is up to the customer to fix the interface logic.
• Peripheral and On-Premise Systems: If the enterprise still runs other systems on-premises (for example, an old SAP BW or third-party applications that have not been moved to the cloud), these remain the customer’s responsibility. To ensure acceptable latency, the customer must also manage network connectivity between SAP’s cloud environment and their systems, including VPNs or direct connections. Note that network costs are typically not included in RISE.
• Data Governance and Security Settings: SAP will secure the infrastructure and application according to standard best practices, but the customer is responsible for application-level security settings – such as user identities (often integrated with the customer’s Single Sign-On/IDM system), role-based access controls inside S/4, data privacy configurations, and compliance with any industry regulations. For instance, if there are specific encryption or data masking requirements, the customer needs to work with SAP to implement them; these are not automatically handled unless they are explicitly purchased as additional services.
• Business Continuity beyond Standard SLA: RISE includes regular backups and a default disaster recovery (DR) option, which aligns with SAP’s cloud policy and often involves recovery in a secondary data center within a certain timeframe. Suppose a customer requires a more aggressive disaster recovery (DR) approach (e.g., active-active high availability across regions or a shorter recovery point objective than the standard). In that case, this might incur extra costs and require the customer to request it. Similarly, any advanced security or compliance services, such as dedicated hardware security modules, may be add-ons.

In summary, RISE shifts a large portion of technical work to SAP—infrastructure, basic operations, and software upkeep are handled as a service. This allows the customer’s IT team to focus more on value-added tasks, such as process improvements and new functionality.

However, CIOs should ensure they have plans (internally or with partners) for the remaining responsibilities: implementation, custom solutions, integrations, and ongoing business support.

The RISE contract can be complemented with additional services from SAP or partners (for example, many SAP partners offer Managed Services on top of RISE to handle application support or continuous improvement). Understanding the boundaries clearly will prevent any gaps in service or surprises about who does what after signing the deal.

RISE vs On-Premises (BYOL) – Pricing, Flexibility, and Control

For organizations considering a move to the cloud, a common question is: Should we go with RISE with SAP or run SAP on the cloud ourselves?

Many SAP customers can use their existing SAP licenses and deploy them on a public cloud, such as AWS or Azure, under a “bring your own license” (BYOL) model.

This essentially treats the change as an infrastructure change while maintaining traditional licensing. Below is a comparison of RISE against that approach across key dimensions:

1. Cost and Pricing Structure:
   • RISE (Subscription Model): As discussed, RISE offers a single annual subscription price that bundles everything. This price includes software, infrastructure, and standard support. You pay by the FUE count and (implicitly) for the size of the systems, as larger systems or database sizes will require more underlying infrastructure, which SAP factors into the subscription. The pricing is typically locked in for the duration of the contract, such as 3 or 5 years. Enterprises can negotiate the rate based on volume (more FUEs usually means a lower unit price) and other factors. Discounts on RISE subscriptions may not be as steep as historical on-prem license discounts, because the fee also covers infrastructure and services (which have a real cost to SAP). However, SAP has been offering incentives, as noted, to make RISE more financially attractive compared to staying on-premises.
   • On-Premise + Hyperscaler (DIY Cloud): Here, the costs are split: you use your existing SAP license (purchased perpetual, so no additional license cost except the annual maintenance you continue to pay to SAP), and separately procure cloud infrastructure (IaaS) from a provider like AWS, Azure, or Google. You might also pay a systems integrator or have internal staff manage the system. The advantage is that you can shop for competitive cloud pricing and scale resources as needed, potentially optimizing costs (e.g., shutting down systems during off-hours to save money). You also avoid the “all-in-one” premium that SAP might charge for bundling convenience. On the other hand, you still pay SAP maintenance, which is subject to annual increases, and it yields no new functionality if you remain on older versions. Over time, SAP’s maintenance for on-premises systems has been rising (recently up to +5% per year, with inflation indexing), which erodes some of the cost advantages of staying on the old model.
2. Commercial Flexibility and Lock-In:
   • RISE: Committing to RISE is effectively a vendor lock-in, with SAP serving as the full-service provider for the duration of the contract. You are tied into SAP’s environment and cannot exit early (without paying for the remainder of the term). You also rely on SAP if you want to change aspects, such as moving to a different cloud region or scaling down capacity – these typically require contract amendments or occur at the next renewal. The benefit is simplicity, as you only have to deal with one vendor, but the downside is reduced leverage if the service does not meet expectations, since switching it out is not trivial. You could revert to on-prem or a different model at renewal time, but that would effectively be another migration or project.
   • On-Premise + Hyperscaler: In this model, you have more granular control and potentially more flexibility. Your SAP software license is perpetual, so even if you decide to stop paying maintenance, you can still legally run the software (albeit without support or updates). You can switch your infrastructure provider or bring it back on-prem if needed (assuming your architecture and contracts allow it). You may want to engage a third party for support. Some companies consider third-party support providers to save on SAP maintenance costs if they plan to stay on an older version for an extended period. There is more commercial freedom to optimize each layer: you can negotiate cloud costs separately and services separately. However, this also means more contracts and potentially more complexity to manage.
3. Control and Customization:
   • RISE: With SAP managing the environment, some control is ceded. For instance, system-level access (at the OS and database levels) is restricted – your basis team will not log into the servers directly; they work through SAP for certain tasks. Changes to the production environment might require SAP’s involvement via change requests. In the public cloud RISE scenario, control is even more limited, as it’s SaaS. In the private cloud RISE, you have more control within the application, as you can configure and customize S/4HANA largely as you like. However, SAP still sets many policies for operations, such as how transports are moved and when maintenance windows occur. Some customers worry that this could slow down their ability to respond to issues (you can’t directly apply a fix; you must request SAP) or that it might limit certain technical nuances (for example, using a custom monitoring agent or third-party tool might not be possible unless SAP supports it).
   • DIY on Hyperscaler: This is like your on-prem environment moved to someone else’s data center. You retain full control of the SAP systems. Your IT team (or service partner) can perform any necessary actions – tuning database parameters, scheduling downtime as needed, or applying SAP Notes and patches on your schedule. You also have control over the infrastructure, within the limits of cloud IaaS. You can choose instance types, scale up or down, and leverage various cloud services. This model is preferable for organizations considering their SAP environment a strategic asset they want to fine-tune. The trade-off is that you are also responsible for maintaining it – monitoring usage, handling security updates, ensuring backups, etc. The level of control can directly translate to a need for more skilled staff and management effort.
4. Risk and Support:
   • RISE: Because SAP takes ownership of operations, the risk of system downtime or performance issues shifts more onto SAP (contractually via SLAs). SAP is responsible for resolving issues if something goes wrong with the infrastructure or base software. This “single throat to choke” can simplify issue resolution – there’s no finger-pointing between vendor and hosting provider, since SAP covers it all. SAP is also vested in keeping the environment stable and efficient, as it manages many customers and has robust procedures. This transfer of operational risk and reliance on SAP’s expertise is a key selling point for many CIOs, especially if their organization lacks a large, experienced team of SAP-based professionals or cloud architects.
   • On-Prem/Hyperscaler: In a BYOL scenario, if an issue arises, it’s up to your team to determine the cause and involve the right support. You may need to coordinate with SAP support (for software issues) and the cloud provider’s support (for infrastructure issues). For example, a complex performance problem might require analysis by your basis admins and potentially engagement with SAP and AWS support to pinpoint whether it’s an application bug or a storage latency issue. Essentially, you are the integrator of the solution. This can be challenging if deep-seated issues arise, but you also maintain control over the troubleshooting process. Organizations with strong internal SAP expertise or a reliable managed service provider may handle this well; others might find it risky. Support-wise, you can still have SAP Enterprise Support and a cloud support contract, but you ensure nothing falls through the cracks.
5. Innovation and Roadmap:
   • RISE: SAP has clarified that certain innovations (especially around AI, advanced analytics, and new industry cloud extensions) are being delivered in the cloud first – and in some cases exclusively to cloud versions of S/4HANA. In mid-2023, SAP leadership announced that new ERP features like AI-driven processes and sustainability analytics would be released for cloud customers and not backported to on-premise systems. This means RISE customers will have access to the latest capabilities as soon as SAP releases them, as part of the continuous updates. Also, by being on RISE, you more easily take advantage of SAP’s broader cloud ecosystem (BTP services, integration hubs, etc.) because those are aligned with the RISE environment. In short, you’re always modern.
   • On-Prem/Hyperscaler: A self-managed S/4HANA system can be technically kept up to date, but it relies on your initiative to perform upgrades. Many on-premises customers historically upgrade less frequently due to the effort required, which can cause them to lag in new features. If you remain on an older version of S/4HANA, you won’t have immediate access to SAP’s latest innovations. Additionally, some cloud-only offerings, such as certain SAP Business Network features or advanced cloud analytics, may not integrate as seamlessly with an on-premises setup. You may also need to perform additional integration work to use them. That said, you have a choice – you can upgrade whenever you want. If you want to wait for a stable release or skip a year, you can. In RISE, you will eventually be moved to the new versions. You control your roadmap, but you might miss out or be slower to get new things if you delay.

Here’s a summary comparison table of RISE vs Traditional (BYOL on cloud):

Neither approach is universally “better” – the right choice depends on the organization’s priorities. Some large enterprises even adopt a hybrid approach (e.g., using RISE for certain divisions or new implementations, and keeping other systems on traditional infrastructure for now) based on specific needs.

The RISE model offers simplicity and a faster route to cloud benefits, while the traditional model provides maximum control and potentially cost efficiencies for those who manage it effectively. CIOs need to weigh these factors in the context of their capabilities, risk appetite, and strategic goals.

Key Considerations in Negotiating a RISE with SAP Deal

If a company decides to pursue RISE with SAP, important commercial and legal terms must be evaluated during negotiations.

RISE contracts can be complex because they bundle multiple elements.

CIOs and procurement leads should keep the following considerations in mind:

• Contract Term and Flexibility: Determine the length of commitment that makes sense for you. SAP often seeks multi-year commitments, ranging from 3 to 5 or even 7 years. A longer term might secure better pricing, but it reduces flexibility if your strategy changes. Negotiate options for flexibility, such as the ability to adjust volumes or to extend the contract for a short period if needed. For example, if you sign a 5-year term, can you have an option to extend for 6–12 months at the same rates to cover any transition period at the end? Ensure you understand what happens at the end of the term – there should be provisions for renewal discussions well in advance, and clarity should be provided that your data will be transferred if you choose not to renew.
• Pricing Protection (Caps and Escalators): Clarify how pricing may change over the contract period and at renewal. Ideally, lock in pricing for the full term. If SAP insists on any inflation-based increases during the term, negotiate a cap, such as a maximum of 3% per year. More critically, negotiate a cap on renewal increase – without a cap, there is a risk that the price could jump significantly after the initial term (when you are somewhat locked in). Try to get commitments such as “renewal increase not to exceed X%” or, at the very least, the right to benchmark against market pricing. Also, if you expect your user count (FUEs) to increase, consider negotiating tiered pricing that includes volume discounts upfront.
• Service Level Agreements (SLA): Review the SLA guarantees in the RISE contract. Typically, SAP guarantees around 99.7% uptime for production systems. Check what that means regarding allowable downtime (about 2.5 hours per month at 99.7%). If your business is extremely sensitive to downtime, you may need a higher SLA (such as 99.9% uptime or better), which reduces downtime to under an hour per month. SAP often offers an enhanced SLA at an extra cost or as part of a premium support package. Ensure the SLA covers not only uptime but also aspects such as disaster recovery (e.g., recovery time objective (RTO) and recovery point objective (RPO)) in the event of a data center failure. Also, look at support responsiveness – for critical Severity-1 issues, what response and resolution targets does SAP commit to? While SAP’s standard support SLAs apply, you might negotiate stricter terms if your operations demand it.
• Penalties and Remedies: Understand SAP’s remedies when SLA targets are missed. Typically, the contract will provide service credits, a percentage of the monthly fee, credited for downtime exceeding the threshold. These credits are usually small relative to the overall impact of an outage, but they are a financial lever. If uptime is mission-critical, consider negotiating stronger remedies or, at the very least, clear rights to terminate the contract without penalty if SLA breaches are chronic. For example, you can terminate the agreement if SAP fails to meet the SLA for three consecutive quarters. The goal is to ensure SAP has skin in the game to perform.
• Scope of Services – Roles and Responsibilities: Ensure the contract clearly outlines what SAP is responsible for and what your team or partners are responsible for. For instance, does the RISE fee include a certain number of sandbox or training systems, or just the main development, QA, and production landscapes? Is disaster recovery (a secondary site) included by default, or is it an additional charge? Is that included if you need high-availability (e.g., cluster failover within the primary site)? Clarify who handles tasks like periodically refreshing test systems with production data. Some customers do this regularly for realistic testing – is that an extra service or a DIY project? The more detail around the scope, the fewer surprises later. If you have specific needs (e.g., integration with a legacy system that requires VPN connectivity), ensure that SAP supports them and include them in the project plan.
• Data Residency and Security: If your enterprise has data residency requirements (e.g., data must remain in a certain country or region), ensure that the RISE contract specifies the cloud region accordingly and that SAP will not move your data outside that region. SAP should also confirm compliance with relevant standards (e.g., SOC 2, ISO 27001, GDPR) – typically,y their cloud meets these, but it’s good to have those assurances in writing. If you need any special security measures (for instance, customer-managed encryption keys, or integration with your identity management), discuss whether that’s supported and if any additional subscription (like SAP’s Data Custodian service, etc.) is needed.
• Exit Strategy and Data Access: Plan for the end at the beginning. Negotiate clear terms for how you can exit the RISE arrangement if needed. For example, ensure that you have the right to obtain a full export of your data and any custom configurations upon contract completion. Understand in what format and how quickly SAP would provide system exports or data extracts if you decide not to renew. Also, if you converted existing licenses to RISE, clarify whether you can revert to on-premises licensing. (Often, once you move to RISE, those perpetual licenses are put on hold or terminated; you’d have to negotiate new licenses if you left RISE later. Some customers negotiate the right to reactivate their old licenses by paying back maintenance or a similar fee, which must be specified in the agreement. While an “exit clause” in the middle of the term is unlikely (SAP typically doesn’t allow early termination without significant penalties), at least ensure that an exit at the end of the term is feasible and supported by SAP cooperation.
• Migration and Implementation Assistance: RISE provides the infrastructure and software, but does not offer default migration services. However, you might ask for assistance or credits toward migration services as part of your deal negotiation. SAP has programs and partner arrangements to help customers migrate to RISE. For instance, as noted, SAP might offer a credit you can use for SAP consulting or a partner of your choice to assist in migration. If you’re a large account, you could even negotiate some SAP consulting hours for advisory or quality assurance on the project at no extra cost. At a minimum, ensure you take advantage of all the tools included (such as the SAP Readiness Check and custom code analysis tools) and ask SAP to guide your team in using them effectively.
• Growth and Change Management: Businesses evolve. Discuss how things like company growth, mergers, or divestitures will be handled upfront. For example, if you acquire another company that uses SAP, can you easily merge them into your RISE contract? What would additional FUEs cost, and can the acquired entity’s licenses be converted? Conversely, if you spin off a division, can you carve out part of the RISE system or reduce scope? While you may not be able to include binding clauses for unknown future events, having a framework (such as a price per additional FUE or the ability to have a separate installation for a spinoff during a transition period) can be valuable. Additionally, clarify how adding new SAP modules or products works – if, in the mid-term, you decide to implement an additional SAP LoB cloud product (e.g., add SAP SuccessFactors or Ariba), that would be a separate contract, but ensure there’s no conflict or unexpected integration charge on the RISE side.
• Legal Protections: Treat the RISE contract with the same scrutiny as any critical IT outsourcing or cloud contract. Ensure there are liability, IP, and indemnification clauses that protect you. For example, what is SAP’s liability if SAP’s service causes a data breach? (They often cap at a certain amount – see if you can get a higher cap for data breach issues.) If SAP uses third-party software in the service, it should indemnify you against IP infringement. Also, check for any non-solicitation clauses or restrictions that might affect hiring (some contracts have clauses about not poaching each other’s staff, which may or may not matter to you). These are standard legal points, but worth reviewing with legal counsel.
• Benchmarking and Audit Rights: In long-term deals, some customers prefer a benchmarking clause – the right to compare the service’s pricing to market standards and renegotiate if it’s significantly out of line. SAP is unlikely to easily allow formal benchmarking clauses, but it doesn’t hurt to ask. At the very least, maintain the right to audit usage (so you can verify FUE counts, etc., are correct) and transparency on how your consumption is measured. This way, if you suspect you are being charged for more than you use, you have recourse to validate.

Engaging experienced legal counsel and perhaps third-party advisors who have seen other RISE contracts can be valuable. SAP will have a standard contract template; many terms that are not included in the base template can be negotiated through an addendum.

The key is to avoid future pain by anticipating possible scenarios, such as growth, mergers, divestitures, performance issues, or strategic shifts, and incorporating as much flexibility and protection as possible.

Indirect Access Considerations

The issue of indirect access, when non-SAP systems or users use SAP data or functionality indirectly, has been a longstanding concern in SAP licensing.

Many CIOs recall high-profile cases where SAP sought license fees for third-party systems interfacing with SAP. How does RISE with SAP change this?

Under traditional licensing, if you had a web storefront that created sales orders in SAP or a CRM system that queried SAP data, those interactions needed to be licensed. In recent years, SAP introduced a “Digital Access” model to handle this via document counts, but it was still something customers had to explicitly license or negotiate.

RISE with SAP largely neutralizes the indirect access issue by including digital access in the subscription:

• In a RISE contract, using SAP via indirect means (APIs, intermediate systems, etc.) is allowed under the terms of your FUE count and accompanying digital access rights. The public cloud edition of S/4HANA comes with built-in metrics for digital access. SAP typically includes a certain number of document transactions in the base subscription. The private cloud edition also includes a digital access license, often with a generous allowance of documents or the ability to create an unlimited number of specific document types without additional fees.
• Practically, you don’t have to separately count users or devices that indirectly interface with S/4HANA for licensing purposes – your RISE subscription covers them. If you have an e-commerce system that creates orders in S/4HANA or a third-party logistics system that pulls inventory data, these are considered part of the entitled use.
• However, be aware of very high-volume scenarios. If your indirect usage is exceptionally high (for example, IoT sensors generating millions of records or a public website making heavy calls), ensure that SAP is aware of this usage pattern. In some cases, SAP might price very large digital access needs differently. However, the included digital access in RISE is ample for most typical enterprise scenarios.
• It’s still wise to document your known interfaces and integrations when negotiating, so everyone is on the same page about how the system will be used. This can be part of the architecture discussions rather than the contract itself, but it avoids any finger-pointing later. For instance, if you plan to have 500 concurrent API connections from various systems, SAP’s technical team may need to size the environment accordingly (licensing-wise, it’s covered).

One area to double-check is if you have third-party applications that embed SAP functionality in a custom way. For example, if you built a custom mobile app that uses an SAP user in the background to perform actions, in a traditional model, this could be tricky from a licensing perspective.

Since users aren’t named per se in RISE, as long as the overall usage is within your FUE and document bounds, you’re fine. But make sure to count those mobile app users in your FUE estimation (they may fall under self-service users if they are basic, for example).

Another benefit: SAP’s combative stance on indirect access has softened in the cloud era—they now want customers to integrate SAP with their entire digital landscape. RISE is an enabler for that by removing the licensing friction.

CIOs can thus push forward with integration projects (connecting SAP to e-commerce, customer portals, IoT platforms, etc.) without the previous anxiety of “Will we get a huge bill for this?”

In summary, RISE with SAP significantly simplifies indirect access licensing. The Full Usage Equivalent model and included digital access rights mean you’re licensing the system’s overall capability, not every technical touchpoint.

This is a significant relief in contract management. Just ensure during planning that you size your FUE count appropriately, including all human and non-human usage of the system, and indirect access will be a non-issue under RISE.

Pricing and Discount Trends: RISE vs Traditional Deals

As enterprises evaluate RISE, it’s helpful to understand how SAP is pricing it relative to traditional offerings, and what negotiation trends are emerging in the market (circa 2024-2025):

• SAP’s Push and Incentives: SAP is strongly incentivized to move customers to the cloud. They have been making this clear through both carrot and stick approaches. On the carrot side, SAP introduced incentive programs – for example, in late 2023, SAP offered significant credits (up to 60% of the first year’s subscription value) to customers who migrated their existing S/4HANA on-premises licenses to RISE. These credits can be spent on other SAP services or used to offset migration costs, making the financial case more attractive. Such deals show SAP’s willingness to invest upfront to win long-term cloud business. Enterprises should certainly explore if these incentives are available, using SAP’s desire to secure a RISE contract to negotiate lower total cost or extra value-added services.
• Maintenance Cost Increases (the “Stick”): SAP has also been applying pressure on customers staying with traditional licensing. SAP raised on-premise support fees in 2023 and again in 2024 (linked to inflation, up to a 5% increase per year) for the first time in years. Additionally, SAP signaled that innovations in S/4HANA, such as AI-driven features and advanced process capabilities, would be cloud-only and not offered to on-premises customers. These moves are meant to make the on-prem status quo less comfortable financially and functionally. CIOs should factor this into their comparison: staying on-prem means potentially higher support bills every year and missing out on some new features unless they undertake upgrades or move later. This narrowing gap will tilt the cost/benefit analysis toward RISE over time.
• Discount Levels on RISE vs. Perpetual: In past decades, SAP perpetual license deals could be heavily discounted (often 50% or more off the list price for large deals), but maintenance was then paid on the discounted license base. The discount percentages might appear lower with RISE because it includes ongoing services. Reports from the field suggest that discounts on RISE subscriptions are typically modest, ranging from 10% to 30% off the list price, depending on the deal size and strategic importance. However, each deal is unique. Instead of a pure discount, SAP sometimes adds value in other ways, such as with credits or by bundling extra tools. Traditional license deals often involve complex discount structures, such as credits for unused licenses.
  In contrast, RISE aims to be more straightforward. If you’re used to seeing huge discount percentages from SAP, be prepared that a RISE quote might not have the same look – the value is in the bundle. What matters is the total cost over the years, not the discount rate on paper.
• Comparing 5-Year Costs: Many customers conduct a five-year total cost of ownership (TCO) comparison. For example, if we compare the cost of a 5-year RISE subscription vs 5 years of running on-prem/hyperscaler:
  • RISE: 5 years of subscription (with any negotiated flat or slightly increasing rate) – includes everything.On-Prem: Year 1 spend on hardware or migration to cloud (if needed), plus license maintenance each year (which might increase), plus cloud hosting fees each month, plus labor costs or MSP costs to manage.
  The results can vary widely. Some have found RISE a bit more expensive, while others find it equal or cheaper. Key factors are how efficiently you run your SAP environment and what internal costs you attribute to it. If a company has already optimized its operations and maybe uses a low-cost hosting provider or an offshore support model, its baseline might be hard for SAP to beat. On the other hand, if a company’s current operations are expensive or due for a tech refresh, RISE’s all-in proposal can lower the 5-year cost by double-digit percentages. SAP’s claimed 20% TCO reduction often assumes that you would otherwise have a like-for-like, high-quality setup (with redundant infrastructure, frequent upgrades, etc.). If you had skimped on those on-prem, the “savings” might not materialize – you’re paying more to get more in RISE. Each CIO should plug in their numbers.
• Public vs Private Edition Costs: It’s worth noting that within RISE, the public edition is generally cheaper than the private edition for the same number of users. If your organization could use either model, SAP may present the public edition as the cost-saver’s choice, for example, roughly speaking, a public edition S/4HANA user might cost 15-20% less than a private edition user in subscription fees. This differential might influence your decision if your primary goal is cost reduction and if your processes can fit within the constraints of the public cloud. Many enterprises don’t consider public vs private as interchangeable – needs dictate it – but if you’re on the fence, factor the cost difference into your evaluation.
• Negotiation Timing: Timing can affect the deal. SAP (like all vendors) has quarterly and annual sales targets. If you approach a deal near the end of the year, you might get a bit more flexibility as they try to close. Conversely, suppose your existing SAP maintenance renewal is due soon. That’s also a point of leverage: you can use the decision to renew maintenance vs. signing RISE to push for a better offer. Be careful not to let a maintenance renewal lapse unless you plan to move off. However, “we might drop maintenance and go with third-party support” is a card some play to motivate SAP.
• Bundle with Other SAP Purchases: Often, RISE discussions coincide with other SAP initiatives (maybe you’re also evaluating SuccessFactors, or database upgrades, etc.). SAP may offer a better overall discount if you commit to a broader suite of products. Ensure transparency if you bundle – break out the costs in the quote so you know what portion RISE vs. other products are. Also, maintain the ability to decouple them; you don’t want your ERP cloud decision to force you into another module if you’re not ready, or vice versa.
• Peer Experiences: It’s valuable to seek out peer opinions. Many SAP user groups and communities, such as ASUG and SUGEN, have members sharing their RISE experiences and even high-level cost impressions. While exact figures are confidential, you can glean trends like “SAP initially quoted high but came down after we showed alternatives” or “We got extra BTP capacity thrown in.” Use these as informal benchmarks. If you have a SAP customer executive advisory board or know companies in your industry that have moved to RISE, consider a reference call to discuss their negotiations. SAP often will offer reference customers for you to speak with as well (they will choose happy customers, of course).
• Don’t ignore the hidden costs: When focusing on SAP’s pricing, remember there are costs beyond SAP. For example, moving to RISE may reduce your internal hardware costs. Still, you may incur organizational change costs, such as training users for more frequent updates and adapting your support processes. Or if you had a contract with a data center that you must exit early, that penalty is a cost. On the other hand, staying on-premises has hidden costs, such as the potential accumulation of technical debt. Bring these into your holistic financial analysis. This ensures that when you negotiate with SAP, you also know what budget to reserve for complementary activities (e.g., a data migration tool license or additional integration work).
• Future Price Trajectory: Consider not just this deal, but also the next one. If you believe SAP’s future roadmap means everyone will eventually be on cloud subscriptions, consider locking in your terms now. SAP’s pricing for cloud could rise over time as adoption grows – early adopters sometimes get better deals. Conversely, if you feel competition (from other ERPs or third-party data centers) will force SAP to keep prices in check, you might be okay with a shorter deal and renegotiating later. There’s a bit of game theory: sign a longer contract to secure a good rate, or a shorter one to allow switching if needed. Many enterprises choose 5 years as a balanced horizon – not too short to disrupt plans, not too long to be stuck.

In summary, the pricing landscape for RISE is dynamic. SAP is very motivated to work with customers to craft a deal that gets them on board. That doesn’t mean accept the first quote – it means you have the opportunity to shape the deal. Use the fact that SAP is making strategic moves (raising maintenance, offering credits) to frame your negotiation.

A well-negotiated RISE deal can potentially deliver strong value, but it requires understanding both hard costs and soft benefits. Achieving an optimal outcome might involve creativity, such as requesting additional training credits or adjusting payment schedules, in addition to the per-user price. Keep a clear view of your objectives (such as cost savings, service quality, or innovation) and let those drive the discussion, not just the allure of the new offering.

Recommendations for CIOs and Procurement Leaders

Decision-making between RISE and SAP and a traditional on-premise approach is strategic and multifaceted.

Here are key recommendations for CIOs and procurement teams as they navigate this decision and any subsequent negotiations:

1. Perform a Comprehensive TCO Analysis: Don’t rely solely on SAP’s cost savings projections. Conduct an internal analysis (or engage a neutral third-party consultant) to model the total cost of ownership for both scenarios over a realistic period (e.g., 5-10 years). Include all relevant costs, such as software, hardware, cloud infrastructure, internal staffing, external services, and potential downtime risks. This will help determine whether RISE’s subscription is financially advantageous or if on-premises might be more economical. Update this analysis with real quotes as you engage SAP – it’s a powerful tool to guide negotiations and justify decisions to executive stakeholders.
2. Align with Your Business Strategy: Consider how each option aligns with your company’s broader strategy and IT principles. Suppose your organization aims for agility, rapid innovation, and uses a cloud-first approach. In that case, RISE’s cloud model supports that direction (and you may value the continuous updates and broad range of cloud services it offers). If your organization values maximum control, has unique processes that are a source of competitive advantage, or operates in an environment with strict compliance that you’re not ready to entrust to SAP, then a more traditional deployment might align better for now. The decision should not be made in an IT silo – involve business leadership to see which model resonates with their needs (e.g., are they willing to adapt processes to standard best practices or do they insist on custom solutions?).
3. Assess Internal Capabilities and Partner Ecosystem: Evaluate your internal team’s ability to manage SAP in various scenarios. You might be well-positioned to handle SAP on a hyperscaler if you have a strong foundation and an infrastructure team with cloud skills. If not, RISE could significantly reduce dependence on skills you lack or are scarce. Also consider partner capabilities: Are you already outsourcing SAP infrastructure management? If yes, how does that partner’s offering compare to RISE? Sometimes, an existing managed service provider can offer to run your SAP on the cloud with similar outcomes to RISE. Weigh those alternatives – SAP RISE is not the only way to get to a cloud-hosted S/4HANA; it’s one package. Knowing your strengths and the strengths of available partners will help you choose a model that ensures success.
4. Use SAP’s Motivation to Your Advantage: Understand that SAP has a strategic imperative to convert customers to RISE or cloud. This gives you leverage. Engage with SAP early, but also let them know you are evaluating all options, including upgrading on-premises, other cloud hosting options, competitors, or continuing to use ECC for longer. This encourages SAP to put its best foot forward. Take advantage of any trial programs or assessments SAP offers – for instance, SAP might offer a free RISE trial system or a free “RISE value assessment” workshop. These can provide useful info (and free consulting) while signaling to SAP that you’re serious but not a guaranteed win. Leverage user groups or executive channels to understand how flexible SAP can be. In some cases, involvement from an SAP account executive’s management or industry specialists can bring creative solutions.
5. Plan the Transition (Pilot or Phases): If you decide to move to RISE, plan the transition carefully. You don’t necessarily have to do a big bang move of all systems to RISE at once. Maybe migrate a non-production environment first to get familiar, or roll out S/4HANA for a smaller division as a pilot under RISE. This phased approach can reduce risk and allow learning before full scale. Include these plans in your roadmap – for example, negotiate the contract so that you start paying for production instances only when they go live, not from the start if you won’t use them immediately. If you intend to make a phased move (for example, moving subsidiaries first and headquarters later), ensure that SAP structures the contract to accommodate that timeline.
6. Consider Future-Proofing: Whatever path you choose, keep future flexibility in mind. If you choose RISE now, consider exit options later, even conceptually, such as how we might shift to another model in 5 years or more if needed. If you choose to stay on-premises now, consider making your environment cloud-ready. For example, you can convert to S/4HANA on-premises in a way that allows for easy porting to the cloud later, or containerize some components. Avoid one-way doors; maintain leverage for the future. SAP’s offerings may evolve (they might offer new cloud subscriptions or different bundles), so avoid contractual clauses that lock you out of adopting those when they come. For instance, if SAP later introduces a pure SaaS S/4HANA for enterprises that’s separate from RISE, you’d want to be able to consider it at the next renewal.
7. Invest in Change Management: Particularly if you opt for RISE and especially the public cloud edition, invest in organizational change management. Being on RISE (cloud) will likely mean more frequent changes in the system, a different way of interacting with SAP support, and possibly less “tinkering” by your internal team. Ensure your team is trained on how to work in this new model (e.g., how to open tickets with SAP for basis issues, how to test quarterly updates quickly). Also, prepare your business users for the new pace of improvements – they may need to adapt their testing cycles and enhancement requests to fit a continuous delivery model. Highlight their benefits: new features, faster, less downtime for maintenance, etc. When users and administrators embrace the new model, the value realization is much higher.
8. Monitor and Benchmark Post-Move: If you move to RISE, monitor the value you’re getting. Track metrics like system performance, support responsiveness, cost vs budget, and business outcomes (e.g., did processes improve because of new tools available?). This will help you validate the decision and provide data for future negotiations, such as renewals or expansions. If something does not meet expectations, SAP should be engaged through the governance process, earlier rather than later. Most RISE engagements have a Customer Success partner or Technical Account Manager from SAP; use them to get issues addressed. Essentially, treat SAP as a partner in this journey, holding them accountable when needed and collaborating to get the best out of the solutions.
9. Stay informed about licensing policies: SAP licensing and cloud offerings constantly evolve. New programs, such as GROW with SAP for midmarket companies or new consumption models, could emerge. As a CIO or procurement lead, stay in touch with SAP user groups or advisory councils to stay informed about any changes that could impact your deal. For example, if SAP changes how FUE is calculated or offers new bundles (perhaps including more SAP BTP), you would want to be aware of this and possibly take advantage of it. Regularly reviewing your SAP strategy each year is wise – even under a 5-year contract, make a habit of an annual check-in to ask, “Is this still working for us, and are we leveraging all we’re paying for?”
10. Don’t Neglect Alternative Scenarios: As part of due diligence, examine alternatives even if you lean towards SAP. Could a third-party support provider, plus a lift-and-shift to the cloud, allow you to defer major decisions and save money for a few years? Could a different ERP strategy (like a competitor’s cloud ERP) better fit your new business units? These might not be paths you choose, but understanding them gives you confidence in your SAP decision and strengthens your negotiating position. For example, knowing that third-party support could cut your support fees by 50% might motivate SAP to ensure their offer (with all the bells and whistles of RISE) demonstrably delivers more value than that cost saving alone.

By considering these recommendations, CIOs and procurement leaders can approach the RISE vs. on-premises decision in a structured and objective manner. The best outcome will differ by organization, but it should always be a proactive choice, not solely based on the vendor’s direction without scrutiny.

Whether you jump to RISE now or hold off, deciding with full awareness of the trade-offs means you can confidently steer your SAP landscape to support your enterprise’s goals.

Read more about our SAP Rise Advisory Services.

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