A practical guide to migrating from SAP PI/PO to SAP Integration Suite for UK businesses, covering assessment, planning, redesign, costs, and implementation.
SAP Process Integration (PI) and SAP Process Orchestration (PO) have been central to enterprise integration landscapes for years. They connect SAP applications with third-party systems, suppliers, customers, banks, logistics platforms, e-commerce applications and legacy environments.
For UK businesses still running SAP PI/PO, the strategic question is no longer simply whether the integration landscape will eventually need to change.
It is:
How can we migrate from SAP PI/PO to a modern integration architecture without disrupting critical business processes?
For SAP Process Orchestration 7.5, mainstream maintenance ends on 31 December 2027. SAP provides an optional extended-maintenance period through 31 December 2030, with no further extension currently planned beyond that point.
This does not mean that every PI/PO interface needs to be migrated immediately.
Instead, organisations should use the remaining maintenance window to assess their integration estate and determine which interfaces should be:
Migrated → Redesigned → Consolidated → Retired → Replaced
For many organisations, the strategic direction will be:
SAP PI/PO → SAP Integration Suite
However, successful migration is not simply a technical conversion. It is an opportunity to simplify the integration landscape, reduce technical debt, modernise connectivity and align integration architecture with the organisation's SAP and non-SAP roadmap.
The maintenance timeline is one of the first things organisations should understand when planning a migration.
| Milestone | Date | What it means |
| SAP PO 7.5 mainstream maintenance | 31 December 2027 | End of mainstream maintenance |
| Optional extended maintenance | Until 31 December 2030 | Additional transition window |
| Beyond 2030 | No further extension currently planned | Organisations should have a supported target architecture |
The end of mainstream maintenance does not mean that SAP PI/PO automatically stops working on 1 January 2028.
However, it changes the maintenance position and increases the strategic and operational risk of continuing to depend on the platform.
For organisations with a significant PI/PO estate, the objective should therefore be to establish the target architecture, migration roadmap and governance model well before the final maintenance deadline.
The two dates should not be treated as equivalent milestones.
31 December 2027
→ End of mainstream maintenance for PI/PO 7.5.
31 December 2030
→ End of the optional extended-maintenance period.
Businesses that choose extended maintenance may gain additional time to complete migration. However, using that period does not remove the need for a target architecture and decommissioning plan.
The practical question is therefore not:
"Can we keep PI/PO until 2030?"
It is:
"What work needs to be completed before we can safely retire PI/PO?"
SAP Process Integration (PI) and SAP Process Orchestration (PO) are SAP integration technologies used to connect applications and exchange business information across enterprise landscapes.
They have commonly been used for integrations between:
PI/PO environments may contain hundreds of interfaces built over many years.
As a result, an organisation's PI/PO landscape is often more than a middleware platform. It can contain critical business logic, mappings, transformations, routing rules, partner integrations and operational dependencies.
This is why migration should begin with assessment, not technology replacement.
SAP PI/PO migration is the process of assessing an existing integration landscape and moving the required integration capabilities to a supported target architecture, typically involving SAP Integration Suite.
A mature migration approach does not simply copy existing interfaces.
It determines whether each integration should be:
The objective is to migrate business capabilities, rather than simply reproduce historical middleware objects.
SAP Integration Suite is SAP's strategic cloud-based integration platform within SAP Business Technology Platform (SAP BTP).
It supports integration across SAP and non-SAP environments and provides capabilities for:
SAP positions Integration Suite as the target platform for customers transitioning from Process Orchestration.
The transition also represents a broader architectural shift.
SAP ERP / S/4HANA
↓
SAP PI/PO
↓
SAP and non-SAP applications
SAP S/4HANA
↓
SAP Integration Suite
↓
APIs / Events / B2B / Standard Integrations
↓
SAP and Non-SAP Applications
The objective should not be to recreate the PI/PO runtime in a different environment.
The objective is to create a more flexible integration architecture that can support APIs, events, external partners, cloud applications and hybrid enterprise landscapes.
The transition is more than a change of middleware technology.
| SAP PI/PO | SAP Integration Suite |
| Primarily associated with traditional SAP and on-premise integration landscapes | Cloud-based integration platform within SAP BTP |
| Strongly message- and middleware-oriented | Broader platform covering application, API, B2B and event-driven integration |
| Existing environments may contain significant custom logic | Opportunity to simplify and modernise integration logic |
| Customer infrastructure and platform management are significant considerations | Cloud operating model |
| Often developed around individual interfaces | Supports reusable integration patterns and APIs |
| Commonly found in legacy SAP-centric landscapes | Designed for SAP and non-SAP hybrid environments |
The key change is therefore architectural, not simply technological.
No.
This is one of the most important principles of a PI/PO migration.
An organisation with 500 existing interfaces does not necessarily need 500 equivalent interfaces in Integration Suite.
Every interface should first be assessed against the underlying business process.
A practical classification is:
| Decision | When it makes sense |
| Migrate | The interface is still required and its current integration pattern remains appropriate |
| Redesign | The business requirement remains but the integration pattern should change |
| Consolidate | Several interfaces can be replaced by a reusable capability |
| Retire | The interface or business process is no longer required |
| Replace | A standard integration or supported mechanism already exists |
This approach can significantly reduce the size and complexity of the target integration estate.
Do not migrate interfaces simply because they exist. Migrate the business capabilities that still matter.
There is no universal percentage because every estate is different.
However, for initial planning purposes, organisations can use a classification assumption such as:
These are planning assumptions, not SAP benchmarks. A highly customised or poorly documented estate may have a very different profile.
The purpose of the exercise is to avoid assuming:
500 PI/PO interfaces = 500 Integration Suite interfaces.
A good assessment should establish the actual numbers for each category before the migration programme is scoped.
A structured SAP PI/PO migration assessment should be the starting point for a large migration programme.
SAP provides Migration Assessment capabilities for supported Process Orchestration environments to help analyse integration scenarios and estimate migration effort.
However, technical analysis alone is not enough.
The organisation also needs to understand business ownership, criticality, dependencies and the future application landscape.
For each interface, assess:
Also identify:
The assessment should answer:
Which integrations are business-critical, which are technically complex, and which are candidates for redesign or retirement?
A useful assessment should produce more than an interface inventory.
For a typical UK enterprise, an assessment may take approximately 4–8 weeks, depending on the size and quality of the existing documentation and technical access.
The output should include:
The assessment should ultimately allow the organisation to answer:
What should we migrate, what should we change, what should we retire, how much will it cost and in what order should we do it?
Not every interface presents the same migration risk.
A relatively simple scenario might be:
SAP → Standard Mapping → SAP
A more complex scenario could be:
SAP → PI/PO → Custom Mapping → EDI → External Partner → Third-Party Platform → Confirmation → SAP
A migration assessment should therefore consider several dimensions.
Review:
Identify interfaces supporting:
Assess:
Map:
Analyse:
A useful prioritisation model is:
Business Criticality × Technical Complexity × Migration Readiness
This helps distinguish quick wins from migrations that require detailed redesign and business involvement.
Customisation is often one of the biggest sources of migration complexity.
Organisations should review:
For every custom component, ask:
Is this still required?
If yes:
Can SAP standard functionality replace it?
If not:
Can the requirement be implemented more cleanly in Integration Suite or another appropriate layer?
And finally:
Should this logic exist in the integration layer at all?
The preferred sequence should be:
Retire → Simplify → Redesign → Rebuild
rather than:
Copy → Convert → Maintain
This is one of the biggest opportunities to reduce technical debt during PI/PO modernisation.
Migration tooling can accelerate the transition, but tooling should not determine the target architecture.
SAP provides assessment and migration capabilities for supported PI/PO scenarios. These capabilities can help organisations identify migration readiness and estimate technical effort.
However, a migration assessment category such as "ready to migrate" should not be interpreted as "no work is required".
Migrated content still needs to be reviewed and tested.
The key question is therefore not:
Which PI/PO objects can we migrate?
It is:
Which integration pattern is appropriate for this business process?
The target architecture should be based on:
Business Requirement + Latency + Volume + Reliability + Security + Lifecycle + Ownership
rather than simply reproducing historical PI/PO patterns.
APIs can be appropriate for controlled application-to-application interactions and reusable services.
Typical scenarios include:
Events can be appropriate when multiple applications need to react to a business event.
For example:
Order confirmed
↓
Event published
↓
Warehouse updated
↓
Customer notified
↓
Analytics updated
Event-driven architectures require appropriate governance around:
B2B integration remains important for:
Modernisation does not necessarily mean eliminating EDI.
Instead, organisations can modernise how B2B processes are managed while preserving required partner connectivity.
Batch integration can remain appropriate for certain high-volume or non-real-time processes.
The objective is not to replace every historical pattern with an API.
The objective is to select the simplest appropriate pattern for the business requirement.
Where SAP or another application already provides a suitable supported integration mechanism, it may be better to use it rather than maintain a custom PI/PO interface.
PI/PO modernisation is often closely connected with an organisation's S/4HANA roadmap.
For example:
ECC → S/4HANA
while:
PI/PO → Integration Suite
and:
Legacy Interfaces → APIs / Events / Standard Integrations
These programmes do not necessarily have to be delivered simultaneously.
However, their dependencies should be assessed together.
An interface connected to an ECC process may no longer be required after an S/4HANA transformation.
Alternatively, the interface may need to be redesigned because the underlying SAP business process or data model has changed.
Migrating that interface before the future ERP architecture is understood can create unnecessary rework.
Organisations should therefore identify:
Which PI/PO interfaces will change because of the S/4HANA transformation?
before finalising migration waves.
A PI/PO migration should not be treated as an SAP-only project.
PI/PO environments often contain critical connections to:
The target architecture therefore needs to support both:
SAP-to-SAP
and:
SAP-to-non-SAP
integration.
This is particularly important for UK enterprises where SAP is only one component of the wider technology landscape.
A successful migration should therefore be treated as an enterprise integration transformation, rather than simply an SAP middleware upgrade.
A practical migration lifecycle is:
Inventory → Assess → Rationalise → Prioritise → Redesign → Migrate → Test → Cut Over → Decommission
Create a complete PI/PO inventory.
Document:
Evaluate:
Identify:
Group interfaces into logical migration waves based on:
Business Criticality × Technical Complexity × Migration Readiness
Select the appropriate target integration pattern.
Move or rebuild eligible integrations in Integration Suite.
Validate both technical and business outcomes.
Move production traffic to the target architecture.
Retire PI/PO components after dependencies have been removed and the target environment is stable.
The timeline depends heavily on the number and complexity of interfaces.
For planning purposes, a UK organisation might consider the following indicative ranges:
| Programme component | Indicative duration |
| Initial assessment | 4–8 weeks |
| Architecture and migration planning | 4–8 weeks |
| Pilot | 6–12 weeks |
| Simple migration wave | 2–4 months |
| Medium enterprise programme | 6–18 months |
| Large / highly customised estate | 18–36+ months |
These are planning ranges, not guaranteed delivery timelines.
A programme involving 300 relatively simple interfaces can be faster than one involving 80 heavily customised integrations with EDI partners, complex mappings and mission-critical business processes.
The most important factor is therefore not simply interface count.
It is the combination of:
Volume + Complexity + Business Criticality + Dependencies + Customisation
A large integration estate should rarely be migrated in a single wave.
A possible approach is:
Use relatively simple integrations to establish:
Migrate important integrations after the target architecture and operating model have been validated.
Handle:
Retire, replace, consolidate or migrate remaining interfaces.
The purpose of the wave model is not simply to divide the workload.
It is to make every subsequent migration more predictable by incorporating lessons from previous waves.
There is no single SAP PI/PO migration price because the scope can range from a small technical migration to a multi-year enterprise integration transformation.
However, for early UK budget planning, indicative programme ranges can be useful:
| Estate / programme profile | Indicative migration budget |
| Small, relatively simple estate | £50k–£150k |
| Medium estate | £150k–£400k |
| Large / complex enterprise estate | £400k–£1m+ |
| Very large, highly customised or multi-country programme | £1m–£2m+ |
These figures should be treated as order-of-magnitude planning ranges, not quotations or SAP pricing.
They may exclude or separately account for:
For initial planning, organisations may also use approximate ranges such as:
| Interface type | Indicative delivery cost |
| Simple | £2k–£5k |
| Medium complexity | £5k–£15k |
| Complex / custom / EDI | £15k–£40k+ |
These figures should not be multiplied mechanically by the number of interfaces.
A migration programme also includes:
Conversely, consolidation and retirement can reduce the number of interfaces that actually need to be rebuilt.
For example, an estate of 300 interfaces may ultimately require only 180 migrations if the remaining interfaces can be retired, consolidated or replaced.
The biggest cost drivers are usually:
The most reliable way to establish a budget is therefore to complete the assessment first and build the programme estimate from the actual estate.
The team required depends on programme size.
A small pilot may be delivered with approximately 3–6 core specialists, for example:
A larger enterprise migration may require 10–25+ people across multiple workstreams, including:
The team should scale with the number of migration waves and external dependencies rather than simply the number of interfaces.
An interface should not be considered successfully migrated simply because it can send and receive a message.
Testing should cover:
For example:
Sales Order
↓
Integration Suite
↓
Warehouse
↓
Transportation
↓
Carrier
↓
Delivery Confirmation
The test should validate the complete business process rather than only individual message delivery.
For high-volume integrations, performance and peak-load testing should also be included.
Critical external integrations should be tested with realistic partner scenarios wherever possible.
Moving from PI/PO to Integration Suite also changes how integration operations are managed.
Before migration, define:
The target operating model should include:
Technical monitoring alone is not enough.
A message can be technically delivered while the underlying business transaction still fails.
The organisation therefore needs both:
Technical Monitoring
and:
Business-Process Monitoring
For critical processes, useful KPIs may include:
The business case should not be based solely on avoiding an unsupported platform.
Potential benefits include:
The financial case should compare the current integration operating model with the expected target state.
Useful baseline metrics include:
The migration assessment can then provide the basis for an ROI and total-cost-of-ownership model.
It is better to build the business case from these actual numbers than to promise a generic percentage reduction.
PI/PO modernisation can also form part of a broader SAP Clean Core strategy.
As organisations move to S/4HANA, they increasingly need to separate:
A modern architecture can therefore evolve from:
ECC + PI/PO + Custom Integrations
to:
S/4HANA + Integration Suite + APIs / Events + BTP Extensions
The transition provides an opportunity to reconsider where custom logic belongs rather than continuing to place business logic inside the integration layer.
A modern integration architecture should support a stable SAP core while allowing external applications and integration capabilities to evolve independently.
Existing interfaces are treated as requirements rather than assets to be assessed.
Better approach: rationalise the estate before migration.
The organisation recreates the same point-to-point complexity on the new platform.
Better approach: introduce reusable patterns, APIs, events and standard integrations where appropriate.
Legacy mappings and scripts are reproduced without questioning whether they are still required.
Better approach: retire, simplify or redesign custom logic.
Technical teams migrate interfaces without understanding the processes they support.
Better approach: assign business and technical ownership to critical integrations.
Interfaces are migrated before the future ERP architecture is understood.
Better approach: align PI/PO and S/4HANA roadmaps.
Migration issues appear only during business-critical cutover.
Better approach: test every migration wave and validate complete business processes.
Supplier, carrier, bank and customer integrations can be more difficult to migrate than internal SAP interfaces.
Better approach: involve external partners early and include their dependencies in the migration plan.
PI/PO and Integration Suite remain operational without a defined decommissioning strategy.
Better approach: define exit criteria for every migration wave.
A complex migration programme starts when the mainstream-maintenance deadline is already close.
Better approach: use 2026 to establish the target architecture and migration roadmap.
For some organisations, temporarily retaining PI/PO may be justified.
This may include businesses that are:
However, extended maintenance should be treated as a transition window, not as a reason to build new strategic dependencies on PI/PO.
A simple decision framework can help:
| Situation | Recommended approach |
| Fewer than 50 relatively simple interfaces | Begin assessment and consider a focused migration programme |
| 50–200 interfaces | Start assessment and migrate in controlled waves |
| 200–500 interfaces | Begin architecture and rationalisation early; expect a multi-phase programme |
| 500+ interfaces | Treat migration as an enterprise integration transformation |
| Heavy customisation or EDI | Start assessment as early as possible |
| Major S/4HANA programme underway | Align the integration and ERP roadmaps |
| Low-risk, stable estate | Extended maintenance may provide additional transition time |
| Significant PI/PO skills dependency | Start migration planning early to reduce future operational risk |
The better question is not:
How long can we keep PI/PO?
It is:
What integration architecture do we want after PI/PO, and what needs to happen to get there?
For organisations still running PI/PO 7.5, the remaining maintenance window should be treated as a structured transition period.
Inventory:
Run the appropriate SAP assessment activities.
Establish:
Retire obsolete integrations and migrate or redesign business-critical interfaces in controlled waves.
Complete critical migrations, validate the operating model and reduce dependency on PI/PO.
The organisation should have an operational target architecture and a clear transition plan rather than relying on PI/PO as its strategic integration platform.
Where extended maintenance is selected, use the additional period only for justified remaining transition work and final decommissioning.
The exact timeline depends on the size and complexity of the integration estate.
The important point is to start with assessment and target architecture, not technical configuration.
Before beginning migration, organisations should be able to answer:
For UK businesses still running SAP PI/PO, LeverX recommends beginning with a structured migration assessment rather than immediately rebuilding interfaces in Integration Suite.
The assessment should map:
Interfaces → Business Processes → Dependencies → Customisations → Complexity → Criticality → Target Patterns
Each integration can then be classified:
Migrate → Redesign → Consolidate → Retire → Replace
The result should be a prioritised roadmap showing:
For a typical enterprise assessment, the objective should be to move from a vague question such as:
"How do we migrate our PI/PO environment?"
to a quantified plan:
"We have X interfaces, Y are candidates for migration, Z can be retired or consolidated, the highest-risk dependencies are A/B/C, the programme is expected to take approximately N months and the indicative budget is £X–£Y."
That is the level of detail required to turn PI/PO modernisation into an executable programme.
A PI/PO modernisation programme may involve much more than interface migration.
The target architecture may require:
LeverX supports SAP and non-SAP integration initiatives, helping organisations assess existing integration estates, define target architectures and modernise enterprise connectivity.
Explore LeverX SAP Integration Services
Mainstream maintenance for SAP Process Orchestration 7.5 ends on 31 December 2027.
SAP provides an optional extended-maintenance period through 31 December 2030.
No.
The end of mainstream maintenance does not mean that PI/PO automatically stops functioning. It marks a change in the maintenance position.
Organisations should nevertheless establish a supported target integration architecture before the end of mainstream maintenance.
SAP provides an optional extended-maintenance period for PI/PO 7.5 through 31 December 2030.
Organisations should treat this as additional transition time rather than a long-term integration strategy.
SAP positions Integration Suite as the strategic target for customers transitioning from Process Orchestration.
However, the migration should not be treated as a one-to-one technical replacement of every existing interface.
SAP PI and PO are older SAP integration technologies associated with NetWeaver-based environments.
SAP Integration Suite is a broader cloud-based integration platform within SAP BTP supporting application integration, APIs, B2B, event-driven architectures and hybrid SAP/non-SAP integration.
SAP Cloud Platform Integration (CPI) was the earlier terminology commonly used for SAP's cloud integration capability.
The current strategic platform is SAP Integration Suite, which includes Cloud Integration alongside other integration capabilities.
As a result, organisations may encounter both "SAP CPI migration" and "SAP PI/PO to Integration Suite migration" in the market, but they refer to different generations of SAP integration technology.
No.
SAP provides Migration Assessment and Migration Tooling for supported scenarios, but migration readiness depends on the individual integration content.
Migrated content should also be reviewed and tested.
No.
Some interfaces should be migrated, others redesigned or consolidated, while obsolete integrations should be retired.
A PI/PO migration assessment is a structured analysis of the existing integration landscape designed to evaluate:
SAP's assessment capabilities can support the technical analysis of supported Process Orchestration scenarios.
A small assessment may take approximately 4–8 weeks.
A pilot may take 6–12 weeks.
A medium enterprise migration can take approximately 6–18 months, while a large or highly customised estate may require 18–36+ months.
The actual timeline depends on complexity, business criticality, external dependencies and the number of migration waves.
Businesses with significant PI/PO dependencies should begin assessment and target-architecture work well before the end of mainstream maintenance in 2027.
Large or highly customised estates should start particularly early.
No.
The programmes can be managed independently.
However, organisations planning an ECC-to-S/4HANA transformation should assess both roadmaps together because changes in the ERP landscape can affect existing integration requirements.
Yes.
SAP Integration Suite is designed to support SAP and non-SAP applications and hybrid enterprise landscapes.
As an early UK planning estimate:
These are indicative programme ranges, not fixed prices. SAP licensing, BTP consumption, third-party costs and internal resources may be additional.
A migration assessment is the best way to establish a more reliable budget.
SAP's current roadmap does not extend PI/PO 7.5 maintenance beyond the end of 2030.
Organisations should therefore establish a supported target architecture before that date rather than build further strategic dependencies on PI/PO.
The SAP PI/PO maintenance deadline is more than a technology-support milestone.
For UK businesses, it is an opportunity to reconsider how enterprise integration should operate in the next phase of the SAP roadmap.
SAP Process Orchestration 7.5 remains in mainstream maintenance through 31 December 2027, with an optional extended-maintenance period through 31 December 2030.
SAP provides assessment and migration capabilities to support the transition to Integration Suite, but successful modernisation requires more than technical migration.
The weakest approach is:
PI/PO → Copy Everything → Integration Suite
A stronger approach is:
Assess → Rationalise → Redesign → Migrate → Test → Stabilise → Decommission
For organisations also moving from ECC to S/4HANA, the PI/PO roadmap should be considered alongside the ERP transformation so that interfaces are not migrated only to be redesigned again later.
The objective is not simply to meet the 2027 maintenance milestone.
It is to create an integration architecture that is:
Modern → Scalable → Governed → Observable → Secure → Ready for Change
For UK organisations, the first practical step is to understand the existing PI/PO estate, establish which integrations still support critical business capabilities, identify technical debt and define the target architecture before migration waves begin.
Assess your SAP PI/PO migration readiness and define the path to SAP Integration Suite.
Disclaimer: Maintenance dates, SAP product capabilities and migration-tool support may change. Cost and timeline figures in this article are indicative planning ranges, not SAP or LeverX quotations. Actual migration scope, effort and cost should be validated through a detailed assessment of the specific PI/PO landscape.