Migrate your SAP PI/PO flows to Cloud Native

Dear community,

Many of our customers are currently evaluating what to do with their SAP PI/PO installations in the future, since maintenance had been restricted to 2027 / 2030. That’s not new. However, the interesting question is where they go with the integration flows. We had been supporting several customers through the last year to make this decision and we are happy to share some findings here.

Ah, maybe I should shortly introduce what we do at QUIBIQ: Our focus is integration, and we build our solutions on the SAP and Microsoft platforms – hence, migrations from SAP PI/PO or BizTalk Server to SAP Integration Suite or Azure Integration Services are a typical use case.

There are excellent middleware systems on the market and their pros and cons are well-known thanks to research from companies like Gartner (see SAP as a Leader of eiPaaS). Furthermore, SAP and Microsoft are constantly improving the integration capabilities of their platforms SAP Integration Suite and Azure Integration Services. We saw in our evaluations, that not the technical capacities where important for the decision but rather strategic and financial questions. Evaluating the best middleware strategy would be a post for itself…

In this post, we want to focus on the option of how to migrate SAP PI/PO. Since many posts already focus on a migration path to SAP Integration Suite, we would show here our special findings on how to migrate SAP PI/PO to Azure Integration Services. In our experience, customers usually choose this way when they had decided to focus on ERP functionalities on the SAP platform and side-by-side-development on Azure.

Technical Aspects and Lesson Learned

From a technical perspective, you should think about the following aspect:

• Many SAP PI/PO interfaces grew historically and are maybe not used any more. Activate tracking to check which flows are still relevant.
• Migrating PI/PO mappings to a new format like XSLT can be a huge task and you should think about using a converter (see below) and about outsourcing conversion and testing.
• It is not only migrating SAP PI/PO itself, but you also must analyse and adapt the SAP-internal call of the migration flows. Use SOA MANAGER to communicate with Azure via SOAP instead of XI – this helps you to continue with proxy classes and have as little impact as possible on SAP side.
• If you migrate to Azure, develop/buy Bicep-based templates that include best practices for monitoring, Service Fabric and Azure Logic Apps
• API Management will heavily boost quality of migration because you can manage the endpoints at a central place. Both SAP and Azure API Management do an excellent work here.

And then, we of course had to learn some lessons when migrating from SAP PI/PO – some are typical for any migration project, others maybe a bit more specific:

• Involve affected external parties early​: Find good incentives for the connected partners, so that they are ready to help. Since 1:1 migrations do not create value on their own, they need to be motivated to help.
• Staff your team with all involved disciplines​, i.e. not only experts for the new platform but also for SAP PI/PO and SAP-internal development.
• Run the project agile, to migrate SAP PI/PO step by step
• Check which interfaces are really in use​
• Check which flows can be removed
• Check which flows can be merged, i.e. used together with other PI flows in a single new flow
• Invest time in a good configuration management and templates​
• Provide test interfaces for connection testing​
• Think about testing and monitoring early​
• Provide a reasonable amount of test data​ from SAP PI/PO

Game Changer: Converter for SAP PI/PO mappings

When our first customer had decided to migrate SAP PI/PO to Azure, one cost driver was the migration from all PI message mappings. That was why we developed a converter for SAP PI/PO mappings that converts XPath-based mappings into XSLT. XSLT is a mapping standard that all up-to-date middleware platforms can use for conversions.

This way, the efforts to convert mappings got significantly lower because the converter took over 80-90% of the work. It then said which parts could not be migrated, e.g. because of specific libraries in Java mappings, and these could be migrated from the software developer. This converter made it financially attractive to migration to Azure in the first place.

Conclusion

Migrations from SAP PI/PO are not only necessary but also in good hands with the cloud-native alternatives from both SAP and Microsoft. Both SAP Integration Suite and Azure Integration Services are good successors for PI/PO flows. Some technical aspects are interesting (see above) and please don’t learn from our mistakes aka lessons (as well above). Last but not least, a converter from PI message mappings to XSLT can give you the freedom to choose the future integration platform of choice.

Further readings

• Basics: An Integrated Enterprise is an Intelligent Enterprise (Christopher Aaron)
• Various blogposts from Daniel Graversen about the PI->CPI migration topic
• Test support for PI/PO migrations (Andrzej Halicki)
• Modern Integration for SAP S/4HANA and RISE for the challenges of today & in the future (Thorsten Düvelmeyer)

Contact

What did you experience? Please share your feedback or thoughts in a comment.

And please contact me for any questions concerning SAP PI/PO migrations, regardless of whether you already have a preference for SAP Integration Suite or Azure Integration Services or not.

And THANKS to the project team and also to Michael Wegelin from 10 point software for backing up this blog post!

I will post other posts about this topics hence I would be happy if you follow my profile.