Migrating SAP to Azure in 2026: Deadlines, Decision Paths and What to Watch Out For

Most SAP-on-Azure discussions are really two discussions at once. One is about infrastructure: certified VMs, storage, network design and high availability. The other is about SAP itself: maintenance deadlines, S/4HANA, RISE with SAP and how much of the operation you keep in-house. Treat them as one decision and you get either an expensive lift and shift that changes nothing, or an S/4HANA business case that ignores the platform underneath.

This post is for CIOs, architects and migration leads in regulated EU organizations moving SAP ECC, BW or S/4HANA to Azure, customer-managed on IaaS or SAP-managed through RISE. It covers deadlines, decision paths, technical traps, tooling, what to expect and a checklist. Everything time-sensitive was checked against SAP and Microsoft sources in October 2026; recheck the listed SAP Notes and Microsoft Learn pages before you commit to a design.

Key takeaways

  • ECC 6.0 (EHP 6–8) leaves mainstream maintenance at the end of 2027, with optional extended maintenance to the end of 2030. SAP’s post-2030 “transition option” is an SAP-managed RISE subscription on HANA, not a lifeline for ECC that you run yourself on Azure VMs.
  • Moving ECC to Azure IaaS is a valid infrastructure decision, but it doesn’t move your SAP deadline. Decide the S/4HANA path and the operating model first.
  • Most SAP-on-Azure performance and stability problems come from a few choices: certified VM and storage SKUs, app-to-database latency, and HA clusters nobody has failure-tested.
  • Recent changes: HANA Large Instances is gone, the M192i v2 sizes retire on 31 March 2027, and the containerized Sentinel agent for SAP is retired.
  • RISE moves infrastructure, OS, database and technical Basis to SAP. Application work, interfaces, testing and most of the transformation stay with you.
  • Rehearse cutovers until downtime is measured.

The deadlines that drive the decision

SAP ECC 6.0 and Business Suite 7

SAP’s maintenance strategy for Business Suite 7 core applications (ERP 6.0, CRM 7.0, SCM 7.0, SRM 7.0) is unchanged since 2020: mainstream maintenance for the latest three enhancement packages (EHP 6–8 for ERP) until the end of 2027, then optional extended maintenance from 2028 to the end of 2030 at a premium of two percentage points, then customer-specific maintenance. EHP 0–5 already left mainstream maintenance at the end of 2025 (SAPUsers).

The “2033” headlines refer to the SAP ERP, private edition, transition option, announced in early 2025 (The Register). SAP’s terms, last updated on 13 October 2026:

  • It targets SAP’s “largest and most complex customers” that can’t finish an S/4HANA transformation by the end of 2030.
  • Systems must be migrated to SAP ERP, private edition (ECC as a RISE subscription) on SAP HANA before 31 December 2030. HANA is the only supported database; the minimum system size is 2 TB.
  • It requires the max success plan in 2031–2033 and technical readiness checks; SAP Note 3591251 lists eligible products.
  • It is priced as an uplift on SAP ERP, private edition: no uplift for customers that committed by the end of 2025, a standard 20 percent for 2026 sign-ups, and undisclosed terms for 2027 or later.
  • The October 2026 update says subscriptions “may run until December 31, 2035 (with further prerequisites).”

SAP is explicit that this isn’t an on-premise maintenance extension; ASUG summarizes it as no change for on-premise customers after 2030. ECC that you run yourself on Azure VMs is, in SAP’s terms, still on-premise. If your plan needs ECC after 2030, it runs through RISE and HANA.

S/4HANA on-premise and private cloud edition

From the 2023 release, S/4HANA on-premise and private cloud edition follow a two-year release cycle with seven years of mainstream maintenance per release, with at least one release in maintenance until 2040. Per SOAPeople‘s summary of SAP’s dates, S/4HANA 2021 leaves mainstream maintenance at the end of 2026, 2022 at the end of 2027, 2023 at the end of 2030 and 2025 at the end of 2032. Target 2023 or 2025 if you convert during the move. RISE customers who miss an upgrade can buy SAP S/4HANA Cloud Safekeeper, which SAP described in 2024 as two more years of updates and patches on the current release.

BW and PI/PO

SAP NetWeaver 7.5, which underpins Process Orchestration, has mainstream maintenance to the end of 2027 and extended maintenance to the end of 2030; Integration Suite is the target. For BW, SAP ties longer maintenance to SAP Business Data Cloud (launched February 2025): integrating BW with it extends BW 7.5 mainstream maintenance to 2030 and BW/4HANA to 2040. Decide BW’s future before sizing it on Azure.

RISE, GROW and where new functionality lands

RISE with SAP is SAP’s offer for existing on-premise ERP customers: S/4HANA as a single-tenant, SAP-managed service on a hyperscaler of your choice, plus transformation services and incentives. GROW with SAP is the public cloud route for growing companies. In 2025 SAP renamed the offerings SAP Cloud ERP and SAP Cloud ERP Private, and replaced the RISE package with the Cloud ERP Private package, still priced per Full Use Equivalent (FUE). The bills of materials changed, so compare offers line by line.

Innovation is what changes business cases. In 2023 SAP reserved Joule and its newest innovations for RISE (SAPinsider). At Sapphire in May 2026 it softened this: most Joule assistants and agents will also work with on-premise ECC and S/4HANA, but only for customers committed to a cloud transformation, with access tied to the Max Success Plan. SAP’s COO: “Joule assistants and agents are designed for the cloud” (SAPinsider). Customer-managed SAP on Azure gets SAP’s newest AI on SAP’s commercial terms, not because it runs in a cloud.

The four decision paths

(a) Lift and shift ECC or BW on AnyDB

A homogeneous move: same database (SQL Server, Oracle, Db2, SAP ASE or MaxDB), new infrastructure. Microsoft’s planning guide recommends deploying fresh, automated infrastructure and moving data with DBMS-native replication or SAP tools, not replicating VMs with Azure Migrate or Site Recovery; those aren’t validated for large SAP migrations, and busy SAP databases exceed their change-rate limits. It is the fastest, lowest-risk path and changes the least: ECC stays on its 2027/2030 timeline. Oracle is supported only on Windows or Oracle Linux guests (SAP Note 2039619).

(b) OS/DB migration to SAP HANA

Move ECC or BW to HANA on the way to Azure, typically with SUM’s Database Migration Option (DMO) with System Move. It removes the database migration from a later S/4HANA conversion and meets the transition option’s HANA prerequisite. It is also a heterogeneous migration with real downtime, HANA sizing and testing, and you are still on ECC afterwards.

(c) S/4HANA: conversion, new implementation or selective data transition

SAP describes three transition paths. The Azure design is similar for all three; the program isn’t.

System conversion (brownfield)New implementation (greenfield)Selective data transition
What movesEverything: history, configuration, custom codeMaster data and open itemsChosen configuration and data, often a time slice
Custom codeKept, must be remediatedStart cleanSelectively transferred
Process changeMinimal, plus mandatory simplificationsHighest; built on SAP Best PracticesMix of reuse and redesign
Watch out forDowntime and data volume; non-Unicode and dual-stack sourcesData migration, change management, parallel runningSpecialist tooling and partners; complex testing

(d) RISE with SAP on Azure versus customer-managed

With RISE on Azure, SAP runs your systems in an Azure subscription and tenant that SAP owns. You don’t see those resources, your Azure support covers only your own subscriptions, and SAP decides the architecture (Microsoft Learn). SAP’s roles and responsibilities document shows the split: SAP does OS and database patching, standard backups and technical monitoring; customer-specific configuration, application support and interfaces stay with you unless you buy SAP’s Cloud Application Services; you get no privileged OS access; and backups can’t be retained beyond the contract end date. Customer-managed flips that: full control, full responsibility.

Lift and shift (AnyDB)OS/DB migration to HANAS/4HANA, customer-managedRISE with SAP on Azure
ControlFullFullFullShared; SAP sets architecture and operating standards
Who runs whatYou or your partner, every layerSameSameSAP: infrastructure, OS, database, technical Basis. You: application, interfaces, testing
Cost modelAzure consumption plus existing SAP and DB licensesAzure consumption, SAP maintenance, HANA licensingAzure consumption plus S/4HANA licensesFUE-based SAP subscription including infrastructure; your own Azure costs for integration
TimelineShortest; mainly technicalLonger; heterogeneous migrationLongest; business transformationSimilar functional effort; provisioning follows SAP onboarding
Main riskFixes the platform, not the SAP deadlineDowntime, sizing, still on ECCCustom code, data, change, in-house HA and Basis skillsLess control, change requests, contract and exit terms
Maintenance horizonECC: 2027, extended to 2030Same; post-2030 needs RISEPer release, commitment to 2040Per release; ECC transition option beyond 2030

Neither model is universally right. RISE suits organizations that want one contract and less Basis capability in-house, and is the only route to the post-2030 transition option. Customer-managed suits strong Basis and Azure teams, strict infrastructure audit requirements and deep integration with your own Azure estate. Either way you need a landing zone; RISE still needs peering, DNS, identity and security integration.

What to watch out for

Certified compute, and what is retiring

Only VM types listed in SAP Note 1928533 are supported for NetWeaver applications; the note also gives each VM’s SAPS rating. For HANA, the reference is SAP’s Certified and Supported SAP HANA Hardware Directory. As of October 2026:

HANA storage

/hana/data and /hana/log must use certified storage: Premium SSD, Premium SSD v2, Ultra Disk or Azure NetApp Files, and mixing is supported. Premium SSD (v1) needs Write Accelerator on /hana/log for M-series, and its caching and bursting complicate sizing. Premium SSD v2 needs no accelerator and lets you set capacity, IOPS and throughput independently, but allows only four performance changes per 24 hours and caps a single disk at 1,200 MB/s, so large systems need striping. Azure NetApp Files suits scale-out and snapshot-centric designs. Check file system support (SAP Note 2972496) and VM throughput limits, and validate with SAP’s HCMT before building production.

Sizing

For a like-for-like move, size from what the source actually does: SAPS from current hardware benchmarks compared with Note 1928533 ratings, plus EarlyWatch reports and OS data over real peaks. For HANA or S/4HANA, run the sizing report attached to SAP Note 1872170 (/SDF/HDB_SIZING) and use Quick Sizer for new scope (SAP Community). Common mistakes: sizing HANA before archiving, and copying on-premise peak sizing instead of planning to resize after go-live.

Network latency between application and database

SAP application servers send thousands of small database calls per second, so latency turns directly into business-process run time (Microsoft Learn).

  • No network virtual appliance between application and database (SAP Note 2731110), and no unpeered virtual networks between them; use NSGs and application security groups.
  • Enable accelerated networking on every SAP VM; Azure Advisor‘s SAP checks flag app-to-database latency above 0.7 ms.
  • Measure with niping, sockperf or ethr and classify against SAP Note 1100926; aim for “good” or “moderate.”
  • For new zonal deployments, Microsoft recommends flexible scale sets with fault domain count 1 over proximity placement groups. Use a PPG only for one SAP system with a measured latency problem; it binds VMs to one network spine and can block resizing.

High availability

Pacemaker on SLES or RHEL and Windows Server Failover Clustering are the only HA frameworks Microsoft directly supports for SAP (planning guide). Use HANA System Replication for HANA, and Always On, Data Guard, Db2 HADR or ASE HADR for AnyDB; shared-disk SQL Server failover cluster instances aren’t supported for SAP. Details that cause outages:

  • Standard Load Balancer with floating IP and HA ports (Basic retired on 30 September 2025), and net.ipv4.tcp_timestamps set to 0 on Linux nodes behind it.
  • ENSA2 is the default from ABAP Platform 1809, and three-node ASCS/ERS clusters require it; follow SAP Note 2641019 when switching from ENSA1.
  • Choose fencing deliberately (Azure fence agent or SBD), measure failover times, and follow guide updates; in 2026 Microsoft added RHEL 10 and SAPHanaSR-angi configurations.
  • Test failover rather than assume it. The SAP Testing Automation Framework scripts failure tests for HANA and Central Services; HA testing is GA, configuration checks are in preview.

Disaster recovery across regions

Replicate databases natively: HANA System Replication, usually asynchronous between regions, in a multi-tier or multi-target setup. Microsoft recommends Azure Site Recovery for application servers and Central Services but not databases. Paired regions don’t always offer the M-series sizes you need, and DR-region capacity isn’t guaranteed in a regional event; running non-production in the DR region keeps capacity available. Replicate Key Vault keys too.

Backup

Azure Backup for SAP HANA is Backint-certified, offers a 15-minute RPO and protects an HSR pair as one container. HANA instance snapshots are GA but require weekly full plus log backups via Backint alongside; snapshots for HSR systems are in preview, and a third HSR node in another region needs its own vault. Microsoft targets up to 420 MB/s for data and 100 MB/s for log backups, so check restore time against RTO. Turn on immutability, soft delete and multi-user authorization: ransomware recovery depends on backups an attacker can’t delete.

SAP Notes, support prerequisites and monitoring

SAP supports SAP on Azure only when its prerequisites are met. Read SAP Note 1928533 (products, OS and DB releases, VM types), SAP Note 2015553 (support prerequisites, including the required Microsoft support contract), and Notes 2235581, 1100926 and 2972496, and recheck them at every phase.

Every SAP VM needs the Azure VM extension for SAP solutions (the enhanced monitoring extension) so SAP Host Agent can report Azure metrics to SAP support. Use the new version for SLES 15+, RHEL 8.1+, Ultra Disk or Terraform/ARM deployments; it needs SAP Host Agent 7.21 PL47 or later and access to management.azure.com:

az vm aem set -g <resource-group> -n <vm-name> --install-new-extension

Azure Monitor for SAP solutions is separate: SAP, database, cluster and OS telemetry in Log Analytics for operations.

OS/DB migration constraints and downtime

  • S/4HANA conversion requires a Unicode, ABAP-only system (SAP conversion guide). Non-Unicode sources need a combined upgrade and Unicode conversion first; dual-stack systems must be split.
  • DMO combines the update with the move to HANA; DMO with System Move changes the environment, and Microsoft notes recent releases support azcopy over the internet.
  • Downtime-optimized DMO migrates selected large tables in uptime but can’t be combined with System Move. Downtime-optimized conversion needs an expert trained on SAP’s ADM329.
  • Near-Zero Downtime Technology is an SAP-delivered service that converts a production clone in uptime, records and replays changes, and leaves a short final delta.
  • Test whether ExpressRoute or the internet moves exports faster.

Interfaces, add-ons and custom code

Inventory every interface and connected system. Interfaces break on hard-coded IPs, firewall rules, file shares, certificates and SAProuter paths, a pattern covered in lessons learned from application migrations. For S/4HANA, the Maintenance Planner blocks the conversion if an add-on, business function or industry solution has no conversion path, so take third-party add-ons to their vendors early. Custom ABAP is remediated after the technical conversion with SPDD/SPAU and ABAP Test Cockpit (check variant S4HANA_READINESS); run SAP Readiness Check up front to size the work.

Data volume management

Every gigabyte archived or deleted before migration cuts HANA memory, Azure cost, transfer time and downtime. SAP’s Data Volume Management tools simulate the effect; agree retention with legal and compliance first.

Licensing

  • SAP: on IaaS you keep your SAP contract but need new license keys; read SAP Note 2243692 for Linux. S/4HANA or RISE is a separate negotiation.
  • Linux: RHEL for SAP and SLES for SAP come as pay-as-you-go or bring-your-own-subscription images; Azure Hybrid Benefit for Linux switches models without redeploying.
  • Windows Server: Azure Hybrid Benefit needs Software Assurance or qualifying subscriptions, with at least 8 core licenses per VM.
  • SQL Server: Marketplace images use the wrong collation for SAP and must be rebuilt to SQL_Latin1_General_CP850_BIN2 (Microsoft Learn). Confirm how your SQL licenses were bought before assuming Hybrid Benefit.

Cost management

  • Commit after sizing settles. A reservation or savings plan is a discount, not a capacity guarantee; for guaranteed M-series or DR capacity, Microsoft points to on-demand capacity reservations.
  • Shut down non-production out of hours; Azure Center for SAP solutions can stop SAP and HANA and deallocate the VMs on a schedule.
  • Right-size after go-live and track cost per SAP system ID.

Security

  • Enable Defender for Cloud on SAP subscriptions and Defender for Endpoint with Microsoft’s SAP-specific settings (Microsoft Learn). It doesn’t find ABAP or Java vulnerabilities, so SAP security notes stay a Basis process.
  • The Microsoft Sentinel solution for SAP applications now uses an agentless connector through SAP Integration Suite and Cloud Connector. The containerized agent retired on 14 September 2026 and its images were removed on 14 October; migrate now if you still run it.
  • Use customer-managed keys where policy demands, plus HANA or TDE encryption. Don’t use Azure Disk Encryption with Linux “for SAP” images or host-based encryption on M-series Linux VMs.
  • Enforce separation of duties with RBAC: Basis deploys VMs and disks but can’t change networks; the network team can’t modify SAP VMs.

Regulated-industry concerns

  • GDPR: keep production, DR and backups in EU regions, and check supporting services. Azure Migrate’s SAP assessment, for example, requires a project in a US or Asia geography.
  • NIS2: SAP usually supports the services that bring you into scope; expect to evidence incident detection, supplier risk management and tested continuity.
  • DORA: for financial entities, RISE is an ICT third-party arrangement with SAP on Microsoft infrastructure, so it needs contract terms, exit strategy and testing.
  • EU Data Act: its cloud-switching rules strengthen your hand on exit and portability; write exit assistance into the contract.

Tools and accelerators in October 2026

ToolWhat it doesStatus and caveats
Azure Center for SAP solutionsGuided S/4HANA deployment and installation; registers existing systems; 100+ quality checks via Advisor; start/stop; cost per SIDGA since May 2023. Guided installation lists S/4HANA 1909–2022 (docs); registration covers ABAP on HANA and AnyDB
SAP Deployment Automation FrameworkOpen-source Terraform and Ansible: control plane, workload zones, HANA and AnyDB, PacemakerFor teams with an infrastructure-as-code practice
SAP Testing Automation FrameworkAutomated HA failure tests and configuration checksHA testing GA; configuration checks preview
Azure Monitor for SAP solutionsTelemetry for NetWeaver, HANA, SQL Server, Db2, Pacemaker, OSUse the current version, not classic
Azure Migrate SAP discovery and assessmentSpreadsheet import of SAP inventory, then sizing and cost assessmentPreview since April 2024; the docs now carry a deprecation notice. Rough estimate only
SAP on Azure landing zone acceleratorCAF design guidance and reference architecture for SAP landing zonesDeprecated; CAF SAP articles are removed on 30 October 2026. Download the PDF
SAP toolsReadiness Check, Maintenance Planner, SUM/DMO, ABAP Test Cockpit, Quick SizerNeeded for S/4HANA regardless of hosting model

Commercially, Microsoft’s umbrella is now Frontier Accelerate for Azure; the FY26 program was Azure Accelerate, and the web address still uses that name. It offers zero-cost Cloud Accelerate Factory help, partner funding and Azure credits, and covers SAP on Azure and SAP RISE. For RISE on Azure, the Global RISE with SAP on Microsoft Azure initiative, expanded in May 2026, gives approved customers free access to SAP-skilled Microsoft engineers and go-live support. Terms change every fiscal year; get them in writing.

What to expect

Phases

Microsoft’s deployment checklist uses six phases that map well onto real programs. Published durations rarely compare across scopes, so plan bottom-up from your own pilot and mock-run timings. For the wider estate, see the Cloud Migration Handbook and datacenter migration to Azure.

  1. Planning: inventory, RACI, design, sizing, HA/DR, security, interfaces, data reduction, automation.
  2. Pilot (Microsoft calls it strongly recommended): prove VMs, storage, latency, HA/DR, security and transfer paths.
  3. Non-production: DEV, QA and regression on Azure, at least one in full production HA configuration; refine sizing.
  4. Production preparation: upgrades done before the move, business tests run on the source first, mock cutovers, maintenance-event playbooks.
  5. Go-live: follow the rehearsed runbook with no late changes; check interfaces, STMS and backups; reset the SM51 host name buffer on connected systems.
  6. Post-production: hypercare, cost reviews, right-sizing, reservations, DR drills.

Team and roles

  • SAP Basis: system copies, SUM/DMO, HANA, kernel, clusters. Usually the critical path.
  • Azure platform: subscriptions, policy, RBAC, automation; request M-series quota early.
  • Network: ExpressRoute, DNS, firewalls, latency testing.
  • Security and compliance: Defender, Sentinel, keys, evidence.
  • Functional owners, key users and testers who sign off each cutover; ABAP developers; integration specialists.
  • With RISE, SAP takes much Basis and infrastructure work, but you still need people who can challenge SAP’s technical deliverables.

Mock conversions and cutover rehearsals

Calm go-lives come from full rehearsals on production-sized data. Each mock run should yield measured step timings, a defect list and an updated runbook; repeat until downtime fits the window with margin, and agree go/no-go criteria and a rollback point. On RISE, check your entitlement: SAP’s roles and responsibilities include two extra test runs for a conversion (one non-production, one production); more are billable.

Hypercare and optimization

If the pilot did its job, hypercare surfaces batch-job and interface outliers, not infrastructure failures. Compare consumption with the on-premise baseline, resize, then commit to reservations. Schedule DR drills and keep quality checks clean; new VM generations arrive faster than SAP releases.

Pre-migration checklist

  1. Confirm your SAP maintenance position: ECC EHP level, the 2027/2030 dates, and S/4HANA target release (2023 or 2025).
  2. Decide RISE or customer-managed before detailed design; for RISE, get roles, backup terms and test-run entitlements into the offer.
  3. Inventory systems, interfaces, add-ons, file shares, printing and batch dependencies.
  4. Run SAP Readiness Check and Maintenance Planner; confirm Unicode and dual-stack status.
  5. Start data volume management under agreed retention rules.
  6. Size with SAPS, EarlyWatch, the Note 1872170 report and Quick Sizer; verify SKUs against Note 1928533 and the HANA directory.
  7. Confirm M-series and storage availability and quota in production and DR regions; avoid retiring series.
  8. Design the landing zone: no NVA between app and database, accelerated networking, DNS, identity, RBAC separation.
  9. Define RTO/RPO, then HA/DR: HSR or native replication, Pacemaker or WSFC, DR capacity.
  10. Design backup with immutable vaults and tested restore times.
  11. Meet SAP support prerequisites: Note 2015553, Microsoft support contract, VM extension for SAP, Host Agent version.
  12. Plan licensing: SAP keys, RHEL/SLES model, Windows and SQL via Hybrid Benefit.
  13. Plan security monitoring: Defender for Cloud, Defender for Endpoint, agentless Sentinel connector.
  14. Map GDPR, NIS2, DORA and Data Act obligations to design and contracts, including exit.
  15. Choose a migration method per system and test transfer throughput.
  16. Plan a pilot and mock cutovers with go/no-go criteria and rollback.
  17. Staff Basis, Azure, network, security, functional, ABAP, integration and testing roles.

Where to start

Start three things in parallel: settle your SAP maintenance and S/4HANA position with SAP; decide RISE versus customer-managed with security, procurement and risk; and run an Azure pilot that proves sizing, storage, latency and failover on real data. Almost everything else depends on those answers. If SAP application servers still run on VMware, see VMware to public cloud.

Sources

Last reviewed: October 2026.

Leave a Reply

Rares Juretchi

Rares Juretchi

Rares is a cloud and enterprise architect with over 25 years of IT experience. He has led or architected over 100 cloud programs in regulated industries, including healthcare, finance, manufacturing and energy, and specializes in Azure landing zones, migrations and governance, with AWS alongside.

The blog offers practical guidance on:

  • Cloud migration strategy and execution
  • EU digital regulation (NIS2, DORA, the AI Act and more) for cloud teams
  • Cloud security frameworks and compliance
  • Landing zones and cloud governance

Read the full profile →

Let’s connect