SAP on Azure means running SAP software, most commonly SAP Cloud ERP Private, S/4HANA, or an existing ECC estate, on Microsoft’s Azure cloud infrastructure using SAP-certified virtual machines, storage, and networking instead of on-premises hardware.
This guide covers what’s supported, how to architect it, the migration paths available, and the part most guides skip: what operating SAP on Azure actually looks like while a complex, multi-year migration is still underway, not just after a single go-live.
Microsoft and SAP have been deepening their partnership steadily, and 2026 has been a particularly active year for it. In May 2026, SAP and Microsoft announced they would more than double the number of customers admitted to the joint RISE with SAP on Microsoft Azure program, an initiative first launched in January 2025 that already counts Nestlé, Migros, and Samsung among its enterprise participants.SAP Sapphire 2026 also brought expanded sovereign cloud support and additional Azure datacenter regions for SAP Business Data Cloud.
A naming note before we go further, because SAP’s terminology here trips up even seasoned practitioners: “RISE with SAP” is the overall transformation journey and go-to-market brand. The specific product that journey delivers, the single-tenant private cloud edition of S/4HANA, was renamed SAP Cloud ERP Private in July 2025.
Most of the market, and even some of SAP’s own current materials, still say “RISE” when they mean Cloud ERP Private specifically. This guide uses both terms deliberately: RISE with SAP for the overall program, and Cloud ERP Private for the specific product running on Azure infrastructure.
What Runs on Azure: Supported SAP Scenarios
Azure’s SAP-certified infrastructure supports the full technical range of SAP products. S/4HANA and SAP Cloud ERP Private are the primary destination for most transformation programs today, while organizations still running ECC or BW commonly move those workloads onto Azure infrastructure as an interim step on the way to eventual S/4HANA conversion, rather than as a permanent landing spot.
SAP Note 1928533 is the master reference SAP maintains for which SAP products and Azure VM types are supported together, and it’s worth bookmarking, since Microsoft and SAP update the certified VM list regularly as new hardware generations ship.
Azure is a particularly common choice for this journey when an enterprise already has a large existing Azure spend commitment (a Microsoft Azure Consumption Commitment, or MACC) from other workloads. Running SAP Cloud ERP Private on Azure lets that spend count toward the existing commitment, which is a real and often underrated reason organizations pick Azure specifically for their SAP transformation, separate from any technical preference between hyperscalers.
On the delivery model, most new SAP Cloud ERP Private engagements on Azure run through SAP’s managed infrastructure, since SAP actively steers customers toward that route, in part by making it commercially attractive to give up existing perpetual on-premises licenses in exchange for a Cloud ERP Private contract. A fully customer-managed, bring-your-own-license deployment on native Azure infrastructure is still possible, but it’s a narrower path today, realistically most relevant to organizations retaining existing perpetual licenses rather than a default option for a net-new transformation.
The commercial and licensing details get complicated fast and are worth working through directly with an SAP account team or an independent licensing advisor rather than treating as a simple either/or choice. The RISE with SAP on Microsoft Azure initiative exists to smooth the managed route specifically, pairing customers with joint SAP-Microsoft engineering teams during onboarding.
Reference Architecture
A typical production SAP-on-Azure architecture uses a hub-spoke network topology: a central hub virtual network handles shared services like connectivity and security, while SAP workloads sit in spoke networks connected back to the hub. Organizations with existing on-premises infrastructure typically connect the two over ExpressRoute rather than a public internet VPN, since the private, higher-bandwidth connection matters for both migration data transfer and ongoing hybrid operations.
Availability Zones, physically separate datacenters within the same Azure region, separate the primary and secondary nodes of high-availability database clusters, so a single datacenter failure doesn’t take the whole SAP system down with it.
For the database layer, SAP HANA workloads run on SAP-certified VM families, most commonly Azure’s M-series (Mv3, Msv3, Mdsv3), which scale from around 192 GiB up to the tens of terabytes of memory the largest HANA installations need, with even larger scale-out configurations available for extreme cases.
Microsoft and SAP jointly maintain a certified hardware directory listing exactly which VM types are approved for which HANA workload sizes, and it’s updated as new hardware generations ship, so it’s worth checking directly rather than assuming last year’s sizing guidance still applies.
For storage, HANA workloads typically use Azure Premium SSD, Premium SSD v2, Ultra Disk, or Azure NetApp Files depending on performance and latency requirements, with data, log, and shared volumes commonly split across separate disk configurations to meet HANA’s specific I/O patterns. Backup runs through Azure Backup or database-native backup tools writing to Azure Blob Storage, and disaster recovery typically pairs a primary region with a secondary Azure region using HANA System Replication.
Migration Paths Compared
There are three broad ways to get an existing SAP landscape onto Azure, and the right one depends on how much you want to change at the same time you move.
Lift and shift (homogeneous)
A lift-and-shift migration moves the existing SAP system to Azure virtual machines with the operating system and database unchanged. Azure Migrate handles the discovery and assessment phase, cataloging existing servers and their dependencies before anything moves. This is most straightforward for systems already running on a database Azure supports cleanly, like SQL Server or DB2.
ECC systems running on Oracle are a common exception: a database migration, typically to SQL Server or HANA, often happens as part of the move to Azure even without an S/4HANA conversion, largely because Oracle’s licensing terms make running Oracle Database on non-Oracle clouds more expensive than on Oracle’s own cloud.
Where a true, database-unchanged lift-and-shift does apply, it’s the fastest path to Azure and the lowest-risk option when the immediate goal is relocating infrastructure, with S/4HANA conversion planned as a later, separate step. A single-system lift and shift commonly runs a few weeks from planning to cutover; a full landscape (DEV, QA, and Production together) takes longer mainly because of the testing and cutover scheduling across environments, not the technical move itself.
Conversion / S/4HANA move (heterogeneous)
A conversion migration combines the move to Azure with a database and/or system conversion, typically to SAP HANA and S/4HANA, using SAP’s Database Migration Option (DMO), part of the Software Update Manager (SUM) tool, with the System Move option. DMO creates a shadow copy of the current database while building the target HANA database in parallel, then cuts over once both are synchronized, which is what allows the OS/DB upgrade and the physical move to Azure to happen as one coordinated step instead of two.
On the target side, the new environment needs to be provisioned in advance: disk layout for /usr/sap, /sapmnt, /hana/shared, and the HANA data and log volumes, correct sizing against SAP’s guidelines, and the SAP system users created before SUM can execute the migration steps. This path is more complex because two major changes happen together, but it avoids running the cloud move and the S/4HANA conversion as two separate projects, and commonly runs several months for a complex production system once testing cycles are included.
Greenfield
A greenfield implementation builds a new S/4HANA system from scratch on Azure rather than converting an existing one, typically following SAP Activate methodology and SAP’s best-practice process content as the starting configuration. This suits organizations that want to redesign processes rather than carry forward legacy configuration and customization, at the cost of a longer implementation timeline and a full data migration and cutover project layered on top of the technical infrastructure work.
Whichever path is chosen, the project team looks similar: Basis or infrastructure engineers handling the Azure-side provisioning and SAP installation, a migration or upgrade specialist running the SUM/DMO or Azure Migrate tooling itself, and functional consultants validating that business processes still work correctly once the move is done. For RISE with SAP or Cloud ERP Private engagements, SAP’s own delivery team joins as well, since SAP manages the infrastructure layer directly rather than handing that piece entirely to the customer or their systems integrator.
Sizing and Cost Optimization
Azure VM sizing for SAP should start from actual workload data, an SAP EarlyWatch report or Quicksizer output, rather than guesswork, since over-provisioning is one of the most common ways SAP-on-Azure costs run higher than expected. It’s worth resisting the instinct to size for peak plus a large safety margin; Azure’s ability to resize a VM with a short restart is part of what makes the cloud model different from fixed on-premises hardware, and workloads can be revisited after a few months of real usage data rather than locked in at go-live.
Reserved Instance or Savings Plan pricing can meaningfully cut compute costs for production systems that run continuously, commonly in the range of 30 to 50 percent versus pay-as-you-go rates depending on term length and payment structure.
Non-production systems are the bigger lever, though. Development and QA systems don’t need to run outside business hours, and organizations that automate the shutdown of non-prod SAP systems and their underlying cloud VMs outside working hours, commonly called “snoozing,” avoid paying for capacity nobody is using overnight and on weekends, which for a typical five-day working pattern can cut non-prod compute spend by more than half.
Avantra’s cloud automation, for example, monitors SAP and cloud performance together and can automatically stop and start SAP instances and their associated cloud nodes on a schedule, without shutting down anything a critical business process still depends on.
Managing the Transition, Not Just What Comes After
Most SAP-on-Azure content, including Microsoft’s own extensive documentation, treats migration as a single clean cutover: on-premises today, fully on Azure tomorrow, with day-2 operations beginning after that. That’s not how it plays out for a large, complex organization.
A typical enterprise SAP estate spans dozens or hundreds of systems across multiple business units, and moving all of it to Azure happens incrementally over several years, not in one project. During that window, some systems are already on Azure, some are still on-premises or on a different hyperscaler, and some are mid-conversion. That hybrid mix is the normal operating state for most of the migration, not a brief transitional phase.
Framing SAP operations automation as purely a “day-2” solution undersells what’s actually needed. The harder, more valuable problem is managing business-as-usual operations continuously across that whole mixed estate while the migration is still underway: unified monitoring and automation that doesn’t care whether a given system sits on-premises, on Azure, or somewhere in between, so the sysops team isn’t relearning their tooling every time another system in the estate cuts over.
Avantra is built for exactly that in-between reality. It integrates natively with hyperscalers, including Azure, to unify infrastructure and SAP-specific monitoring with automated remediation across a hybrid estate, so a system newly on Azure and a system still on-premises show up in the same view instead of two disconnected tools.
The same platform automates patching, system refreshes, and the non-prod scaling described above, wherever a given system currently sits, which is what makes an incremental, multi-year migration manageable for the team running it, not just something that becomes useful once the migration is finished.
Security and Compliance
Identity for SAP on Azure typically runs through Microsoft Entra ID (formerly Azure Active Directory), which can provide single sign-on into SAP Fiori and other web-based SAP interfaces alongside the rest of an organization’s Microsoft 365 and Azure identity footprint. Network Security Groups and, for larger estates, Azure Firewall segment SAP traffic from the rest of the virtual network, typically restricting database-tier access to only the application servers that need it rather than leaving it broadly reachable.
Data at rest and in transit should be encrypted using Azure’s built-in disk encryption and TLS. Microsoft Defender for Cloud includes SAP-specific recommendations that flag common misconfigurations, and Azure Policy can enforce baseline settings, like requiring encryption or blocking public IP assignment, across every SAP VM automatically rather than relying on someone remembering to check each one.
Audit logging should flow into a central tool such as Azure Monitor or a SIEM for compliance reporting, and organizations in regulated industries should confirm which Azure region and sovereign cloud options apply before committing to a target region, since data residency requirements vary significantly by industry and geography.
FAQ
What is SAP on Azure?
SAP on Azure means running SAP software, most commonly S/4HANA or SAP Cloud ERP Private, on Microsoft’s Azure cloud platform using SAP-certified virtual machines and Azure-native services instead of on-premises infrastructure.
How long does an SAP to Azure migration take?
Timelines vary widely by scope: a straightforward lift-and-shift of a single system can take a few weeks, while a combined S/4HANA conversion and Azure migration for a large, complex estate commonly takes several years when phased incrementally across many systems. The single biggest timeline driver isn’t usually the technical migration itself, it’s the testing and business sign-off cycle for each system, which is why phasing an estate system by system tends to be more realistic than attempting one large-bang cutover.
Is Azure certified for HANA?
Yes. Microsoft maintains SAP HANA-certified Azure virtual machine types, and SAP Note 1928533 is the authoritative reference for which VM families and configurations are currently supported.[4]
What does SAP on Azure cost?
Cost depends on VM size, storage tier, and whether Reserved Instance pricing or an existing Azure consumption commitment is used, but the biggest controllable factor for most organizations is non-production spend, since dev and QA systems that run around the clock out of habit rather than necessity are the most common source of avoidable cost.
Conclusion
Running SAP on Azure is well-supported territory: the certified scenarios, reference architectures, and migration paths are mature and well documented by both SAP and Microsoft. The part that determines whether a migration actually pays off is what happens across the years it takes a complex estate to get there: keeping infrastructure and SAP-layer monitoring unified across a hybrid mix of on-premises and Azure systems, and non-production costs under control, the whole way through.
Avantra’s SAP cloud automation and SAP monitoring on Azure are built for exactly that. Book a demo to see how Avantra manages a hybrid SAP estate through an Azure migration, not just after it.