How to migrate an SAP Cloud Transport Management instance

How to migrate an SAP Cloud Transport Management instance
Estimated read time 12 min read

In this blog post I would like to explain what it takes to migrate an SAP Cloud Transport Management Service (cTMS) instance. 

 

Motivation

There are several scenarios in which you would like to migrate a Cloud Transport Management instance:

Move the complete cTMS instance to another subaccount. 
This could be relevant if you decide for a different setup of your subaccount landscape, for example establishing a separate administrative subaccount into which you would like to move your cTMS instance. A specific use case is switching from a cTMS instance integrated into the SAP Cloud ALM subaccount to a ‘normal’ stand-alone cTMS instance (see the blog post by my colleague Moritz: https://community.sap.com/t5/technology-blogs-by-sap/new-integration-of-sap-cloud-transport-management-and-sap-cloud-alm/ba-p/13728049).  Separate parts of your cTMS transport landscape into two (or more) cTMS instances.
Currently all users with roles in cTMS can see all transport nodes and routes, although they might not be able to perform activities in these nodes (due to their assigned roles). Therefore customers with large landscape might prefer to separate parts of their transport landscapes into separate cTMS instances. As long as the involved subaccounts are in the same global account, this has no implications on the cost of cTMS (uploaded data volumes are aggregated on global account level).Merge separate cTMS instances.
This is only possible if the names of transport nodes and routes are unique in both instances.Move transport landscape from a cTMS instance running on a trial subaccount.
While it is possible to switch from a free to a standard plan of cTMS and keep your transport landscape, this does not work for trial subaccounts. Here the only option is to migrate the landscape to a ‘real’ subaccount.

 

Procedure

Currently the migration procedure involves several manual steps which can lead to a significant effort for migrating large transport landscapes.

Create target instance of cTMS
Follow the standard procedure for setting up Cloud Transport Management including the subscription to cTMS a service instance with service key. This is described here: https://help.sap.com/docs/cloud-transport-management/sap-cloud-transport-management/set-up-environment-to-transport-content-archives-directly-in-application
 Export transport landscape from source instance
This done from within the ‘Landscape Visualization’ pane:

You receive a .zip file that contains three files: the landscape data itself, metadata information of the cTMS source instance (both in json format) and a signature. The signature which is checked at import ensures that the content of the zip file cannot easily be changed. 
See also the corresponding documentation: https://help.sap.com/docs/cloud-transport-management/sap-cloud-transport-management/using-landscape-visualization

Export deployment destinations from source subaccount
In the subaccount from which you exported your transport landscape, open the destination maintenance UI (in the SAP BTP Cockpit under Connectivity -> Destinations). Here, use the download functionality for all destinations that are used in your transport nodes definitions:

Currently, the destination UI only allows the export (and import) of single destinations. In large landscapes, this can be a lot of work…
Alternatively, you could use the SAP Content Agent service UI to select up to 50 destinations in one go to export (and import them in the target subaccount). For large landscapes, it could be worth the effort of the needed SAP Content Agent service setup which is described here: https://help.sap.com/docs/content-agent-service/user-guide/initial-setup and here: https://help.sap.com/docs/content-agent-service/user-guide/content-agent-user-interface. As the destination migration is a one time effort, I would suggest to use the export / import functionality instead of the also available integration with cTMS, unless you plan to use further content types available in the SAP Content Agent service UI.

Import deployment destinations into target subaccount
In the target subaccount with your new cTMS instance, import the exported destinations either one by one using the destination UI:

or use the SAP Content Agent service UI to import the destinations exported in the previous step.

 Maintain client secrets / passwords in deployment destinations in the target subaccount
For security reasons, the passwords and client secrets are not exported and therefore must be maintained in the target subaccount. This has to be done one by one manually for each destination (there is no advantage here of using the SAP Content Agent service).
 Import landscape into target instance
In your newly created cTMS target instance, import the cTMS .zip file you exported in step 2. 

Please remember: merging a landscape into another is only possible if there are no duplicate names for transport nodes and transport routes.

Update destinations pointing to cTMS instance in subaccounts used as content source
As you have created a new cTMS instance in step 1 that should be used from now on in your transport scenarios, you have to reroute the existing destinations pointing to cTMS in the source environments. 
In many scenarios, this destination is called ‘TransportManagementService’, but there are other scenarios that require specific activities, for example: 
– SAP Continuous Integration and Delivery service in SAP BTP: the service key for the cTMS instance has to be uploaded as new credential that then has to be used in the jobs (pipelines) involving handover to cTMS in the release stage
– SAP Analytics Cloud: here as well, the new service key has to be uploaded
– SAP BTP ABAP environment: the outbound communication arrangement has to be adjusted

Handling of the cutover phase

As written above, transport requests are not migrated, but stay in the ‘old’ cTMS instance. After switching the destinations pointing to cTMS to the new instance, new transport requests will be created there. So, there can be a phase in which there are transport requests targeting the same environments in two independent cTMS instances.

Our recommendation would be to first process the ‘old’ transport requests by either importing them into their targets or delete them if they are outdated. After this has been done, you should change the authorizations assigned to the cTMS user to ‘view only’ (role ‘Viewer’). We would advise against deleting the old instance, because you might still need access to the logs. Alternatively, you could export the logs and put them into a long-term storage for potential auditing.

A little more challenging is the cutover, if cTMS is integrated with SAP Cloud ALM or SAP Solution Manager ChaRM. 
SAP Cloud ALM allows to define connections to several cTMS instances by setting up destinations pointing to the individual cTMS instances. The transport requests from the ‘old’ and the ‘new’ cTMS appear both in the list of selectable transport requests. They can be distinguished by the name of the destination. 
In SAP Solution Manager ChaRM, we would recommend to completely redo the setup of the integration for the new cTMS instance (RFC connections, external services in LMDB, solution landscape in SLAN, change cycle definition). This allows you to complete processing of existing change documents using the old cTMS instance, while using the new environment for new change documents.

Summary

As you can tell from the above explanations, migrating a cTMS instance involves several manual steps and can create significant effort. It should therefore be done only if absolutely necessary. In some cases, it can be better to create the new cTMS instances from scratch and switch the scenarios step by step.

 

​ In this blog post I would like to explain what it takes to migrate an SAP Cloud Transport Management Service (cTMS) instance.  MotivationThere are several scenarios in which you would like to migrate a Cloud Transport Management instance:Move the complete cTMS instance to another subaccount. This could be relevant if you decide for a different setup of your subaccount landscape, for example establishing a separate administrative subaccount into which you would like to move your cTMS instance. A specific use case is switching from a cTMS instance integrated into the SAP Cloud ALM subaccount to a ‘normal’ stand-alone cTMS instance (see the blog post by my colleague Moritz: https://community.sap.com/t5/technology-blogs-by-sap/new-integration-of-sap-cloud-transport-management-and-sap-cloud-alm/ba-p/13728049).  Separate parts of your cTMS transport landscape into two (or more) cTMS instances.Currently all users with roles in cTMS can see all transport nodes and routes, although they might not be able to perform activities in these nodes (due to their assigned roles). Therefore customers with large landscape might prefer to separate parts of their transport landscapes into separate cTMS instances. As long as the involved subaccounts are in the same global account, this has no implications on the cost of cTMS (uploaded data volumes are aggregated on global account level).Merge separate cTMS instances.This is only possible if the names of transport nodes and routes are unique in both instances.Move transport landscape from a cTMS instance running on a trial subaccount.While it is possible to switch from a free to a standard plan of cTMS and keep your transport landscape, this does not work for trial subaccounts. Here the only option is to migrate the landscape to a ‘real’ subaccount. ProcedureCurrently the migration procedure involves several manual steps which can lead to a significant effort for migrating large transport landscapes.Create target instance of cTMSFollow the standard procedure for setting up Cloud Transport Management including the subscription to cTMS a service instance with service key. This is described here: https://help.sap.com/docs/cloud-transport-management/sap-cloud-transport-management/set-up-environment-to-transport-content-archives-directly-in-application Export transport landscape from source instanceThis done from within the ‘Landscape Visualization’ pane:You receive a .zip file that contains three files: the landscape data itself, metadata information of the cTMS source instance (both in json format) and a signature. The signature which is checked at import ensures that the content of the zip file cannot easily be changed. See also the corresponding documentation: https://help.sap.com/docs/cloud-transport-management/sap-cloud-transport-management/using-landscape-visualizationExport deployment destinations from source subaccountIn the subaccount from which you exported your transport landscape, open the destination maintenance UI (in the SAP BTP Cockpit under Connectivity -> Destinations). Here, use the download functionality for all destinations that are used in your transport nodes definitions:Currently, the destination UI only allows the export (and import) of single destinations. In large landscapes, this can be a lot of work…Alternatively, you could use the SAP Content Agent service UI to select up to 50 destinations in one go to export (and import them in the target subaccount). For large landscapes, it could be worth the effort of the needed SAP Content Agent service setup which is described here: https://help.sap.com/docs/content-agent-service/user-guide/initial-setup and here: https://help.sap.com/docs/content-agent-service/user-guide/content-agent-user-interface. As the destination migration is a one time effort, I would suggest to use the export / import functionality instead of the also available integration with cTMS, unless you plan to use further content types available in the SAP Content Agent service UI.Import deployment destinations into target subaccountIn the target subaccount with your new cTMS instance, import the exported destinations either one by one using the destination UI:or use the SAP Content Agent service UI to import the destinations exported in the previous step. Maintain client secrets / passwords in deployment destinations in the target subaccountFor security reasons, the passwords and client secrets are not exported and therefore must be maintained in the target subaccount. This has to be done one by one manually for each destination (there is no advantage here of using the SAP Content Agent service). Import landscape into target instanceIn your newly created cTMS target instance, import the cTMS .zip file you exported in step 2. Please remember: merging a landscape into another is only possible if there are no duplicate names for transport nodes and transport routes.Update destinations pointing to cTMS instance in subaccounts used as content sourceAs you have created a new cTMS instance in step 1 that should be used from now on in your transport scenarios, you have to reroute the existing destinations pointing to cTMS in the source environments. In many scenarios, this destination is called ‘TransportManagementService’, but there are other scenarios that require specific activities, for example: – SAP Continuous Integration and Delivery service in SAP BTP: the service key for the cTMS instance has to be uploaded as new credential that then has to be used in the jobs (pipelines) involving handover to cTMS in the release stage- SAP Analytics Cloud: here as well, the new service key has to be uploaded- SAP BTP ABAP environment: the outbound communication arrangement has to be adjustedHandling of the cutover phaseAs written above, transport requests are not migrated, but stay in the ‘old’ cTMS instance. After switching the destinations pointing to cTMS to the new instance, new transport requests will be created there. So, there can be a phase in which there are transport requests targeting the same environments in two independent cTMS instances.Our recommendation would be to first process the ‘old’ transport requests by either importing them into their targets or delete them if they are outdated. After this has been done, you should change the authorizations assigned to the cTMS user to ‘view only’ (role ‘Viewer’). We would advise against deleting the old instance, because you might still need access to the logs. Alternatively, you could export the logs and put them into a long-term storage for potential auditing.A little more challenging is the cutover, if cTMS is integrated with SAP Cloud ALM or SAP Solution Manager ChaRM. SAP Cloud ALM allows to define connections to several cTMS instances by setting up destinations pointing to the individual cTMS instances. The transport requests from the ‘old’ and the ‘new’ cTMS appear both in the list of selectable transport requests. They can be distinguished by the name of the destination. In SAP Solution Manager ChaRM, we would recommend to completely redo the setup of the integration for the new cTMS instance (RFC connections, external services in LMDB, solution landscape in SLAN, change cycle definition). This allows you to complete processing of existing change documents using the old cTMS instance, while using the new environment for new change documents.SummaryAs you can tell from the above explanations, migrating a cTMS instance involves several manual steps and can create significant effort. It should therefore be done only if absolutely necessary. In some cases, it can be better to create the new cTMS instances from scratch and switch the scenarios step by step.   Read More Technology Blogs by SAP articles 

#SAP

#SAPTechnologyblog

Avatar for

You May Also Like

More From Author

+ There are no comments

Add yours