Article | SAP | 10 min read
Negotiating RISE with SAP: what nobody tells you
The migration is the negotiation. The clauses that matter, the FUE problem, the hyperscaler choice, the exit terms most customers never read.
The migration is the negotiation. The clauses that matter, the FUE problem, the hyperscaler choice, the exit terms most customers never read.
RISE with SAP is not a migration. It is a multi-year subscription contract that carries technical, commercial, and operational consequences for the duration of the term. The migration is the negotiation, and most of the leverage points sit in clauses that look harmless on a first read. This is what we tell clients in the eight to twelve weeks before they sign a RISE contract.
Most procurement leaders treat RISE as a single document. It is not. It is a software license (S/4HANA Cloud Edition or Private Edition), a managed service (SAP runs the technical operations), and a hyperscaler subscription (the underlying infrastructure on AWS, Azure, or GCP). Each of those carries its own set of terms, its own escalation rules, and its own exit consequences. Reading them as one document leaves the customer signing commitments they have not understood.
The right approach is to deconstruct the RISE bundle into its three components, evaluate each on its own merits, and then negotiate the points where the components interact. The interaction points are typically where the largest risks sit, because they are not addressed cleanly in any single document.
RISE pricing is built on Full Use Equivalents (FUE), a unit that converts named users from an ECC contract into a normalised RISE quantity. The conversion factor varies by user type. SAP's published conversion factors are anchored at the high end of the range, which means the FUE calculation typically inflates the user count by 20 to 40 percent versus a literal ECC-to-RISE mapping.
The mistake to avoid is accepting SAP's first FUE calculation. The right response is to model the user population at the level of actual transaction frequency and module access, then negotiate the conversion factor down toward the realistic end of the range. We have seen FUE counts reduced by 25 to 30 percent through this exercise, with no change in the technical user population.
SAP will offer RISE on AWS, Azure, or GCP. The technical platforms are roughly equivalent for most workloads. The commercial differences are substantial. Each hyperscaler has its own discount structure with SAP, its own committed-spend treatment, and its own approach to bringing the customer's existing hyperscaler contracts into the RISE arrangement.
The negotiation move is to treat hyperscaler selection as a separate procurement track. Force the three hyperscalers to bid for the RISE workload, separate from the SAP licensing decision. The customer's existing hyperscaler relationship matters here. If you already have a $20M Azure commit, RISE on Azure may produce a different commercial outcome than RISE on AWS, even at the same headline price, because the Azure consumption can offset against the existing commit.
One of the marketing claims around RISE is that the move to digital access licensing simplifies the indirect access problem. In practice it changes the shape of the problem rather than eliminating it. Under RISE, indirect access is licensed via the digital access document model, which prices on the volume of inbound documents created in S/4HANA from external systems.
The risk is that customers under-estimate the document volumes from connected systems (web portals, ecommerce platforms, partner integrations, IoT feeds) and end up with materially under-licensed RISE contracts that are corrected at the first true-up. The fix is to instrument the source systems before signing, model the realistic document volume, and contract for it explicitly. The alternative is signing for a notional volume and discovering at month 14 that the actual volume is two to three times higher.
RISE exit terms cover three things: data extraction, transition support, and the cost of leaving early. The default terms in SAP's standard RISE contract are not unreasonable, but they are also not customer-favorable. The data extraction provision typically gives the customer a defined window to extract data after termination. The transition support provision is usually time-limited and fee-bearing. The early termination clause typically requires payment of the remaining contract value or some defined fraction of it.
None of these are deal-breakers, but all three should be negotiated explicitly. We typically push for: a longer data extraction window with explicit format requirements, transition support priced at a defined hourly rate rather than a custom statement-of-work, and early termination structured as a step-down rather than a cliff. These changes do not always succeed but the asks are reasonable and SAP is responsive to them at signing time. Post-signing, none of these are negotiable.
RISE contracts include an annual price escalation that is typically uncapped or capped at a high inflation index. Over a five-year term this compounds materially. A customer who signs a five-year RISE contract at $10M annual value with a 5 percent uncapped escalation pays $12.16M in year five, against a notional level of $10M. The cumulative cost over five years is $11.4M higher than the level scenario.
The buyer-side move is to cap the annual escalation at a lower number, ideally inflation indexed but with a hard ceiling. SAP will resist any cap below 4 percent. The negotiating range is typically 2.5 to 4 percent depending on contract value and term length. Anything above 4 percent should be considered red.
SAP's RISE SLA documents look comprehensive. Read carefully and the actual obligations are narrower than they appear. The 99.9 percent uptime commitment typically excludes scheduled maintenance windows that are at SAP's discretion. The performance commitments are at the platform level, not the application level. The remediation in case of breach is service credits, capped at a defined percentage of monthly fees, with no path to material recovery.
Customers who treat RISE as a managed service often assume the SLA carries enterprise-grade availability and performance commitments. It does not. The SLA is a baseline that protects SAP's interests at least as much as the customer's. If the workloads under RISE are mission-critical, the SLA needs to be supplemented with contractual commitments that go beyond the published document. That is a negotiation point at signing, not a complaint to make at month 14.
RISE is the right answer for some enterprises and the wrong answer for others. The decision should be made on a clear-eyed read of the technical, commercial, and operational implications, not on a vendor pitch about simplification. The negotiation should happen during the eight to twelve weeks before signing, not after. And the contract that gets signed should reflect the customer's understanding of what they are committing to, not the vendor's preferred framing.
Read RISE with SAP: The Buyer's Negotiation Guide for the full clause-by-clause framework. Read the SAP audit manufacturer case study for what audit risk looks like in the SAP world. Or request a confidential RISE review if you have a contract on the table.
500+ enterprise clients. 11 vendor practices. Gartner recognized. One conversation can change what you pay for the next three years.
Monthly vendor intelligence and negotiation insights for IT leaders. Free.
