Home / Insights / PI/PO migration guide

PI/PO to SAP Integration Suite migration: a practical guide

By iFlow Integrate Tech · SAP BTP Integration Suite

Many organizations still run business-critical interfaces on SAP Process Integration or Process Orchestration (PI/PO). SAP's strategic direction for integration is SAP Integration Suite on SAP BTP, so planning a migration is a question of when and how, not whether. This guide outlines the approach we follow.

1. Assess your landscape first

Start with an inventory of every interface: sender and receiver systems, adapters, volumes, mapping types, and business criticality. SAP Integration Suite includes a Migration Assessment capability that analyzes your PI/PO landscape and helps estimate scope. Combine the tool output with business input to group interfaces into waves.

• Retire: interfaces that are no longer used.
• Lift and migrate: standard interfaces that map cleanly to iFlows.
• Redesign: interfaces that depend on ccBPM, custom Java or unusual adapters.

2. Choose the migration approach per interface

SAP provides a migration tool in Cloud Integration that can convert supported PI/PO content into integration flows. It speeds up the simple cases, but expect manual work for anything custom. Treat tool output as a starting point: review each generated iFlow against your standards.

3. Mappings

• Graphical message mappings usually transfer well and can be reused or rebuilt as message mapping artifacts.
• XSLT mappings can generally be reused with limited changes.
• Java mappings need review. Many can be rewritten as Groovy scripts or replaced with standard flow steps.
• Value mappings should be exported and imported, then validated for consistency.

4. Adapters and connectivity

Confirm that each PI/PO adapter has a Cloud Integration equivalent (for example SOAP, IDoc, SFTP, HTTP, OData or RFC). For on-premise systems, plan SAP Cloud Connector setup, network access, certificates and authentication early, because these tasks often take longer than the interface build itself.

5. ccBPM and complex orchestration

Cross-component BPM processes do not have a one-to-one equivalent. Analyze what each process really does (correlation, collection, long-running state) and redesign it using iFlow patterns, data stores, JMS queues or a process automation service where it fits.

6. Testing strategy

Build regression tests from real, anonymized payloads. For each interface, compare the output of the old and new flow, covering success cases, error cases and volume. Plan unit testing, system integration testing, user acceptance and performance validation, and keep the test evidence as part of your documentation.

7. Cutover and monitoring

Run migrated interfaces in parallel where possible, switch sender systems in planned waves, and keep a rollback path for each wave. Set up monitoring and alerting before go-live so your support team sees issues immediately.

8. Document as you go

Capture interface specifications, architecture diagrams and operational runbooks during the project, not after it. Good documentation is what lets your own team run and extend the new landscape.