SAP PI/PO Migration to SAP Integration Suite: Strategy, Assessment, and Roadmap

SAP PI/PO is still running business-critical traffic in a large number of enterprises, and in most of them it is running it well. That is worth stating plainly, because a lot of writing on SAP PI/PO migration opens as though the platform were already failing. It is not.

What has changed is the maintenance horizon. Mainstream maintenance for PI/PO 7.5 runs to the end of 2027, with optional extended maintenance available to the end of 2030, per SAP's published maintenance strategy. That is enough time to plan properly and not enough to keep deferring the question.

The mistake most migrations make is starting in the wrong place. Converting interfaces feels like progress because it produces visible output early. But an estate that took twelve years to accumulate cannot be understood by opening it in a conversion tool, and a migration that begins with conversion tends to end with a cloud-hosted copy of the same problems.

How do you migrate from SAP PI/PO to SAP Integration Suite?

A SAP PI/PO migration should begin by assessing the existing integration landscape, classifying every interface, and defining the target Integration Suite architecture. Organisations can then evaluate feasibility with SAP Migration Assessment, decide which interfaces to migrate and which to modernise, execute in controlled waves, validate through testing, and transition operational ownership before retiring the old PI/PO scenarios.

Why are companies migrating away from SAP PI/PO?

Rarely for one reason. The maintenance timeline is the trigger that creates a deadline, but it is seldom the reason a business case gets approved. The reasons that carry a business case tend to be:

• Maintenance lifecycle. A dated end point forces a decision that would otherwise be deferred indefinitely

• S/4HANA transformation. An ERP programme already in flight makes integration modernisation cheaper to attach than to run separately

• Cloud and hybrid requirements. New systems arrive as SaaS, and connecting them through an on-premise middleware layer becomes increasingly awkward

• API and event demand. Requirements arriving now often do not suit traditional message-based interface patterns

• Technical debt. Years of custom mappings and Java code that fewer people understand each year

• Skills. The pool of people who want to build a career on NetWeaver-era middleware is shrinking

Worth being clear about what does not happen: PI/PO does not stop functioning at the end of 2027. Maintenance ending means support, patches and fixes change, not that the platform switches off. Anyone using an imminent shutdown to create urgency is overselling, and architects recognise it immediately.

When does SAP PI/PO maintenance end?

Two things follow from this that are easy to get wrong.

Extended maintenance is optional and typically carries a commercial arrangement. Treating 2030 as a free extension of 2027 is a planning error, and it is one that surfaces late, usually during budgeting for the year it starts.

Maintenance dates are also not the only clock. Connected systems have their own lifecycles, and an S/4HANA programme or a data centre exit will often force the integration question earlier than SAP's calendar does.

What replaces SAP PI/PO?

SAP provides a defined path from Process Orchestration to SAP Integration Suite, with published migration guidance, Migration Assessment for evaluating the estate, and migration tooling within Cloud Integration for converting supported objects.

That is the product answer. The architectural answer is more useful and slightly less tidy: replacement is not one-to-one. What currently lives in PI/PO will typically distribute across several capabilities. Application and process integration into Cloud Integration. Governed exposure into API Management. Asynchronous and decoupled scenarios into events. Partner-facing traffic into B2B capabilities. And a portion into technologies that are not part of Integration Suite at all, because they were never a good fit for middleware in the first place.

Thinking of it as "PI/PO becomes Cloud Integration" is the single most common scoping error in these programmes. It quietly assumes the target looks like the source. Full detail on the destination platform is in what is SAP Integration Suite.

SAP PI/PO vs SAP Integration Suite: what changes?

This is not old versus new. PI/PO estates frequently contain a decade of hard-won operational knowledge, well-understood failure modes, and interfaces that have run without incident for years. Some of that is genuinely valuable and gets thrown away by teams treating the migration as an escape rather than a transition.

The seven stages of a SAP PI/PO migration

Conversion is stage six of seven. Most of what determines cost and risk happens before it.

1. Discover the existing landscape

Build the inventory: interfaces, connected applications, protocols, adapters, mappings, custom code, BPM and B2B components, message volumes, business owners, dependencies and SLAs.

Business owner and message volume are the two fields most often left blank and the two that matter most later. An interface with no identifiable owner and no traffic is a retirement candidate. An interface with high volume and a named owner in operations is a wave-one risk. Neither can be judged without the data.

2. Assess migration readiness

Migration Assessment provides structured technical scenario analysis and effort indicators. Manual technical review, dependency analysis, architecture design and business context still have to be assessed separately, which is the subject of a later section. See SAP's Migration Assessment documentation.

3. Classify every interface

Every interface receives a disposition: retire, retain temporarily, migrate, refactor, rebuild, replace with API, replace with event, or consolidate. This is the step that turns an unmanageable number into a manageable portfolio, and it is covered in detail below.

4. Design the target architecture

Before anything moves, define integration styles, target capabilities, cloud and hybrid requirements, security model, monitoring approach, governance, DevOps and transport, naming and packaging standards, and the support model.

Skipping this is one of the most expensive shortcuts available. Without agreed standards, the first three delivery teams establish three different conventions, and by the time anyone notices there are two hundred integration flows built to inconsistent patterns. Retrofitting standards costs several times what setting them would have.

5. Prioritise migration waves

Group interfaces by complexity, dependency, business criticality, target pattern, connected system, testing availability and the business calendar. A wave should be small enough to complete, coherent enough to test as a unit, and scheduled outside the periods when its business owners cannot tolerate risk.

Big bang cutover is rarely appropriate for a large estate, and rarely achievable at that scale even when it is attempted.

6. Migrate and modernise

Now the actual work. Migration tooling handles supported patterns, manual migration covers what the tooling cannot, and redesign applies where the disposition was refactor, rebuild, API or event.

These three tracks have different skill profiles and different velocities. Planning them as one undifferentiated stream is how migration schedules slip.

7. Test, cut over, and operate

Regression testing, business validation, performance testing, parallel running where the risk justifies it, cutover, rollback planning, monitoring, operational handover, and decommissioning the old scenarios.

The migration is not finished when the integration flows are deployed. It is finished when the new integrations run reliably in production and the team supporting them can resolve an incident without calling the project team. Decommissioning matters too: an estate that never switches off the old platform pays for both indefinitely.

How SAP Migration Assessment works

Conceptually the workflow is four steps. Connect to the Process Orchestration system, extract scenario metadata, evaluate the extracted scenarios, and estimate the potential technical migration effort.

What Migration Assessment can identify

• Extraction of integration scenarios from the PO system

• Evaluation of those scenarios against migration criteria

• An estimate of potential technical migration effort

• Categorisation of scenarios by technical migration suitability

For a large estate this is genuinely valuable. Producing the same technical picture by hand across several hundred scenarios takes weeks that can be spent on the parts a tool cannot do.

What Migration Assessment cannot fully assess

This section matters more than the previous one, because the gap between what the tool reports and what the migration actually requires is where estimates go wrong.

SAP documents limitations in several areas, including custom adapter internals, custom adapter modules, B2B, BRM and BPM logic, recursive Java, XSLT and function dependencies, and certain interface relationships and dependencies.

Beyond the documented technical limits, four things no automated assessment can supply:

• Business process understanding. What the interface is for, and what breaks if it stops

• Dependency mapping. Which interfaces silently depend on each other through shared data or sequencing

• Business criticality. Technical complexity and business risk are different axes and frequently uncorrelated

• Target architecture design. A tool assesses what exists. It has no opinion on what should exist

Automated assessment is the beginning of migration analysis, not the whole of it. Treat the output as a starting inventory with an effort indicator, not as a plan.

How much of PI/PO migration can be automated?

More than nothing and considerably less than the number in the slide deck.

SAP's migration tooling is pattern-based. It converts supported PI/PO objects into integration flows, which means suitability is determined per scenario rather than across the estate. Scenarios built from supported patterns and components convert with less effort. Scenarios that depend on components outside that supported set, such as custom adapter modules or certain orchestration logic, require more manual work.

The supported component and pattern list has expanded over time and continues to, so it is worth checking SAP's current Integration Suite documentation for supported patterns and components against your own scenarios rather than relying on a general rule.

The useful framing is that automation is an accelerator, not a substitute for architecture analysis. It reduces the effort on the interfaces that were going to be straightforward anyway. It does not reduce the effort on the interfaces that were going to be difficult, and those are the ones that determine the timeline.

Which is why any migration estimate expressed as a single automation percentage should be treated with suspicion. The meaningful number is not what proportion of objects convert. It is what proportion of your effort sits in the objects that do not.

Should you migrate PI/PO interfaces 1:1?

Not automatically. An estate of 800 interfaces is not 800 migrations. It is a portfolio, and portfolios are managed by classification.

A recurring pattern in these inventories is threefold. Interfaces built for a business process that has since changed or ended. Duplicated interfaces moving substantially the same data, built by different teams years apart. And interfaces whose consuming system was decommissioned without anyone switching off the feed.

A one-to-one migration carries all three forward and pays cloud consumption to host them. The classification step is where a large estate becomes a smaller one, and it is often one of the highest-return activities in the whole assessment.

The counterweight is worth stating too. Redesigning everything is its own failure mode. Every interface that changes pattern needs new testing, new documentation and new operational knowledge, and a programme that modernises indiscriminately will run out of budget before it runs out of interfaces. Migrate the simple things simply. Spend the redesign effort where the architecture actually improves.

How to prioritise a large PI/PO landscape

Five dimensions, weighed together rather than in sequence:

• Technical complexity. Custom code, adapters, mapping depth, orchestration

• Business criticality. What the business loses per hour if this interface is down

• Dependency level. How many other interfaces or systems are coupled to it

• Migration readiness. Documentation quality, test data availability, an owner who answers

• Business timing. Quarter end, peak season, stock count, regulatory reporting windows

A common instinct is to start with the most business-critical interfaces because they matter most. That is usually backwards. Early waves should build the team's confidence and establish the standards, which argues for interfaces that are well documented, moderately complex and low enough risk to survive a mistake. Critical interfaces move once the patterns are proven.

Common SAP PI/PO migration challenges

• Custom mappings and Java code. Frequently undocumented, occasionally written by someone who left years ago

• Unsupported or specialised adapters. Each one is a separate design decision, not a conversion task

• BPM, ccBPM and B2B complexity. Orchestration logic rarely maps cleanly to a different platform's model

• Hidden interface dependencies. Sequencing and shared data assumptions that exist nowhere except in behaviour

• Weak documentation. The reason most discovery phases run longer than planned

• Test data availability. Often the actual constraint on migration pace, and almost never in the initial plan

• Operational differences. Monitoring, alerting and error handling work differently, and operations teams need retraining

• Skill transition. PI/PO developers do not become Cloud Integration developers over a weekend

• Migrating technical debt. Costly precisely because it succeeds. The interfaces move, and so does everything wrong with them

How should PI/PO migration be tested?

Testing is where migrations are actually validated or quietly not validated, and it deserves more planning than it usually gets.

Regression testing establishes that the migrated interface behaves as the original did. This is harder than it sounds when the original's behaviour was never specified, only observed. Business validation confirms the outcome is correct from the process owner's perspective rather than the developer's. Performance testing matters wherever volumes are significant, because a pattern that behaved acceptably on-premise will not necessarily behave the same way in a cloud runtime.

Parallel validation, where both platforms handle the same traffic and outputs are compared, is one of the strongest validation approaches where it is technically safe. That qualifier matters. Genuine dual processing of production transactions can cause duplicate postings and other side effects, so it is not universally appropriate.

Distinguish the variants before planning it. Shadow or replay testing feeds copied traffic through the new implementation without committing the result. Differential testing compares outputs from both platforms offline. Dual processing of live production transactions is the strongest and the riskiest, and for transactional flows it often should not be attempted at all. Reserve whichever variant is safe for interfaces where the cost of being wrong justifies the effort, which usually means financial, regulatory or customer-facing flows.

The recurring constraint is test data. Production-like data is often unavailable for good reasons, and synthetic data does not exercise the edge cases that break interfaces. Identify this early, because it will shape the schedule whether or not it appears in the plan.

How long does SAP PI/PO migration take?

There is no honest single answer, and any figure quoted without seeing the estate is a sales number rather than an estimate.

What can be said usefully is which variables drive the duration:

• Interface count, and more importantly the distribution of complexity across it

• The proportion of custom code, custom adapters and BPM content

• Documentation quality, which determines how long discovery takes

• Test data availability and testing capacity

• How many interfaces are being redesigned rather than migrated

• Team size and whether the skills exist internally

• Business calendar constraints on when cutover is permitted

Two estates with the same interface count can differ by a factor of several on all of these, which is why a benchmark drawn from someone else's programme is close to worthless for planning yours. What does hold generally is the relationship between the phases: organisations that compress discovery and assessment to accelerate delivery tend to find the time reappears later, with interest.

What should a PI/PO migration assessment include?

For an enterprise migration assessment, IGT recommends covering eight areas. This is our recommended framework rather than an SAP-defined standard, and automated tooling contributes to only part of it.

• Platform. Current version, patch level, landscape, sizing, hosting

• Interfaces. Full inventory with volumes, patterns, adapters and owners

• Connectivity. Protocols, endpoints, certificates, network paths, on-premise reach

• Development. Custom code, mappings, adapter modules, BPM and B2B content

• Business context. What each interface supports and what its failure costs

• Operations. Monitoring, alerting, incident handling, support ownership, SLAs

• Target architecture. Integration styles, capability selection, standards, governance

• Migration planning. Dispositions, waves, effort, dependencies, risks

An assessment proposal covering only the first four is closer to a technical inventory than a migration assessment. The difference tends to show up later as scope change.

When should organisations start planning their PI/PO migration?

If the estate is large and nothing has started, now is reasonable, and that is a scheduling observation rather than a sales line.

Work backwards through the sequence rather than forwards from today. Discovery and assessment comes first. Target architecture design and standards take longer than teams expect, because they require agreement rather than only analysis. Migration then runs in waves. Testing and validation extend the tail beyond the last wave, and decommissioning happens after that.

Against a 2027 mainstream maintenance date, a large estate that has not started discovery is already working to a compressed timeline. Against 2030 with extended maintenance, there is more room, but extended maintenance is optional and typically paid, which makes it a budget decision as well as a technical one.

The organisations that handle this well tend to be the ones that separated assessment from commitment. Understanding the estate is useful regardless of what you decide to do about it, and it is cheap relative to the decisions it informs.

How IGT approaches integration modernisation

Seven steps, matching the stages above: discover, assess, design, prioritise, migrate and modernise, validate, operate.

What shapes our view is that we work across platforms rather than one. Our integration delivery experience spans SAP and webMethods environments, which means the question we start from is not "how do we move this to the platform we sell" but "what should this estate look like, and what is the least disruptive route there".

Sometimes that answer is a full migration. Sometimes it is a partial migration with deliberate coexistence, where SAP-centric application integration moves to Integration Suite while B2B, EDI and managed file transfer stay where they already work well. Our published SAP and MES integration case study, covering one SAP ECC core, five factories, two MES platforms and 41 integration points, was delivered on webMethods Integration Server rather than Integration Suite. We include it because it shows the scale of heterogeneous estate we work in, not as an Integration Suite reference.

Conclusion

A SAP PI/PO migration is a portfolio decision before it is a technical one. The estate has to be understood, every interface has to receive a disposition, and the target architecture has to be designed before conversion begins, because conversion is the step that locks in whatever was decided beforehand.

Automation helps and it helps unevenly. It accelerates the interfaces that were already going to be straightforward, which means the timeline is set by the ones it cannot touch.

And migration ends later than most plans assume. Not when the integration flows deploy, but when they run reliably in production, the support team can handle an incident unaided, and the old scenarios have actually been switched off.

Planning a PI/PO migration and want a view of what is actually in your estate before committing to a route? Our SAP integration services team can support architecture and migration assessment.

See also: What is SAP Integration Suite?  ·  What is SAP BTP?  ·  SAP Integration Suite architecture

Sources

•      SAP: Product maintenance strategy and Product Availability Matrix