Skip to Content

13 Reasons to Migrate from SAP PI to SAP PO (and Intelligent Business Operations) – Chalk and Cheese – Key for S/4 HANA

Let’s face it, integrating IT systems / automating processes (often referred to as Middleware) isn’t considered as eye grabbing / interesting as mobile user interfaces.

So to grab some attention and prove that UI has a place in middleware, there is a screenshot below from our SAP Process Orchestration server, exposing the processes available using the Fiori launchPad. Note. screen is from 7.4, 7.5 has the more modern Fiori LaunchPad


Like security, middleware is a specialised area of IT, which if done well, enables the real-time data exchange and governance that is key for the business models demanded by Digital Transformation. If you want to understand this in more detail, I can recommend this OpenSAP Course – it is critical to get the middleware right first, in order to get the most from S/4HANA.

For example – Do you think Uber batches up your taxi requests! Your customers expect the same service level – competition is a click/tap/swipe away.

As I have discussed in this blog, SAP’s middleware portfolio has grown massively in features and maturity since it was introduced as XI in early 2000, I now regularly see SAP Middleware winning against pure play middleware vendors.

The purpose of this blog isn’t to demonstrate the long list of newer features, such as; Real-time KPI monitoring with OpInt, Complex Event processing on high volume data streams using ESP/SDS, Monitization of API’s outside your organization with SAP API Management by APIGEE or Cloud Integration using HANA Cloud Integration.

I want to focus on how you can build the case to move from SAP Process Integration – PI (or any other Middleware solution) to SAP Process Orchestration – PO.

What is SAP Process Orchestration

First let’s make sure we all understand what these two products are:

SAP Process Integration – This is an integration broker which traditionally uses BOTH ABAP and Java stacks to enable Message Based integration between IT systems using a number of adaptors to get messages into and out of these systems. It is possible to deploy PI to just run on the Java stack, but if you are doing this you might as well activate the extra PO components (see below). This blog describes how to use only the Java part of PI.

SAP Process Orchestration – This is the combination of SAP Process Integration (as above), SAP Business Process Management (used to create workflows between people and systems), SAP Business Rules Management (used to enable user defined business logic required in any business process e.g. sign off limits). It also has lots of helpful technical components like the Composite Application Framework (for creating data persistency), Enterprise Content Management (used for document management) and a light weight version of SAP Portal capabilities (used for role based access to content), all only running on the SAP Java Stack.

Simply put,  SAP Process Orchestration encompasses all the tools you need to create business logic, applications and integration required to plug any gaps between your IT systems – an on-premise Extension Platform

License Conversion

If you have PI, BPM and BRM licenses, you can get a credit for the full value from SAP to put towards your PO license.

You have to discuss with SAP about how this is turned into a license credit and how much PO will cost you. Also as the move from PI to PO is a migration (can’t do an in place upgrade) you might want to do this over a period of time (to reduce risk), so again you need to discuss with SAP about running both in parallel for the period of the migration.

Note to SAP: A clear policy on parallel running during migration would be really helpful.


Many customers I speak to are disappointed that they have to migrate from PI to PO. In my experience PI systems are often seen as something that you don’t touch as long as they work and customer side PI skills can often be low as the integration was done during an implementation project by the SI engaged at the time – the customer team can often be in support not development mode.

I would encourage you to look at the migration as an opportunity to spring clean your middleware landscape – implementing problem interface using state-of-the-art techniques. You can look at this blog to see the huge variety of Integration Patterns that are supported by PO. This blog also outlines what you can do in your current PI environment to make the migration as easy as possible.

Migration Tool

SAP provide a migration tool that moves/converts the PI content that can be migrated from the PI system to the PO system. The key items that can’t be moved are ccBPM logic (which is replaced by BPM in PO) and ABAP mapping logic (as you don’t have an ABAP stack!).

Once migrated you can take advantage of the 13 reasons I have listed below – You can easily build your business case from these.

13 Reasons to Migrate from PI (or other middleware product) to PO

  1. B2B add on – With PO you can use the SAP B2B adaptors and trading partner management and remove the need for 3rd party solutions to EDI or costly 3rd party adaptors (this alone can justify the business case). Read this blog by Agnieszka Domanska for more details.
  2. Simplified IT Landscape – by running ononly SAP Java stack your IT landscape is simpler to manage.
  3. More Throughput – The move to Java only architecture means we get a massive boost in the performance throughput.
  4. Human to System / Workflow – With PO we get access to SAP BPM which allows for great Human (screen) integration and workflows, this means we automate integrations where possible and involve Human steps which need review or additional data (e.g. make mapping errors into a business task instead of a IT one). See the screenshot above to see the type of processes that can be enabled.
  5. Native Business Rules – Business rules allow you to empower business users to be able to “flex” the behaviour of integrations / processes. These can be maintained in production so changes can happen at the speed of business not the speed of IT. Examples might include look up value, sign off limits, % change etc.
  6. Modern User Experience – As can be seen above, Fiori has made its way into PO, so where human interaction is required this can be done using HTML5 user interfaces that work on Desktop / Tablets / Phones and Watches. The best example being the My Inbox Fiori Application.
  7. Easier to Develop – Having all the tools in PO in one box it is much easier to develop complete solutions.
  8. Easier to Configure / Monitor / Tune – Because the tools are all running on one technical platform, it is much easier to configure / monitor and tune a PO system vs PI, as you only have one application server to worry about. See this great server overview available in PO.Monitor.png
  9. Value Help – The value help framework allows easy integration to Business Suite systems for reference data (e.g. Company Codes, Plants, Customer Groups etc.) which you might want to use in your applications. Read this blog by Kate Burcham for more details.
  10. Java Gateway / Rest Adaptor – These technical tools allow for fast integration with SAP Fiori services and other modern restful architectures
  11. Ready for Cloud – The iFlows used in the PO system use artefacts that can also be used in the HANA Cloud Integration product – so if/when you choose to use that tool for cloud – cloud or cloud on-premise integration, you can re-use work you have put into interface definitions and mappings.
  12. Ready for HANA – With PO you can run your middleware on HANA (PI dual stack will not be released for HANA, instead at 7.5 you have to split the ABAP and Java Application servers on to their own SIDs) which means you can get real-time insight from the system tables, plug Operational Process Intelligence directly into the process / integration events and use HANA Smart Data Streaming for high volume IoT scenarios.OPINT.png
  13. SAP are not developing PI dual-stack anymore – By not being on PO you are locked out of new features. So PI isn’t a burning platform (perhaps smouldering a bit), but you will be locked in the past when it comes to new features.

I hope that using the above list you can find the value required to go through the hassle of negotiations with SAP and the migration. With state of the art SAP middleware (including PO) you can be sure that you will not hit any bottlenecks getting data into and out of your S/4 HANA landscape.

One of my longer term PI colleagues goes white when I tell her she has to work on “just PI” now she is used to the PO.

You must be Logged on to comment or reply to a post.
  • Hi Pettiford,


    Good info on benefits of switching to PO..


    Here I would like to know the details on the points 5, 8 & 9.


    Fiori inbox - Are you talking about the BPM inbox here ?

    Value Help - What is the new about value help , was this feature not there in PI ? If this is different can you throw more light on this please.

    Java Gateway - Though I can see the Rest Adapter available now  in PI , I dont think Gateway is fully compatible with Fiori based mean we can expect this in future ?




      • Thanks for your responses ...


        Can I ask you couple more info on usage of CAF and ECM on PO . How these can be leveraged ..Are these mainly useful during the BPM scenarios or any other integration scenarios also ?




        • CAF and ECM can be leveraged in any scenario. Both have rich API access.


          FYI - BPM standard attachments uses ECM.


          CAF often used for large contexts in BPM.

  • Excellent post. I can only agree with the items it is a much better platfrom.


    I'm missing item 13?


    Is it the longer you wait the more you will have to migrate.

  • Amazing post Owen Pettiford, I had been looking up for such a concise and informative blog and you have captured it nicely. Keep iup the good work!!!

  • This indeed great blog with Insight of benefits of Migration to PO.


    Thanks Owen Pettiford .

    Could you please answer my queries as well?

    We are exploring options to Migrate to PO. What i would like to know is what is minimum requirement from ECC side?

    Also, We are currently on PI 7.31. Can we upgrade this itself to PO?



    • Prabhat,


      The ECC side shouldn't matter.


      If you have PI dual stack (ABAP and Java), you have to migrate to PO. You can use the migration wizard to do this.


      I would also recommend that you consider putting PO in SAP HANA as you can then co-deploy OPInt and Smart Data Streaming.



  • Hi Owen Pettiford  First of all let me say it is a great blog.


    My question is same as Rajesh pasupula   asked above.  How did you manage to deploy the My Inbox ( Fiori)  app using the Java Gateway that is delivered with PO - as seen in screen shot ?


    Or did you say Yes to it is planned.   I believe the Java Gateway embedded in PO still has limitations, I think we will still need to use ABAP Gateway to be able to use My Inbox ( Fiori App ). 



    The Product Capabilities Matrix still shows that PO Java Gateway does not support "Task Gateway Service Consumption".  Also just a note that the Fiori apps can not be deployed on the Java Gateway too. 


    Thanks again for the excellent blog,



  • good taught you have Owen Pettiford. But I have a question.


    How can you convinced for example an existing customer constantly updating their version of SAP PI? Meaning, the latest version of SAP PI which is 7.5 SPS00 does have reasons that it can integrate with S/4 HANA (except for usage on Process Intelligence). For customer who have PI 7.31 SPS17, they have updates as well.


    The reasons above for me is very much convincing (which I am currently using as a strategy when customer would migrate to S4 HANA), but in my own opinion, current customer will still utilize what they have.





    • R-jay,


      If a customer has no need for any of the 13 reasons I have quoted above you are right why move. The last reason will be the most compelling in the end as customers will be forced to migrate in the end. My experience is that it is something you should consider the next time you think about upgrading/re-platforming your PI system. Often it is a chance to relook at the why things have been done and do them in better more modern ways which should lead to lower ownership costs.



  • Owen Pettiford, really a very crisp and perfect blog to understand the real need of PO. Am exactly looking for these inputs which were covered in a single blog.


    Great work !!!

      • Hello Owen


        Your blog says 'Ready for Cloud' from PO7.5, in our landscape we have PI7.4(Java only -not PO). If we upgrade it to PI 7.5(not PO), still this option of 'Ready for Cloud' can be supported or will it be available only with PO(PI+BPM).


        Also same question applicable for User experience/Java Gateway.


        Kindly provide your valuable input!

  • Hi Owen


    Great blog on covering the migration from PI to PO.


    But do you have any idea if there's a standard tool available to migrate CE processes to the BPM part of PO? As with a migration, you could have some running processes on the old CE that should be migrated to the new PO. I was wondering what SAP's best practices would be on that.




    • Nicolas,


      I don't know of any tools that exist to migrate processes from CE (I has asked the question and will add the answer when I get it).


      What you can do is upgrade your CE systems to PO, they way you don't need to migrate the BPM processes.



  • Hi Owen,


    I would disagree with this:

    With PO you can run your middleware on HANA (PI will not be released for HANA

    As of 7.40 you can install PI on HANA and we have an instance, e.g .an AAEX running as 7.50 SP1 on HANA right now, without the PO, e.g. the SWPM has an option for PI to install on HANA.



  • SAP Process Integration – This is an integration broker which uses BOTH ABAP and Java stacks


    PI 7.4 can be deployed Java stack only. Dual stack is still an option. If moving to Java only need to migrate any RFC or iDoc channels to use new alternate adapters.


    PI7.5 is single stack Java only. No ABAP stack.


    I believe both PI 7.4 and 7.5 single Java stack installs can run on HANA, but not dual stack.

    • A "dual-stack" option is still available for PI 7.50, however it requires the ABAP stack & Java stack to both be installed on separate system ID's.


      To quote SAP:

      As of SAP NetWeaver 7.5, dual-stack installations of SAP Process Integration are replaced by dual usage type installations that install the SAP NetWeaver AS for ABAP (PI ABAP) and the SAP NetWeaver AS for Java (PI Java) on separate system IDs.


      Dual-Stack Option Changed to Dual Usage Type (Changed)



      However there isn't a clear answer on the question if they can both run on HANA as well in the Dual-Usage type.

  • Dear Owen,

    my understanding is that Fiori LaunchPad runs exclusively on ABAP systems so it can not exist on a single stack Java PO Server.

    Can you please explain how this picture was taken? Was the Fiori Launchpad embedded from another ABAP system using the portal functionality (as part of PO)?

    Best regards,


  • Hello Owen

    I think that the post needs a 2016 "edit" in order not to create confusion. "PI uses both ABAP and Java" or "PI will not be released for HANA", need to be edited, in my honest opinion. People does not often go to the "comments" part to read up-to-date info.

    Regards, and thanks for the content.

  • Hi Owen,

    Greetings...This is a nice and valuable blog.

    We have a scenario to migrate our PI 7.4 Dual Stack system to PO 7.5 Java Only system.

    Source System runs on Oracle DB. Target Java Only system needs to be on Sybase DB.

    Is this activity possible using Content Migration Tool without upgrading the Source System to PI dual stack 7.5?

    Please suggest a way forward...

    Thanks & Best Rgds,




    I appreciate this article is quite old, but I have a question I have not been able to find the answer to within the blogs I have read.

    The simple question is, how long can a BPM run for.  I understand its an in memory process, but what does that mean.  If you have a complicated process that may be on going for a few weeks, such as a loan application, how is that managed?  Is it within one or more linked BPMs that sit in memory for the duration, or is there another way of managing this, such as linking together the steps in a database and making the process an event driven one?

    Any thoughts or details of an example process or application would be appreciated!


    • Sorry only just saw this comment.

      The BPM processes are persisted to disk and in theory could run for ever.

      They are "woken up" and put in memory when and event needs to interact with them or they trigger an event, so they more active process you have the more reading from disk to memory the system needs to do (unless you are on HANA in which case everything is in memory - but BPM still needs CPU to process the Active processes).

      So generally don't leave processes Active if you don't need to but if you do just make sure this is sized in.

      We have customers that run processes for months / years.