RISE with SAP Hyperscaler Choice: Negotiation Strategies

The Negotiation Starting Point: Why Most Enterprises Lose

When SAP tables a RISE with SAP proposal, it arrives with three non-negotiable defaults baked in: a software licence model, a support structure, and an infrastructure component. The infrastructure component—the hyperscaler choice, the infrastructure BoM, the migration pathway—is treated as a take-it-or-leave-it element. This is deliberate.

In my experience advising 80+ enterprises through RISE negotiations, fewer than 15% challenge the hyperscaler component. This is a $5–15M error over the contract lifetime.

Why enterprises don't challenge it: Three reasons. First, the technical complexity. Hyperscaler choice feels like an operations decision, not a commercial negotiation. Your CIO, cloud architect, and CFO disagree on who owns it. By the time you've internally aligned, you're 6 weeks into negotiations and SAP has already issued an Order Form with Azure locked in. Second, there's a false assumption that SAP's recommendation (Azure) reflects a technical truth. It doesn't. It reflects SAP's partnership economics and Azure commit deals. Third, SAP trains their AEs to position hyperscaler choice as infrastructure logistics, not a negotiable commercial element. "We'll run it on Azure, they handle the platform operations, we handle the application. Done." This framing removes it from the negotiation table.

The consequence: you accept a hyperscaler that doesn't align with your existing cloud commitments, your team's architectural preferences, or your infrastructure bargaining power.

What actually matters: Hyperscaler choice influences five commercial outcomes over your RISE contract lifetime:

• Infrastructure cost. If you have $50M of AWS Reserved Instances (RIs) or Committed Use Discounts (CUDs) already active, moving SAP onto Azure wastes that commit. You're now paying twice: for unused AWS capacity and for Azure SAP infrastructure. SAP's proposal doesn't account for this. You need to quantify the waste and use it as negotiating leverage.
• Data residency and egress costs. If your customer data lakes sit on AWS or GCP, SAP on Azure means cross-region egress fees every time SAP queries or syncs data. These costs are hidden in the infrastructure BoM. Negotiating "data egress cost caps" and "region mobility" clauses locks this down.
• Future cloud flexibility. If your org is evaluating multi-cloud strategies or thinking about migrating off SAP in 3–5 years, locking to one hyperscaler now limits your options. Multi-cloud BTP access and explicit migration rights protect you.
• Bargaining leverage with your hyperscaler. If you already spend $200M+ on AWS, you have leverage with AWS to negotiate SAP infrastructure costs down. SAP's Azure BoM prevents this. Your AWS account team can't help if SAP infrastructure isn't on AWS.
• Organisational risk. Concentrating SAP operations on one hyperscaler creates single-point-of-failure risk. Having SAP-capable architecture on multiple clouds (AWS, Azure, GCP) reduces blast radius. This is a legitimate risk management argument SAP understands.

These five factors are absolutely negotiable. SAP is not ideologically committed to Azure. They're committed to the margin structure in their Azure partnership.

Sequencing the Negotiation: Infrastructure First, Software Terms Second

Most enterprises negotiate RISE in a single linear process: SAP tables a proposal, you respond with cost concerns, SAP adjusts the software licence price, you negotiate support terms, you close. This is backwards.

The correct sequence is:

1. Month 1–2: Hyperscaler choice and infrastructure BoM negotiation. Before you discuss software licence counts, user assignments, or support hours, lock down which cloud provider(s) you'll use and what the infrastructure architecture looks like. This sets the financial baseline for everything else.
2. Month 3–4: Software licence model counter-proposal. Once you've agreed on infrastructure, you negotiate licence positions: Named Users vs. Concurrent Users, user conversions, products included in the licence footprint.
3. Month 5–6: Support terms and ancillary commercial elements. After software is locked, you negotiate SLA hours, priority support, technical resource allocation, and contractual escalation rights.

Why this sequence works: The infrastructure BoM cost ($30–60K per month) is fixed by the hyperscaler and SAP's infrastructure pricing model. You can't negotiate it down; you can only change it by changing hyperscalers or architecture. Software licence cost ($15–40K per month) is directly tied to your licence position (user counts, product editions). Support cost ($5–15K per month) is discretionary. If you negotiate software first, you're leaving $M on the table because you haven't solved the infrastructure question. You'll compromise on user counts to win a discount, then discover 6 months later that infrastructure costs were the real lever.

Most SAP AEs will resist this sequence. They want to keep hyperscaler choice opaque and move straight to "here's our Azure proposal, here's the price, let's negotiate the discount." Resist. Tell them: "We need to validate the infrastructure architecture against our cloud strategy before we lock software terms. Let's start there."

Contractually, why it matters: The Order Form and Bill of Materials are issued in phases. The infrastructure BoM comes first (it defines the underlying platform). The software licence BoM comes second (it runs on that platform). Once the infrastructure BoM is signed off, inserting hyperscaler choice amendments becomes a change order, not a negotiation. You'll be paying SAP change-request fees and your AE will lose interest because change requests don't count toward their quota. Lock infrastructure choice in the negotiation phase, before signatures. After signature, you've lost leverage.

Five Negotiation Levers Specific to Hyperscaler Choice

Here are the five specific negotiation provisions that unlock hyperscaler choice flexibility and protect your interests:

Negotiating Against SAP's Azure Default: How to Create Leverage Without Commercial Friction

SAP's preferred position is Azure. This is documented. Azure is SAP's largest cloud partnership, and SAP's pricing models for infrastructure cost are optimized around Azure commitment structures. When SAP's AE tables a RISE proposal, it will default to Azure unless you've signalled otherwise upfront.

Your goal is to credibly challenge this without triggering defensive behaviour from SAP's sales team.

Step 1: Lead with infrastructure strategy, not vendor preference. Don't say, "We prefer AWS." Say, "Our cloud infrastructure strategy is [AWS-first / multi-cloud / we have $X committed on AWS]." This frames it as strategic, not personal. SAP's AEs understand strategic infrastructure positioning. Vendor preferences sound like procurement noise.

Step 2: Use existing hyperscaler commitments as evidence. If you have active AWS Reserved Instances or GCP Committed Use Discounts, cite these in the negotiation kickoff. "We have $150M of active AWS capacity commitments through 2027. Our infrastructure strategy is to consolidate SAP workloads onto AWS to optimize our overall cloud spending." This is a financial fact, not an opinion. SAP can't argue with it.

Step 3: Run a credible alternative architecture study. Before negotiations, ask your cloud architect or a third-party infrastructure firm to model RISE costs on AWS and GCP, as well as Azure. Don't do a deep financial model; just show costs. "We evaluated RISE on Azure ($X), AWS ($Y), and GCP ($Z) per month. Our preference is AWS because [existing commits / architectural fit / cost]. We want to understand if there are SAP cost differences or licensing implications if we choose AWS."

This legitimizes the conversation. You've done homework. You're not guessing.

Step 4: Offer a trade-off SAP can live with. SAP might say, "We can do AWS, but infrastructure costs are 8% higher because our Azure partnership is deeper. We'd need to adjust the software licence discount to account for this." Don't fight this. Say, "If AWS infrastructure is 8% higher than your Azure equivalent, let's document that cost delta and credit it against the software maintenance discount. We'll land on a net number that reflects AWS choose."

This tells SAP: you're serious about AWS. You understand there's a cost. You're not asking for free leverage. You're asking for transparency and a fair allocation of costs. This is how you avoid commercial friction.

Step 5: Frame multi-cloud interest as risk management, not procurement. If you want AWS now and GCP optionality later, don't say, "We want to keep SAP vendors competitive." Say, "Our organization uses AWS as our primary cloud and GCP for specific workloads (analytics, AI services). We want SAP to be location-agnostic so we can place workloads where they're most cost-effective." This is an operational argument, not a negotiating argument. SAP's technical teams understand it immediately.

The result: You'll get Azure by default, but with a clear pathway to negotiate AWS if you've built your case credibly. And if you do land on AWS, you'll have done the groundwork to justify it commercially.

What SAP Will Concede vs. What Requires Escalation: Knowing the Boundary

Not all hyperscaler-choice negotiation levers are equal in SAP's organization. Some can be agreed at account-team level. Some require escalation to SAP's RISE leadership or legal team. Knowing which is which saves 8–12 weeks of negotiation and prevents you from making requests that will be auto-rejected.

What account teams (AEs, SEs) can concede:

• Alternative hyperscaler choice (AWS, GCP). Your AE can table an AWS or GCP proposal if you justify it strategically. They'll escalate internally to their sales leadership, but this is standard. Cost: typically 5–10% premium to SAP's Azure baseline, which you negotiate away. Timeline: 3–4 weeks.
• Data egress cost caps. This is infrastructure cost management. AEs can negotiate cost caps with their infrastructure partner team. Timeline: 2 weeks.
• EDP/CUD credit application. This is billing mechanics. SAP's billing team can code credits once you've provided proof of active commits. AEs can table this. Timeline: 1 week.
• Infrastructure benchmarking rights (with caveats). This one is contentious, but account teams can agree to a benchmarking clause if you frame it as protection, not transparency. They may add carve-outs (e.g., "benchmarking only if SAP cost exceeds market average by 20%"), but they can negotiate it. Timeline: 4–6 weeks.

What requires SAP internal escalation (RISE leadership, legal, sales ops):

• Multi-cloud BTP access across hyperscalers. This breaks SAP's hyperscaler partnership structure. Your AE can't approve it. It needs RISE program leadership sign-off because it affects SAP's cloud economics. Timeline: 6–10 weeks. Escalation path: Account team → SAP Regional Sales Manager → RISE Advisory Board (internal SAP governance). Approval chance: 40–50% if you've built a strong business case.
• Hyperscaler migration rights (annual review option). This is a contractual right that SAP doesn't typically grant because it creates management overhead. Account teams won't agree to it. It needs legal + RISE leadership approval. Timeline: 8–14 weeks. Escalation path: Account team → SAP Legal → RISE Program Governance. Approval chance: 30–40% unless you're a $100M+ customer or in a strategic industry (financials, automotive).
• Discount multipliers tied to infrastructure benchmarking. SAP won't agree to automatic discount triggers based on cost audits because it affects their margin model. This is sales strategy. Timeline: 10–16 weeks. Escalation path: Account team → Regional Sales Management → SAP Pricing/Commercial Strategy. Approval chance: 25–35%. Workaround: instead of automatic triggers, propose optional annual benchmarking with mutual discussion of findings (less threatening).

Strategic insight: The escalation timeline matters. If you're negotiating a renewal that closes in 8 weeks, you can't request a provision that needs 12 weeks of SAP internal approvals. You'll lose negotiating time on levers SAP can actually decide. Sequence your requests: ask account-team-level items first (they resolve in 2–4 weeks and build momentum), then escalate to RISE leadership items (they take 8–14 weeks but you're already negotiating other terms). This way, when you reach your close deadline, you have 80% of your negotiation positions locked and a few escalation items in process.

The Role of Competitive Tension: Even Fake Leverage Creates Real Negotiating Advantage

One of the most powerful levers in hyperscaler-choice negotiation is credible competitive alternative positioning. And here's the secret: you don't need a genuine intent to switch to GROW with SAP, Oracle Cloud, or perpetual S/4HANA on-prem. You just need SAP to believe you've evaluated it seriously.

Why this matters for hyperscaler negotiation: If SAP thinks you're only negotiating RISE on Azure because you haven't evaluated alternatives, they'll hold firm on infrastructure cost and hyperscaler choice. If they believe you've evaluated GROW with SAP on AWS or perpetual S/4HANA on-prem, they'll move on infrastructure faster because they're worried about losing the deal entirely.

Here's how to create credible competitive tension without lying or wasting internal resources:

Tactic 1: Run a lightweight GROW with SAP assessment (Month 2–3 of negotiation). GROW is SAP's managed-services, subscription-based ERP model. It's not cheaper than RISE (it's often more expensive), but it places SAP on AWS by default. Ask GROW to run a 4-week assessment for you: "We're evaluating RISE vs. GROW. We'd like GROW's view on our requirements." Cost: zero (GROW will do this for free). Timeline: 4 weeks. Outcome: A GROW proposal that shows AWS infrastructure costs, which becomes a credible comparison to your RISE Azure baseline.

Now, when you tell your RISE AE, "We're evaluating GROW and they're showing AWS infrastructure at $X per month vs. your Azure at $Y," your AE has a real competitor to react to. They'll move on cost or hyperscaler choice.

Tactic 2: Engage a perpetual S/4HANA partner for a feasibility study. If you're on an older SAP version, perpetual S/4HANA on-prem is a genuine alternative. Partner with an SAP implementation firm (Accenture, Deloitte, or a mid-market firm like Cognizant, Capgemini) and run a 6-week perpetual-to-cloud comparison. "We want to understand the ROI of upgrading to S/4HANA with perpetual licensing vs. moving to RISE." This is a real assessment, not theater. Cost: $50–100K (you'd consider it anyway). Timeline: 6 weeks. Outcome: A credible alternative cost model that puts RISE on commercial pressure.

Tactic 3: Benchmark against Oracle Cloud and Workday. These are not SAP competitors in the traditional sense, but they're cloud-ERP alternatives. If your organization has any reason to evaluate them (different use case, business-unit separation, new market entry), include them in your strategic assessment. Brief SAP on this: "Our organization is evaluating cloud-ERP economics across SAP, Oracle Cloud, and Workday for specific workloads. We want RISE to be part of this assessment." This signals that RISE is being tested against other platforms, not rubber-stamped.

Why this works: SAP understands that real customers have options. If you're not acknowledging those options in your negotiation, you're not being credible. You're bluffing. SAP's AEs are trained to call bluffs. But if you've actually engaged GROW, run an assessment with an implementation partner, and briefed SAP on competitive alternatives, you're not bluffing. You're evaluating the market. SAP will move on infrastructure cost and hyperscaler choice because they want to protect the deal.

The psychological shift is powerful: You move from "We want AWS instead of Azure" to "We've evaluated the ERP market and we want AWS infrastructure to support our RISE choice." The second framing puts you in a strategic buyer position, not a procurement haggler.

Common Negotiation Mistakes: What Buyers Regularly Get Wrong

Mistake 1: Accepting the infrastructure BoM without independent review.

SAP will table an infrastructure BoM that breaks out compute, storage, database, network, and SAP-specific services (RISE Platform, migration tooling, BTP provisioning). Most buyers read it, nod, and move to "what's the price?" This is wrong. The BoM contains the architectural assumptions that drive cost. If SAP has assumed 8 vCPUs of compute, 500 GB of storage, and standard SQL database pricing, and you're actually going to use half of that, you're overpaying 50%. Get your cloud architect to review the BoM, understand the sizing assumptions, and push back. "We don't need this much storage. Can we reduce it?" You'll find 15–25% cost reduction opportunities in most infrastructure BoMs.

Mistake 2: Negotiating hyperscaler terms after software terms are agreed.

If you've already locked your software licence positions and support hours, your negotiating leverage for infrastructure is almost zero. You can't walk; you're already committed to software scope. SAP knows this. Negotiate hyperscaler choice and infrastructure architecture in parallel with software, before any BoM is finalized. Once software is locked, hyperscaler choice is a done deal.

Mistake 3: Failing to connect hyperscaler choice to BTP credit allocation.

RISE contracts typically include BTP credits: "You have $X monthly BTP budget to consume across services." These credits are baked into your all-in monthly fee. But if you've negotiated AWS as your hyperscaler and BTP defaults to Azure, those credits might not be usable for your preferred services. Or, if you want multi-cloud BTP (some services on AWS, some on GCP), your credit allocation has to flex across clouds. Most buyers don't surface this. When they do, 8 months into the contract, they've wasted credits. Negotiate BTP credit allocation mechanics upfront. "If we're on AWS infrastructure, we want BTP service provisioning to default to AWS. Credits should apply across all regions and services without location penalty."

Mistake 4: Not documenting migration assistance terms for hyperscaler switches.

If you've negotiated annual hyperscaler migration rights, great. But what's the definition of "migration assistance"? Does SAP provide resources? Do they pay for downtime? Do you? Get this in writing. A vague "migration assistance" clause means SAP will send you a bill when you actually try to migrate. Detailed T&Cs prevent this.

Mistake 5: Treating hyperscaler choice as a technical decision with SAP's tech team, not a commercial decision with sales.

Your cloud architect and SAP's solution engineer will say, "Both Azure and AWS work fine for RISE." They're correct. But hyperscaler choice is not a technical question; it's a commercial question: "Where can we run SAP most cost-effectively given our existing cloud commitments and organizational architecture?" This is a CFO and procurement question. If you're negotiating it with SAP's technical team, you're negotiating the wrong conversation with the wrong stakeholders. Escalate to sales. SAP's AE owns hyperscaler choice as a commercial lever, not the SE.

Frequently Asked Questions