Insights · SAP Basis
SAP system landscape and client strategy: DEV, QA, production, sandbox
Development, quality assurance, production: this is the classic SAP system landscape, often supplemented by a sandbox, training and a second landscape for projects. The client strategy determines which clients belong in which system. In S/4HANA, each of these decisions comes at a price, because every system needs main memory.
Structure of an SAP system landscape: the three-system landscape
SAP recommends a three-system landscape consisting of a development system (DEV), a quality assurance system (QAS) and a production system (PRD). Each of the three central clients thus gets its own system.
The reason is technical. Repository objects and cross-client Customizing are the same for all clients in a system. A change in one client takes effect immediately in all others. Only if development, testing and production run in separate systems will a change reach production only after it has been tested.
The path is always the same: changes are made in the Customizing client of the development system, go by transport to the QA client and, after a successful test, into production. When people talk about ‘the SAP test system’, they usually mean the QA system. That is where business departments check changes, in many landscapes with data from production.
Smaller installations sometimes manage with two systems. The QA client is then located in the development system. The drawback: cross-client changes in the Customizing client also affect ongoing tests. SAP does not recommend a single-system landscape, because hardly any development is possible after go-live.
Sandbox, training, pre-production and project landscape
Sandbox: SAP describes an optional sandbox client in the development system, in which you try out settings before making them in the Customizing client. For upgrade trials, new functions or migration tests, many companies also run a separate sandbox system. It does not need a route to production.
Training: SAP assigns the training client to the QA system. It needs a stable, defined data set so that every training session runs the same way.
Pre-production: Some landscapes have a further system between QA and production that resembles production as closely as possible. Acceptance, performance and cutover tests run there.
Project landscape: Large projects such as a release change or a rollout often get their own landscape. The existing chain remains responsible for maintenance and support, while the project develops in parallel in its own systems. Corrections from maintenance then also have to reach the project. SAP Solution Manager supports this as Retrofit and refers to N+1 landscapes.
Every additional system means additional transport routes, additional refreshes and additional main memory.
Transport routes with TMS
Transports between the systems are controlled by the Transport Management System (STMS). The systems of a landscape form a transport domain. One of them is the transport domain controller, which holds the configuration centrally. The transport routes define in which system change requests are consolidated and to which systems they are forwarded automatically.
For the three-system landscape, STMS offers a standard configuration. It connects development to QA via a consolidation route and QA to production via a delivery route. Caution in existing landscapes: the standard configuration replaces all previous settings for all systems. If pre-production or a project landscape is added, maintain the additional routes manually and selectively.
The client strategy: which clients go where
The client strategy defines which clients exist in each system, what they are for and what may be changed in them. SAP describes three central clients that exist in every landscape and three optional ones:
| Client | System | Purpose and changes |
|---|---|---|
CUST | Development | Customizing client. Customizing and custom developments are created here; changes are recorded and transported. Cross-client changes are only allowed here. |
TEST | Development | Developer test client. Developers check their changes before release. Customizing and repository are locked. |
SAND | Development | Prototype or sandbox client. Try out settings here before they are made in the Customizing client. Cross-client changes are locked. |
QTST | Quality assurance | QA client. Testing of transported changes before go-live. Customizing only arrives by transport. |
TRNG | Quality assurance | Training client. Users learn new functions with test data. Customizing and repository are locked. |
PROD | Production | Production client. Production operation only: no Customizing, no development, no testing. |
SAP recommends making all Customizing settings in a single Customizing client and transporting them from there. Every additional client in which Customizing is maintained is a source of discrepancies.
Technically, you implement the strategy in SCC4: with the appropriate client role, such as Customizing for CUST, Training/Education for TRNG and Production for PROD, with the change options and with protection against overwriting for the production client. How this works in detail is shown in the article Creating, deleting and configuring an SAP client in SCC4.
What each system costs in S/4HANA
In S/4HANA, the data resides in the main memory of the SAP HANA database. On top of that comes working memory for queries and intermediate results. How much main memory a system needs therefore depends directly on how much data it contains. The sizing report from SAP Note 1872170 provides an estimate for an existing system.
For the landscape, this means that what matters is how each system is populated. A development system with Customizing and a few test cases stays small. By contrast, every system that receives application data from production by system copy or client copy inherits the complete history. It needs almost as much main memory as production.
| System | Typical content | Main memory |
|---|---|---|
| Development | Customizing and specifically created test data | small |
| Quality assurance | often a copy from production | close to production |
| Pre-production, maintenance QA | often a copy from production | close to production |
| Sandbox system | copy of production or Customizing only | small to close to production |
| Training | defined training data or a copy | small to close to production |
| Production | all data | benchmark |
Simplified example. Production holds 3 TB of data in main memory. QA, pre-production and sandbox are full copies. Together, that is around 12 TB, three quarters of it in systems in which nobody works productively. A project landscape adds further copies.
Storage and backups of every system grow along with main memory. And memory has become considerably more expensive since autumn 2025; read more in the article RAM prices and S/4HANA.
Sizing non-production systems by purpose
For every non-production system, the question is: what is tested there, and what data is needed for that? The answer differs from system to system.
- Development and developer tests: Customizing and specifically created test cases. Production data is rarely needed here and, because of personal data, not desirable either.
- QA and regression tests: production-like data. For most tests, the last few months are sufficient, plus open business transactions and master data.
- Maintenance and error analysis: current documents, so that errors from production can be reproduced.
- Training: a defined data set that can be restored before every training session.
- Load and performance tests: Volume is what counts here. A full copy remains the right tool for this, ideally only for the duration of the tests.
In addition, there are levers that work regardless of the copy method: running non-production systems without high availability, keeping systems only for as long as a project needs them, deleting clients that are no longer needed and reducing production itself through archiving. The basis is an inventory: database size and main memory of every system, not just production. How to plan a QA refresh with this goal is shown in the runbook for the QA refresh.
Time slices instead of full copies
The standard client copy has no concept of a time period. Its copy profiles select types of data, not years. Anyone who fills QA with production data therefore gets the entire history, even if a few months would be enough for the tests.
The Data Refresh Operator instead copies a time slice, for example the last 90 days, plus all dependent objects from earlier years, resolved up to the fixpoint. This way, every non-production system can be filled with the time period its purpose requires. DRO itself measures the database sizes of all connected systems in the control system. That is the inventory from the previous section.
- –75%
- HANA RAM in non-production
- –60%
- Storage & backup
Guideline values from reference scenarios. The actual effects depend on system size, history and refresh cycles.
DRO runs on SAP S/4HANA from release 2023 and replaces the client copy, not the system copy. For load and performance tests or a sandbox system created by system copy, the familiar methods remain. How memory in QA, test and sandbox is made up is shown on the page Reducing HANA memory in non-production.
Sources
- SAP Help: System Landscape (SAP NetWeaver 7.3)
- SAP Help: Clients and Their Roles (SAP NetWeaver 7.3)
- SAP Help: Configuring TMS (SAP NetWeaver 7.3)
- SAP Help: Configuring the Development, Quality Assurance, and Production Systems (SAP NetWeaver 7.3)
- SAP KBA 2461322: Where to find information on configuring and using Retrofit? Solution Manager 7.2 (SAP Support Portal, login required)
- SAP Note 1872170: ABAP on HANA sizing report (S/4HANA, Suite on HANA) (SAP Support Portal, login required)