Site-Specific Deployment of Changes
You can assign an existing transport request to several change documents to support the site-specific deployment of changes. The overall advantage of this concept is that you can minimize your risks by going live in one region first before deploying the changes in another region. Also it improves traceability as the original change document maps the go-live in the initial region while the second change document is created for documenting the go-live in the subsequent region.
For example, a system landscape consists of one development system (A1D) and two transport tracks for different geographical regions, ending in production systems with different go-live dates (A1P, AXP). The initial change document manages the software distribution to the leading production system (for example, A1P). To distribute the change to both production systems, that is, to both sites, the same transport request needs to be assigned to different change documents.
Site-Specific Deployment of Changes
Prerequisites
Your change cycles are enabled for the central change and transport system (central CTS).
Features
You can assign one transport request to several changes. Those changes need to be assigned to different change cycles whose landscape does not share the same production system.
To do so, in the WebClient UI, manually assign the released transport request to an additional change of the second change cycle. The same transport request is now managed by different changes within different change cycles, and so the transport to different production systems at different points in time can be tracked separately.