Why perform the migration

SAP Cloud Integration Suite is the Swiss army knife of SAP Integration. It has many of the things that you need as a developer to make sure you are effective with your development. 

The main part of the Cloud Platform Integration. Then you have 

• API management for external access and security
• Open Connectors to easily connect with all types of platforms
• Enterprise Messaging so you can use messaging services
• Integration Content Advisor so you can perform mappings much faster based on the business context

Once you have migrated you would have a solid platform to handle all your integration with. 

When is the correct time to migrate

It depends on your roadmap and your plans for the correct platform.

If you want more details about which platform to choose then check the post SAP PI/PO vs SAP CPI.

For a lot of scenarios, SAP CPI is a better option than SAP PI/PO. 

• Cloud integration
• Technical bpm flows

The places where CPI currently is not as capable is

• On-prem to on-prem. There will be released an integration cell, that users will be able to run on a server in their own landscape. If the systems you are integrating with anyway are hosted in the cloud then it probably does not matter. 
• B2B integration: The TPM and EDI support lags a bit. There is a new solution to handle partner management, it will be important to understand how this fit into your view. There is the Intelligent Content Advisor that enables you to perform the new B2B Mapping faster. 

If you only have a low number of the last two types of interfaces, then it is not a big problem. If you are planning on moving 100s of EDI partners CPI is probably not the right platform at the moment. 

If you have less than 50 interfaces it could be beneficial to perform the migration. Then you have one less platform to handle. 

If you currently are on SAP PI/PO 7.5 there may not be a lot of value to force the migration thru, but it would make sense for you to perform the migration to see the benefit faster. Then you can learn if the platform is ready for your use. 

Get an estimation of your Migration

Do you know how much in time, money and human resources are needed for your migration?

If not, to ensure you have everything you need to successfully operate your migration, you should get an understanding of how resource-heavy your migration will be.

We gave create an assessment tool as a part of Figaf Platform this will allow you to easily understand your current landscape. In about 30 minutes you can have report of all your current integrations and get a view of what can be migrated with our Free PI to CPI Assessment report.

We have created a migration estimator to help you know how much you will spend in time and money for your migration. Moreover, you will be able to see how much you save in money and time with the use of Figaf.

Automating the Migration

At Figaf we have created a tool to automate SAP PI/PO to CPI migrations. It will allow you to speed up the migration process with a log.

It simplifies the different parts of the migration so you can migrate and test the integration much faster. So with a few clicks, you can migrate a Receiver Determination or ICO with all mappings and channels copied.

Then you can use the tool to automate the testing and transport to production. You can see more details about what the tool can help with here.

Steps in a migration

As in any migration, there is a number of steps to perform to make sure you are performing the correct migration and are preparing correctly. 

You would still need to perform the following steps to handle your migration the best way. You need to plan the migration.

Mapping of used integration

You need to understand what interfaces you are currently using and what kind of patterns they follow. You need to have a good understanding of what is possible with the set of interfaces you are using.

You can start with the Message Monitor Overview and see what is used. 

Then you would need to understand the pattern used for the exercise and then 

Build PoC of the migration

You need to build a PoC of some of the different types of interfaces to make sure that you know how to handle each interface and then be able to migrate it. 

• Make sure you test error handling processes.
• How do you use different types of modules and groovy scripts?
• Know how you will be testing the interfaces
• Create some templates that you want to be using from this. 
• Understand how to support it in the future

Redesign iflows

SAP CPI is a new platform that gives new patterns for integration. In SAP PI/PO you sometimes had to develop flows that were not standards to support some business requirements. They can be designed to support the processes better. 

• BPMs like ccBPM/BPMN where you used them to handle a technical process. That can mostly be condensed into just one iflow
• Lookup performed in mappings to get extra data or to set status. 
• “Adapters” that can be replaced with Open Connectors
• Bridges or places where PI sends to PI. 
• And other places where you have been bordering what the PI can do standard. 

And there are probably other cases where you can improve the integration by looking at the process at a different level. 

And then there are the places where it would make sense to deprecate the systems that are integrated with because it no longer makes sense. Then you don’t need to create that integration, but there may be a new one that that CPI could support. 

Web dispatcher or reverse proxy

If you have SOAP or Rest interfaces that you want to move. Then you can make modifications to the Webdispatcher and instead of sending the data to SAP PI then forward it to the SAP CPI. 

You will need to find a way to rewrite authentication. 

The idea is to simplify the communication with partners so it becomes less friction for them. 

If you have other reverse proxies or API management in place you may also be able to use them. 

Project Planning

Neo vs Cloud Foundry

Such a migration is going to be a huge job. CF is the platform for the future, so it is recommended to migrate directly to it, instead of having to migrate again in 1-2 years. 

At the moment you cannot get new Neo installations so you will need to go with Cloud Foundry.

Plan to learn

The migration is going to be a learning journey. You will need to know how the platform can support your integration needs and which part it does not support. Then you need to be able to solve those parts. 

The way you run and monitor your integration is going to be different and it makes sense to spend the time on improving the process. 

What are your releases?

You want to perform the migration in waves or releases. You should plan with a number of releases so you get to release content along the way. 

First release: This should be a small one. Take some different interfaces that cover some different patterns. 

It is better if it is internal systems, so you have easier access to switch back when something fails. And there will be things that are not working as expected. 

Then create a release that makes sense in terms of risks and where your changes normally happen. 

Communication

You will need to involve the outside world to ensure that the integration will continue to work. You will need to find system owners of the internal systems and also partners to deal with their integration. 

Some of the information you will need are:

• IP Ranges for sending data
• Server IP and Credentials 
• Change in performance
• Go live date
• Rollback procedure

Some partners may be more difficult to get access to, depending on your relationship. 

Protection via API management

If you have any public-facing URLs it is highly recommended to use the API management in front to ensure that you can ensure the access and security are correct. It will enable you to monitor your partner’s transactions and ensure they do not overload your integration systems. It will also give you easier access to switching between CPI platforms if they need to be changed. 

Creating repository

You need to create a repository of all the artifacts that you want to reuse. It could be Groovy scripts or standard XSDs that are used in multiple places. 

In the Figaf Tool, we have a concept called shared resources for SAP CPI. This will allow you to track all the places where an object is used, and if it is changed, then enable it to be update in the other platforms. 

Process for migrating an interface

Create test data

It is vital to test each integration and make sure it works the same way before and after migration if it is 1:1 after the migration. 

With the Figaf Tool you can easily collect test data from your productive system and use them as test data. This makes the migration process much simpler. You can see the migration of SAP PI/PO to CPI test data in this blog. 

If you are not using SAP PI/PO you still need to find a way to test the new integration works the same way. You have options to create test cases manually with the Figaf Tool.

Create iflow and migrate artifacts

It is possible to migrate all of the artifacts with the Figaf PI to CPI migration Tool. You may need to change part of the generated process but it will greatly simplify the migration effort.

Testing

Testing is a large part of the migration. You need to run lots of tests to ensure that nothing has changed. There can be a difference in how the message mappings work, it is essential that your UDF still work and the logic in the mapping produces the same result. 

If you know the differences/variances in input and rules you may be able to have fewer tests. For simple mappings the testing could be rather small, but if you are dealing with EDI structure or complex mappings, you must increase your testing amount. 

At Figaf we have created an automated testing tool that allows you to fetch input and output messages from your SAP PI system. Then send it thru SAP CPI and see if everything gives the same result. It is a good way to be able to verify all your logic. Then testing with partners may be much lower. 

Plan Go live

You must find a good time to go live on. Ideally sometime outside of peak hours, so you are able to see it performs well. 

The time also depends on where you need to switch the action. If it is an SFTP file you can change it when you want. 

If it involved multiply partners, then you can also switch partners one by one. 

Before you Go-Live you must have a rollback plan. Who should be contacted or what should be done to switch the interface back to SAP PI. If you need to roll back then do it before the peak period. 

Go live 

Activate the interface in the SAP CPI and then disable those adapters in the old platform. 

Perform monitoring to see if everything runs successfully. 

Also, be involved with the business to see if they see everything as it is supposed to be. 

Learn

You will need to learn how the interfaces work and what is required to automate the process, so you don’t need to perform the same steps again and again. 

You can also look at the tooling required to see if there is room for implements. 

Repeat

Then go back and start with the next batch of interfaces. 

What can the Figaf Tools help with

The migration process is a manual process that you need to be spending a lot of time figuring out how you can optimize. 

At Figaf we have been building tools to simplify the process of delivering SAP Integration. We believe the standard way of delivering SAP CPI, can be improved dramatically. To ensure better visibility into change and also handling the change process. 

The Figaf DevOps Tools have been designed to simplify the process of delivering SAP PI and CPI integration. It works like you are suppose to delivering SAP Integration in 2021. 

It is also possible to automate the full migration.

It can perform testing. To see if the original output message is equal to the new output message. That can greatly simplify the delivery process. There is a need to understand what is being changed from the old to the new system. 

It is also able to offer advanced versioning, transport, and documentation tools. 

Automated Testing of the Migration

The testing tool can help you automate the testing process to ensure that there are no surprises in the process. It can take messages from your SAP PI/PO system and run them on the CPI system after the conversion. Then you can validate if the CPI behaves as SAP PI. If it does you can simplify your processing. 

Migration automation

This is possible with the Figaf Migration Tool to automate the migration.

The following could be options our platform can handle

• We do have the option to map out host ports etc and enable you to help out with the configuration in the new landscape.
• Migrate message mappings with RFCs
• Copy of other artifacts like XSD, WSDLs
• Other ideas that can help you with your migration

We will build the tool so you and your developers can be more productive and deliver the integration much faster. 

UPDATE:
As recently announced on the SAP Blog we have built a prototype Tool for SAP PI to CPI Migration which won the “SAP Hack2Build-Beyond a Hackathon”– a two-week competition sponsored by SAP to automate SAP PI to CPI migration process.

You can sign up for the trial and try to see how the tool works for your scenarios.