RISE with SAP is often described as “S/4HANA Cloud, private edition, signed with one pen.” That’s true but incomplete. Underneath the subscription, the production systems run on a hyperscaler — and for a large share of contracts, that hyperscaler is Azure. This tutorial unpacks what the bundle actually contains, how the SAP-to-Azure contracting works, which VM SKUs host a 15 TB HANA database, and where the realistic cost levers are in 2026.
Who RISE with SAP is (and is not) for
RISE with SAP bundles the ERP subscription, the infrastructure, and a defined set of platform services into one contract with SAP. The standard package includes:
- SAP S/4HANA Cloud, private edition — a dedicated instance, single tenancy, running in a hyperscaler data center chosen during the deal (Azure, AWS, GCP, or Oracle).
- SAP Business Technology Platform (BTP) usage entitlements — a credit pool you consume against services such as Integration Suite (the successor to SAP Cloud Platform Integration/CPI), Extension Suite, and AI services. Entitlement size scales with the subscription value of the contract.
- Content and tooling — SAP Activate methodology, SAP Signavio process intelligence, a SAP Business Network entry entitlement, and (since the 2024–2025 refreshes) SAP’s Business AI capabilities including Joule copilots. See the official RISE with SAP page for the current entitlement matrix, as SAP adjusts bundles periodically.
RISE fits you if: your SAP ECC 6.0 mainstream maintenance is ending (2027, with extended options to 2030), you want a single throat to choke for ERP + infrastructure, and you don’t intend to develop deep in-house capacity for HANA host administration. It fits you less well if you need direct control of the Azure subscription (for policy, private networking, or a private SKU), want the Azure invoice separate from the ERP invoice, or plan heavy customization that SAP-managed update cycles will slow down.
How RISE + Azure actually combine: the contract flow
Two contracting patterns coexist, and teams routinely confuse them:
Pattern 1 — Standard RISE (SAP procures the Azure capacity). You sign only with SAP. SAP runs your S/4HANA Cloud private edition instance in Azure capacity that SAP itself procures from Microsoft under their global agreement. Consequences:
- Your invoice is one line from SAP (subscription + services + infrastructure bundled). You never see an Azure bill for the SAP landscape.
- SAP owns the OS patching windows, HA/DR tooling (HANA system replication), and the hypervisor/storage stack; Microsoft and SAP share support for the platform layer.
- You cannot apply your own Azure reservations, savings plans, or Azure Hybrid Benefit to the RISE infrastructure, because those resources are not in your subscription.
Pattern 2 — Azure-side procurement that keeps your commitment working. Microsoft’s Marketplace Azure Consumption Commitment Benefit lets eligible RISE offers purchased through Microsoft Marketplace count toward your Azure spending commitment (MACC). Practically, if you hold a large annual Azure commitment, you can route a RISE purchase so it consumes prepaid Azure credit instead of stranding it — your finance team gets one statement, and your commitment burn-down includes the ERP. Verify the current eligible offer list before negotiating; the program is offer-specific.
Complementing both patterns, the expanded Global RISE with SAP on Microsoft Azure initiative (announced January 2025, doubled in capacity for 2026) gives approved RISE-on-Azure customers joint Microsoft+SAP engineering support, Azure health checks, go-live readiness reviews, and Cloud Accelerate Factory access at no additional cost. Ask your SAP or Microsoft account rep to nominate you — it’s free and materially de-risks cutover.
Architecture choices on Azure
For either pattern, the technical landing zone is an Azure question:
- Managed disks on VMs (default). HANA runs on Azure M-series VMs with Premium SSD, Premium SSD v2, or Ultra Disk attached via NVMe/SCSI. Full control, per-second billing, reservations apply. This is the architecture most “bring your own subscription” SAP-on-Azure estates use.
- Shared-disk / scale-out layouts. Ultra Disk and Premium SSD v2 support multi-LUN striped volumes under LVM; large scale-out HANA whitepapers build shared
/hana/dataon striped NVMe disks across worker nodes. Choose this only when a single VM size genuinely cannot cover the memory need — it multiplies operational complexity. - Azure landing zone for SAP. The Cloud Adoption Framework’s SAP enterprise-scale landing zone prescribes the hub-and-spoke or Virtual WAN topology, central identity, Private Endpoints for Blob backup, and separate subscriptions per landscape (DEV/QAS/PRDR). Build SAP into a landing zone, not alongside it.
- Under RISE, you inherit a SAP-operated version of all this. You influence region, HA topology, and DR SLA at design time; you do not operate it.
Sizing example: a 15 TB HANA system
Take a 15 TB HANA database allocation (typical of a very large S/4HANA single-node deployment with tens of thousands of users). The certified path in 2026 is the Msv3 High Memory family:
| VM SKU | vCPUs | RAM | Remote storage ceiling | Network |
|---|---|---|---|---|
| Standard_M416s_6_v3 | 416 | 5,696 GiB | 130k IOPS / 4,000 MBps | 40 Gbps |
| Standard_M832is_16_v3 | 832 | 15,200 GiB | 260k IOPS / 8,000 MBps | 100 Gbps |
| Standard_M896ixds_32_v3 (VHM, on request) | 896 | 30,400 GiB | 110k IOPS / 8,000 MBps + local NVMe cache | 185 Gbps |
A 15 TB database lands on Standard_M832is_16_v3 (15.2 TB usable host RAM). Growth beyond ~15 TB pushes you to the 32 TB Mdsv3 VHM SKUs: Microsoft recommends the SMT-disabled M896ixds_32_v3 for transactional S/4HANA (per SAP note 2711650 guidance), while the SMT-enabled M1792ixds_32_v3 suits analytics. VHM sizes are dedicated to a single customer, are not enabled by default (contact your Microsoft account team), require Gen2 images (SLES 15 SP4+, RHEL 8.8+, Windows Server 2022), and do not support Live Migration — plan maintenance windows accordingly. Smaller systems don’t need M: HANA-certified Ev5/Dv6 memory-optimized sizes cover sub-1 TB and non-production landscapes.
Storage layout for the M832is_16_v3, following Microsoft’s production guidance: /hana/data ≈ 1.2× host memory (~18 TiB) provisioned for 4,000 MBps and 60,000 IOPS aggregate; /hana/log 500 GiB at 600 MBps/10,000 IOPS; /hana/shared 1 TiB; backups to Blob (30–45 TiB retention). A single Premium SSD v2 disk caps at 1,200 MBps/80,000 IOPS, so stripe 4–8 disks per volume — each disk includes 3,000 IOPS + 125 MBps free, which is usually the cheaper direction.
Expected monthly range (East US, Linux, prices pulled from the Azure Retail Prices API in November 2026; prices vary by region and change — verify in the Azure pricing calculator):
| Model | HANA VMs (primary + HSR secondary) | Whole landscape incl. storage, app tier, backup |
|---|---|---|
| Pay-as-you-go | $163.86/h × 2 ≈ $239,200/mo | ≈ $265,000–290,000/mo |
| 1-year reservation | $834,816/yr per VM ≈ $139,100/mo | ≈ $165,000–185,000/mo |
| 3-year reservation | $1,209,163 per VM over 3 yr ≈ $67,200/mo | ≈ $95,000–120,000/mo |
Remember: under standard RISE, you never pay these numbers directly — SAP prices them into the subscription. The ranges matter for the bring-your-own-subscription path and for sanity-checking what you’re being sold.
Three migration paths compared
| Dimension | Lift-and-shift existing S/4HANA to Azure | New implementation (greenfield) | RISE + DMO conversion procured against Azure commitment |
|---|---|---|---|
| Contract | Azure subscription (your EA/MCAA) + existing SAP license; reservations/HBR apply | RISE with SAP, new S/4HANA Cloud PE instance | RISE with SAP, or own subscription with Marketplace/MACC benefit |
| Infra operator | You / your MSP | SAP (on Azure) | You or SAP depending on variant |
| Typical duration | 2–6 months | 9–24 months | 6–15 months incl. mock cycles |
| Cutover downtime | Hours–1 day per system copy | N/A (phased) | 8–24 h typical; optimized DMO runs lower (see below) |
| Process change | None — same Z-code, same business flows | Full redesign on SAP Activate best practices | Selective — clean core + BTP extensions |
| Best for | Already on S/4HANA, want cloud billing control | Mid-market, ECC-era orgs without legacy baggage | ECC 6.0 customers hitting the 2027/2030 wall |
Timeline & workload: DMO vs classic migration
| Workstream | DMO (SUM with Database Migration Option) | Classic (SWPM system copy, then upgrade) |
|---|---|---|
| Steps | Migration + upgrade + S/4 conversion in one orchestrated run | Export/import (R3load), DB install, then separate upgrade/conversion |
| Mock cycles before cutover | 2–4 full + 2+ incremental | 3–5 full cycles |
| Cutover downtime, 5–10 TB source | 8–24 h standard; 2–8 h is achievable with delta migration / near-zero-downtime options (estimates — system-dependent) | 24–72 h+ without third-party replication tooling |
| Team shape | 1 migration lead + basis; SAP tooling does the heavy lifting | Larger basis + DBA team, longer manual phases |
| Consistency risk | Lower — single toolchain, tested upgrade path | Higher — version combinations drift between steps |
These are directional estimates from common project experience; run your own timed mock cycles, because real downtime is governed by your largest table, your ABAP post-processing, and your validation gates — not the tool.
Cost levers, with rough impact
Label everything below as estimates; treat percentages as planning inputs, not quotes.
- Reservations / savings plans (BYO-subscription path): the biggest lever on large SKUs — measured against the November 2026 list above: ~42 % (1-year) and ~72 % (3-year) off pay-as-you-go compute. On a 15 TB landscape, compute is 70–80 % of the bill, so the landscape-level saving is roughly 30–55 %.
- Spot VMs for non-production: the same API data shows the M832is_16_v3 spot Linux rate at $30.28/h — ~82 % off on-demand. Never for production HANA; fine for DEV/QAS copies where eviction is tolerable.
- Right-size the tiers: keep only PRD + HSR secondary on the 15.2 TB SKU. Run DEV/QAS on the 5.7 TB
M416s_6_v3($55.30/h PAYG) or 7.6 TBM416s_8_v3, and app servers on Esv5/Dsv6 — an estimated 25–40 % off a naive all-landscape-on-big-SKU bill. - Auto-shutdown for non-prod: compute billing stops on deallocation; 12×5 scheduling of DEV saves an estimated 50–65 % of that tier’s compute cost (HANA reload time is the tradeoff).
- Storage shape: Premium SSD v2/Ultra charge capacity, IOPS, and throughput independently (Ultra East US: $0.12/GiB-mo, ~$0.05/IOPS-mo, ~$0.35/MBps-mo). Provision to measured peaks from HCMT/BQA runs, not to SKU ceilings — an estimated 10–25 % off storage line items.
- Azure Hybrid Benefit: applies to Windows Server and SQL Server VMs (app tier, peripheral systems), roughly halving license cost on those VMs. It does not cover SAP application or HANA database licenses — under RISE those are inside the subscription; under your own subscription they are whatever contract you already hold.
- Marketplace/MACC routing: not a discount, but it converts stranded Azure commitment into ERP funding — worth real negotiating leverage when you re-paper the RISE price.
Pitfalls to avoid
- Assuming reservations work inside RISE. They don’t — Pattern 1 resources live in SAP’s subscription. Budget them against the BYO path or the Marketplace variant.
- Sizing VM RAM = HANA memory. Apply SAP’s memory sizing factors; the 15 TB database assumption above already includes host overhead — don’t stack a second fudge factor on top of it, and don’t skip the compression-ratio benchmark (
HANA_MERGE/ real conversion statistics). - Ignoring HA operational constraints. HM/VHM SKUs don’t support Live Migration; patched OS reboots are planned downtime. Use HSR with
syncin-zone for RPO≈0 and an ANF/Blob volume-backup Tier 2 for regional DR. - VHM availability surprises. 32 TB VHM sizes are quote-driven hardware, limited regions, long lead time. Confirm with your Microsoft account team before committing cutover dates.
- SMT confusion on 32 TB hosts. Wrong SMT setting between the 896-vCPU and 1,792-vCPU SKUs measurably degrades S/4 transactional performance — follow SAP note 2711650 guidance, not defaults.
- One mock cutover. DMO downtime estimates are meaningless without timed cycles including ABAP post-processing and interface regression tests.
- Forgetting the BTP pool is a use-it-or-late-upgrade asset. Burn entitlements on Integration Suite/extension work early; unused credits don’t roll into the next renewal discount.
FAQ
Does RISE with SAP on Azure mean I don’t need an Azure subscription at all?
For the RISE landscape itself, correct — the production system runs on SAP-procured Azure capacity and appears nowhere in your tenant. Most customers still keep their own Azure subscriptions for BTP-linked integration, analytics (Fabric/Synapse feeding SAP data), and lift-and-shift estates. If you want your spend to hit one commitment, look at the Marketplace Azure Consumption Commitment Benefit instead.
Can a 15 TB HANA database run on a single Azure VM?
Yes — Standard_M832is_16_v3 provides 15.2 TB host RAM, 832 vCPUs, and 260k IOPS/8 GBps remote throughput, which Microsoft documents as a production-supported single-node configuration. Beyond ~15 TB, the 32 TB Mdsv3 VHM SKUs (M896ixds_32_v3) cover you until ~30 TB before you’d need a scale-out design.
Which is cheaper long-term: DMO conversion or greenfield?
DMO conversion wins the first 3–4 years (shorter project, familiar processes, one cutover). Greenfield’s cost advantage, if any, appears later through a cleaner core, lower customization debt, and cheaper upgrades. On typical RISE pricing, a greenfield program usually carries 30–60 % more implementation services cost (estimate) than a comparable conversion — buy it only if you intend to redesign processes seriously.
Who patches the operating system in RISE?
SAP manages the OS/host for the S/4HANA Cloud PE instance and schedules updates with you; Microsoft and SAP jointly cover the Azure substrate. On the bring-your-own-subscription path, patching is yours — plan around the no-Live-Migration constraint on HM/VHM SKUs.
References
- SAP, RISE with SAP — product overview (accessed 2026-11-08)
- SAP News Center, Expanding the Global RISE with SAP on Microsoft Azure Initiative (May 11, 2026)
- Microsoft Learn, M family memory-optimized VM size series
- Microsoft Learn, Msv3 High Memory sizes series
- Microsoft Learn, Mdsv3 Very High Memory sizes series
- Microsoft Learn, SAP HANA Azure virtual machine Premium SSD v2 storage configurations
- Microsoft Learn, Azure Storage types for SAP workloads
- Microsoft Learn, SAP enterprise-scale landing zone — Cloud Adoption Framework
- Microsoft Learn, Azure Consumption Commitment Benefit — Marketplace
- Azure Retail Prices API, prices.azure.com/api/retail/prices — VM and disk meters, East US, retrieved 2026-11-08
- Azure pricing calculator: azure.microsoft.com/pricing/calculator
Next steps
- Hands-on: Deploy SAP HANA on Azure — build the managed-disk single-node stack you sized here.
- Explore more cloud architecture in the Cloud category, including multi-cloud comparisons for SAP workloads.
All prices in this article are list prices for one region on one date, for planning only. Confirm every figure in the Azure pricing calculator and with your SAP/Microsoft deal desk before contracting.