SAP landscape

The standard arrangement is DEV → QAS → PRD: a Development system where configuration and code are built, a Quality Assurance system where they are tested, and a Production system that runs the real business. Changes flow in one direction through the Transport Management System, so nothing reaches production without passing through test.

Each SAP system is divided into clients, self-contained tenants with their own master and transaction data. A typical DEV system has a customizing client, a sandbox client and sometimes a golden configuration client. Understanding the client concept is essential to avoid changing the wrong data.

The distinction that causes the most confusion: some things are client dependent and some are not, and knowing which explains behaviour that otherwise looks random.

Client dependent means separate per client. Master data, transactional data, users and their roles, and most configuration. Creating a material in client 100 does not create it in 200.

Client independent means shared by every client in the system. The repository, so programs, tables, classes and CDS views. Also some configuration, notably anything defining the system itself rather than a business arrangement.

Two consequences follow. Importing a workbench transport affects every client at once, which is why a program change cannot be tested in one client and withheld from another. And a developer changing a table structure in a development client changes it in every client of that system, immediately.

The practical shape in development is usually two clients: a customising client where configuration is made and recorded on transports, and a unit test client with data, used to try the result. The configuration reaches the test client by transport rather than by being made twice.

Real landscapes include more: a sandbox for experimentation, a pre-production system that mirrors PRD, and separate landscapes for connected products (BW, PI/PO, Solution Manager). Each must be sized, secured and kept in sync.

Each of those extra systems exists for a specific reason worth naming. A sandbox is disposable, outside the transport path, so somebody can try a thing without consequence. A training system is refreshed before each course so trainees always start from the same state. A pre-production system is a recent copy of production used to rehearse a cutover or test a fix against realistic data. And in a landscape with several products, each has its own three systems, connected by interfaces that must also be pointed at the right tier, which is where refreshes go wrong.

Half an hour on your first day, and it tells you more than the architecture diagram.

1. Run System, then Status in each system you have access to. Note the system ID, the release and the components.
2. Check SCC4 for the client settings: which clients exist, which allow changes, and which are marked as production. A development client that is closed to changes explains a lot.
3. Open STMS and read the transport route. It shows which system sends to which, and whether the path is what people describe.
4. Look at SM59 for RFC destinations and check what the quality system points at. A destination in QAS pointing at a production partner is a refresh that was not finished.
5. Ask when quality assurance was last refreshed from production. If the answer is a year ago, the testing everyone relies on is against stale data.

Step four is the one that finds real problems, and it takes two minutes.

The landscape is the safety mechanism of SAP change management. It lets teams build boldly in DEV, prove changes in QAS, and protect PRD, while transports give a controlled, auditable path for every change.

It is also the reason a change can be reversed. A configuration made in development, transported and found wrong can be corrected and transported again, and every system's state is explained by the requests it has received. A change made directly in production has no such record, which is why the cardinal rule is a rule rather than a preference. See the landscape architecture for the technical layout.

A quality assurance system is only useful if its data resembles production, and keeping it that way is routine work with a routine set of mistakes.

A system copy or a client copy takes production down to the target. Then comes the part that matters: post-copy activities.

Repoint every interface. RFC destinations, file paths, web service endpoints. A refreshed system still holding production's destinations will talk to production's partners, and that is the incident everybody hears about.

Reschedule or delete background jobs. Copied jobs will run, and a payment run in a test system that reaches a real bank interface is the worst version of this.

Reset users and passwords. Production users now exist in a system with weaker controls.

Scramble sensitive data, or decide explicitly not to. Salaries and customer records in a system where more people have access is a data protection question with a legal answer.

Clear output. Spool requests and pending output can fire real documents at real customers.

The list exists because every item on it has gone wrong somewhere. Automating it, so a refresh is a script rather than a memory exercise, is what makes refreshes frequent enough to be useful.

• Three systems or more. Three is the minimum that separates building, testing and running. A fourth for pre-production is worth it where cutovers are frequent or where a realistic rehearsal environment is needed.
• How many clients in development. A customising client plus a unit test client is the common pattern. More clients means more copies to keep in step.
• Refresh frequency. Quarterly keeps testing realistic and consumes effort each time. Annually is cheaper and means testing drifts from reality.
• Whether production allows any change. The answer should be no, and the exception process for emergencies has to exist before it is needed rather than being improvised.

• Making changes directly in production, the cardinal sin of SAP operations.
• Confusing systems and clients, they are different layers of isolation.
• Letting DEV/QAS/PRD drift out of sync, tests then do not reflect reality.

• A quality system never refreshed. Testing against data from two years ago proves the code runs, not that it works.
• Interfaces left pointing at production after a refresh. The test system then sends real messages to real partners.
• Development client open to configuration but not recording transports. Changes are made and never travel. See what SAP is and the beginner guide if the vocabulary here is new, and the benefits page for why the discipline is worth its cost.

• A sandbox connected to the transport path. It exists so people can try things without consequence, and a route out of it removes that.
• Client roles set wrongly. A production client marked as a test client permits changes it should refuse.

Recognising a landscape is straightforward, and designing the client strategy and transport route so changes reach production safely is the part you do in the course.

The check worth running on any landscape you join is the transport route in STMS against what people describe. The diagram on the wall and the configured path are not always the same thing, and the configured one is what actually happens.