Two Contracts, One Strategy
The fundamental commercial reality of SAP on Azure is that you are managing two distinct vendor relationships. Your SAP agreement governs software licences — the right to use S/4HANA, SAP HANA, BTP, and other SAP applications. Your Microsoft agreement governs infrastructure — the compute, storage, networking, and platform services that run SAP in Azure.
Most enterprise buyers negotiate these contracts sequentially or even completely independently. The SAP team handles SAP. The cloud team handles Azure. Finance sees two separate invoices. This structure is commercially suboptimal. SAP and Microsoft have a deep co-selling partnership precisely because joint customers are strategically valuable to both companies — and buyers who understand this dynamic can extract value from it.
The key insight: when Microsoft knows you are running SAP on Azure, Microsoft wants that workload visible in its Azure consumption figures. When SAP knows you have an Azure commitment, SAP wants to be the path through which you consume it (via RISE). Both positions create negotiating leverage — if you are positioned to use them simultaneously.
SAP BYOL on Azure: What It Covers and What It Doesn't
Bring Your Own Licence (BYOL) is the mechanism by which your existing SAP perpetual or subscription licences are applied to Azure infrastructure without purchasing new SAP licences from Microsoft or through the Azure Marketplace. For most SAP on Azure deployments, BYOL is the standard approach — and it is straightforward in principle, but the details matter.
What BYOL Permits
Under SAP BYOL on Azure, you may deploy SAP software licensed under your existing SAP contract onto Azure Virtual Machines that are certified by SAP for production use. The SAP Certified Infrastructure list (available on SAP's support portal) identifies approved Azure VM families. Key entitlements include:
- Running SAP HANA Database on SAP-certified Azure M-series and Mv2 VMs
- Deploying S/4HANA, ECC, BW, and other SAP applications on certified Azure compute
- Using Azure NetApp Files and Azure Premium SSD for SAP HANA storage tiers
- Applying existing SAP Basis licences to Azure-hosted infrastructure
What BYOL Does Not Cover
BYOL does not automatically grant rights to SAP BTP services, SAP Integration Suite, or SAP cloud applications (such as SuccessFactors or Ariba) deployed on Azure. These are separately licensed SAP cloud products. A common misconception is that a BYOL S/4HANA deployment on Azure includes BTP entitlements — it does not. BTP access requires a separate BTP contract with SAP, regardless of your infrastructure choices.
Additionally, BYOL assumes that your existing SAP licences are correctly sized for Azure deployment. If your on-premise licence was measured on physical core counts and you are moving to a virtualised Azure environment, SAP's virtualisation licensing rules apply — which may trigger a licence resizing discussion.
RISE with SAP vs Self-Managed Azure BYOL
The most significant commercial decision for SAP on Azure is whether to use RISE with SAP (where SAP manages the Azure infrastructure as part of a bundled subscription) or to deploy S/4HANA yourself on Azure using BYOL licences and your own Azure agreement.
"RISE is not just an infrastructure decision — it is a commercial decision that affects your SAP licence flexibility, your exit options, your Azure MACC achievement, and your negotiating leverage with both vendors for the next 3–5 years. Do not make it without modelling all four dimensions."
The Case for Self-Managed Azure BYOL
Self-managed Azure BYOL preserves maximum commercial flexibility. Your SAP licence agreement remains distinct from your infrastructure contract, giving you the ability to switch cloud providers, renegotiate independently, and retain ownership of your SAP licence assets. Azure consumption counts directly towards your MACC commitment. You control the infrastructure architecture and can optimise Azure spend using Reserved Instances and Azure Hybrid Benefit.
The Case for RISE with SAP
RISE with SAP bundles S/4HANA Cloud (Private Edition), HANA infrastructure, and managed services into a single subscription. For organisations that want to reduce operational complexity and fully outsource SAP infrastructure management, RISE can deliver value. SAP runs the infrastructure on Azure (often confirmed in the contract), but Azure spend flows through SAP's account — meaning it does not directly accelerate your Microsoft MACC. However, Microsoft has introduced co-selling arrangements where certain RISE deployments can still count toward Azure committed spend through partnership credits. This area is evolving rapidly and should be confirmed with both vendors in any current negotiation.
Azure Commitment Credits and SAP Workloads
For organisations with a Microsoft Azure Consumption Commitment (MACC), SAP workloads represent a significant opportunity to accelerate commitment achievement. SAP on Azure typically involves substantial compute consumption — HANA M-series VMs are among the most expensive Azure VM types, and a production S/4HANA environment running on Azure can consume $500,000–$3M annually in Azure infrastructure costs depending on scale.
This infrastructure spend counts directly against MACC when deployed under a self-managed model. For buyers with underperforming MACC commitments, migrating SAP workloads to Azure can be the single largest lever for MACC catch-up — which in turn unlocks better Azure pricing tiers and avoids MACC shortfall penalties.
Azure Hybrid Benefit for SAP Workloads
Azure Hybrid Benefit (AHB) allows customers with Software Assurance-covered Windows Server licences to apply those licences to Azure VMs, reducing the operating system cost component of VM pricing. SAP on Windows deployments (less common than SAP on SUSE or Red Hat Linux, but present in legacy environments) can leverage AHB. SAP on Linux deployments cannot use Windows AHB directly, but organisations with SUSE Linux Enterprise Server for SAP licenses may qualify for SUSE's bring-your-own-subscription programme on Azure.
MACC Strategy for SAP Migrations
If you are negotiating a Microsoft Azure Consumption Commitment alongside a planned SAP migration to Azure, the sequencing and sizing of the MACC is critical.
- Model your SAP Azure consumption before committing to MACC size. Run a detailed SAP sizing exercise to estimate annual Azure infrastructure costs for your target architecture. Include HANA VM costs, storage, networking, backup, and DR. Use this as the floor for your MACC commitment — not aspirational estimates from Microsoft's pre-sales team.
- Build migration timeline contingency into MACC ramp structures. SAP migrations to Azure routinely take 12–24 months longer than planned. MACC contracts with linear consumption ramps will penalise you if the migration slips. Negotiate a back-weighted or milestone-based ramp that accommodates realistic migration delays.
- Negotiate MACC credit for SAP pre-production environments. Dev, test, and QA environments spin up well before production goes live and can represent 20–30% of total SAP Azure consumption. Ensure these environments count towards MACC from day one — some early-stage MACC structures exclude non-production workloads.
- Align MACC renewal with SAP contract renewal. If your SAP licence agreement expires at a similar time to your MACC commitment, coordinate both renewals. A simultaneous renewal creates competition between both vendors for your strategic commitment — and typically yields better terms from each.
Negotiation Playbook: Running Both Deals Simultaneously
The highest-value approach to SAP on Azure commercial strategy is to conduct SAP contract negotiations and Microsoft Azure/MACC negotiations in parallel — ideally with both vendors aware that the other is in play.
Create RISE as a negotiating foil in the Microsoft discussion. When negotiating Azure infrastructure pricing with Microsoft, indicate that RISE with SAP is under active evaluation. RISE represents a scenario where SAP — not Microsoft directly — captures the Azure infrastructure relationship. Microsoft is motivated to price Azure competitively to prevent this outcome.
Create the Azure MACC as a negotiating foil in the SAP discussion. When negotiating RISE or traditional SAP licence terms, indicate that your Azure MACC commitment creates a strong structural incentive for self-managed deployment (where Azure costs count toward your commitment). SAP wants RISE to win — and has commercial flexibility to make RISE commercially comparable to self-managed alternatives when the MACC argument is credible.
Use both vendors' co-selling ambition to your benefit. Both SAP and Microsoft have joint pipeline targets and co-selling KPIs. A confirmed SAP on Azure migration — whether RISE or BYOL — is a win for both companies' partnership metrics. Buyers who frame their decision as a strategic joint win can extract last-mile concessions from both vendors when the deal is close to closure.
For more on SAP contract strategy, see our SAP Licensing Complete Guide and our article on RISE with SAP contract negotiation. For cloud contract strategy beyond SAP, read our SAP on AWS guide. You can download our Cloud Contract Framework for a comprehensive multi-cloud negotiation template.