SAP CPI Neo to Cloud Foundry Migration

SAP wants all clients to migrate to SAP Integration Suite on Cloud Foundry (CF) and preferably to the Integration Suite license of it. Neo does not have an end of life, but CF is where new development will happen first. 

UPDATE: 2022 November. We have created a tool to help you with your migration project. You can read about the features in the Neo to CF migration tool here. All the other aspects here still make sense and should be considered.

There are some good reasons why Cloud Foundry is better

  • It is in all Hyperscalers, so it is close to your SAP data in the cloud
  • It has a better way of scaling 
  • Disaster recovery is better
  • It is where new features are added first including ISA-M tool and probably also the PI to CPI migration Tool.

Some drawbacks

  • The license is handled differently. It can be more expensive. A way to save is to use our transport tool that allow you to reuse your Dev Tenant also for QA. So you save one tenant.
  • There can be some challenges going from having data with an EU-based company to having it hosted in an American hyperscaler.
  • You need to migrate all your integration and connections. 

Steps in your migration

  1. Plan the migration and your landscape
  2. Perform technical migration
  3. Security material
  4. Perform testing
  5. Transport
  6. Go live

Steps in the migration 

Plan the migration and your landscape

You will need to understand how you want your new landscape look like. How many systems do you want in it? The normal is Development, Test, Production. 

If you have a small landscape, with few integrations you may consider running a virtual Test system. In the Figaf Tool, we have added automation for virtual landscapes you don’t need to copy and edit iflows manually. See virtual landscape

You also need to understand which iflows are delivered by SAP. In some cases, they iflows can be used free of charge with the Integration Suite license. So it is probably a good idea to import them again from the Discover part. 

It is a good idea to see what is being processed in your production environment so it is easy for you to find the iflows you are using. It does not make sense to migrate all your demo or experiments to CF.

Landscape size

One big consideration is if you need a real SAP Integration Suite/Cloud Integration/CPI tenant for all your environments. If you have a large landscape on over 400 integrations it may not be a problem. But if your landscape adding a new tenant is around 4.000 EUR(list price). A lot of customers reuse one tenant for both development and test. The normal way is to copy the iflows and add a prefix to the name. This can be a challenge for governance.

You can get both governances and save one or more tenants with our virtual agents, here, you can handle transports and configuration just like a real system. This is a super usecase to get Figaf that will improve your delivery processes. We have created a blog where we go into detail about how you can save an SAP CPI tenant in your landscape.

Perform the technical migration

SAP have created a Postman collection that will allow you to handle the migration you can find it here SAP Note 2937549. It is pretty simple to use it and it will enable you to copy and upload

  • IFlows
  • Configurations
  • Number ranges etc

And you can find the SAP Guide here

SAP has created a small tool to simplify the migration process.

We will always recommend Figaf Tool to such migration because it gives you the ability to

  • Rename objects
  • Test the migrated integration
  • Get a good overview of the migration
  • And have solid practices for transporting your integration.

Security artifacts

One of the challenges that the SAP migration is missing is the security credentials that you need to use. There is a good workaround solution for it. 

Santhosh Kumar Vellingiri has written an iflow that can extract the security artifacts so you can configure them in your landscape. Just remember to delete the IFlow from your CPI Tennant after use. 

HTTP endpoints and IP ranges

You can get a DNS endpoint assigned to your CPI tenant. It is probably not a good idea to reuse your existing endpoint unless you know that the change of the DNS would not affect your clients. 

If you are going with Integration Suite, it may be beneficial to also add API management as a security layer. It can give some extra level of monitoring and it will make it easier to move next time.

You will need to communicate the endpoints to your systems and partners, together with keys. API management also can provide a better approach for handling the connections. 

Users and API keys

The way to maintain technical users is a bit different on the two platforms. In NEO you primarily relied on S-Users for the technical connectivity. In CF you can use API keys. 

Once you are creating the API key for each system you can add password to the authentication. Then it will be possible to use the credentials as Basic Authentication Username and Password. It will make it much easier for creating the connection. So username will be the clientkey and password will be the secret. 

In that perspective, it also makes sense to consider how to handle each system. Do you want to use the ESBMessage Send role or do you want to be using separate roles.


The platform is different and so it does make sense to test that everything works as expected. My guess is that there is not a lot of difference between the two platforms. CF may have some newer options and adapters that are not a part of the NEO. 

The parts that need to be tested most are the connections because of the changed URL, authentication, and IP ranges. And of course to make sure that you have created the users correctly. 

If you want to perform a full test of how your iflows are working Figaf Testing Tool has some options that make it easy to record messages on your Neo system and rerun those tests on the Cloud Foundry environment. If there is any difference between the two runs you will see the results easily. 


After you have tested your new integration, you can start the transport to production. 

SAP CPI integration suites come with Transport Management and you can also connect it with CTS+ if you want to. You know have some experiences with your SAP Landscapes and know where it can be improved.

You can also just move each landscape separately. It will depend on how many changes you make to objects in the CF development system. I believe it will be better to transport the data from Development to QA and production. Then you can apply the configuration via the Postman connection and possibly connect the other artifacts used. 

The recommended approach is to set up a landscape with the Figaf tool that will enable you to transport the configuration to your production system. Figaf is the easiest way to have approvals, testing and documentation of your SAP Integration. A transport could have a process like this if you are using the Figaf Tool for DevOps.  

Go live

Now you are ready to go live it is a good idea to continuously be able to switch over the processing to your new CPI CF instance. So take some processes or systems to move in one go. That way it will be possible to see how your systems are working. 

If there are any problems, you can always roll back to the old Neo for that process. 

After you have completed the migration project, you can start leveraging other resources on the platform. 


Good post about a lot of the technical things about setting up the landscape and using the migration tool by Marty McCormick 

Simplify your SAP Integration in under 10 minutes with Figaf DevOps Suite on Cloud.

No credit card is required. 30 days free trial.

Latest Articles