Key Takeaways
- SAP will not volunteer unfavourable commercial information about hyperscaler choice — you must ask directly, and get answers in writing before signing.
- 10 critical questions force transparency on infrastructure costs, exit mechanics, data residency, hyperscaler credits, and SLA definitions.
- Documented SAP responses create contractual record that protects you if SAP later claims different commercial terms.
- Not all questions can be answered by SAP alone — some require direct engagement with AWS, Azure, or GCP to understand their commitment to your RISE contract.
- Hyperscaler choice locks you in for the contract term. The questions below help you understand the true cost and consequences of that lock-in.
Why These Questions Matter
RISE with SAP is a managed service. Your choice of hyperscaler — AWS, Microsoft Azure, or Google Cloud Platform — determines infrastructure cost, data residency, integration architecture, and exit mechanics for the entire contract term. This choice is effectively irreversible. Changing hyperscalers mid-contract is contractually complex and commercially expensive. Yet most enterprise buyers make this choice with minimal transparency from SAP about the actual cost and implications.
SAP's account team will not volunteer commercially unfavourable information about hyperscaler choice. They have no incentive to. Your infrastructure cost will vary by hyperscaler. Your exit costs will vary by hyperscaler. The availability of BTP services varies by hyperscaler and region. SLA mechanics differ. Yet these differences are rarely discussed upfront in explicit terms.
The 10 questions below are designed as a buyer's interrogation framework. They force transparency. They create a documented record of SAP's commercial position before you sign. And they give you the information you need to make an informed hyperscaler choice — rather than a choice based on incomplete information or SAP's implicit preferences.
For comprehensive guidance on RISE hyperscaler strategy, see our complete enterprise guide for hyperscaler choice in 2026, and our detailed analysis of negotiation strategies for hyperscaler choice.
RISE Hyperscaler Choice Series
The 10 Essential Questions to Ask SAP About Hyperscaler Choice
Why this matters: SAP's standard RISE pricing includes infrastructure, but the Order Form typically lumps all infrastructure cost into a single line item. You need the underlying cost structure to understand what you're actually buying from each hyperscaler. Compute, storage, and network have different unit economics across AWS, Azure, and GCP. Without this breakdown, you cannot compare hyperscaler options on cost, and you cannot forecast the true cost impact of future workload changes.
What to expect: SAP's sales team will initially resist providing this level of detail, claiming it "varies by deployment." Push back. Demand a specific cost structure for your assumed workload. Get it in writing as an exhibit to the contract. This becomes your baseline for cost verification and dispute resolution if SAP's actual charges differ materially from the forecast.
Red flag: If SAP cannot or will not provide per-unit cost breakdown, you are signing a contract where infrastructure cost is opaque and unverifiable. This is high risk. Escalate this question to SAP's commercial leadership before signature.
Why this matters: SAP's BTP (Business Technology Platform) is a key part of the RISE value proposition. Many RISE customers plan to migrate workloads to BTP as part of the modernisation strategy. But BTP service availability is not uniform across hyperscalers or regions. If you need your data to reside in the EU (for GDPR or regulatory reasons), specific BTP services may not be available on all hyperscalers in EU regions. This constraint could eliminate a hyperscaler option or force significant workaround costs.
What to expect: SAP maintains an official BTP regional availability matrix. Ask for it. Match it against your data residency requirements and planned workload. If a hyperscaler option lacks critical BTP services in your required region, you need to know this before choosing that hyperscaler.
Follow-up question: "If BTP service X is not available in region Y, what is SAP's roadmap to make it available? Is this documented in SAP's published service roadmap?" SAP often has plans to expand BTP availability, but these are not always obvious from public documentation.
Why this matters: Most large enterprises have existing commitments with hyperscalers — Azure Enterprise Agreements, AWS Enterprise Discount Program agreements, or Google Cloud Committed Use Discounts. These commitments give you negotiated unit rates on compute and storage. The question is whether RISE infrastructure — which SAP manages and bills through a single line item — qualifies for those discounts, or whether SAP's infrastructure charges sit outside your existing commitments and consume the commitment without generating the discount.
What to expect: The answer varies by hyperscaler and by the specific terms of your existing commitment. SAP will usually claim that RISE infrastructure qualifies for your commitment discounts. But get this in writing, with specifics about which cost components qualify. If your AWS EDP gives you 30% off compute, confirm that the compute portion of RISE infrastructure qualifies for that discount in the Order Form billing mechanics.
Red flag: If SAP claims RISE infrastructure does not qualify for your existing hyperscaler commitments, this is a material cost issue. It means you're paying full list price for RISE infrastructure while your existing workloads get discount pricing on the same hyperscaler. This is worth a separate commercial negotiation with SAP.
Why this matters: The hyperscaler choice is made at contract signature. But circumstances change. SAP cloud costs might shift relative to the other hyperscalers. Your data residency requirements might evolve. You might discover that a particular hyperscaler integration is more complex than expected. The question is: what does your RISE contract allow you to do if you want to change hyperscalers after the initial contract has been signed?
What to expect: Most RISE contracts do not explicitly allow mid-contract hyperscaler migration. The contract assumes you've chosen a hyperscaler and will remain with that choice for the contract term. If you want to change, you typically need SAP's consent and you'll likely be charged for the migration effort. Get the mechanics in writing: (1) How much notice must you provide? (2) What does SAP charge for hyperscaler migration? (3) Does migrating to a different hyperscaler require a new contract? (4) What happens to the remaining contract term — do you get credit for the cost already incurred on the old hyperscaler?
Negotiation point: If this is important to your risk profile, ask SAP to include a one-time hyperscaler change provision with defined financial terms. This protects you against technology or cost assumptions that prove wrong.
Why this matters: Many RISE contracts include a BTP credit allocation for development, testing, or modernisation workloads. These credits have real commercial value — they represent usage you can consume at no additional cost. The question is what happens to these credits if you migrate off the contract or change hyperscalers. Are they forfeited? Are they refunded (as credit for under-utilisation)? Do they carry over to the new hyperscaler context?
What to expect: The standard RISE contract language treats BTP credits as "use it or lose it." If you don't consume the credits during the contract term, you forfeit them. There's typically no refund. If you change hyperscalers, the credits associated with the old hyperscaler may not be portable to the new one. This creates a financial loss if SAP's recommendations or your own planning lead you to significantly under-use the BTP credits.
Negotiation point: Ask whether unused BTP credits can be refunded or carried forward. Some SAP negotiations have successfully included carryover provisions or partial refund for material under-utilisation. This is worth asking, especially if the BTP credit allocation is substantial.
Why this matters: RISE infrastructure lives on the chosen hyperscaler. Your other systems — legacy ERP, CRM, BI, custom applications — may live elsewhere (on-premise, private cloud, or a different hyperscaler). When data moves from RISE (on hyperscaler A) to another system (on a different cloud or on-premise), the hyperscaler charges data egress fees. These fees are typically per-GB and can be substantial at scale. A large daily data sync from RISE SAP to a legacy BI system could generate €50K–€200K+ in annual egress costs, depending on data volume and the hyperscaler.
What to expect: SAP is not responsible for hyperscaler egress charges — the hyperscaler is. But SAP should disclose what egress charges apply and estimate them based on your expected data flows. Get SAP to model this in the cost forecast. Ask specifically: "What is the per-GB egress charge on [hyperscaler name]?" and "What does our data architecture assumption generate in monthly egress charges?" This becomes a key input to your hyperscaler cost comparison.
Red flag: If egress costs are not discussed upfront, they often become a surprise cost driver during the contract. The hyperscaler egress costs are real and material, and they should factor into your hyperscaler choice.
Why this matters: SAP's RISE pricing includes a fixed infrastructure fee. But the question is whether that fee is truly fixed, or whether SAP reserves the right to adjust it based on changes in hyperscaler pricing, utilisation, or other factors. If SAP can adjust the infrastructure fee during the contract, you have price escalation risk. If the fee is locked in, your cost is predictable.
What to expect: Most RISE contracts include language that allows SAP to adjust infrastructure pricing if your utilisation (CPU, storage, network) exceeds the forecasted assumptions. This is legitimate — if you consume significantly more infrastructure than assumed, the cost will be higher. But get the mechanics clear: (1) How much utilisation variance triggers a price adjustment? (2) How is the adjustment calculated? (3) What notice must SAP provide before adjusting? (4) Can you dispute SAP's utilisation measurement, or is it taken as fact?
Negotiation point: Try to negotiate a utilisation variance tolerance (e.g., "up to 20% variance is covered in the fixed price") before SAP can charge overages. This protects you against unexpected cost increases from modest utilisation growth.
Why this matters: SAP publishes an overall SLA for RISE — typically 99.5% or higher. But that SLA is dependent on the underlying hyperscaler infrastructure. Each hyperscaler publishes its own SLA for compute, storage, and networking services. SAP's RISE SLA is only as good as the hyperscaler infrastructure it depends on. If you choose a hyperscaler with lower SLA guarantees (or lower SLA credits for outages), your RISE service reliability is correspondingly lower.
What to expect: Ask SAP to provide side-by-side comparison of each hyperscaler's published SLA for the infrastructure services that RISE depends on. Also ask: "If a hyperscaler outage causes RISE to breach its SLA, what compensation do we receive?" The answer is complex — SAP may not pass through hyperscaler SLA credits directly to you, or it may have contractual limitations on its liability for hyperscaler-caused outages.
Red flag: If SAP's RISE SLA is identical across all three hyperscalers, but the underlying hyperscaler SLAs differ, you're not getting differentiated risk pricing. One hyperscaler option may carry higher risk than another, and you should understand that trade-off.
Why this matters: RISE contracts have a multi-year term (typically 3–5 years). At the end of the contract, you have options: renew with SAP, migrate to a different SAP offering, or exit SAP entirely. If you exit, your data needs to be repatriated — moved off the RISE infrastructure and either to your own systems or to a third-party provider. Repatriation cost varies by data volume, complexity, and the hyperscaler you chose. Each hyperscaler has different data export capabilities, costs, and timelines.
What to expect: SAP is not primarily responsible for repatriation costs — you and the target platform are. But SAP should be transparent about what repatriation involves and what it might cost. Ask SAP: "What data export tools and formats are available?" "What is the typical timeline for a full data export?" "What hyperscaler-specific constraints apply to data repatriation?" Also, ask whether there are any financial penalties for early exit or accelerated repatriation.
Negotiation point: For hyperscaler options where repatriation is more complex or expensive, you may want to negotiate lower pricing during the contract term. Or negotiate repatriation assistance clauses that commit SAP to support the exit process at specified cost or timeline.
Why this matters: SAP manages your RISE infrastructure and bills you on a fixed or usage-adjusted basis. But you should have the right to verify that you're not over-provisioned or that SAP is not running an inefficient environment that drives unnecessary infrastructure costs. The question is what benchmarking or audit rights exist to measure whether the RISE environment is optimised and cost-effective relative to your workload.
What to expect: SAP typically reserves the right to audit your use of RISE to verify compliance. But audit rights often run one way — SAP can audit you, but you may have limited rights to audit SAP's infrastructure efficiency. Ask: "What benchmarking provisions exist to verify that my infrastructure allocation is optimised?" "Can we engage independent third parties to benchmark the RISE environment against comparable on-premise or other-cloud deployments?" "What happens if benchmarking shows over-provisioning — do we get cost credits?"
Negotiation point: Try to negotiate a two-way audit clause: SAP can audit your use compliance, and you can engage third-party benchmarking to verify infrastructure efficiency. Include cost adjustment provisions if material inefficiencies are identified.
How to Interpret SAP's Answers (and Recognise Evasion)
SAP's account team knows that detailed transparency on these questions reveals commercial trade-offs that may not favour RISE, or may favour a particular hyperscaler. You'll encounter evasion. Here's what to watch for:
- "That varies by deployment." This is often code for "we don't want to commit to a specific answer." Demand specificity based on your deployment assumptions. Get it in writing.
- "That's a hyperscaler question, not an SAP question." Some questions do require hyperscaler input. But SAP should facilitate those answers or include them in the contract. Don't accept deferral to the hyperscaler without SAP committing to support the answer.
- "The standard contract doesn't include that level of detail." True, but it can. Insist that critical answers be documented as exhibits or schedules to the contract. Undocumented oral answers are unenforceable if SAP's position changes later.
- "We can address that in implementation." No. Implementation is too late. The decision — and the cost implications — are locked in at signature. Get answers now, when you still have leverage.
- "That's subject to [hyperscaler's] terms, not ours." SAP acts as your interface to the hyperscaler infrastructure. If SAP won't commit to understanding the hyperscaler terms, or won't help you negotiate them, escalate this to SAP's commercial and legal leadership.
The pattern is clear: SAP's account team will resist detailed transparency because it reveals cost and risk. Your job is to insist on transparency before you remove your negotiating leverage by signing.
Questions You Must Ask the Hyperscaler Directly
Some questions cannot be answered by SAP alone. You need direct engagement with the hyperscaler. Before you sign the RISE contract, your legal, procurement, and cloud architecture teams should have direct discussions with the hyperscaler on these topics:
- SLA commitment for RISE infrastructure: What SLAs apply specifically to SAP RISE resources? Are there any SAP-specific limitations or exclusions in the hyperscaler's standard SLA?
- Data residency and regulatory compliance: If you have specific data residency or compliance requirements (GDPR, HIPAA, sectoral regulations), confirm that the hyperscaler's commitment to those requirements covers RISE resources managed by SAP.
- Egress pricing and data export: What are the per-GB egress charges? Are there any special pricing agreements if your contract with SAP requires frequent data exports or repatriation?
- Capacity and performance guarantees: If SAP has committed to specific performance (response times, throughput), what infrastructure guarantees does the hyperscaler provide to enable SAP to meet those commitments?
- Escalation and dispute resolution: If there's a performance issue or a dispute about SLA compliance, who at the hyperscaler do you escalate to? What's the process?
These conversations protect you in two ways: (1) you get direct confirmation from the hyperscaler about the infrastructure services available, and (2) you create a direct relationship that becomes valuable if issues arise and you need the hyperscaler to advocate for you or verify SAP's claims about infrastructure performance or compliance.
Using Documented Answers in Negotiation
Once you have SAP's written answers to the 10 questions above, you've created documented records of SAP's commercial position on hyperscaler choice. These documents become negotiating leverage in multiple ways:
Cost comparison: When you have per-unit infrastructure costs for each hyperscaler, you can model the true cost impact of each option. If one hyperscaler shows materially higher total cost over the contract term, you can use that analysis to negotiate a price reduction for that option or to build a business case for the lower-cost alternative.
Constraint identification: If BTP service availability or data residency requirements eliminate one hyperscaler option, you've narrowed the negotiation. SAP can't claim all three options are equivalent if technical or regulatory constraints eliminate one.
Dispute precedent: If SAP answers a question in a specific way (e.g., "your existing Azure EA discounts will apply to RISE infrastructure"), and later claims something different, you have a documented record to reference. This is particularly valuable if disputes arise about cost calculations or SLA performance.
Escalation trigger: If SAP's account team cannot or will not provide specific answers, that's a signal to escalate to commercial leadership. The escalation message is clear: "Your account team cannot clarify basic cost and commercial mechanics. We need the commercial and legal leadership to engage before we commit to a multi-year agreement."
For detailed negotiation strategies on RISE hyperscaler choice, see our hyperscaler choice negotiation strategies article. And for cost optimisation tactics specific to each hyperscaler, see our RISE cost optimisation article.