SAP System Copies and Licensing: Development, Test, QA and Production Rules Explained

The SAP System Landscape and Licensing Fundamentals

Most SAP enterprises operate a multi-system landscape to support the full software development lifecycle. A typical architecture includes:

• Production (PRD): The live system where business transactions run daily. This is where the organisation processes real business data and generates revenue.
• Quality Assurance (QAS): A system used for final testing before production deployments. QAS typically contains production-representative data and is used by business and technical testers.
• Development (DEV): Where developers build and test new functionality. DEV may contain sanitised production data or test data, depending on development practices.
• Training (TRN): Dedicated environment for end-user onboarding and skills refreshment. Often contains a subset of production data and processes.
• Sandbox (SBX): Innovation and proof-of-concept environments, sometimes with exploratory user populations.
• Disaster Recovery (DR): Business continuity systems that mirror production and stand ready for failover in case of production outages.

The fundamental SAP licensing principle is this: SAP licences are primarily tied to named user consumption in production environments. However, the use of system copies introduces compliance complexity because non-production systems are not exempt from licensing requirements — they are governed by a different set of rules.

The critical question most enterprises get wrong is this: "Are non-production users licensed?" The answer is nuanced. Non-production users may not require a separate production licence, but only if specific contractual conditions are met and actual system use remains within defined boundaries. Many organisations violate these boundaries without realising it.

What SAP Contracts Actually Say About System Copies

SAP licence agreements contain explicit provisions governing the use of system copies. These are typically found in clauses titled "Use Restrictions" or "Permitted Use" sections. Here is what the standard position looks like:

• Non-production systems (DEV, QAS, TRN) may be used for development, testing, and training related to the licensed production software.
• Non-production systems must not be used for productive processing — that is, processing that generates business value, creates operational reports for business decision-making, or processes real customer or transactional data on an ongoing basis.
• Named users in non-production systems do not automatically require separate named-user licences, provided they are only performing development, testing, or training work.

The critical distinction SAP makes is between testing activity and productive activity. A user running a report in QAS to validate a feature behaves differently than a user running a daily operational report to support business decisions. The former is testing; the latter is productive use.

Most SAP ELAs (Enterprise Licence Agreements), ELLAs (Enterprise Licence Lease Agreements), and UELAs (Unlimited Licence Agreements) contain language limiting non-production system use to "development, testing and training in direct support of the licensed software." This carve-out is the foundation of non-production licensing, but it is narrower than many organisations believe.

Development Systems (DEV) — Rules and Risks

Development environments are generally the least risky non-production system from an audit perspective, but risks emerge when development practices blur the lines between development and production use.

Permitted Use

Standard SAP contracts allow unlimited named users in DEV systems for genuine development purposes. There is no contractual restriction on headcount in DEV — developers can log in without triggering separate licence obligations. This is by design: development requires rapid experimentation, prototyping, and iteration.

However, the licence benefit only applies when developers are actually developing. The moment a developer uses DEV to generate a business report, extract operational metrics, or run queries to support business decisions, that work slides into productive use territory.

Real-World DEV Risks

SAP auditors specifically watch for three scenarios in DEV systems:

1. Consultant and contractor usage: Consulting firms and contractors often have access to both DEV and production systems. If the same individual performs production support work (fixing bugs, optimising performance) from the same SAP login, auditors may argue that work is production-related, not development-related. This creates a blended-use risk.
2. Embedded analytics and reporting: Larger development teams often run HANA queries, generate analytics reports, and pull business intelligence from DEV to understand data flows. If these reports are presented to business stakeholders to inform decisions, they qualify as productive use.
3. UAT seepage: Development systems sometimes host user acceptance testing (UAT) as a precursor to QAS formal testing. When business users from operations join DEV UAT, their usage transitions from development to quasi-production, potentially triggering licensing obligations.

How Auditors Count DEV Users

SAP auditors typically use USMM (User and System Measurement) data to identify all users with login activity in DEV, regardless of login frequency or duration. A consultant who logged in once for fifteen minutes appears in auditor reports the same way as a full-time developer. Most enterprises are shocked by the total headcount auditors discover across DEV when USMM is pulled, especially when external consultants and temporary contractors are included.

Auditors then cross-reference these DEV users against production named user lists. If DEV user headcount significantly exceeds production headcount — particularly if external consultants are included — auditors may question whether all development activity is genuine or whether some users are performing production support masked as development work.

Quality Assurance / Test Systems (QAS) — The Highest Risk

QA and test systems represent the highest audit risk in most SAP landscapes. This is where system copy licensing most commonly fails — and where organisations take the biggest financial hits during audits.

Why QAS is High Risk

QAS systems are problematic because they occupy a grey zone between testing and production:

• QAS typically contains full production data sets (or nearly full). This realism is essential for meaningful testing, but it also creates appearance of productive use.
• QAS hosts user acceptance testing (UAT), which by definition involves business users — not just testers — evaluating system changes. Business users performing UAT are operating in a quasi-production capacity, even though they are technically testing.
• QAS is used for extended parallel running during go-lives. During a major system migration or new release deployment, QAS may run in parallel with production for weeks or months. This extended operational period looks and feels like productive use.
• QAS users often have overlapping production roles. A business process owner testing a new feature in QAS is the same person who will own that process in production. SAP auditors argue that such users must be counted as production users because they are performing job functions that directly support operational decisions.

SAP's Position on QAS

SAP's standard licensing position on QAS is restrictive: named users performing work that supports business decisions must be counted as production named users, even if the work is technically happening in a QAS system. This includes:

• Business users running reports and analytics in QAS that feed into business decisions
• Process owners validating workflow logic and confirming process changes work correctly
• Finance managers testing period close processes before deploying to production
• Supply chain planners validating demand planning or procurement workflows in QAS

The distinction SAP draws is between testing activity (executing test scripts to validate specific features) and business-decision-support activity (using the system to extract information or make business calls). Once QAS users cross into the latter category, licensing treatment changes.

The Parallel Running Trap

One of the most costly QAS traps is extended parallel running. When organisations migrate to a new SAP version or deploy a major system update, the cutover process often involves running both the old version (in production) and the new version (in QAS) in parallel for a period of time — sometimes weeks, occasionally months. During this window, QAS is performing genuine production work: processing transactions, handling customer orders, generating invoices.

SAP's licence interpretation is clear: while parallel running is active, QAS transitions from a testing system to a production system. All users active in QAS during this period are performing productive work and require production licences. Many organisations have been significantly penalised for failing to license all parallel-running users.

Training Systems — User Licence Requirements

Training systems are one of the few areas where organisations consistently hold false beliefs about licensing. The common myth: "Training users don't require licences because they are not doing real work."

This is incorrect. SAP's standard licensing position is clear: training systems require the same user licences as production systems unless explicitly negotiated otherwise.

SAP's Default Position

SAP's licence agreements typically state that training systems require named-user licences for all users accessing the system. The logic is straightforward: a training user logging in to SAP and using the system is consuming the licensed software, regardless of whether the work is for training versus production purposes.

Many organisations are shocked when SAP auditors request lists of all users trained in SAP systems — auditors use this to validate that training user populations are properly licensed. If an organisation reports training 500 employees in the past year but only licensed 200 named users, SAP will argue that 300 training users were unlicensed.

What to Negotiate

The good news: training system licensing is heavily negotiable, especially in larger deals. When negotiating ELAs or contract renewals, push for:

• Training system carve-outs: Explicit language that training systems (distinctly identified by system ID) do not require separate user licences beyond the production user base.
• Temporary access permits: Permission for training systems to host user populations equal to 1-2x the production named-user count, with automatic de-licensing of training users after the training period ends.
• Periodic training allowances: Rights to conduct annual, quarterly or monthly training sessions with larger populations (e.g., 20% additional users) for defined training periods without additional licences.
• Definition clarity: Explicit definition of what qualifies as "training" versus "productive use" to prevent auditor disputes later.

Many enterprise licence agreements do include training system allowances. If your organisation doesn't have this protection, it's a critical gap worth addressing in your next renewal or negotiation.

Disaster Recovery Systems — The DR Licence Trap

Disaster recovery systems represent one of the largest hidden audit exposures in most SAP landscapes. This is where well-intentioned business continuity planning collides with SAP licensing rules.

The Core Problem

Most organisations implement DR systems as exact replicas of production SAP systems. Every table, every user, every transaction type is mirrored. When a production outage occurs, the organisation fails over to DR and runs business operations from the DR system until production is restored.

SAP's licensing position is that if a DR system is activated and used for productive work — even for a brief period during a genuine disaster — it requires equivalent production licences for the duration of that use.

Many organisations are unaware of this rule. They build DR systems with no additional licence allocation, assuming disaster recovery is covered under the production licence. When a genuine production outage forces a DR failover, the organisation discovers it is technically running out of compliance — every user processing business transactions in DR without a corresponding DR licence is an unlicensed user.

Active-Passive vs. Active-Active

Two common DR architectures have different licence implications:

• Active-Passive DR: Production runs on the primary system; DR is idle until activated. When production fails, users are switched to DR. From a licensing perspective, passive DR systems used only for disaster recovery (not ongoing testing or reporting) typically do not require separate licences — because the system is not actively used. However, if your organisation regularly accesses passive DR for testing, monitoring, or validation, those access activities may trigger licensing obligations.
• Active-Active DR: Both production and DR are running simultaneously, with workload distributed between them or with DR regularly tested with production-like load. Active-active DR configurations typically require separate DR system licences because both systems are in active productive use. Some organisations negotiate "burst" DR licences that activate only during actual failover events.

What to Negotiate

DR licensing deserves explicit contractual attention. When negotiating your SAP agreement, push for:

• Disaster recovery failover rights: Explicit language permitting activation of a standby DR system without additional user licences during a genuine production outage (typically defined as unplanned outage, not for testing or planned upgrades).
• Failover duration limits: Clear time limits (e.g., 30 days, 90 days) for how long DR can be used productively before separate DR licences are required.
• Periodic testing carve-out: Permission to conduct DR testing (bringing up the DR system to test failover and recovery procedures) without triggering immediate licence requirements, provided the test period is limited (e.g., 24-48 hours per test, maximum 4 tests per year).
• Burst licensing: Option to acquire temporary "burst" DR licences (for a small premium) that activate only when DR is failover-activated.

Without these protections, your organisation has undisclosed DR licensing exposure.

Sandbox Systems — The Forgotten Exposure

Sandbox environments — systems used for innovation, proof-of-concept testing, architectural exploration, and new module evaluation — are often created outside formal IT governance structures. This lack of oversight creates substantial audit risk.

Why Sandbox Systems Fly Under the Radar

Sandbox systems are typically:

• Created by development or innovation teams without explicit approval from SAP licence management
• Used by developer populations, consultants, and business process owners exploring new functionality
• Sometimes forgotten after POC projects conclude, remaining in the system landscape but dormant
• Not always tracked in central SAP system inventory, making them "invisible" to enterprise licence audits until SAP's discovery process surfaces them

The Audit Exposure

When SAP auditors conduct a full system landscape audit, they typically request USMM data from all SAP systems in the environment. If sandbox systems are included in this request, auditors will identify:

• All users with login activity in sandbox systems
• The nature of work performed in those systems
• Whether sandbox users are licensed (named users or unlicensed)
• Whether sandbox systems contain production data

If a sandbox system has a large user population (e.g., 50+ users exploring a new module) and those users are not separately licensed, auditors will argue that the sandbox system represents unlicensed software consumption.

The Grey Area

Sandbox systems exist in a licensing grey area. They are not production systems, so standard production licensing may not apply. But they are not universally recognized non-production systems like DEV or QAS, so standard non-production carve-outs may not apply either. The safest assumption: sandbox system users require named-user licences unless explicitly carved out in your SAP agreement.

How SAP Auditors Measure Non-Production Systems

Understanding auditor methodology is essential for preparing before an audit and defending during one.

USMM and LAW Data

SAP auditors use two primary measurement tools:

• USMM (User and System Measurement): A transaction that runs within SAP to capture user login and usage data. USMM data shows every user who logged in to a given SAP system, when they logged in, and how long they spent in the system. Auditors typically request 12-24 months of USMM history from all SAP systems in the landscape.
• LAW (Licence Administration Workbench): An on-system tool that aggregates user data across multiple SAP instances. LAW consolidation can show auditors which users appear in multiple systems (production and non-production) and how their usage patterns vary across systems. LAW data is forensically powerful because it reveals hidden user overlaps and usage anomalies.

Read our USMM measurement guide and LAW (Licence Administration Workbench) for deeper technical understanding of these measurement tools.

Specific Red Flags Auditors Look For

Auditors specifically flag these scenarios across non-production systems:

• Production data in non-production systems: Auditors check whether QAS and DEV contain current production data. If they do, auditors question whether the system is being used productively.
• Business user populations in QAS/DEV: If USMM shows operations team members, finance users, or supply chain staff logging in to QAS regularly, auditors treat this as evidence of productive use.
• DR system activation records: Auditors check system logs to see whether DR systems have been activated. Any activation history triggers questions about licensing during the activation period.
• User overlap anomalies: If the same user appears with high login frequency in both production and QAS, auditors may argue that the user is performing production work from QAS and should be counted as a production user.
• Report execution patterns: LAW and USMM can show not just login data but also report execution. If business users are running daily operational reports from QAS, this is auditor evidence of productive use.

Contractual Protections and What to Negotiate

The most effective defence against system copy licensing disputes is a well-drafted contract with explicit non-production use rights.

Key Contractual Elements

Your SAP licence agreement should include:

• Explicit system list: Appendix clearly identifying each non-production system (DEV, QAS, TRN, DR, SBX) by system ID, with a statement that these systems are licensed for non-production use only.
• Permitted use definitions: Clear definition of what qualifies as "development," "testing," and "training" to eliminate auditor interpretation disputes. For example: "Development use means writing, compiling, and testing code. Testing use means executing test scripts to validate system functionality. Training use means hands-on instruction of end users in system navigation and business processes."
• Data restrictions: Language specifying whether production data may be copied to non-production systems and under what conditions. For example: "Production data may be copied to QAS quarterly for testing purposes, provided all personally identifiable information is masked."
• User population limits: For QAS and training systems especially, explicit headcount limits. For example: "QAS may host up to 150 named users. Training systems may host up to 200 named users."
• Disaster recovery provisions: Clear language on DR failover rights, failover duration, and when DR licences are required.
• Parallel running carve-out: If your organisation does periodic major upgrades with parallel running, negotiate explicit language permitting QAS parallel running for a defined period (e.g., 30 days) without additional licensing.

ELA vs. ELLA vs. UELA

SAP offers three primary licence agreement types, and non-production licensing varies significantly across them:

• ELA (Enterprise Licence Agreement): The most flexible agreement type for large enterprises. ELAs typically include the most favorable non-production provisions, including explicit carve-outs for development, testing, and training systems. If you have scale (e.g., 500+ named users), negotiate for an ELA, which offers better non-production protection than other types.
• ELLA (Enterprise Licence Lease Agreement): A lease-based alternative to ELA ownership. ELLA non-production provisions vary significantly based on negotiation; some are quite restrictive.
• UELA (Unlimited Licence Agreement): A simpler, transactional agreement often used for smaller deployments. UELAs typically offer minimal non-production carve-outs and are the most restrictive for system copy use.

If you are operating under a UELA and your organisation has significant non-production system complexity, upgrading to an ELA may be cost-justified purely for the improved non-production licensing protection.

How to Prepare Your Landscape Before an Audit

Proactive preparation is more cost-effective than reactive dispute defence during an audit.

System Inventory and Documentation

Conduct a complete system landscape audit before SAP does:

1. Create a master inventory of all SAP systems in your environment, including system IDs, system types (PRD, QAS, DEV, etc.), and the business purpose of each.
2. For each non-production system, document the permitted use and user population guidelines as defined in your SAP agreement.
3. Identify any systems that are not listed in your SAP licence agreement (especially sandbox systems) — these are hidden exposure and must be addressed.

User Population Analysis

Before an audit, pull USMM data from all systems and analyse user populations:

1. For QAS, compare user count to production. If QAS users significantly exceed PRD, prepare an explanation.
2. For DEV, identify any users who also appear in production — prepare to explain whether these are blended-role consultants or whether development work is genuinely separate from production work.
3. For training systems, tally total unique training users across a 12-month period and ensure this population is properly licensed or covered by training system carve-outs.
4. For DR, document the last activation date and duration. If DR has been activated within the audit period, ensure licensing was appropriate during the activation.

Documentation and Governance

Create clear documentation for your audit file:

• System use policies defining what work is permitted in each system type
• User access policies explaining how users are assigned to systems
• Data management policies describing how production data is handled in non-production systems
• Training programme documentation showing who was trained, when, and in which system

SAP auditors will request these documents. Having them prepared and organised reduces both audit duration and auditor scepticism.