STMS — Transport Management System Configuration and Import Queue
STMS is the transaction that configures the transport domain, maintains transport routes between systems in a landscape, and runs the import queue that brings transport requests into a target system. It does not create or release requests itself; that happens in SE09 or SE10. STMS sits on top of the OS-level tp program and reads the transport buffer, not a simple database table.
This page covers what STMS actually controls versus what it only displays, the real sequence of screens a Basis consultant uses to import or troubleshoot a stuck request, and the recurring categories of import failure with the order in which to check them. It also separates what belongs to Basis from what belongs to the functional or ABAP owner of the request content.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,218 words
What it does
STMS configures the transport domain (which systems belong to the landscape and how they trust each other), maintains the transport routes that decide where a request lands after release, and exposes the import queue used to bring requests into a target system. The one fact that explains most confusion: STMS is a configuration and monitoring front end. It does not build the request, does not list object-level content in a searchable way, and does not itself move data - the OS-level tp program and R3trans do that, reading from a file-based transport directory shared across the landscape. When people say 'the transport is stuck in STMS', the actual problem is almost always at the tp/OS layer, an RFC connection, or a route definition, not inside the transaction itself.
When it is used
Basis reaches for STMS when setting up a new system landscape, adding a system to an existing domain, defining or correcting transport routes (single-system, three-system, or dual-landscape setups), and during routine import windows to move released requests from DEV through QA into PRD. Functional and ABAP consultants normally live in SE09 or SE10 to release requests and check their status, and only open STMS when a request appears stuck in a queue, an import fails with a return code, or they need to confirm which target system a request is actually routed to. It is also the tool used right after a system copy or client refresh to re-point routes and RFC destinations that a copy silently breaks.
How to use it
- Call STMS, then Overview > Systems, to confirm the domain configuration and that the RFC connections to other systems in the landscape are working.
- Go to Overview > Transport Routes to review the consolidation and delivery route setup; this is usually maintained once, at the domain controller, and only touched again when the landscape changes.
- From the initial screen, open Import Overview to see every system's queue at once, or double-click a specific system to open just its Import Queue.
- Select the request(s) to bring in and choose Request > Import; specify the target client and only add options like unconditional mode when the failure is understood, not as a default reflex.
- After execution, open the import log for that request and read the return code and detail lines before deciding the import succeeded.
Key fields
- E070 - header data for each transport request and task, including owner, type, target system, and release status.
- E071 - the object list attached to a request, showing which objects and keys were captured.
- E07T - short description text stored against each request.
- The transport buffer (data and cofiles in the OS-level transport directory) - not a database table, this is what the Import Queue screen in STMS actually reads to show what is waiting for each target system.
How to prove it in the data
To confirm a request's real status independent of the STMS display, check E070 by TRKORR: TRSTATUS shows R for released and blank or D for still modifiable, and the target system field shows where it was released to. Cross-check E071 for the same TRKORR to see what objects are actually inside it before assuming a queue problem is object-related. If the request shows released in E070 but never appears in the target system's queue, the fault is in routing or the transport buffer transfer, not in the request itself, and the fix belongs at the OS/RFC layer, not inside STMS.
ECC vs S/4HANA
STMS is unchanged in structure and purpose on S/4HANA; the transport domain, routes, and import queue work the same way. Some landscapes add extra validation for extensibility and custom code objects moving through the same transport path, but the checks run alongside the standard tp/R3trans mechanism rather than replacing it. There is no dedicated Fiori app that replaces STMS for transport administration; it remains a SAP GUI transaction.
Common pitfalls
- Request stuck in the queue - check the RFC connection from the domain controller to the target system first, then confirm the tp interface can reach the OS-level transport directory with the right authorizations, then look for a locked queue icon caused by a prior failed import that must be finished or reset before anything else can proceed.
- Non-zero return code on import - open the detailed import log rather than reacting to the summary code alone; codes commonly trace back to a locked object in the target system, a missing predecessor request that has not yet been imported, or a table conversion that the import step could not complete automatically.
- RFC connection failures inside the domain - typically appear right after a system copy or refresh where the copied system still carries the source system's logical system name or connection details; test the connection directly rather than assuming the domain configuration itself is broken.
- Misconfigured or stale transport routes - a request lands in the wrong queue, or in no queue at all, most often after a new system was added to the landscape but the routes were never updated to include it.
- Client-level import errors - the target client is not open for the required change type, producing an error that looks like a queue problem but is actually a client settings issue in the target system.
- tp/kernel version mismatch - after a kernel upgrade, tp reports a version incompatibility on import; this is a Basis patching issue, not something fixable from inside STMS.
- The reflex that makes it worse - forcing an import through with unconditional mode to clear a red status without understanding the underlying return code; this can leave the target system in an inconsistent state that only surfaces later as a runtime error unrelated to the original transport.
Whose problem this is
STMS configuration, RFC connections, and queue-level troubleshooting belong to Basis. The content of a request - which objects it contains and whether they are correct - belongs to the functional or ABAP consultant who created it. A good handover states the request number, target system, the exact return code and log text, and whether the failure happens before the queue (routing/RFC) or during the import itself (object/client level).
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/stmsERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.