Dieter SteigerDieter Steiger SAP Change and Transport Management – Efficient and Safe

06/12/2008 by Dieter Steiger

In order to handle the various problems resulting from changes to a SAP landscape, it is common use to spend of lot of money on experts rushing to fix them. But there is a better alternative: Focussing on a tool-supported, automated SAP change and transport management environment, including measures to ensure consistency, can eliminate the cause of the failures once and for all. There is a couple of measures to be taken: organizational measures, technical transport validation, and consistency-ensuring measures with horizontal and vertical effects.

Basic Organizational Measures

  • Definition, digitalization of the end-to-end transport process or of the whole change process
    • ensuring that no transport request (technical change) is issued without change request (organizational change)
    • diversification of the transport types so that for projects and releases the suitable transport can be selected
  • Replacing manual execution by automatic technical implementations
    • no inconsistencies due to missing and/or incorrect interactions
    • release processes are validated, executed and documented
    • tedious routine tasks are automated
  • Also operational customizing must be subject to a controlled change management process.
  • Creating development guidelines and naming conventions to support change and transport management
    • changes can be checked for consistency with respect to form and – in parts – content
  • Definition of a company template – particularly useful if there are more than one development client

Validation of Transports

  • Early detection and exclusion of risky objects from transport, e.g. NRIV objects (SAP number ranges)
  • Formal validation of the transport objects with regard to project/support release and organizational unit they belong to
    • ensuring that a transport request contains only related changes or changes for specific areas so that parallel project activities are not compromised
    • code inspection based on system engineering, validation of the transport object´s affiliation
    • ensuring that the development guidelines are followed and verifying – on the basis of naming conventions – that the code is related to one single business area
  • Verifying, for example by running test imports, if all referenced objects which are not yet on the target system are transported
  • Object-related customizing documentation such as owner, change, changed keys, including customizing versioning
    • complete documentation, complete history (comprehensive life cycle of the customizing settings), traceability and audit trail

General Consistency Measures

  • Content-related division of transport requests of multiple projects or maintenance requests
    • consistent, project-oriented deployment; interdependencies of objects are understood, taken into account and controlled
    • autonomy of projects in terms of change transport
  • Opening and closing of the systems and clients should – whenever possible – be subject to an automated change process
    • system-based monitoring of the change; it can be tracked at any time, when system changes were possible.

Horizontal Consistency-Ensuring Measures

  • Ensuring the correct sequence when transporting customizing changes, workbench transport objects (programs and data structures), considering dependencies between workbench and customizing objects with regard to overtaking issues.
    • No inconsistencies on target systems resulting from early arrival of objects (overtaker issues)
  • Rollback functionalities and automated updating of systems and clients based on transport history (system or client copy) when systems are re-initialized, added or when changes need to be reset.
    • Full transparency as to which transport orders apply to which system or client level. Executed transport orders can be undone at any time when unexpected problem show up or tests are not successful.

Vertical Consistency-Ensuring Measures

  • Ensuring the correct installation order of all changes (transport requests from all SAP component systems such as SAP CRM, ERP, BW for ABAP and customizing, Java packages, portal configurations) before they are further processed on the target system. This includes all changes that have to be installed together, not by themselves via different SAP Transport Systems (SAP TMS).
    • all changes belonging to a group are completely installed before the next organizational step is released
  • Synchronizing and locking of company template customizing
    • no inconsistent company templates in target system landscapes
    • vertical distribution of these settings to all SAP component systems
  • Horizontale und vertikale Konsistenzsicherung


Many big SAP organizations still practice a reactive method of solving the problems resulting from change transport. The enormous costs seem to be accepted as inherent to the process. But we have seen that applying a clean automated process including consistency-ensuring measures can save a lot of money and puts aside large parts of the work involved.

Interestingly, not the unnecessary and incalculable costs and effort motivate more and more enterprises to improve their SAP change and transport management, but the requirements which result from compliance rules and which, SAP IT, too, is faced with. Thanks to the transparency and traceability of the processes and to comprehensive documentation, SAP change and transport management, if stringently applied and supported by suitable tools, will supply these needs on the fly.

Sphere: Related Content

No TweetBacks yet. (Be the first to Tweet this post)

6 Responses

  • 1
    Lifecycle Management – a Nightmare? /// beteo:

    […] in the development of different ERP systems. He has been involved in a variety of release changes, system roll-outs and consolidations and – thanks to his good constitution – has survived, more or less free of […]

  • 2
    Isaie Manimpire:

    How can we rollback the transports which are allready done from SAP BW development environment to SAP BW production environment?

  • 3
    Dieter Steiger:

    Isaie: for already done transports it depends on your own procedure for SAP (or non SAP) transports whether you can rollback (including BW changes) or not. Just launching transports using SAP transport management system does not automatically allow such rollbacks.

    Today, what transport types do you distinguish and how do you organize deployment for them? Rollback scenarios need to be setup for different transport types. E.g. it makes sense to implement a procedure to properly reactivate the previous version for workbench objects.

    This is the reason for companies to implement tool supported SAP transport management procedures as described in this blog that allow consistent and safe rollouts and rollbacks for all transports. How sophisticated such a transport management environment is depends a lot on the complexity your SAP landscape and SAP system and on the frequency and complexity of your transports.

  • 4
    Integrating HP PPM with HP Quality Center – As Simple as It Looks? /// beteo:

    […] often, the processes of change & transport and quality management in the IT organzation are technically not very tightly integrated. Although […]

  • 5
    Transport Management - SAP CTS+ will hardly straighten it out /// beteo:

    […] my article on SAP Change and Transport Management, I discuss the topic of “measures that ensure horizontal and vertical consistency.” After […]

  • 6
    Isaïe Manimpire:


    Today, I transport in BW environment all objects following this order: infoobjects, catalogues, datasources, DSO, infocubes, transformations, multiproviders, infosets, requests, abap programs and process chains.

    If any problem appears after transport into target system, I don’t know how to rollback. Could you, please, give me detailed suggestions to follow in order to be able to roll back? Thanks.