Skip to content

What we do

SAP on Azure

Landing zone and security design for SAP workloads on Azure, with the RISE responsibility split written down and agreed.

Frameworks
CAF: Ready, Manage · Well-Architected: Reliability, Security
Good first step
Microsoft CAF Readiness Assessment, a baseline in 3–4 weeks

The problem

SAP on Azure sits between two teams. The SAP practice owns the application and the platform team owns Azure, so the infrastructure layer between them can easily end up with neither. Under RISE with SAP the boundary moves again, and the shared responsibility split tends to be written down after something breaks.

You probably need this if

  • Your SAP team and your Azure team each assume the other owns the infrastructure layer
  • It's hard to say in one sentence where SAP's responsibility under RISE stops and yours starts
  • SAP infrastructure alerts arrive somewhere different from everything else
  • The stated RPO and RTO haven't been tested against the design

What the service covers

  1. 1SAP-specific landing zone design: network topology, proximity placement, and the storage tiering HANA requires
  2. 2RISE with SAP integration: connectivity, identity federation, and a documented responsibility split between you, SAP and us
  3. 3Security baseline for native SAP on Azure, including privileged access to the infrastructure you still own
  4. 4Backup, HA and DR design validated against stated RPO and RTO for native workloads; under RISE, a review of what the contract commits SAP to, tested against your assumptions
  5. 5Cost management for SAP estates, where reservation planning is materially different from general compute
  6. 6Monitoring integration so SAP infrastructure alerts land in the same place as everything else

Agreeing the responsibility split

We begin by writing down how your SAP estate is hosted, whether RISE is in scope, and where responsibility sits between your teams and SAP. Most of the design decisions that follow depend on having that agreed first.