The hidden part of your SAP Cloud Transport

Get your end-to-end process before you complete the migration.

I have talked with many customers who are planning a migration to the integration suite. Most of the time, we only get time to discuss moving integration from SAP PI to the Integration Suite.

But that is only half the migration project. Other parts include testing and moving the integration to production. In this post, we look at how to transport the integration.

The transport

"Basis" would probably suggest following the standard with SAP Cloud Transport management (or getting the service for a small fee). It works similar if you are using CloudALM or ChaRM. Here, you just move the integration configuration, which should be handled separately.

There is also the Good old export and import. It will surly work, but you will not be albe to understand anything about your landscape. This may be an okay approach for the first 5 interfaces but is not something that should be considered else.??

The hidden time spend

There are some areas you normally would spend a lot of time in.

1) Building the correct transport. If you have a number iflows and scripts or other used artifacts,??you need to move to production it is important you you get the everything imported in the correct order. Otherwise you can have challenges with importing something that has a higher level of configuration. You should otherwise have good control over the different transports you have.

2) Configuration of all the parameters. You should have some documentation about what should be configured in your productive system. I have seen many places where the basis was in charge of the configuration. An integration developer was needed to create a list of changes to the configuration.

It is one of the things that break the flow of the transport because there are the manual actions that someone needs to help with. Often they are not as much into working with Cloud Integration and there is a significant effort of showing them how to perform the actions.

I wrote about what you should have in your transports to ensure proper governance over them, which is something that you should consider.

Figaf is the tool that will allow you to steam-line your transport process and let the people with the most knowledge handle the steps involved.

You can via the API integration with your existing processes.

Dev tenant also as QA

Quite a few customers just have two Integration suite tenants because of the cost. They then copy objects from the Dev area to the QA area by adding pre- or post-fixes. This is a good way to handle the ability to test your integration.

The challenge is then once you move the integration to production, what are you moving and do you know if it is the same version that you tested.

In Figaf transport you can easily transport to the "QA" and it will just be a part of the transport process. You have the same governance steps as covered in the last post.