# SAP Transport Request Checklist: From Development to Production Import > Source: https://netray.co/tools/sap-transport-request-checklist > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer A step-by-step checklist for creating, releasing and importing SAP transport requests through STMS, with the critical controls flagged. ## Category sap ## Erp SAP ECC and S/4HANA ## Audience - SAP Basis administrator - SAP developer - Change manager ## Tool **Kind:** checklist **Groups:** #### Request creation and scope **Items:** Choose the correct request type in SE09 or SE10: Workbench for repository objects, Customizing for client-specific settings. **Text:** Give the request a description that starts with the change ticket number so it can be traced from the import log. **Critical:** true Confirm each object sits in the right package and transport layer (SE80 or SE21) so it routes to the intended target system. Check that the Customizing client records changes automatically (SCC4) and that the work is saved in the intended client. Search for the same objects in other open requests (SE03, Search for Objects in Requests) to avoid lock conflicts and overwrites. Keep one request per logical change; do not use one long-lived request as a dumping ground. #### Pre-release technical checks **Items:** **Text:** Confirm no inactive objects remain in the request; activate everything before release. **Critical:** true Run the extended syntax check and the ABAP Test Cockpit (ATC) or Code Inspector checks against the agreed variant. Run available ABAP unit tests and confirm the result is clean. Verify that dependent objects travel together or were already imported: DDIC objects, message classes, text elements, authorization objects. **Text:** Check the import order against earlier requests that this change builds on. **Critical:** true Get a peer or lead review of the objects before release. #### Release and export **Items:** **Text:** Release every task in the request first, then release the request itself (SE09, Release Directly or the release button). **Critical:** true **Text:** Read the export log and confirm the return code. Code 0 is success, 4 is a warning to read, 8 or higher is an error to fix. **Critical:** true Record the request number, owner, objects and release time in the change ticket. Do not modify released objects in an emergency without a new request and a recorded reason. Confirm the request reached the import buffer of the next system in the route (STMS import overview). #### Import into QA **Items:** Confirm the transport route and target client in STMS (Transport Routes) before importing anything. Import requests in the order they were released, not in the order that is convenient. Avoid the option to leave requests in the queue for later import unless you have a documented reason. Check the import log for the return code and for activation, table conversion or generation errors. Execute the regression and change-specific test cases in the QA client. **Text:** Capture tester and business sign-off against the request number. **Critical:** true #### Production import **Items:** **Text:** Obtain change advisory approval and a confirmed import window. **Critical:** true **Text:** Confirm the exact request tested in QA is the one being imported, with no later changes. **Critical:** true **Text:** Document the rollback plan, including the previous object versions available in version management. **Critical:** true Import through STMS with the production target client specified, in the approved order. Check the import return code and review runtime errors (ST22) and system log (SM21) straight after. Run a short smoke test of the affected business process and tell the business owner the result. Archive the import log with the change ticket. #### Governance and housekeeping **Items:** **Text:** Keep production in a non-modifiable state for repository and Customizing objects (SE06 system change option, SCC4 client role). **Critical:** true Separate duties: developers should not hold production import rights (S_CTS_ADMI, S_TRANSPRT). Define a break-glass emergency change procedure with after-the-fact review. Review old or orphaned open requests monthly and release, merge or delete them. **Scoring Note:** Aim for every critical item ticked before a production import. Anything left unticked should be written into the change ticket as an accepted risk. ## Content **Intro:** An SAP transport request moves repository objects or Customizing settings from development through QA to production. Most outages and audit findings trace back to missed steps, not to the transport tool. This checklist gives Basis and change teams one place to confirm each step. **Sections:** #### How to use this checklist **Body:** Work through the groups in order for each change. Tick items as you confirm them, then export the result to PDF or Excel and attach it to the change ticket. The items flagged critical are the ones that most often explain production incidents or audit exceptions, so treat them as gates. Items you do not tick should have a short written reason. The same list works for ECC and S/4HANA, because the Change and Transport System (CTS) behaves the same way for classic transports. Teams that use the enhanced Change and Transport System (CTS+) or Cloud Transport Management can keep the logic and swap the tool names. **Bullets:** - One checklist per change ticket, not per request, if several requests travel together - Attach the export to the ticket as evidence - Review the unticked items in the change advisory meeting #### The method behind the controls **Body:** CTS is built around three ideas: a transport route (development to QA to production) maintained in STMS, a request that bundles objects, and an import buffer in each target system. Controls attach to each. The route decides where a change can land. The request carries a description, owner and object list. The import buffer is where production teams can stop, sequence and approve. Auditors usually test that production cannot be changed directly, that imports are approved, and that developers cannot import their own work. The checklist maps to those three tests plus the technical hygiene that prevents failed imports. **Bullets:** - Return code 0 means success, 4 means warnings, 8 and above means errors - Import order matters when objects depend on each other - Production should be locked against direct repository and Customizing changes #### Reading the result **Body:** If every critical item is ticked, the transport is ready for the next system. If one or two are open, decide whether to defer or document the risk. If several critical items are open, the change is not ready, and importing it will most likely cost more time in recovery than waiting. A useful habit is to track how many imports to production needed a follow-up transport within a week. A high number usually points at weak QA testing or missing dependency checks, not at bad luck. **Bullets:** - Follow-up fixes within days signal missing dependency or test coverage - Return code 4 in QA should be understood before production - Emergency changes need the same record, just faster #### Common mistakes **Body:** The most common mistakes are importing in the wrong order, releasing a parent request before its tasks, leaving a request in the queue and importing it weeks later against changed objects, and forgetting that Customizing requests are client specific. Another frequent finding is a production system left open for changes after a project went live. Finally, teams often skip the rollback plan because transports feel reversible. They are not: there is no undo, only a new request with the earlier version, so the previous version must be identified before the import. **Bullets:** - No rollback exists: you restore by transporting a previous version - Check the target client for Customizing requests - Do not rely on memory for sequence, read the buffer **Cta:** If you want ticket data and transport logs summarized automatically for your change advisory board, Netray can build that over your own SAP and ITSM data, on-prem if needed. **Faq:** #### What does return code 4 mean in an SAP transport import? **Answer:** Return code 0 means the import finished cleanly. Return code 4 means it finished with warnings, for example objects that were generated with a minor issue. You should read the log before moving on. Codes 8 and above signal errors, and 12 or higher usually means the import was aborted. #### Can I undo an SAP transport after importing it into production? **Answer:** No. SAP has no rollback for an import. You recover by creating a new request that contains the previous version of the objects, tested and imported the same way. That is why identifying earlier versions in version management before the import is a critical item in this checklist. #### Should developers be allowed to import into production? **Answer:** Not in most audited environments. Segregating development from production import is a standard control. Authorization objects S_CTS_ADMI and S_TRANSPRT govern transport administration, and the import step is normally given to Basis or release management under an approved change. #### Does this checklist work for S/4HANA and ECC? **Answer:** Yes. Classic transports through SE09, SE10 and STMS work the same way in both. If you use CTS+ or Cloud Transport Management for non-ABAP content, the governance items still apply even though the screens differ. ## Search terms sap transport request checklist, sap transport management checklist, stms import checklist, sap transport release process, sap change management checklist, se09 transport organizer checklist, sap production transport approval, sap transport best practices --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json