SAP PI/PO End of Support 2027: What UK Businesses Need to Know

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.

SAP PI/PO End of Support: Key Dates

SAP PI/PO End of Support: Key Dates

The maintenance timeline is one of the first things organisations should understand when planning a migration.

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.

2027 vs 2030: What Is the Difference?

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?"

What Is SAP PI/PO?

What Is SAP 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:

• SAP ERP and S/4HANA;
• SAP and non-SAP applications;
• suppliers and customers;
• banks;
• logistics providers;
• WMS and TMS platforms;
• e-commerce applications;
• manufacturing systems;
• legacy applications;
• external partners.

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.

What Is SAP PI/PO Migration?

What Is SAP PI/PO Migration?

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:

• Migrated — the interface remains valid and its existing logic is still appropriate;
• Redesigned — the business requirement remains, but a modern integration pattern is more suitable;
• Consolidated — several similar interfaces can be replaced by a reusable integration pattern;
• Retired — the integration or underlying process is no longer required;
• Replaced — a standard application integration or another supported mechanism makes the existing interface unnecessary.

The objective is to migrate business capabilities, rather than simply reproduce historical middleware objects.

Why Are Businesses Moving From SAP PI/PO to Integration Suite?

Why Are Businesses Moving From SAP PI/PO to Integration Suite?

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:

• application integration;
• API management;
• B2B integration;
• event-driven architectures;
• connectivity;
• integration monitoring;
• partner integration.

SAP positions Integration Suite as the target platform for customers transitioning from Process Orchestration.

The transition also represents a broader architectural shift.

Traditional model

SAP ERP / S/4HANA

↓

SAP PI/PO

↓

SAP and non-SAP applications

Modern target model

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.

SAP PI/PO vs SAP Integration Suite

SAP PI/PO vs SAP Integration Suite

The transition is more than a change of middleware technology.

The key change is therefore architectural, not simply technological.

Should Every PI/PO Interface Be Migrated?

Should Every PI/PO Interface Be Migrated?

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:

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.

SAP PI/PO Migration Assessment: What Should You Analyse?

How Many PI/PO Interfaces Actually Need to Be Migrated?

How Many PI/PO Interfaces Actually Need to Be Migrated?

There is no universal percentage because every estate is different.

However, for initial planning purposes, organisations can use a classification assumption such as:

• 30–50% — potentially straightforward migration candidates;
• 20–40% — likely to require adjustments or redesign;
• 10–30% — potential candidates for retirement, consolidation or replacement.

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.

SAP PI/PO Migration Assessment: What Should You Analyse?

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:

• source system;
• target system;
• business process;
• interface type;
• message format;
• frequency;
• transaction volume;
• synchronous or asynchronous pattern;
• transformation logic;
• adapters;
• dependencies;
• business owner;
• technical owner;
• criticality;
• security requirements;
• monitoring requirements;
• error-handling model.

Also identify:

• unused interfaces;
• duplicate integrations;
• obsolete applications;
• heavily customised mappings;
• Java mappings;
• XSLT transformations;
• custom adapters;
• point-to-point dependencies;
• legacy connections;
• interfaces with poor monitoring;
• integrations with unclear ownership.

The assessment should answer:

Which integrations are business-critical, which are technically complex, and which are candidates for redesign or retirement?

Assess PI/PO Interfaces by Complexity and Business Criticality

What Should a PI/PO Migration Assessment Deliver?

What Should a PI/PO Migration Assessment Deliver?

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:

• complete PI/PO interface inventory;
• business-process mapping;
• technical complexity classification;
• business-criticality assessment;
• dependency map;
• customisation analysis;
• Migrate / Redesign / Consolidate / Retire / Replace classification;
• recommended target integration pattern;
• migration readiness;
• estimated effort;
• key risks;
• migration waves;
• target Integration Suite architecture;
• indicative programme budget.

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?

Assess PI/PO Interfaces by Complexity and Business Criticality

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.

Technical Complexity

Review:

• custom mappings;
• Java mappings;
• XSLT;
• adapters;
• scripts;
• custom components.

Business Criticality

Identify interfaces supporting:

• financial processes;
• order processing;
• supply chain;
• warehouse operations;
• customer-facing processes;
• regulatory processes.

Operational Complexity

Assess:

• monitoring;
• retries;
• reconciliation;
• alerting;
• support ownership;
• service levels.

Integration Dependencies

Map:

• upstream systems;
• downstream systems;
• external partners;
• batch processes;
• APIs;
• legacy platforms.

Volume and Performance

Analyse:

• message frequency;
• peak transaction volumes;
• large payloads;
• processing-time requirements;
• peak-period behaviour.

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.

What Should You Do With Custom PI/PO Logic?

What Should You Do With Custom PI/PO Logic?

Customisation is often one of the biggest sources of migration complexity.

Organisations should review:

• custom mappings;
• Java mappings;
• XSLT;
• custom adapters;
• scripts;
• custom monitoring;
• business logic embedded in integrations.

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.

SAP PI/PO Migration Tools: What Can Be Automated?

SAP PI/PO Migration Tools: What Can Be Automated?

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?

Which Integration Pattern Should Replace PI/PO?

Which Integration Pattern Should Replace PI/PO?

The target architecture should be based on:

Business Requirement + Latency + Volume + Reliability + Security + Lifecycle + Ownership

rather than simply reproducing historical PI/PO patterns.

APIs

APIs can be appropriate for controlled application-to-application interactions and reusable services.

Typical scenarios include:

• application integration;
• customer portals;
• cloud applications;
• reusable business services.

Event-Driven Integration

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:

• event ownership;
• event definitions;
• ordering;
• retries;
• idempotency;
• monitoring;
• failure handling.

B2B and EDI

B2B integration remains important for:

• suppliers;
• customers;
• retailers;
• carriers;
• banks;
• logistics partners.

Modernisation does not necessarily mean eliminating EDI.

Instead, organisations can modernise how B2B processes are managed while preserving required partner connectivity.

Batch Integration

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.

Standard Application Integrations

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.

SAP PI/PO Migration and S/4HANA

SAP PI/PO Migration and S/4HANA

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.

PI/PO Integration With Non-SAP Systems

PI/PO Integration With Non-SAP Systems

A PI/PO migration should not be treated as an SAP-only project.

PI/PO environments often contain critical connections to:

• Microsoft applications;
• Salesforce;
• Oracle;
• Workday;
• MES;
• WMS;
• TMS;
• e-commerce platforms;
• banking systems;
• tax platforms;
• logistics providers;
• customer platforms;
• supplier systems;
• legacy applications.

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.

SAP PI/PO Migration Roadmap

SAP PI/PO Migration Roadmap

A practical migration lifecycle is:

Inventory → Assess → Rationalise → Prioritise → Redesign → Migrate → Test → Cut Over → Decommission

1. Inventory

Create a complete PI/PO inventory.

Document:

• interfaces;
• systems;
• business processes;
• owners;
• dependencies;
• customisations.

2. Assess

Evaluate:

• technical complexity;
• business criticality;
• dependencies;
• migration readiness;
• operational requirements.

3. Rationalise

Identify:

• obsolete interfaces;
• duplicate integrations;
• unused processes;
• legacy applications;
• unnecessary custom logic.

4. Prioritise

Group interfaces into logical migration waves based on:

Business Criticality × Technical Complexity × Migration Readiness

5. Redesign

Select the appropriate target integration pattern.

6. Migrate

Move or rebuild eligible integrations in Integration Suite.

7. Test

Validate both technical and business outcomes.

8. Cut Over

Move production traffic to the target architecture.

9. Decommission

Retire PI/PO components after dependencies have been removed and the target environment is stable.

How Long Does SAP PI/PO Migration Take?

The timeline depends heavily on the number and complexity of interfaces.

For planning purposes, a UK organisation might consider the following indicative ranges:

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

SAP PI/PO Migration Waves

SAP PI/PO Migration Waves

A large integration estate should rarely be migrated in a single wave.

A possible approach is:

Wave 1 - Lower-Complexity Interfaces

Use relatively simple integrations to establish:

• migration methodology;
• development standards;
• testing approach;
• monitoring;
• support processes.

Wave 2 - Core Business Processes

Migrate important integrations after the target architecture and operating model have been validated.

Wave 3 - Complex and Business-Critical Integrations

Handle:

• high-volume interfaces;
• EDI;
• custom mappings;
• multi-system scenarios;
• critical external dependencies.

Wave 4 - Remaining Legacy Estate

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.

How Much Does SAP PI/PO Migration Cost?

How Much Does SAP PI/PO Migration Cost?

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:

These figures should be treated as order-of-magnitude planning ranges, not quotations or SAP pricing.

They may exclude or separately account for:

• SAP Integration Suite licensing;
• BTP consumption;
• third-party tooling;
• external partner costs;
• infrastructure;
• internal employee costs;
• major S/4HANA transformation work;
• extensive business-process redesign.

Indicative Cost Per Interface

For initial planning, organisations may also use approximate ranges such as:

These figures should not be multiplied mechanically by the number of interfaces.

A migration programme also includes:

• assessment;
• architecture;
• reusable patterns;
• testing;
• project management;
• governance;
• security;
• monitoring;
• cutover;
• decommissioning.

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.

What Determines the Final Cost?

The biggest cost drivers are usually:

1. Number of interfaces
2. Technical complexity
3. Custom mappings and code
4. EDI and external partners
5. Business criticality
6. Testing requirements
7. Data volume and performance
8. S/4HANA dependencies
9. Target architecture
10. Number of migration waves

The most reliable way to establish a budget is therefore to complete the assessment first and build the programme estimate from the actual estate.

What Does a PI/PO Migration Team Look Like?

The team required depends on programme size.

A small pilot may be delivered with approximately 3–6 core specialists, for example:

• integration architect;
• PI/PO or Integration Suite developer;
• SAP functional specialist;
• QA/test specialist;
• project management support.

A larger enterprise migration may require 10–25+ people across multiple workstreams, including:

• enterprise/integration architects;
• Integration Suite developers;
• SAP functional consultants;
• PI/PO specialists;
• API specialists;
• B2B/EDI specialists;
• security specialists;
• QA and test engineers;
• business analysts;
• DevOps/operations specialists;
• programme and project management.

The team should scale with the number of migration waves and external dependencies rather than simply the number of interfaces.

How to Test a PI/PO Migration

How to Test a PI/PO Migration

An interface should not be considered successfully migrated simply because it can send and receive a message.

Testing should cover:

• functional correctness;
• mapping;
• data integrity;
• end-to-end business processes;
• error handling;
• retries;
• performance;
• security;
• monitoring;
• reconciliation.

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.

PI/PO Migration Operating Model and Monitoring

PI/PO Migration Operating Model and Monitoring

Moving from PI/PO to Integration Suite also changes how integration operations are managed.

Before migration, define:

• Who owns the integration?
• Who receives alerts?
• Who investigates failures?
• Who communicates business impact?
• Who owns reconciliation?
• Who approves changes?

The target operating model should include:

• interface monitoring;
• failed-message management;
• alerting;
• retry procedures;
• API monitoring;
• security monitoring;
• ownership;
• escalation;
• service-level reporting.

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:

• integration success rate;
• message latency;
• failed messages;
• retry volume;
• unresolved errors;
• reconciliation differences;
• business transactions delayed by integration failures.

What Is the Business Case for PI/PO Modernisation?

What Is the Business Case for PI/PO Modernisation?

The business case should not be based solely on avoiding an unsupported platform.

Potential benefits include:

• reduced infrastructure and platform-management costs;
• lower integration technical debt;
• fewer redundant interfaces;
• faster onboarding of applications and partners;
• improved monitoring and observability;
• reduced dependency on scarce PI/PO skills;
• greater use of reusable APIs and integration patterns;
• simpler support and governance;
• better alignment with S/4HANA and cloud transformation.

The financial case should compare the current integration operating model with the expected target state.

Useful baseline metrics include:

• annual PI/PO infrastructure costs;
• support and maintenance effort;
• number of integration incidents;
• average incident resolution time;
• cost of maintaining custom interfaces;
• number of unused or redundant integrations;
• external support costs;
• specialist PI/PO skills required.

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.

SAP PI/PO Migration and Clean Core

SAP PI/PO Migration and Clean Core

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:

• core ERP processes;
• integration;
• extensions;
• external applications.

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.

How Much Does SAP PI/PO Migration Cost?

Common SAP PI/PO Migration Mistakes

Migrating Everything

Existing interfaces are treated as requirements rather than assets to be assessed.

Better approach: rationalise the estate before migration.

Rebuilding the Existing Architecture

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.

Copying Custom Logic

Legacy mappings and scripts are reproduced without questioning whether they are still required.

Better approach: retire, simplify or redesign custom logic.

Ignoring Business Ownership

Technical teams migrate interfaces without understanding the processes they support.

Better approach: assign business and technical ownership to critical integrations.

Ignoring S/4HANA Dependencies

Interfaces are migrated before the future ERP architecture is understood.

Better approach: align PI/PO and S/4HANA roadmaps.

Leaving Testing Until the End

Migration issues appear only during business-critical cutover.

Better approach: test every migration wave and validate complete business processes.

Underestimating External Dependencies

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.

Running Both Platforms Indefinitely

PI/PO and Integration Suite remain operational without a defined decommissioning strategy.

Better approach: define exit criteria for every migration wave.

Waiting Until 2027

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.

Should You Use SAP PI/PO Extended Maintenance Until 2030?

Should You Use SAP PI/PO Extended Maintenance Until 2030?

For some organisations, temporarily retaining PI/PO may be justified.

This may include businesses that are:

• in the middle of an ECC-to-S/4HANA transformation;
• operating highly complex integration landscapes;
• dependent on heavily customised interfaces;
• managing major business or technology programmes;
• migrating hundreds of integrations in multiple waves;
• constrained by critical external-system dependencies.

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:

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?

SAP PI/PO Migration Timeline: 2026–2030

SAP PI/PO Migration Timeline: 2026–2030

For organisations still running PI/PO 7.5, the remaining maintenance window should be treated as a structured transition period.

2026 - Assess

Inventory:

• PI/PO interfaces;
• dependencies;
• customisations;
• business processes;
• external partners.

Run the appropriate SAP assessment activities.

2026 - Define

Establish:

• target Integration Suite architecture;
• migration principles;
• governance;
• security model;
• monitoring model;
• operating model.

2026–2027 - Rationalise and Migrate

Retire obsolete integrations and migrate or redesign business-critical interfaces in controlled waves.

2027 - Stabilise

Complete critical migrations, validate the operating model and reduce dependency on PI/PO.

31 December 2027

The organisation should have an operational target architecture and a clear transition plan rather than relying on PI/PO as its strategic integration platform.

2028–2030

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.

SAP PI/PO Migration Checklist

Should You Use SAP PI/PO Extended Maintenance Until 2030?

SAP PI/PO Migration Checklist

Before beginning migration, organisations should be able to answer:

Current Landscape

• How many PI/PO interfaces exist?
• Which are actively used?
• Which are business-critical?
• Which contain custom logic?
• Which connect to external partners?

Target Architecture

• What will replace PI/PO?
• Where will APIs be used?
• Where are events appropriate?
• How will B2B and EDI be handled?
• Which standard integrations can replace custom interfaces?

Business Ownership

• Who owns each critical integration?
• Which business process does it support?
• Who approves changes?
• Who owns business reconciliation?

Migration

• Which interfaces should be migrated?
• Which should be redesigned?
• Which can be consolidated?
• Which can be retired?
• Which should be replaced?

Operations

• How will integrations be monitored?
• How will failures be handled?
• How will retries work?
• How will business reconciliation be performed?

S/4HANA

• Which interfaces depend on ECC?
• Which will change after S/4HANA migration?
• Which should be migrated only after the ERP target state is confirmed?

Decommissioning

• What are the exit criteria?
• When can PI/PO components be retired?
• How will remaining dependencies be identified?

LeverX Recommendation: Start With a PI/PO Migration Assessment

LeverX Recommendation: Start With a PI/PO Migration Assessment

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:

• what needs to move;
• what should be redesigned;
• what can be retired;
• which interfaces are high-risk;
• which migration waves should come first;
• what the target Integration Suite architecture should look like;
• indicative programme effort and cost.

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.

LeverX SAP Integration Services in the UK

LeverX SAP Integration Services in the UK

A PI/PO modernisation programme may involve much more than interface migration.

The target architecture may require:

• SAP Integration Suite;
• API management;
• B2B integration;
• event-driven architecture;
• SAP BTP;
• S/4HANA integration;
• non-SAP application connectivity;
• integration monitoring;
• migration assessment;
• integration governance.

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

Frequently Asked Questions

When does SAP PI/PO 7.5 mainstream maintenance end?

Mainstream maintenance for SAP Process Orchestration 7.5 ends on 31 December 2027.

SAP provides an optional extended-maintenance period through 31 December 2030.

Does SAP PI/PO stop working after 2027?

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.

Can SAP PI/PO be supported until 2030?

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.

Is SAP Integration Suite replacing PI/PO?

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.

What is the difference between SAP PI, SAP PO and Integration Suite?

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.

Is SAP CPI the same as SAP Integration Suite?

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.

Can all PI/PO interfaces be migrated automatically?

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.

Should UK businesses migrate every PI/PO interface?

No.

Some interfaces should be migrated, others redesigned or consolidated, while obsolete integrations should be retired.

What is a SAP PI/PO migration assessment?

A PI/PO migration assessment is a structured analysis of the existing integration landscape designed to evaluate:

• technical complexity;
• business criticality;
• dependencies;
• migration readiness;
• target integration patterns;
• estimated effort;
• migration priorities.

SAP's assessment capabilities can support the technical analysis of supported Process Orchestration scenarios.

How long does SAP PI/PO migration take?

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.

When should a UK business start its PI/PO migration?

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.

Does PI/PO migration require an S/4HANA migration?

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.

Can Integration Suite connect non-SAP applications?

Yes.

SAP Integration Suite is designed to support SAP and non-SAP applications and hybrid enterprise landscapes.

How much does a PI/PO migration cost?

As an early UK planning estimate:

• small estates may require approximately £50k–£150k;
• medium estates £150k–£400k;
• large enterprise programmes £400k–£1m+;
• very large or highly customised programmes may exceed £1m–£2m+.

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.

What happens if a business continues using PI/PO after 2030?

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.

Conclusion

Conclusion

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.

Request a free consultation

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.