SAP System Landscape and Its Impact on Your Licence Position: What Every Architect Must Know

Your SAP system landscape is not just an architectural decision — it is a licensing decision. Every development system, QA environment, sandbox, and training client you spin up has direct implications for your Effective License Position (ELP). And yet most SAP architects make landscape choices based purely on technical requirements, with no visibility into the commercial consequences. SAP's measurement tools — USMM and LAW — measure every system in your landscape. If users touch those systems, SAP counts them. If you haven't mapped your landscape to your licence entitlements, you're building compliance risk into your infrastructure one environment at a time.

This guide explains exactly how SAP's licensing model treats each system type, where the traps are, and what architects, CIOs, and ITAM teams can do to design landscapes that don't silently inflate licence exposure.

SAP's primary measurement tool is the USMM (User & System Measurement). When a USMM measurement runs — whether triggered by SAP during an audit or executed internally during annual self-declaration — it identifies all users in the system being measured and assigns them a licence classification based on their roles, authorisations, and transaction usage.

Crucially, USMM measures productive systems. SAP's definition of "productive" is broader than most architects assume. A system is treated as productive if it contains real business data and real business users — regardless of whether you internally classify it as development, QA, or test. The label you give a system in your landscape documentation is not what SAP looks at. SAP looks at who has access and what they can do.

The second tool is LAW (License Administration Workbench), which aggregates measurement results across your entire landscape and consolidates them into an ELP. LAW is the system of record SAP uses in its audit claims. If you have never run LAW across your full landscape, you do not know your actual ELP — and SAP does.

The Landscape SID and System Role

Each system in your SAP landscape has a System ID (SID) and a defined role — typically PRD (production), QAS (quality assurance), DEV (development), or sandbox. SAP's standard licence agreement requires that named users be licensed for all productive systems they access. But the agreement's definition of "productive" often includes systems you've designated as non-productive. If a user's SAP ID is active in a QAS system that contains current business data and has the same authorisation profile as PRD, SAP treats it as a productive access and counts accordingly.

Understanding how SAP treats each environment type is the starting point for any landscape licence analysis. The rules are more nuanced — and more commercially aggressive — than most technical teams realise.

Production Systems (PRD)

All users with access to production systems must be licensed as named users in the appropriate user type. This is unambiguous. Every active user ID in PRD is counted in USMM and must be covered by your licence entitlement. The only accepted reduction is to delete or lock user accounts promptly when employees leave or change roles.

Quality Assurance and Pre-Production (QAS)

This is the most dangerous environment for licence exposure. Most enterprises assume QAS carries no licence obligation because it's "just a test system." SAP's position is the opposite: if QAS is used for user acceptance testing (UAT), parallel runs, or any activity that involves real users making business decisions — even temporarily — it triggers a named user licence obligation. Worse, QAS environments are rarely managed as rigorously as production from a user hygiene perspective, leading to bloated user counts that inflate the USMM measurement.

Development Systems (DEV)

Developer access requires a Developer licence, which is a separate named user type in SAP's ELP. Organisations routinely under-licence developers because they incorrectly assume that any technical user with "developer" access can be covered by a Professional licence. SAP draws a clear distinction. Furthermore, when business analysts, functional consultants, or support teams are given access to DEV to "test configurations," they must also be licensed. The casual sharing of developer system access is a significant audit risk.

Sandbox and Training Systems

Sandbox systems are frequently treated as licence-free by enterprise teams. This is only correct when the sandbox uses synthetic, non-production data and the access is limited to truly exploratory use. If real employees access a sandbox with their live SAP credentials — especially one that was created via a system copy of production — SAP can and does assert licence claims. Training systems carry the same risk when production employees use their standard credentials to access them.

The most common landscape-related audit finding we encounter involves DEV and QAS systems. The pattern is almost always the same: the organisation has carefully licensed its production environment, but the non-production landscape has grown organically over years, accumulating users, roles, and authorisations that mirror production — without the corresponding licence coverage.

The "Copy Production Roles to QAS" Problem

When transport management releases a new change into QAS for testing, it's common practice to give testers production-equivalent authorisations so they can validate the full business process. From a technical standpoint, this makes perfect sense. From a licensing standpoint, it creates a named user obligation for every person running those tests. Over a large organisation, this can add hundreds of user-days of licence exposure annually.

The User Account Hygiene Gap

Non-production systems rarely have the same rigorous user lifecycle management as production. Leavers' accounts persist. Contractors retain access long after engagement end. Temporary access granted for a specific project never gets removed. When USMM runs across QAS, it counts every active user — not just the ones currently engaged in testing. A QAS system that's been running for five years without proper user account management can contain two or three times as many users as production.

Shared DEV Environments

Shared development environments — where multiple teams work in the same DEV client — compound the problem. If 40 developers, 20 functional consultants, and 10 basis administrators all have access to the same DEV system, you need Developer licences for all of them. The cost difference between a Professional licence (often used to cover these users incorrectly) and a Developer licence matters, but the bigger risk is that the users haven't been licensed for DEV at all under the assumption that it doesn't count.

System copies are a standard SAP operations practice. You take a copy of production to refresh QAS, create a performance test environment, or stand up a new landscape for a project. What most teams don't consider is that a system copy carries with it the full user population and authorisation structure of the source system. From SAP's perspective, you now have two productive environments with the same users — and the obligation to licence both.

What the Contract Actually Says About System Copies

SAP's standard licence agreement (EULA) permits system copies for non-productive purposes but does not exempt them from measurement. The key qualifier is "non-productive" — and as noted above, SAP's interpretation of productive is tied to user behaviour and data, not system role. If your refreshed QAS environment is accessed by real users for UAT before a go-live, SAP treats it as productive for measurement purposes. Your contract will not protect you from this claim unless it contains explicit language carving out QAS from the measurement scope — language SAP does not include by default and which must be specifically negotiated. Our SAP contract negotiation team regularly secures these protections for enterprise clients.

Disaster Recovery (DR) Systems

DR landscapes present a related but distinct challenge. SAP's standard position is that a fully mirrored DR system requires the same licence entitlement as production. Some contract variations include a "DR exemption" — typically permitting a single standby system to remain unlicensed as long as it is never productively used. Enterprises that assume their DR system is automatically exempt, without having verified this in their contract, are at risk of a significant audit claim if the system is ever activated for a parallel run or failover test with real users.

One of the most effective — and underused — tools for permanently reducing SAP licence costs is landscape consolidation. Enterprises running multiple ECC systems, often acquired through mergers or grown organically across subsidiaries, frequently pay for redundant licence capacity across systems that serve overlapping user populations.

When multiple production systems are consolidated into a single S/4HANA environment, the user population consolidates with it. Users who previously needed access to two or three production systems — each requiring separate licence coverage — now need access to only one. The licence savings can be substantial: we typically see a 15-25% reduction in named user obligations following a well-executed consolidation. This is not a theoretical benefit. It is a contractual and commercial reality that should be built into every S/4HANA business case.

The Subsidiary Landscape Problem

Multinational organisations frequently run separate SAP systems for subsidiaries that were once independent companies. These subsidiary systems are often small — a few hundred users — but they each require licensed access for all active users. When aggregated across a group with 20 or 30 subsidiaries, the landscape complexity creates enormous measurement and compliance risk. Group licence agreements (often negotiated as part of an SAP Enterprise Licence Agreement or ELA) can provide more predictable cost structures for these environments, though they come with their own commercial trade-offs. See our detailed guide to SAP Enterprise Licence Agreements for more on this.

For organisations considering consolidation, our S/4HANA migration licensing team provides end-to-end analysis of how your current landscape maps to post-consolidation licence requirements — including identifying where you can negotiate reduction credits as part of the migration commercial terms.

For organisations transitioning to RISE with SAP or deploying S/4HANA Private Cloud Edition, the landscape model changes significantly — but the licensing principles do not disappear. In cloud deployments, SAP manages the infrastructure, but you remain responsible for licensing the named users who access the system.

RISE with SAP typically bundles a single production system and a limited number of non-productive system copies — but the allocation of non-productive system access and the rules governing which users can access them are contractual matters, not defaults. Enterprises that assume the RISE bundle covers all their non-productive access requirements are frequently surprised to discover that sandbox access, additional QAS refresh cycles, or parallel systems for hypercare periods require additional entitlements.

BTP Landscapes and Indirect Access

SAP Business Technology Platform (BTP) introduces a new landscape dimension that carries its own licence implications. Custom applications built on BTP that trigger SAP S/4HANA document creation — whether Order, Delivery, Invoice, or Material — are subject to SAP's Digital Access licensing model. If your BTP landscape includes applications that access SAP via APIs, you need to ensure those interactions have been mapped against your Digital Access entitlement. Failure to do so creates an indirect access exposure that can be just as significant as named user gaps. See our guide to SAP indirect access for a comprehensive breakdown.

Every SAP architect making landscape decisions should be able to answer the following questions before any new system, client, or environment is provisioned:

• Who has access? What are the named users in this environment, and do they exist in other systems that are already being measured?
• What data does it contain? Is this a system copy of production? Does it contain real business data?
• What authorisations are assigned? Are users in this environment carrying production-equivalent roles?
• Is this system in the LAW scope? Has the new system been included in the LAW landscape configuration?
• What does the contract say? Does your current SAP agreement include any explicit non-productive system exemptions?
• What is the user lifecycle management process? How will user accounts be managed in this environment — who approves access, and when does it get removed?
• Is there a DR or failover copy? If so, is it covered by a DR exemption in your contract, and has that exemption been tested with SAP?

If you can't answer these questions confidently, your landscape is creating licence exposure that you can't see. Engaging a dedicated SAP licence optimisation review before an audit — not in response to one — is the most cost-effective way to close these gaps.