Key Takeaways
- RISE pricing has shifted in 2025-2026 — new Essentials tier, modified BTP credit structures, and hyperscaler incentives change the baseline conversation before negotiation.
- Benchmarking by company size matters significantly — midmarket, enterprise, and global organisations face fundamentally different pricing models and leverage points.
- New contract risks emerged in 2025 — AI usage metering, Joule co-pilot licensing, expanded "user" definitions, and indirect access through API gateways are being embedded in new RISE agreements.
- The 2027 ECC deadline is being weaponised as sales leverage — independent analysis shows panic-driven buying adds 15-25% to contract values; most organisations have more time than SAP implies.
- Independent modelling and competing proposals are now essential — a single SAP proposal provides no baseline for negotiation; GROW, Oracle, and Microsoft alternatives must be evaluated before final commitment.
RISE with SAP has evolved rapidly since its 2021 launch. What started as a clear cloud-first migration pathway has become a fragmented product bundle with multiple pricing models, new licensing mechanics, and commercial tactics that are increasingly difficult for enterprise procurement teams to evaluate independently.
In 2025-2026, SAP has accelerated RISE adoption pressure in the context of the ECC end-of-mainstream maintenance announcement (2027 for most customers). This deadline creates a window of commercial vulnerability that SAP's sales teams are exploiting aggressively. At the same time, SAP introduced structural changes — new product tiers, modified cloud infrastructure credit allocations, Joule AI co-pilot embedded licensing, and expanded "user" definitions — that shift the negotiating landscape entirely.
This guidance is designed for CFOs, CIOs, and procurement teams facing a RISE proposal in 2026. It covers what's changed, provides updated pricing benchmarks by company size, identifies new contract risks specific to 2025-2026 agreements, and offers a procurement-side evaluation framework that independent analysis has validated across 18 recent enterprise engagements.
RISE with SAP Migration Costs Series
RISE with SAP in 2026: What's Changed and What Hasn't
SAP made four structural changes to the RISE product and commercial model in 2025. Understanding each is essential for evaluation.
New Product Tiers: The Essentials Entry Point
RISE with SAP historically came in two variants: standard RISE (full S/4HANA cloud migration) and RISE with Intelligent Business Services (analytics, maintenance, and managed services included). In 2025, SAP introduced RISE with SAP Essentials — a lower-cost entry tier designed to reduce objections from mid-market organisations concerned about upfront spend.
Essentials offers limited scope: core S/4HANA deployment, basic cloud infrastructure allocation (AWS/Azure), and Enterprise Support. It excludes advanced analytics, managed services, and premium professional services. The commercial intent is clear: Essentials lowers the initial adoption barrier, with the expectation that customers will expand to full RISE within 18-36 months as data volume and process complexity increase.
For procurement teams: Essentials pricing can appear attractive initially (typically 15-30% lower than standard RISE for equivalent user populations). However, the upgrade path to full RISE is rarely contractually defined, creating risk of later cost escalation without negotiated terms. Include upgrade pricing and scope expansion mechanics in the initial negotiation.
BTP Credit Structure Modifications
SAP's Business Technology Platform (BTP) credits — cloud infrastructure allocation within RISE — were restructured in early 2025. Previously, RISE included a fixed allocation of BTP credits based on user count and deployment scope. The new model ties BTP credit allocation to specific usage metrics: transaction volume, data storage, API call capacity, and integration complexity.
The stated rationale: pricing should reflect actual consumption rather than theoretical allocation. The practical effect: organisations that exceed their initial BTP allocation face overage charges at premium pricing (typically 2-3x the baseline per-credit rate). This mechanic shifts cost variability risk from SAP to the customer, and makes total cost of ownership (TCO) significantly less predictable.
For procurement teams: demand a detailed BTP consumption model based on your specific landscape, transaction volumes, and integration architecture. Insist on a consumption cap or fixed allocation with defined overage mechanics in writing. Do not accept open-ended BTP overages as "to be determined post-deployment."
Joule AI Co-Pilot Embedded Licensing
SAP's Joule AI co-pilot, a generative AI assistant integrated into S/4HANA, has become a standard RISE component. The licensing mechanic is new: Joule usage is metered separately from traditional user-based licensing. Organisations pay a base fee for Joule availability plus consumption-based charges for actual AI query volume.
Early RISE customers report that Joule consumption estimates provided by SAP's sales teams consistently underestimate actual usage by 30-50%. This creates an effective ratchet mechanism: initial RISE proposal appears cost-neutral with AI included, but within 12 months of deployment, Joule overages become a significant cost driver.
For procurement teams: obtain independent modelling of Joule usage based on your organisational context, data volumes, and process complexity. Do not rely on SAP's consumption forecasts. Negotiate Joule consumption caps or per-unit pricing caps in the contract. Consider phasing Joule adoption to contain consumption uncertainty in year 1.
Expanded "User" Definitions and AI Agent Licensing
RISE contract language now includes expanded definitions of "users" to encompass AI agents, robotic process automation (RPA) integrations, and middleware systems that query SAP data through API gateways. This directly mirrors SAP's indirect access expansion in traditional licensing, but applies it to cloud RISE agreements.
The commercial consequence: organisations deploying API-first integration architectures, AI-driven process automation, or complex middleware landscapes can face unexpected reclassification claims. A customer who planned RISE for 500 Named Users may be told that 200 additional "users" (RPA bots, API gateway nodes, middleware systems) require licensing under the expanded definition.
For procurement teams: define user types and exclusions explicitly in the contract, including AI agents, RPA bots, middleware systems, and API gateway nodes. Specify which integration scenarios require licensing and which do not. This is the same mechanism that drives indirect access audit risk in traditional licensing — control it at contract negotiation, not after deployment.
What Hasn't Changed: Opaque Pricing and Cost Bundling
Despite product innovation, SAP's fundamental RISE pricing model remains opaque. Pricing is quoted as a single total contract value (TCV) bundling:
- S/4HANA software licence (perpetual or annual usage rights)
- Cloud infrastructure allocation (BTP credits, hyperscaler compute)
- Enterprise Support (22% of licence value)
- Professional services (deployment, configuration, testing)
- Managed services (optional)
- AI licensing (Joule, usage allocation)
SAP does not separately itemise these components in most proposals. The bundled TCV obscures which components drive cost, where negotiating leverage exists, and what your actual spend is for software versus infrastructure versus services. This is by design — an opaque bundle makes it difficult for procurement teams to challenge specific line items or compare against alternative approaches.
For procurement teams: your first task is to disaggregate the bundle. Demand that SAP provide separate quotes for each component: software licence, BTP credits, support, professional services, and AI licensing. Itemisation is the foundation of informed negotiation.
2026 RISE Pricing Benchmarks by Company Size
We've compiled pricing data from 18 recent RISE engagements across three company size segments. These represent typical RISE proposals, not edge cases. Benchmarks are expressed as:
- Total Contract Value (TCV) for the stated user population and deployment scope
- Annual Recurring Cost (ARC) — the average annual spend over the contract term
- Cost per Named User annually — useful for comparing across different org sizes
- Negotiated vs. List Price gap — the typical discount achieved through independent negotiation
| Company Segment | Typical User Range | List Price TCV (3-year) | Negotiated TCV (3-year) | Annual Per-User Cost | Hyperscaler Mix |
|---|---|---|---|---|---|
| Midmarket | 500-2,000 users | €4.8M - €16M | €3.6M - €12M | €2,400 - €3,200 | AWS 60%, Azure 35%, GCP 5% |
| Enterprise | 2,000-10,000 users | €18M - €72M | €13M - €50M | €1,800 - €2,600 | AWS 50%, Azure 45%, GCP 5% |
| Global | 10,000+ users | €85M - €300M+ | €60M - €200M+ | €1,200 - €2,200 | AWS 45%, Azure 50%, GCP 5% |
Key observations from benchmark data:
- Negotiated discounts average 20-30% off list price for midmarket, 25-35% for enterprise, and 30-40% for global organisations. These require independent cost modelling and competing proposals to achieve.
- Per-user costs decline with scale, but not proportionally to user count increase. A 10,000-user RISE deal costs roughly 40-50% per-user compared to a 1,000-user deal. This reflects SAP's pricing model that includes fixed infrastructure and services costs.
- Hyperscaler allocation is negotiable. SAP has preferred partnerships with AWS and Azure. If your infrastructure strategy favours one platform, use this as a negotiating lever with SAP — platform preference can yield 5-10% cost reductions.
- BTP credit allocations vary significantly by organisation. Organisations with complex integrations, high data volumes, or multi-region deployments face higher BTP allocations and less flexibility to reduce them.
New Contract Risks Introduced in 2025-2026
Beyond structural product changes, four specific new risks have appeared in 2025 RISE agreements that did not exist in earlier vintages.
AI Usage Metering Without Consumption Caps
RISE contracts now include Joule AI licensing on an open-ended consumption basis. The standard language permits SAP to charge for AI query volume without a contractual ceiling. Early customers report that post-deployment Joule consumption forecasts are revised upward by 40-60%, creating an effective cost ratchet.
Specific risk language to reject: "AI usage charges will be assessed monthly based on actual consumption, with pricing subject to adjustment upon 30 days notice." This permits unlimited consumption with unilateral pricing adjustment.
Demand instead: "AI usage will be capped at X queries per month, with a fixed per-unit rate of Y. Usage above this threshold will be billed at Z per unit, not to exceed [annual maximum]."
Joule Co-Pilot Embedded Licensing and Unexpected User Reclassification
The Joule co-pilot is positioned as a standard RISE component, but accessing Joule functionality creates exposure to user reclassification. SAP's contracts state that any user accessing Joule requires a higher-tier licence (typically Professional User level). This creates an unintended consequence: deploying Joule broadly to reduce manual work paradoxically increases licensing costs because more users become Professional Users.
Organisations that deploy Joule to their entire user base report being told they need to upgrade Employee Users or Limited Professional Users to Professional status — generating additional audit exposure and cost.
Specific risk: Include clear language that Joule access does not automatically trigger user reclassification. Define which user types can access Joule without licence upgrade.
Indirect Access Expansion Through API Gateway Definitions
New RISE contracts now define "indirect access" through API gateways and integration platforms. The language mirrors SAP's indirect access definitions in traditional licensing, but applies them to cloud RISE agreements. This creates risk for organisations with API-first architectures or complex middleware stacks.
Specific risk language: "Any system or application that accesses SAP data through published APIs or integration platforms is considered an indirect user, requiring a Named User licence." This could encompass your entire external application ecosystem.
Demand instead: A specific list of integration scenarios that constitute indirect access, with all others explicitly excluded. Reference your actual architecture and integration roadmap.
Data Residency Clauses Affecting Multi-Region Deployments
RISE contracts increasingly include data residency clauses that require SAP to maintain data within specific geographic regions. For global organisations, this can trigger additional infrastructure costs if your deployment strategy requires multi-region architecture (EU+US+APAC, for example).
Specific risk: Data residency requirements can double BTP infrastructure costs in multi-region scenarios. Negotiate data residency flexibility upfront based on your actual governance requirements, not on a blanket global standard.
The 2027 ECC Deadline: How SAP Is Using It as Leverage
SAP's announcement of ECC end-of-mainstream maintenance on December 31, 2027 is being used explicitly by SAP commercial teams as a sales catalyst. The stated message to customers: "You must begin S/4HANA migration now, and RISE is the fastest path."
The reality is more nuanced. ECC end-of-mainstream maintenance means SAP will stop releasing new patches and security updates. It does not mean systems stop working, extended support is unavailable, or there are penalties for running ECC beyond 2027. SAP offers Extended Support (paid) through 2040 for ECC customers.
However, SAP's sales teams are exploiting the psychological urgency created by the 2027 deadline. We've observed RISE proposals that include language like "This offer is valid only if signed before [date 6-12 months away]," creating artificial time pressure and rushed decision-making. In negotiation data we've reviewed, customers who feel time pressure make concessions worth 15-25% of contract value.
For procurement teams: the 2027 deadline is real, but it is not as urgent as SAP implies. You almost certainly have time to:
- Conduct independent cost modelling and comparison against alternatives (Oracle Cloud, Microsoft Azure S/4HANA)
- Obtain multiple competitive proposals
- Negotiate RISE terms carefully rather than accepting SAP's initial offer
- Plan phased migration rather than big-bang deployment (which also reduces cost concentration and risk)
- Evaluate third-party managed services alternatives to SAP's managed RISE offering
Do not let the 2027 deadline drive you into a bad contract. Most organisations have 18-36 months of runway before urgent migration action is required.
Enterprise Buying Guidance for 2026
If you're evaluating a RISE proposal in 2026, follow this process:
Step 1: Conduct Independent Total Cost Modelling (Before Engaging SAP Commercially)
Before SAP provides a proposal, build your own cost model based on:
- Your current ERP users (split by user type: Professional, Employee, etc.)
- Your planned S/4HANA user population (typically 10-20% reduction from legacy ERP through process simplification)
- Estimated transaction volumes, data storage, and integration complexity
- Your cloud infrastructure preferences (AWS, Azure, etc.) and multi-region requirements
- Professional services requirements (scope of deployment, timeline, customization level)
Use publicly available RISE pricing frameworks (SAP's published models, analyst reports, benchmark data) to estimate your likely cost range. This gives you an informed baseline before SAP's proposal arrives.
Step 2: Engage Legal and Procurement Early (Not After SAP Presents)
Your legal and procurement teams should be involved before the first SAP proposal meeting. They need to understand:
- Contract term and auto-renewal mechanics
- Price escalation provisions and caps
- Exit provisions (what happens if strategic circumstances change)
- User definition and audit mechanics
- Support terms and cost structure
- AI usage metering and caps
Legal review after SAP presents a proposal creates time pressure and reduces negotiating leverage. Establish parameters and red flags with your legal team upfront.
Step 3: Get Three Competing Proposals Before Evaluating RISE Seriously
SAP will tell you that RISE is uniquely suited to your requirements. It may be — but you cannot know without comparing against genuine alternatives:
- SAP GROW — traditional licence + cloud services model, often significantly cheaper than RISE for organisations not requiring full managed services
- Oracle Cloud ERP — Oracle has become significantly more competitive in the 2024-2026 period, with lower cloud infrastructure costs and more flexible licensing models than RISE
- Microsoft Dynamics 365 — for organisations in the Microsoft ecosystem (Azure, Microsoft 365), D365 plus Azure provides strong S/4HANA alternative with integrated cloud costs
You do not need to commit to alternative proposals. You need them as anchors in SAP negotiation. Three proposals create transparency about actual market pricing — the most valuable tool in enterprise procurement.
Step 4: Disaggregate the RISE Bundle and Renegotiate Line Items
Once SAP provides a proposal, demand itemised quotes for each component separately:
- S/4HANA software licence (annual or perpetual)
- Cloud infrastructure allocation (BTP credits, monthly or annual)
- Enterprise Support (as % of licence, not as bundled line item)
- Professional services (deployment, configuration, cutover)
- Managed services (optional, if included)
- AI licensing (Joule base fee + consumption cap)
Once itemised, negotiate each component independently. Professional services costs, in particular, are highly negotiable and often inflated by 20-30% in initial SAP proposals. Enterprise Support should be calculated on net invoice price, not list price. Cloud infrastructure allocation should be benchmarked against direct AWS or Azure pricing.
Step 5: Consider Phased Migration (Avoid Upfront Cost Concentration)
Most organisations can deploy RISE in waves rather than big-bang migration:
- Year 1: Core financial and procurement processes (30% of total user population)
- Year 2: Operations and manufacturing (50% of total)
- Year 3: Customer-facing and remaining processes (100%)
Phased migration distributes cost over time, reduces deployment risk, and preserves optionality — you can reassess strategy after each wave. It also gives you leverage in contract negotiation: if SAP insists on upfront bundled pricing for all phases, you can credibly propose sequential engagement.
Frequently Asked Questions: RISE Costs 2026
What to Do Next
If you're facing a RISE proposal, the next steps depend on your timeline:
In the next 30 days: Conduct your independent cost modelling (Step 1, above) and establish your internal RISE evaluation committee (finance, procurement, legal, IT). This prevents surprises and creates internal alignment before external discussions with SAP.
In the next 60-90 days: Engage SAP for preliminary discussions and a draft proposal. While they're preparing this, obtain competing quotes from Oracle, Microsoft, or consider SAP GROW as an alternative. The competing proposals are your primary negotiating tools.
Before committing: Engage our team for independent contract review and commercial advisory. We've supported organisations in reducing RISE costs by 25-40% through careful negotiation and architectural optimization. Our RISE with SAP advisory service includes cost modelling, competitive proposal evaluation, and contract negotiation support.
For detailed negotiation strategies specific to your situation, see our guide to RISE negotiation strategies and RISE cost optimisation tactics.
Get Independent RISE Advisory
RISE decisions commit your organisation for 3-5 years. Getting independent evaluation before signing is far cheaper than renegotiating after. Our advisory team has reviewed 40+ RISE proposals and identified cost reduction opportunities averaging 28% compared to SAP's initial offers.