Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
Showing results for 
Search instead for 
Did you mean: 

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.


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


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.wegelin2 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.
Active Contributor
Very nice christoph_hanser38! Always nice to see lessons learned. To me the next iteration would be to support the migration assessment in a tool based way 🙂

For a view on integration patterns transitioning from PI/PO to CPI or Azure Integration Services have a look at this blog series.


0 Kudos
Would wonder who does something like that. XSLT is relatively complicated in comparison to low code-no-code message mappings. In addition, SAP has a clear roadmap to its camel-based SAP Integration Suite which sounds like a reasonable multi-cloud native future perspective.

Azure has so much value to offer to SAP customers. I see migration as an unreasonable effort that (for heavy SAP PI / PO customers) is better invested in architecting SAP + AZURE solutions that add more value.

0 Kudos
Hi Andreas, you definitely have a good point here that the most natural way is to migrate SAP PI/PO to SAP Integration Suite. This also counts for most of our customers. If you wonder who acts differently, this happens, when a customer has reasons to not use the Integration Suite as her standard middle layer. In our case, the customer, wanted to move all non-ERP processes to Azure. But as I mentioned, most customers will be happy with migrating from SAP PI/PO to Integration Suite.

Like you, I see also benefits in the other aspects of SAP & Azure cooperation, esp. Hosting and maintaining SAP and also site-by-site development of apps and services. I recently had a talk about this on a conference and will soon write a blogpost about that.
Labels in this area