Your SAP estate is already on Azure, or the business case is nearly approved. The landing zone exists, S/4HANA is being sized, and the migration plan has a target weekend. Then someone asks a less comfortable question: what happens to analytics extraction after cutover, can the workload be recovered in the required jurisdiction, and who owns the platform at two o'clock in the morning?
That's the point at which SAP on Azure stops being a hosting project. It becomes an operating model covering certified infrastructure, application resilience, data integration, security, sovereignty, cost control, and continuous change. The migration is only the first production event. The test is whether the estate remains supportable and predictable afterwards.
Table of Contents
- Why SAP on Azure Is Now a Strategic Choice, Not Just a Hosting One
- What SAP on Azure Actually Means Layer by Layer
- Common SAP on Azure Architecture Patterns and When Each One Fits
- Migration Patterns, Cutover Options, and the Hidden Cost of Going Greenfield
- What Changes When RFC-Based SAP Replication Is Deprecated
- Governance, Security, and Sovereignty Beyond the Compliance Tickbox
- Cost, Performance Trade-offs, and How Kagool's Factory Model Delivers Predictable SAP on Azure
- The Decisions a Leadership Team Should Make Before Signing the SOW
Why SAP on Azure Is Now a Strategic Choice, Not Just a Hosting One
A CIO may approve Azure to modernise an aging SAP estate, but the decision quickly reaches beyond infrastructure. Finance wants predictable consumption. Security wants identity and access controls aligned with the wider Microsoft estate. Data leaders want SAP information available for analytics and AI. Regional executives want recovery and support arrangements that respect local obligations.
That breadth is why the Microsoft and SAP relationship matters. The companies have maintained a strategic technology partnership for more than 30 years, expanding from traditional Windows Server and SQL Server deployments into certified SAP HANA infrastructure, S/4HANA, automation, identity, analytics, and collaboration. By 2018, Azure offered 26 SAP HANA configurations, with memory options from 192 GB to 24 TB, and availability in 12 Azure regions, according to Microsoft's SAP HANA infrastructure overview.
Azure's position also reflects enterprise familiarity. Microsoft reported that 47% of respondents in a 2020 SAPinsider survey identified Azure as the primary platform they were considering for public-cloud S/4HANA deployments, compared with 21% for Google Cloud and 18% for AWS. The same Microsoft analysis cited a Forrester model showing 112% ROI, a 30% reduction in time to market, and payback in less than six months. Those are modeled outcomes, not guarantees, but they explain the strength of the business case.
Architect's view: Treat SAP on Azure as a recurring product, not a completed migration. Design the operating model before the first cutover rehearsal.
The lift-and-shift-and-forget mindset causes programmes to drift. A workload can run successfully on Azure while its replication jobs, recovery procedures, ownership boundaries, and regional exit options remain unresolved. The strategic choice is therefore not only where SAP runs. It's how the organisation will operate the business system and everything connected to it.
What SAP on Azure Actually Means Layer by Layer
SAP on Azure is a stack, not a single service. Each layer has its own support boundary, certification requirement, failure mode, and owner.
At the top sit the SAP applications, such as S/4HANA, ECC, BW, and connected SAP services. Beneath them is the HANA database, which keeps its working data in memory and therefore drives much of the infrastructure design. The operating system is typically SUSE Linux Enterprise Server or Red Hat Enterprise Linux, followed by Azure virtual machines, storage, networking, backup, and monitoring.
Start with the certified HANA boundary
Don't select a VM because its raw memory specification looks attractive. Microsoft's guidance requires teams to use the SAP HANA Certified and Supported Hardware Directory when choosing infrastructure. Documented scale-up options range from Edsv4 and Edsv5 deployments with at least 160 GiB of RAM to Mv3 systems supporting up to 30 TiB, while Azure documentation describes single-node scale-up capacity reaching 32 TB in the relevant guidance (Microsoft HANA architecture guidance).
Certification validates more than memory. It covers the processor, memory, storage, and virtualisation characteristics SAP requires. A larger uncertified VM can therefore introduce support and migration risk even when it appears technically powerful.
Add the control planes
The surrounding platform determines whether the SAP stack is governable:
- Identity: Microsoft Entra ID, SAP identity services, privileged access, and service identities need explicit boundaries.
- Network: Application, database, management, backup, and integration traffic should be separated according to risk and operational need.
- Storage: Data, log, shared, and backup volumes require different performance, resilience, and retention decisions.
- Operations: Azure Monitor, SAP monitoring, backup validation, patching, and incident response must work as one runbook.
RISE with SAP changes the commercial and operational boundary, but it doesn't remove the need to understand dependencies. SAP Business Technology Platform can extend the environment, while Azure services can support integration, security, analytics, and collaboration. The leadership team still needs to document who owns each layer, who approves changes, and who proves recovery.
The practical sizing sequence is straightforward: estimate HANA memory including growth and non-production overhead, select a certified VM, validate the supported Linux release, and then check compatibility among the operating system, HANA revision, and SAP product in the Product Availability Matrix. That sequence prevents the common mistake of designing an Azure environment first and checking SAP validity afterwards.
Common SAP on Azure Architecture Patterns and When Each One Fits
Architecture should follow the workload, not the vendor diagram. A sandbox, a global ERP system, and a BW platform have different availability, latency, and operational requirements.
Three patterns that cover most estates
A single certified VM is appropriate for development, proof of concept, training, and smaller non-production systems. It's simple to build and easy to understand, but it creates a clear outage boundary. Don't use it for a core production ERP system merely because the application technically starts.
A high-availability pair across availability zones suits production HANA workloads where database resilience is a primary requirement. The design normally combines HANA system replication, cluster management, application routing, and carefully tested failover procedures. It increases complexity and operational discipline, but a production system without a tested recovery path is only apparently cheaper.
A multi-tier architecture separates application servers, HANA, central services, shared storage, management access, and backup or recovery services. This is the right pattern for large S/4HANA estates, BW on HANA, and side-by-side transformation programmes where integration and lifecycle boundaries matter as much as compute.
| Pattern | Best Fit Workload | Availability Posture | Typical Cost Signal |
|---|---|---|---|
| Single certified VM | Sandbox, development, training, smaller non-production estate | Basic recovery, limited redundancy | Lowest infrastructure complexity and consumption |
| HA pair across zones | Core production ERP and business-critical HANA | Replicated database and zonal resilience | Higher compute, storage, licensing, and testing effort |
| Multi-tier landscape | Global S/4HANA, BW, integration-heavy or side-by-side estates | Independent tier resilience with broader recovery design | Highest design and operating complexity |
Choose the pattern with failure in mind
For a global ERP system, place availability and recovery decisions ahead of convenience. A pair of database VMs doesn't automatically create a resilient SAP service. Application servers, central services, routing, batch processing, interfaces, backup restoration, and operator access all need a tested response.
BW on HANA deserves particular scrutiny. Large analytical workloads can create different storage and network patterns from transactional S/4HANA, especially where extraction, transformation, and reporting run alongside operational activity. Separate the tiers when contention, security, or recovery objectives justify it.
Practical rule: If the team can't explain what happens to the application tier, interfaces, scheduled jobs, and users after a database failover, the architecture isn't finished.
For side-by-side S/4HANA transformation, a multi-tier model gives the programme room to introduce BTP services, integration workloads, data products, and controlled coexistence. That flexibility costs more to govern, but it avoids forcing every future capability into the production ERP boundary.
Migration Patterns, Cutover Options, and the Hidden Cost of Going Greenfield
Greenfield is not a synonym for good architecture. It's a business decision to redesign processes, data, custom code, roles, integrations, and operating procedures at the same time as the platform changes.
A brownfield conversion preserves more of the existing system. It can reduce business disruption and protect embedded process knowledge, but it may carry forward unnecessary custom code, weak master data practices, and historical design compromises. Use it when continuity matters, the current process model remains defensible, and the organisation can't absorb a broad redesign.
A greenfield implementation rebuilds processes on S/4HANA, often with a cleaner target model. It can be the right answer when the existing estate has become an obstacle, but the hidden cost is substantial. Business owners must define new processes, test them, retrain users, rebuild integrations, cleanse data, and agree what historical information remains available.
Selective data transition sits between the two. It preserves selected data and capabilities while allowing process redesign where the business needs it. This path is attractive for organisations that want a controlled transformation without carrying every historical decision forward.
Make the cutover decision explicit
Big-bang cutover offers one clean system boundary but concentrates risk into a narrow window. Phased migration reduces the blast radius, yet it creates coexistence, reconciliation, and interface complexity. Neither is automatically safer.
Before choosing, settle four questions:
- Custom ABAP: Which developments are retained, remediated, replaced, or retired?
- Data scope: Which master, transactional, open-item, and historical data moves?
- Parallel operation: How will old and new systems reconcile during coexistence?
- Business readiness: Can process owners test and sign off the target model?
Stage data loads early and rehearse them with production-like volumes. The team should measure completeness, reconciliation, processing duration, restart behaviour, and user acceptance, not just whether the technical job finishes.
For organisations trying to industrialise this work, a SAP migration factory approach can standardise assessment, build, testing, and cutover controls instead of relying on a small group of programme heroes.
Greenfield is justified when process redesign has a funded owner, a realistic adoption plan, and a clear data policy. If those conditions don't exist, brownfield or selective transition usually offers a more credible route to business continuity.
What Changes When RFC-Based SAP Replication Is Deprecated
A successful HANA migration can still break the data platform. That happens when teams treat extraction as a connector detail rather than as part of the production operating model.
SAP's updated direction indicates that third-party use of RFC-based ODP replication APIs is being discontinued, while the proposed OData-based alternative isn't expected to be further developed. The result isn't a simple replacement exercise. Data leaders must review each extraction workload, including ECC and S/4HANA objects, change-data-capture jobs, reconciliation feeds, audit datasets, and high-volume tables.
Build an object-level decision register
Do not approve a migration interface at platform level. Assess the object and workload level instead.
- Classify the source: Record the ECC or S/4HANA object, extraction method, volume profile, change frequency, and business owner.
- Define the control: Decide how the target proves completeness, ordering, latency, duplicate handling, and restart behaviour.
- Test the fallback: Identify the alternative for high-volume or operationally sensitive tables before the current interface is withdrawn.
- Preserve evidence: Store lineage, mappings, run history, exceptions, and reconciliation results in a form auditors can inspect.
- Sequence the cutover: Run old and new paths where possible, compare outputs, and establish an explicit rollback decision.
A web-based interface can be suitable for some workloads, but a generic connector swap won't solve volume, semantics, authorisation, or audit requirements. The data engineering team must test real objects and real business controls.
Teams moving SAP information into Azure Data Lake, Synapse, Fabric, or another analytical platform should treat extraction as a first-class migration stream. SAP-compliant data extraction before and after the ODP RFC prohibition provides a useful reference point for framing that work.
The uncomfortable truth: “Cloud migration complete” doesn't mean “data integration stable.” Your ERP can be healthy while downstream reporting quietly loses freshness or completeness.
At minimum, the cutover dashboard should show extraction success, data latency, record counts, reconciliation exceptions, schema changes, and failed restarts by workload. Assign an owner for each feed. If a report is business-critical, its evidence trail must be treated as part of the service, not as an afterthought owned by whoever built the original job.
Governance, Security, and Sovereignty Beyond the Compliance Tickbox
Security, governance, and sovereignty are one decision set. Separating them into independent checklists hides the interactions that matter during an incident, a recovery event, or a regulatory review.
Identity begins with Microsoft Entra ID, SAP identity management, privileged access, service principals, and emergency access. Define which identities can administer Azure, which can administer SAP, which can access production data, and which can perform recovery actions. Use least privilege, approval workflows, and monitored break-glass access.
Network design should isolate application, database, management, backup, and integration paths according to the threat model. Encrypt data at rest and in transit, manage keys through Azure Key Vault where appropriate, and document who can use, rotate, or recover those keys. Non-production governance deserves equal attention. Production extracts copied into development environments can create a serious exposure even when the production platform itself is well protected.
Sovereignty includes the failure path
Residency during normal operation is only one question. Ask where the workload, backups, support access, monitoring data, recovery copies, and operational staff are located when something goes wrong.
SAP documentation for a SuccessFactors storage change warns that customers moving between Azure-based and non-Azure datacenters, or between certain Azure and Google Cloud locations, can face migration constraints. Cross-datacenter integrations may also require manual intervention, as described in the SAP SuccessFactors storage change guidance.
That matters for any multinational estate with regulatory, geopolitical, or exit concerns. A region may satisfy residency under normal operations while recovery or support procedures create a different exposure. Document:
- Regional placement: Which Azure regions contain primary, secondary, backup, and monitoring data?
- Recovery movement: Can the service recover within the permitted jurisdiction?
- Exit portability: Can the organisation move between Azure regions or another hyperscaler?
- Privileged access: Which personnel and support teams can access systems and data?
- Testing evidence: How often are recovery, access, and residency assumptions tested?
A practical SAP on Azure governance and compliance framework should connect controls to failure scenarios rather than merely listing certifications. Sovereignty is an architecture and product concern, not a contract line that can be checked once.
Cost, Performance Trade-offs, and How Kagool's Factory Model Delivers Predictable SAP on Azure
Production HANA-certified VMs usually dominate the infrastructure bill, but they aren't the only lever. Storage tier, replication design, backup retention, non-production scheduling, network architecture, and the number of environments can change the economics materially.
Use reserved capacity or savings plans only after the workload profile is understood. Otherwise, the organisation can lock in consumption that changes after sizing, consolidation, or migration. Apply the same discipline to storage. HANA data and log volumes need predictable performance, while backup and archive data may have different requirements.
Spend according to workload behaviour
Non-production environments should have clear owners, schedules, refresh rules, and shutdown policies. A development VM left running because nobody owns it is a governance failure disguised as a small cost.
Performance choices need measurement. Scale-up simplifies HANA memory management and can suit large transactional workloads. Scale-out may provide a route for very large systems, but it adds topology, placement, and operational complexity. BW workloads also require careful network and storage design because extraction, processing, and reporting can compete with transactional activity.
Premium SSD v2 can be considered where its performance and configuration characteristics match the workload, but the decision should follow measured I/O demand rather than product fashion. Benchmark application response, database latency, batch completion, backup windows, and failover behaviour with representative data.
Replace bespoke heroics with repeatable controls
A factory model works when it standardises the activities that otherwise vary from project to project:
- Assessment: Capture dependencies, interfaces, custom code, data scope, and operational ownership.
- Build: Apply repeatable landing-zone, network, security, compute, and database patterns.
- Validation: Automate migration checks, reconciliation, performance evidence, and recovery tests.
- Transition: Move the same controls into managed operations with clear support boundaries.
Kagool's Velocity provides no-code SAP-to-Azure data ingestion, while Pulse supports SAP data migration planning, execution, and validation. Its SparQ suite covers reporting, governance, transformation, insights, and security. Those tools are useful when they sit inside a controlled delivery method rather than being treated as shortcuts around architecture.
The Build Factory Model is the important idea. It turns repeatable work into governed assets, keeps evidence consistent across environments, and makes exceptions visible. That helps the CFO understand what is being standardised, while the architect can still approve workload-specific deviations.
The Decisions a Leadership Team Should Make Before Signing the SOW
The SOW should not begin with “migrate SAP to Azure.” It should name the target operating model and the decisions that prevent scope from expanding after the first design workshop.
Bring the following questions to the steering committee:
| Decision | Why It Matters Now | Default if You Delay |
|---|---|---|
| Migration pattern | Determines data scope, process redesign, custom-code treatment, and business disruption | The programme drifts toward an expensive hybrid |
| Architecture pattern | Sets resilience, tier boundaries, performance, and operating effort | A reference design becomes the default without workload evidence |
| Extraction strategy | Protects analytics, CDC, reconciliation, lineage, and auditability as RFC-based replication changes | Reporting teams discover interface risk after ERP cutover |
| Sovereignty posture | Defines region placement, support access, recovery movement, and exit options | Residency is treated as normal-operation compliance only |
| Cost controls | Establishes VM commitment, storage policy, non-production scheduling, and backup discipline | Consumption grows before ownership is clear |
| Delivery model | Determines how repeatable build, testing, migration, and evidence will be | Delivery depends on scarce individual specialists |
| Steady-state ownership | Clarifies who monitors, patches, restores, tests, and responds to incidents | The SI, cloud team, SAP team, and data team assume someone else owns it |
The team should also decide whether it wants a traditional systems integrator, a nearshore or distributed model, or a factory-led approach with reusable accelerators. When assessing capability, a resource example such as how nexus IT group placed an azure can help leaders think about the difference between sourcing an individual expert and building an accountable delivery capability.
Ask for written acceptance criteria before signing. They should cover certified infrastructure, cutover rehearsal, data completeness, recovery evidence, security controls, operational handover, and the ownership of exceptions. If the supplier can't state how these will be demonstrated, the programme isn't ready for a fixed commitment.
Kagool helps organisations assess and migrate SAP estates to Azure, design certified target environments, stabilise SAP data extraction, and establish repeatable migration and operations controls. Visit Kagool to discuss an SAP on Azure programme built around migration evidence, governance, and predictable steady-state delivery.
