We run SAP AI Lab — two of us, one in ML systems, one in enterprise information systems, entirely independent of SAP and Microsoft. This spring our lab finally got approval to move a real SAP landscape to Azure, and before touching a single VM we spent three weeks arguing about landing zones. Half our search results led nowhere. Here's what we settled on, verified as of 2026-11-08.
The pages we needed were gone
The Cloud Adoption Framework once shipped SAP-specific enterprise-scale landing zone docs describing an "SAP on Azure construction set" of six design areas: identity and access, network topology, management and monitoring, business continuity/DR, security-governance-compliance, and platform automation and DevOps. Those pages are now retired from the live English site — requesting them today redirects to the generic landing zone overview. Nothing officially documented replaces their SAP-specific checklists one-for-one.
So we went to the archive: the docs repository on GitHub, read at a pinned commit. Two recommendations from there we adopted verbatim — run at least two SAP management groups so production and non-production get distinct controls, and keep the core SAP platform in dedicated subscriptions. When a fact comes from a 2021 revision, we label it as archived rather than pretending the live page exists. If you're designing this now, plan on doing the same archaeology.
What the live framework does still say — and it's enough
The current subscription design area explicitly names SAP, alongside high-performance computing and IoT, as a "large specialized workload" that should use separate subscriptions to avoid running up against platform limits. Three reasons we now repeat in every review meeting: a subscription is a scale unit, a management boundary, and a policy boundary — "development environments have more relaxed policy requirements than production environments." A 2 TB-in-memory database box does not want to share a quota namespace or a policy scope with your chatbot demo.
Our tree, after two failed drafts: tenant root → Online (platform: identity, connectivity, management, security subscriptions — the design area is blunt that you "do not combine platform responsibilities into a single subscription") → a workload management group named SAP, with SAP-DEV, SAP-TEST, and SAP-PRD as separate children. Production under its own management group child is what makes "deny by default in prod, relaxed in dev" a two-click policy assignment instead of an exception spreadsheet. One counterintuitive mercy: subscriptions are global logical containers, so you do not need one per region — the primary-plus-secondary DR pair shares a subscription unless it's independently managed.
The gotcha that cost us two days
A service principal with only Contributor cannot grant permissions to what it deploys. The SAP Deployment Automation Framework planning doc is explicit that automation identities also need User Access Administrator — and our first control-plane deployment failed for two days before we found that one line:
az role assignment create \
--assignee <your-application-ID> \
--role "User Access Administrator" \
--scope /subscriptions/<your-subscription-ID>/resourceGroups/<your-resource-group-name>
Two smaller landmines, same price bracket. Every dedicated spoke subscription eats your account's subscription count, and the defaults are not generous — we requested a quota increase before creating the sixth spoke. And the archived governance page recommended excluding SAP database servers from automatic endpoint-protection policy installs; we nearly learned that one the painful way during a HANA storage-layer test.
Then, and only then, the compute
The sequencing that actually worked: management groups and policy scopes → control plane (the DAF's hub subscription with deployer VMs, Key Vault, firewall, Bastion) → workload zones → systems. For one system instead of a landscape, Azure Center for SAP solutions and its Virtual Instance for SAP solutions resource bakes the separation-of-duties RBAC in for you — the framework and ACSS are complementary, not a decision between tribes. Naming is governance too: fight the DAF convention (DEV-WEEU-SAP01-INFRASTRUCTURE) after you've deployed anything and you'll be miserable; decide it in the review meeting, not in the Terraform state.
The full walkthrough with all the pricing sources and checklists is on our site: Azure Landing Zone for SAP in 2026 — the complete management-group layout, commit-pinned archive citations, and what we verified versus guessed. The compute decisions that come after this carve-out live in our HANA deployment guide, and the contract-side reading is in RISE with SAP on Azure.
Top comments (0)