SAP PI/PO to Integration Suite migration: step by step

Why migrate from PI/PO to Integration Suite?

SAP Process Orchestration (PI/PO) follows the SAP NetWeaver maintenance timeline, and SAP Integration Suite is its strategic successor. Migration is therefore a question of when, not if. The teams that do well start early and treat it as a redesign; the teams that struggle leave it late and try to lift and shift. For the platform context, see the SAP Integration Suite complete guide.

This is a how-to. The steps below take you from inventory to cutover.

Step 1: Run Migration Assessment

Start with facts, not guesses. SAP's Migration Assessment analyses your PI/PO system, inventories the scenarios, estimates migration complexity and effort, and flags technical showstoppers. The output is a scored backlog: which interfaces are simple, which are complex, and which cannot be converted directly.

Do not skip this. An honest inventory is what lets you plan realistically, size the programme, and avoid surprises halfway through. It also surfaces dead interfaces you can retire rather than migrate, which is often a meaningful slice of an old estate.

Step 2: Plan by business priority

Sequence the migration by business value and risk, not by technical convenience. A practical ordering:

• Low-complexity, low-risk interfaces first, to build the team's muscle and prove the target patterns.
• High-value interfaces next, once the patterns are proven and the team is confident.
• Complex or unsupported scenarios last, where a rebuild is likely and more design time is needed.

Group interfaces that share systems or data so you cut over related flows together, reducing the number of risky transition states.

Step 3: Convert with Migration Tooling

For supported objects, use the Migration Tooling inside Cloud Integration. It converts PI/PO artefacts into Integration Suite artefacts semi-automatically, handling a meaningful portion of the technical effort. Treat the output as a strong starting point that you review and refine, not a finished product.

Step 4: Rebuild and modernise what the tool cannot

Quick answer: rebuild unsupported scenarios natively and use the moment to add modern reliability patterns.

Some scenarios will not convert cleanly. Rather than forcing them, rebuild them, and use the opportunity to modernise. This is where you add what PI/PO scenarios often lacked: a proper exception subprocess, retry with JMS or Data Store, idempotent receivers, and consistent monitoring. The reliability pillar is your reference for the target patterns.

Step 5: Test with realistic, safe data

Test each migrated or rebuilt interface against a regression pack, using synthetic or masked data so you never move sensitive production data into test. Compare behaviour against the old PI/PO interface: same outputs, same error handling, same edge cases, same volumes where possible. Document the evidence; you will need it for approval and for proving equivalence to the business.

Step 6: Cut over under change control

Cut over one interface at a time. For each:

1. Confirm the new interface passed its regression pack.
2. Get independent approval under your change control.
3. Schedule the switch, keep a named rollback, and monitor closely afterwards.
4. Decommission the PI/PO scenario only once the new one is proven in production.

A phased cutover keeps blast radius small: if one interface misbehaves, you roll back one interface, not the whole estate. The gated playbook on PI/PO to Integration Suite migration covers the governance and sequencing in more depth.

What are the migration pitfalls?

• Lift and shift: copying PI/PO designs verbatim, carrying forward their weaknesses.
• Big-bang cutover: switching many interfaces at once, so any problem is a large problem.
• Skipping assessment: planning on guesswork and discovering showstoppers late.
• Testing with production data: creating a data-protection problem during a technical project.
• No rollback: going live with no way back.

What about S/4HANA at the same time?

Many migrations coincide with a move to S/4HANA, often the public cloud edition. If so, align the target patterns: released APIs, communication arrangements and events, as described in S/4HANA Public Cloud integration. Migrating and re-platforming together, interface by interface, is less risky than two separate big-bang programmes, and it avoids building new interfaces twice.

How long does a migration take, and what drives effort?

Quick answer: effort is driven by the number and complexity of interfaces, not the calendar, which is why assessment comes first.

There is no single answer, because a landscape with fifty simple interfaces is a very different project from one with five hundred, many heavily customised. What the Migration Assessment gives you is a scored inventory, which is the honest basis for a timeline. The biggest effort drivers are custom adapter modules, complex mappings, and scenarios with no direct equivalent that must be rebuilt. Plan in waves rather than a single date, size each wave from the assessment, and keep the sequence driven by business priority. Beware anyone quoting a duration before the assessment is done.

How do I build the team and skills?

Migration is as much a skills transition as a technical one. The engineers who know PI/PO need to learn Cloud Integration patterns: iFlows, the exception subprocess, JMS and Data Store retry, and cloud connectivity through Cloud Connector. Pair experienced PI/PO developers with Cloud Integration patterns early, use the low-risk first wave as deliberate learning, and capture the target patterns as reusable templates so later waves go faster. Investing in skills up front is what turns the later, higher-value waves from risky to routine.

How do I handle interfaces with no direct equivalent?

Some PI/PO scenarios, particularly those relying on custom adapter modules or unusual patterns, have no direct Cloud Integration equivalent. Rather than forcing a like-for-like rebuild, step back and ask what the interface needs to achieve, then design the modern equivalent: perhaps an event instead of a poll, or a released API instead of a bespoke extractor. This is where migration pays off as a redesign, and where aligning with an S/4HANA Public Cloud target architecture matters most.

How do I prove equivalence to the business?

The business does not care that an interface moved platforms; it cares that the process still works. Prove it with evidence: run the old and new interfaces against the same regression pack, compare outputs and error behaviour, and document the result. Keep that evidence as part of the change-control record for each cutover. This is what turns a technically successful migration into one the business trusts, and it is covered in the gated PI/PO to Integration Suite migration guide.

What does Migration Assessment actually tell me?

Quick answer: it extracts your PI/PO configuration, evaluates every scenario against a rules framework, and places each one into a category, ready to migrate, adjustment required, or evaluation required, with a weighted effort estimate.

The assessment report is most valuable as a planning instrument, not a verdict. Rules carry weights, so scenarios that trigger several heavy rules, for example custom adapter modules or complex Java mappings, rise in estimated effort. The report also surfaces technical details such as message throughput and the status of sender and receiver channels, which helps you spot interfaces that are inactive and may not need migrating at all. Treat inactive interfaces as a gift: every scenario you can retire is effort saved and risk removed.

Which patterns can migration tooling convert?

Quick answer: SAP's migration tooling semi-automatically creates integration flows for supported patterns, including point-to-point asynchronous, point-to-point synchronous, recipient list asynchronous and content-based routing, from SAP Process Orchestration 7.5 integrated configurations.

That coverage handles a large share of a typical estate, but "converted" does not mean "finished". Generated flows still need connectivity configured on the target, security material created, externalised parameters reviewed, and the team's standard exception handling applied. Plan time for this finishing work in every wave, and use the generated flow as a consistent starting point rather than a final artefact.

How do PI/PO concepts map to Integration Suite?

Quick answer: most concepts have a direct counterpart, but some, especially ccBPM and NW BPM processes and custom adapter modules, need redesign rather than conversion.

The rows at the bottom are where effort and risk concentrate. Identify them early in the assessment and give them experienced people.

How much time do I have?

Quick answer: SAP has stated mainstream maintenance for SAP Process Orchestration 7.5 until the end of 2027, with extended maintenance available until the end of 2030. That is a planning horizon, not a reason to wait.

A scenario: planning the first wave

Quick answer: pick a wave with a mix of quick wins and one representative complex interface, so the team builds momentum and learns the hard lessons early.

A manufacturer with around two hundred PI/PO interfaces runs Migration Assessment and finds a large group ready to migrate, a middle band needing adjustment, and a small set needing evaluation. Wave one takes twenty ready-to-migrate interfaces from one business domain plus a single complex interface with a Java mapping. The quick wins prove the pipeline, transports and monitoring; the complex one exposes the finishing work early, while there is time to adjust the plan. Each interface is tested with realistic data, see the gated testing guide, cut over under change control, and decommissioned on PI/PO only after a stable run. For the wider strategy, see the gated PI/PO migration guide.

The one-line summary

Assess, plan, convert what you can, rebuild and modernise the rest, test with safe data, and cut over interface by interface under change control. Return to the complete guide for the bigger picture, or the reliability pillar for the patterns to build in.