SAP Transport Management System (TMS)

Every change to a customizing setting or a development object is recorded in a change request (transport request), created automatically the first time you save an object in a client configured for automatic recording. A transport request contains one or more tasks, one per developer, and must be released (SE09/SE10) before it can be exported from the source system. Requests are typed as either Workbench requests (cross-client repository objects - programs, DDIC objects) or Customizing requests (client-specific configuration), and this distinction determines which target clients a request is relevant for.

The transport route itself is configured in STMS, defining the landscape topology (which systems feed into which) and the consolidation/delivery routes. Once released, a request sits in the import queue of downstream systems and is imported via STMS (or scheduled/automatic import for QAS, but typically manually controlled and scheduled for PRD with strict change windows). Return codes matter here: 0/4 generally mean success (4 = warnings), while 8+ indicates an error worth investigating before assuming the import succeeded.

A mature Basis-level answer also covers the TMS domain controller concept, transport layers for classifying which systems an object transports through, and practical operational habits: never importing directly into production without QAS validation, keeping transport requests logically small and focused (one request per logical change, not one giant request per sprint), and reviewing the import log for objects that returned warnings even when the overall return code looks green.