Top SAP Licensing Risks and Pitfalls in RISE Deals

Top SAP Licensing Risks and Pitfalls in RISE Deals

SAP’s RISE with SAP offering promises an all-in-one path to S/4HANA in the cloud, but it introduces significant licensing risks that buyers must navigate carefully. Key pitfalls include potential dual licensing overlaps during migration, loss of existing usage rights when trading perpetual licenses for subscriptions, and confusion around indirect access fees for third-party interfaces.

RISE deals often bundle extra services – from cloud platform credits to limited SAP Business Network access – which can turn into shelfware if unused. They may pressure customers into migrating modules they aren’t ready to move.

RISE’s single bundled contract can also lack pricing transparency, hiding markups or scope limits (like caps on usage or storage) that lead to unexpected costs.

Sourcing and IT leaders should take a proactive approach to mitigate these risks. Thorough due diligence on current SAP usage is essential before negotiating RISE, to avoid overpaying for unnecessary capacity.

Strong negotiation safeguards are needed, such as ensuring contractual clarity on transition rights, caps on price increases, inclusion of indirect use in the subscription, and flexibility to adjust or exit.

Engaging an independent SAP licensing advisor (such as Redress Compliance or similar experts) can provide objective guidance and negotiation leverage. Enterprises can embrace RISE’s benefits while controlling cost and risk by securing detailed terms and maintaining vigilant compliance management.

Problem Overview: RISE vs Traditional SAP Licensing

Moving to RISE with SAP means shifting from SAP’s traditional licensing model to a new, cloud-centric paradigm. In a traditional SAP license model, customers purchase perpetual software licenses for a hefty one-time fee and deploy SAP on their own (or hosted) infrastructure.

They pay annual maintenance (around 20% of the license cost) for support and updates. However, they own the licenses indefinitely – even if maintenance is dropped, the software can still be used (albeit without support). Customers also directly manage infrastructure or choose a hosting partner, giving them control over systems and the flexibility to opt for third-party support or delay upgrades on their timeline.

In contrast, RISE with SAP is a subscription-based “ERP-as-a-service” model. Instead of owning licenses, the customer pays a recurring subscription fee for a bundled package: S/4HANA software rights, cloud infrastructure, technical management services, and SAP support are all included under one contract.

This shifts SAP from a capital expense (license purchase) to an operational expense (subscription). It also consolidates what used to be separate agreements (software, hosting, support) into one contract managed by SAP, simplifying procurement but reducing transparency and direct control.

Under RISE, SAP takes on much of the infrastructure and maintenance responsibility. The S/4HANA system runs in an SAP-managed cloud environment (SAP’s datacenters or a hyperscaler like AWS/Azure/GCP arranged by SAP). SAP handles updates on a defined schedule – for instance, quarterly upgrades are automatic in the public cloud edition, keeping customers on the latest version.

The private cloud edition of RISE offers more flexibility (allowing some customizations and customer control over major upgrades), but SAP still manages the underlying environment and minor patches.

Crucially, RISE is available only for cloud deployments – you cannot use a RISE subscription to run SAP on your on-premise servers. This cloud-exclusive approach means companies must be ready to give up some autonomy: for example, changes to infrastructure sizing or region must go through SAP rather than being handled directly, and there is no option to forgo SAP support or use a third-party support provider, since support is baked into the subscription.

This new structure brings benefits – one throat to choke for service issues, reduced need for in-house basis infrastructure skills, and potentially faster access to innovations – but also introduces challenges in licensing. Companies transitioning from traditional SAP licensing must reconcile their contracts and investments with the RISE model.

They face questions like: What happens to our sunk-cost licenses and prepaid maintenance? How do our named user licenses translate into the new metric? What if we only move some systems to RISE and keep others on-prem? The following sections delve into the key risk areas in RISE deals and how to address them.

Key Risks and Pitfalls

Overlapping On-Premise and Cloud Licensing

One immediate risk during a RISE migration is license overlap. Enterprises often run their legacy SAP ERP (e.g., ECC) parallel to the new S/4HANA cloud system during data migration, testing, and user training.

Without proper safeguards, this dual usage period can lead to overlapping licenses, technically requiring you to simultaneously be licensed for both environments.

In a worst-case scenario, a company might pay double maintenance fees or violate license terms if the legacy system isn’t retired on schedule. SAP does offer “temporary dual use” provisions, but they must be negotiated and documented.

For example, SAP typically allows a 6-12 month period during which the old system can run in read-only mode alongside S/4HANA. It’s critical to get this in writing, specifying the allowed duration and any restrictions (e.g., no new transactions in ECC once S/4 is live). Failing to formally secure these rights can result in compliance issues or audit penalties if the old system lingers beyond the grace period.

Similarly, overlapping coverage can occur in a hybrid scenario, where a business moves some components to RISE but retains others on-prem. Companies must carefully architect their licensing to avoid paying twice for the same users or modules.

For instance, if only part of your SAP estate moves to RISE, ensure you adjust your on-prem license counts or terminate licenses for migrated components so you’re not left holding excess on-prem licenses (or continuing maintenance on them) while also paying for the subscription.

In negotiations, savvy buyers sometimes ask SAP for bundled pricing or discounts on remaining on-prem licenses when adopting RISE for a subset of systems, to mitigate redundant costs.

The key is proactively addressing the coexistence period: negotiating explicit dual-use allowances, planning the timing of maintenance contract termination, and performing license reconciliations so that cloud and on-premise entitlements are aligned without a gap or overlap.

Loss of Existing Usage Rights (Surrendering Licenses and Changing Metrics)

Adopting RISE is not just a technical migration but a contractual reset of your SAP relationship. One significant pitfall is the loss of existing usage rights with swapping perpetual licenses for subscription access.

When moving to RISE, SAP typically requires a contract conversion: your old license agreements are terminated or put into abeyance as you sign the new RISE subscription. In practical terms, your perpetual ERP licenses are surrendered (often in exchange for some credit), and you become a renter of SAP software.

This has two major implications. First, it’s generally a one-way street – once you give up those perpetual rights, you can’t easily return. If, in a few years, you become dissatisfied with SAP’s cloud, you no longer have the option to fall back to your old ECC system or licenses (those licenses will have been nullified or left inactive without maintenance). Reverting would likely require buying new licenses from scratch, potentially at a higher cost and for a product SAP no longer actively sells.

Customers must recognize the gravity of this lock-in and be very sure of their cloud strategy before committing to RISE. Ensuring adequate trade-in credit for your existing licenses is also crucial – SAP may offer conversion incentives. Still, they might not match the full value of your original investment. You should press for transparent credit calculations, especially if you have a lot of unused (“shelf”) licenses that can be given up.

The second implication is a shift in licensing metrics. Traditionally, SAP ERP licensing revolved heavily around Named Users (e.g., Professional User, Limited Professional, Employee Self-Service, etc.) and some package or engine metrics for add-on modules.

Under RISE, SAP uses a Full Usage Equivalents (FUE) metric for S/4HANA Cloud. Essentially, different types of users and usage are weighted and summed into a single FUE count. For example, one professional user might equal 1 FUE, whereas a light self-service user might count as 1/30 of an FUE, etc.

The idea is to simplify licensing by avoiding a dozen user categories – you contract for a total FUE number that covers all users. However, this change can be a cost trap if not managed. Overestimating your required FUEs or blindly converting named users to FUE without optimization can lead to overpaying.

In some cases, companies discovered they had far more dormant or unnecessary user licenses on their books than active users. If those are translated directly into the FUE subscription, you’d be paying for ghost users.

Analyzing and “right-sizing” your user counts and license assignments is imperative before conversion. For instance, one enterprise found that cleaning up duplicate and inactive users and adjusting license types could reduce their needed FUE count by over 200, a huge cost saving in the subscription.

Additionally, be mindful of functional usage rights: some packages or modules you owned under ECC might not have direct equivalents included in RISE by default. Certain industry solutions or niche modules may require separate cloud services.

If you don’t ensure they’re accounted for in the new contract, you could lose functionality when you switch. Always map out which SAP products and components you use and confirm how each will be covered under RISE.

The contract should list all the needed S/4HANA Cloud entitlements (and any additional cloud services for things like Treasury, Extended Warehouse, etc., if those were part of your ECC scope).

In summary, entering RISE means giving up perpetual ownership and transitioning to a new metric. Mitigate this by securing fair credits for past investments, optimizing license usage beforehand, and double-checking that no critical usage rights are inadvertently dropped in the move.

Indirect Access and Digital Interface Licensing Confusion

Indirect access – when third-party systems or external users interact with SAP data without directly logging into SAP – has long been a thorny issue in SAP licensing.

Many customers have been caught off-guard in audits by charges for this kind of use (for example, an e-commerce site creating sales orders in SAP, or a robotic process automation tool reading SAP data).

To address this, SAP introduced a Digital Access model (document-based licensing) in recent years. Still, it added complexity as customers had to estimate how many documents (orders, invoices, etc.) external systems generate.

A common misconception is that moving to RISE with SAP will magically eliminate indirect use concerns. In reality, indirect usage policies still apply in the cloud, which is a potential pitfall if you assume otherwise.

By default, a RISE contract typically does not automatically include unlimited digital access rights – you may still need to purchase a digital access license (often as a certain number of document packs) or ensure it’s built into your subscription.

If you neglect this, an audit after you’re on RISE could reveal thousands of documents created via non-SAP interfaces, resulting in an unexpected bill for unlicensed use. The rules haven’t changed: if a non-human or third-party system uses SAP functionality, it must be licensed appropriately.

The confusion often comes because the RISE sales pitch focuses on simplicity and may not emphasize these edge cases. To avoid surprises, inventory all the third-party applications, middleware, portals, and interfaces that connect to your SAP system. Discuss each scenario with SAP during the RISE negotiations.

In some cases, SAP can bundle a certain amount of digital access into the RISE deal (for example, include rights for a defined number of documents or give a discounted package for Digital Access licenses).

If they won’t include it by default, ensure you at least get clarity on how such usage will be measured and charged under your contract. The goal is to have no grey areas: if you know that an external CRM will create customer records or a supplier portal will query inventory data from S/4HANA, have it explicitly addressed in the agreement.

Also, clarify the policy on API calls and integrations in general – RISE subscriptions usually cover standard SAP-provided integrations. Still, heavy use of custom APIs or high-volume data calls might fall outside standard usage.

In summary, treat indirect access under RISE with the same diligence as you would on-prem: identify it, license it, or negotiate it upfront, and avoid the trap of thinking “cloud means free pass for interfaces.”

This will prevent the nasty shock of indirect use fees during an audit when you thought your new subscription had you fully covered.

Bundled Shelfware and Forced Migration of Modules

RISE with SAP is sold as a bundle of software and services, which is convenient, but can also lead to paying for things you don’t need or aren’t ready to use – essentially shelfware. SAP often touts that RISE includes S/4HANA and a set of ancillary cloud services to support your transformation.

For example, most RISE deals come with a starter pack of SAP Business Technology Platform (BTP) credits (for building extensions and integrations), access to SAP Business Network modules (like a limited number of Ariba Network transactions or Logistics Business Network usage), and Business Process Intelligence tools (such as Signavio for process analysis).

These extras are bundled to showcase added value, but not every customer will utilize them fully. A pitfall is that you might pay for these bundled components regardless of actual use.

If you don’t have a plan for deploying new apps on BTP or onboarding suppliers to Ariba in the near term, the included credits or transactions might sit unused while you still foot the bill as part of your subscription.

That unused portion is wasted spending throughout a multi-year contract. To mitigate this, scrutinize the bill-of-materials in SAP’s RISE proposal: identify each component and ask, “Will we use this? How much value do we get from it?”

If something is not immediately needed, consider negotiating its removal for a cost reduction, or at least ensure the quantities are minimal to start (with the ability to grow later when you’re ready). For example, if RISE includes 1,000 Ariba document transactions but you have no near-term plan to implement Ariba, see if that can be flexed down or if SAP can substitute something more relevant.

Another related risk is feeling forced to migrate certain modules or systems as part of the RISE deal, even if they aren’t in your roadmap yet. SAP’s incentive is to move as much of your footprint to cloud subscriptions as possible, which can manifest as pressure to include additional cloud products in the RISE contract.

For instance, if you currently use SAP’s on-prem HR (HCM) or supplier relationship management (SRM) modules, which don’t have a like-for-like S/4HANA module, SAP might push cloud alternatives (SuccessFactors for HR, Ariba for procurement, etc.) bundled into the deal.

The danger is being pushed into migrating those functions on SAP’s timeline, potentially before you’ve evaluated the best solution or when those cloud products aren’t fully mature for your needs.

It can also lead to an over-scoped contract where you are subscribing to procurement and HR cloud modules from day one of RISE, even though your actual move of those areas will happen much later (or you might have chosen a different solution entirely).

This is another form of shelfware: “forced” cloud modules that sit idle while you continue using legacy or alternate systems. Buyers should resist the urge to simply accept every module SAP suggests. Instead, base the scope on your roadmap.

Suppose certain SAP modules will remain on-prem for a while or are undecided. In that case, it may be better to keep their licensing separate until you truly migrate them (or negotiate a flexible clause to add them to RISE when ready at a predetermined discount).

Additionally, clarify how any legacy modules not moving to RISE will be handled – can you keep running them on-prem under existing licenses? Often, companies will end up with a hybrid licensing scenario: core ERP on RISE, but perhaps some satellite systems (like an older BW data warehouse or a plant-floor SAP system) still under perpetual license.

That’s fine, but careful management is required to avoid compliance issues. Ensure SAP doesn’t inadvertently cancel licenses for systems you still need to run locally, and maintain support on those if required.

In summary, treat the RISE bundle like a menu: don’t pay for the full buffet if you only eat a few items. Insist on transparency about each included service’s value, and avoid any unnecessary additions “for future use” unless they’re truly part of a planned near-term project.

Lack of Transparency in Pricing and Scope Limitations

One of the most cited challenges by customers in RISE negotiations is the lack of transparency in pricing and scope.

The RISE proposition rolls software, hardware, and services into one price, but this can make it difficult to tell whether you’re getting a good deal or an inflated one.

Unlike a traditional scenario where you might negotiate a license discount separately, shop around for cloud hosting rates, and decide on support costs, with RISE, you see only a bundled subscription fee. SAP does not typically break out the cost components line-by-line for you.

For example, SAP essentially resells the infrastructure portion (the cloud hosting on AWS/Azure or SAP’s data center), often with a markup or at least without passing through potential cloud provider discounts to you.

You have limited insight into whether the resource sizing and cost assumptions are efficient. If SAP sized your environment too generously, you might be overpaying for unused capacity – or if they sized it too small, you could face incremental charges later when usage grows.

Either way, without transparency, it’s hard to benchmark the cloud cost against doing it yourself. It’s advisable to do an internal cost comparison: calculate what it would cost to run S/4HANA in your cloud subscription with a similar spec and compare that to SAP’s price.

While SAP’s bundled price includes other elements (support, etc.), this exercise can tell you if there’s a large unexplained premium. In some cases, customers found that RISE’s convenience came at a higher price than expected because they couldn’t see, for instance, that they were paying extra for infrastructure that, if purchased directly, would be cheaper.

Another transparency issue is understanding what’s included vs. extra in the RISE scope. The base RISE subscription will have certain limits; if you cross them, additional fees kick in. Examples of such scope limitations include storage capacity, data throughput, user count, and service level features.

A common pitfall is assuming “all-inclusive” and later discovering that certain things were not included in your contract’s baseline.

For instance, standard RISE might include, say, 4 TB of storage—if your database grows beyond that, there could be a steep cost per additional GB. Basic disaster recovery (DR) might also be included (like daily backups and the ability to restore in the same region).

Still, a more robust DR setup (like a hot-warm standby in a separate region for quick failover) might cost extra or not be part of the standard SLA. Similarly, high-availability beyond certain measures, extra non-production systems beyond what’s provided, or premium support tiers (like dedicated support personnel or shorter response SLAs) may incur additional fees.

Without transparency, customers might not realize these nuances until they need them. To avoid this trap, SAP must demand clarity and documentation on all service components. Ask SAP: “What exactly is included in this price? What happens if we need more users, more storage, or additional environments?”

Are there any services we might assume are included that aren’t?” It’s wise to have SAP’s proposal detail the resource entitlements (e.g., number of sandbox systems, included BTP credits, allowed peak transaction volumes, etc.). Identify any likely growth areas – if you anticipate needing significantly more of something (users, transactions, interfaces), negotiate pricing for those expansions now rather than later.

Also, watch for automatic price escalators: Many RISE contracts allow SAP to increase the subscription fee annually (commonly 3-5% per year), which can compound costs over the long term.

Try to negotiate a cap on those increases or fix the price for an initial term. Finally, consider including a benchmarking or transparency clause in the contract, if possible, where SAP commits to discussing cost components or ensuring rates remain in line with market norms for infrastructure.

While SAP may resist breaking out a line-item price sheet, even getting commitments like “if cloud provider costs drop by X%, SAP will pass a portion through at renewal” can help.

The bottom line is: don’t be lulled by the simplicity of a single number – peel back the onion on RISE’s pricing so you fully understand your financial exposure and can manage the subscription cost-effectively over time.

Comparison Table – RISE vs. Traditional SAP Licensing

To see how RISE with SAP differs from a traditional SAP licensing approach, the following table compares key dimensions side-by-side:

(Note: The above table generalizes common differences. Specific contract terms can vary, especially for RISE private vs public cloud, so always refer to your SAP agreement.)

Real-Life Examples of RISE Licensing Challenges

• Dual Environment Overlap – Avoiding Double Pay: A global manufacturer negotiated a RISE deal to move to S/4HANA Cloud. However, it needed to keep its SAP ECC running parallel for a year to ensure a smooth transition. Initially, SAP’s proposal didn’t explicitly allow this dual use beyond 3 months, which would have meant shutting off ECC quickly or potentially paying maintenance on ECC while also paying for RISE – effectively double paying. The company pushed to include a 12-month dual-use clause in the contract, granting rights to run ECC in read-only mode until the S/4HANA go-live was fully stabilized. They also arranged to suspend maintenance fees on ECC during that period. This negotiation saved them from overlapping costs and audit risk; without it, they might have been non-compliant (or paying extra) for the months both systems ran. The lesson: secure written transition rights to avoid paying for two systems or getting caught in a license violation during cutover.
• Surrendering Perpetual Licenses – One-Way Street: A large retail chain with an extensive SAP ECC footprint (and many customized modules) decided to move to RISE as part of a digital transformation. In the contract conversion, they traded in their ECC user licenses for S/4HANA Cloud FUEs. Two years in, they became unhappy with certain aspects of the cloud solution – performance issues and less flexibility for a custom modification they needed. They contemplated reverting to their on-premise model. However, they discovered that after going to RISE, they no longer had rights to their old ECC licenses. Those had been terminated when they signed the RISE contract (SAP had given them some subscription credit, but the licenses were now effectively gone). To go back, they would have to license SAP ERP anew (which was not financially feasible, nor was SAP keen to sell the older version). Essentially, they were locked into the cloud model. This real scenario underscores that moving to RISE is a long-term commitment – customers must go in with eyes open that it is not easy to “undo.” The retailer wished they had done a more gradual pilot or verified that all their requirements could be met in S/4HANA Cloud before committing the entire enterprise to RISE.
• Indirect Access Surprise in the Cloud: A distribution company implemented RISE but later received an unexpected compliance notice from SAP’s audit team regarding Digital Access. The company had a homegrown logistics system interfacing with S/4HANA to create delivery notes and invoices. Under their RISE subscription, they assumed everything was covered. However, SAP’s audit revealed that these externally-triggered documents were not accounted for in their license – they had never purchased a digital access add-on. SAP presented a significant bill for excess document licenses. The company disputed it, noting they thought RISE was all-inclusive, but ultimately had to enter negotiations to buy a digital access document pack to cover past and future usage. Post-incident, they renegotiated their RISE terms to explicitly include a certain volume of documents created via that interface, preventing future surprises. The takeaway: even in RISE, you must identify indirect usage and ensure it’s licensed upfront – a misunderstanding can lead to audit penalties just as it would on-prem.
• Bundled Services – Pay for What You Use: An energy sector firm signed up for RISE and later realized they weren’t utilizing large portions of the bundled offerings. The RISE package came with SAP BTP credits and SAP Ariba network access, which sounded useful. However, in practice, the company focused on migrating core ERP to the cloud; they had no bandwidth in year one to develop on BTP or launch Ariba. Essentially, tens of thousands of dollars’ worth of BTP credits and a bundle of 500 supplier transactions in Ariba went unused – yet the cost for them was baked into the subscription. When renewal time approached, the firm engaged an independent licensing advisor to analyze usage. Armed with data, they were able to negotiate a re-scoped renewal: SAP reduced the BTP credit allocation (and knocked off the associated cost) and removed the Ariba piece entirely, replacing it with a small carve-out for a different service the client needed (additional QA environment capacity for S/4HANA). This example shows the importance of continuously aligning the RISE contract with actual business usage – otherwise, you might be paying for shelfware. It’s far better to start smaller and add services as needed than to buy into an over-bundled package that overruns your requirements.
• Negotiating Renewal Protections: A services company that had moved to RISE (private cloud edition) learned during initial negotiation that renewal terms were a big risk. SAP’s standard contract had a 5-year term with a clause that pricing at renewal would be “at then-current rates,” with no cap. Concerned that SAP could hike the price significantly in five years (once they were fully dependent on RISE), the company fought to insert a price cap clause. They managed to negotiate a provision that the renewal increase would be limited to a single-digit percentage, and that they could reduce the user count by up to 10% at renewal if their business contracted. These concessions were hard-won, but proved valuable when, indeed, in year five the company’s headcount had shrunk slightly and SAP’s list prices had risen – thanks to the negotiated clause, the customer avoided a major cost jump and right-sized their subscription downward without penalty. The real-life moral: treat the initial RISE contract negotiation as the time to safeguard your future flexibility. Once you’re in the cloud, your leverage is reduced, so lock in protections early (caps, flex options, etc.) while SAP eagerly signs you.

Playbook – What to Do (Mitigation Strategies for RISE Deals)

• Conduct Comprehensive Due Diligence Before Committing: Preparation is your best defense against RISE-related risks. Before you even sit at the negotiation table, inventory and analyze your current SAP usage in detail. This means auditing how many users are active (and at what license levels), what modules and custom systems you have, and what third-party integrations exist. Identify any shelfware in your current environment – unused modules or far more named users than needed – as these can be leveraged during negotiation (e.g., you might drop them in exchange for credit). Simulate how those translate into the RISE model: How many FUEs would you truly need if you cleaned up the user list? Which specific cloud services (like Analytics Cloud, BTP, etc.) will you require as part of the deal? Doing this homework lets you right-size the RISE contract and avoid over-provisioning. Many companies engage specialist tools or license optimization services to get these numbers, for example, by analyzing historical user login data to see peak usage. This due diligence should also cover financial analysis: compare the total cost of ownership of sticking with on-prem (plus upgrades) vs. going RISE over a 5-10 years. If staying on ECC or moving to S/4HANA on-prem looks cheaper in a model, you’ll have data to push SAP for deeper discounts to make RISE worthwhile. Also, research SAP’s policies and programs (like conversion credits, dual-use allowances, etc.) so you know what to ask for. The goal is to enter talks with a clear picture of what you need and don’t and what your walk-away alternatives are to avoid being swayed by SAP’s packaged pitch that might contain more than you bargained for.
• Negotiate Key Contract Clauses and Protections: A RISE contract is complex and covers many elements, so negotiation must go beyond just getting a discount on the headline price. Focus on securing specific clauses that protect your interests now and in the future. Some critical levers to consider: (1) Price caps on renewals – since you’ll have to renew the subscription to keep using SAP, insist on a limit (for example, no more than CPI or a single-digit percentage increase) or even negotiate the renewal rate upfront. This prevents nasty surprises after the initial term. (2) Flexibility to adjust usage – try to include rights to reduce or adjust your subscription if business conditions change. While SAP may not allow mid-term reductions, you might negotiate the ability to true-down at renewal, or to swap some unused services for others of equal value. Also consider a clause allowing you to temporarily extend the contract term at the same rate (if, say, you need a few extra months beyond term to transition – otherwise SAP could use a hard deadline as leverage). (3) Include Transition and Legacy Rights – as discussed earlier, get it in writing that you can run legacy systems for X months in parallel, and/or access historical data in the old system after cutover (read-only access for compliance). If you foresee needing to keep an ECC instance for archival purposes, ensure SAP grants a license for that use case even after conversion. (4) Explicitly Address Indirect Use and Add-Ons – don’t leave it implied. If you need digital access to documents, get a defined quantity included. If you have a heavy interface scenario, describe it in the contract and confirm it’s allowed under the subscription. List any additional SAP cloud products you include (e.g., SuccessFactors, Ariba, Concur) with their metrics and ensure the contract states what happens if you exceed the included amounts (e.g., the overage rate for extra documents or extra BTP consumption). (5) Service Level and Scope Clarity – ensure the contract (and related documents like the RISE Scope of Services) clearly defines the performance SLAs (uptime, response times), support expectations, and which party handles what (for instance, data backups, disaster recovery provisions, responsibilities in case of outages). If you have specific needs like data residency or particular security standards, include them. Anything not spelled out will likely cost extra later, so negotiate it now. (6) Termination Assistance or Exit Options may sound pessimistic during a fresh deal, but wise negotiators plan for “what if this doesn’t work out.” While SAP is unlikely to give a full walk-away clause, you can ask for some form of termination assistance. This could be an agreement that if you decide not to renew RISE, SAP will allow access to your data for X months and a conversion option to a perpetual license (even if at a cost) rather than leaving you completely stranded. SAP might resist, but even having an off-ramp framework documented is better than nothing. Throughout negotiation, maintain a stance of transparency and documentation. Every promise from sales (e.g., “Oh, we’ll allow you 12 months dual usage, no problem”) should be incorporated into the contract or an addendum. Remember that once you sign, the contract governs the relationship, not the friendly assurances. It is often helpful to have a licensing-savvy attorney or advisor review the documents, as SAP’s cloud contracts have many embedded terms that favor SAP (for example, clauses about data deletion, indirect use, or audit rights,) which you may want to adjust.
• Engage Independent Licensing Experts: Don’t go it alone, especially if your team doesn’t deal with SAP licensing daily. Independent SAP licensing advisors (such as specialist consultancies like Redress Compliance, among others) can be invaluable. They bring deep knowledge of SAP’s tactics, benchmarks from other global negotiations, and an unbiased perspective focused on your interests (unlike SAP, whose goal is maximizing their cloud revenue). An independent expert can help you validate SAP’s proposals. For instance, they can tell you if the FUE count SAP suggests is reasonable or padded, if the cloud infrastructure sizing looks right, or if the contract terms have concerning language. They might spot hidden costs or ambiguous terms that a layperson might miss. Moreover, they often know what concessions SAP has given other customers, strengthening your position (“we’ve seen SAP agree to a price-lock at renewal for a similar client – we want the same”). Involving such experts early, ideally in the strategy and planning phase, means approaching SAP with a strong fact base and a clear negotiation playbook. They can also run interference in tricky discussions – sometimes having an external licensing consultant ask the tough questions or challenge SAP’s assertions takes the pressure off your internal team. Additionally, these advisors can simulate compliance audits, helping you find and fix any indirect usage or user classification issues before SAP does. Consider also leveraging them post-deal for ongoing compliance monitoring (some offer managed services to track your license use). The key point is that SAP’s licensing is a specialized domain; having seasoned negotiators and technical licensing experts on your side levels the playing field. The cost of their services is often a fraction of what you save through a better negotiated contract or avoided audit penalties. Ensure any advisor is independent (not reselling SAP services) and has a strong track record with SAP contract reviews. It’s analogous to hiring a building inspector before buying a house – you want an expert who works for you to uncover any issues and ensure you’re making a sound decision.
• Maintain Active Compliance and Optimization Post-Migration: Signing the RISE contract is not the end of the journey – in fact, maintaining control over licensing and usage is an ongoing discipline. Implement a governance plan for your SAP usage under RISE to avoid cost creep and compliance risks over time. First, assign clear ownership (perhaps your SAM – Software Asset Management team, or an empowered IT finance manager) to monitor your consumption against contract entitlements. This includes tracking the number of users provisioned vs. the FUEs contracted, the volume of digital documents created (if those are limited), and the consumption of any included services like BTP credits or Ariba transactions. SAP will likely give you tools or a portal to see usage stats – make sure someone is looking at them regularly. If you start nearing thresholds (e.g., using 90% of your included storage, or your user count grows beyond what you contracted), you’ll want to plan rather than reactively pay steep overage fees. Perhaps you can true-up more cost-effectively or negotiate an add-on before an audit forces it at list price. Second, the practice of periodic license audits should be continued internally. Just because it’s cloud doesn’t mean you should stop checking if all users are still active or if their roles match the type of license (advanced vs. core use) you planned. Remove or reassign unused accounts promptly to stay efficient. If you have a pool of FUEs, avoid letting every request for access inflate usage – still apply discipline (e.g., joiners and leavers processes to ensure former employees are deactivated). Third, keep documentation of your entitlements and any communications with SAP regarding usage. In case there is a dispute (e.g,. SAP says you owe more for indirect use), you will benefit from having the original contract, any side agreements, and even emails where clarifications were made. It’s your evidence of what is permitted. Fourth, manage the hybrid environment carefully if you have one. You might still have some on-premise licenses for products outside of RISE – those remain subject to classic audit. Ensure you’re not accidentally using them beyond their scope (for example, using an old engine license in a new way not allowed). If you reduced your on-prem users when moving some to RISE, keep documentation of that division in case SAP audits the on-prem side and questions the reduction. Finally, continuously optimize costs throughout the RISE lifecycle. Before each renewal or expansion, revisit your usage and see if you can drop anything. Perhaps after a couple of years, you realize you haven’t touched a certain module – maybe you can remove it from the contract and save money. Or conversely, maybe your usage of a particular service exploded – you’ll want to negotiate a better bulk price for the next tranche of capacity. Engaging your independent advisor annually for a “health check” can pay off, as they might spot an area where you’re over-licensed (and can cut costs) or under-licensed (and can proactively address it on favorable terms). Also, keep an eye on SAP’s product strategy; new licensing programs or replacements might emerge, and you should be ready to take advantage if they simplify compliance or reduce costs (for instance, if SAP were to adjust the Digital Access model or offer new bundles). In short, treat RISE not as a set-and-forget subscription, but as a dynamic investment you actively manage, much like cloud infrastructure in general; oversight is needed to prevent sprawl and surprises. With vigilant management, you can enjoy the benefits of RISE’s cloud model while keeping financial and legal control firmly in hand.