SAP PI/PO end of support: What the 2027 deadline means for your integration strategy

SAP has set the deadline. PI/PO support ends in 2027. For many organizations, the immediate reaction is to find the fastest migration path and stay within the SAP ecosystem. But that decision, made under time pressure, has consequences that extend well beyond the cutover date.

The forced migration is also a forced decision about what your integration architecture should look like for the next decade. Getting it right matters more than doing it fast.

PI/PO was built for a different world

SAP PI/PO was designed for SAP-centric, on-premises architectures. When it was introduced, most enterprise integration looked like SAP talking to SAP, with a handful of external connections managed through a central middleware layer.

Today's enterprise looks nothing like that. Alongside SAP ECC or S/4HANA, most organizations run a mix of SaaS platforms, cloud services, REST and SOAP APIs, EDI trading partners, legacy databases and on-premises applications. PI/PO was never designed to handle that breadth, and the gap between what it was built for and current business requirements has only grown.

Many organizations have been working around these limitations by building custom adapters and workarounds on top of the platform. Now, the end-of-support deadline will expose the technical debt accumulated in the process.

The default migration path has a long-term cost

SAP Integration Suite is the obvious default for organizations migrating off PI/PO. It solves the deadline problem: it is SAP's own successor product, it supports the migration tooling SAP provides, and it keeps the integration layer within the SAP relationship.

The trade-off is dependency. SAP Integration Suite ties your integration strategy to SAP's licensing model, update cycles and future pricing decisions. For organizations whose integration landscape is primarily SAP-to-SAP, that dependency may be an acceptable cost. For organizations with significant non-SAP integration needs, which describes most large enterprises today, it means solving a deadline problem while creating a strategic one.

Licensing costs for cloud-based SAP tools have a track record of increasing over time. Locking the integration layer into that model before understanding the long-term pricing trajectory is a risk that should be  examined carefully.

Most organizations underestimate what they have in their PI/PO landscape: hundreds of interfaces; limited documentation; institutional knowledge held by a small number of specialists who may or may not still be with the organization. 

A migration done under deadline pressure, without a structured approach to interface inventory and dependency mapping, trades one risk for another.

Migration as a business opportunity

SAP integrations touch orders, invoices, logistics, manufacturing and financial data. A disruption to any of those flows during migration has immediate operational consequences. The urgency created by the 2027 deadline can push organizations toward approaches that compress testing, reduce parallel running time, or skip steps in validation — all of which increase the risk of exactly the kind of failure the migration is meant to avoid.

A PI/PO migration done right starts with the interface inventory early, building a phased migration plan that keeps legacy connections live until replacements are validated, and ensuring that monitoring is in place before the cutover, not after an incident occurs.

The migration is an opportunity to address the limitations that have accumulated in the PI/PO environment, instead of simply replacing them with a different vendor's version of the same constraints.

The integration architecture that makes sense for most large enterprises after 2027 has a few clear characteristics.

• It connects SAP and non-SAP systems without treating them as separate problems.

• It runs in hybrid environments (cloud, on-premises or both) because most large organizations have infrastructure that cannot move to the cloud on a fixed timeline.

• It gives operations teams real visibility: end-to-end monitoring, alerting and audit logging across all flows, not just the SAP ones.

• It keeps the integration logic under the organization's control, not tied to a single vendor's licensing decisions.

How Frends approaches SAP PI/PO migration

Frends is a hybrid iPaaS built to handle the full breadth of an enterprise integration landscape: SAP and non-SAP, cloud and on-premises, standard protocols and custom connections. For organizations migrating from PI/PO, that means the migration itself and the architecture that follows it are handled on one platform, by a team that knows both.

On the SAP side, Frends connects to SAP ECC and S/4HANA via RFC, BAPI, IDoc, OData, SOAP and REST, across both private and public cloud deployments. Beyond SAP, 300+ pre-built connectors cover SaaS platforms, cloud services, APIs, databases and enterprise applications. EDI, file-based and trading-partner traffic (EDIFACT, AS2, X12, IDoc and legacy file formats) is handled natively, so partner integrations that currently run through PI/PO can be migrated without rebuilding the underlying patterns.

The migration methodology is structured: interface inventory, dependency mapping, phased cutover and parallel running, so each flow is validated before the legacy connection is retired.

Integration logic is built in a visual, low-code BPMN environment with reusable components and version control, which reduces dependency on PI/PO specialists and makes documentation a natural output of development rather than an afterthought.

Every integration on Frends runs with end-to-end monitoring, alerting and audit logging. Teams get operational visibility across all flows — SAP and non-SAP — in a single interface, with the kind of traceability that most PI/PO environments have never provided.

Because Frends sits outside SAP's ecosystem, integration logic and orchestration are managed on Frends, not tied to SAP licensing, update cycles or future platform transitions. This type of independence has direct commercial value fFor organizations with heterogeneous landscapes, like most enterprises today.

A strong track-record in SAP environments

Raisio consolidated eight ERPs into one while managing over 1,000 integrations and enhancing SAP connections on Frends. Orion migrated hundreds of SAP interfaces to a modern, hybrid iPaaS. At Fazer, the shift to Frends enabled the team to reuse existing integration components across multiple processes, reducing the time and resource cost of each new project.

"Frends is our main integration platform at Fazer. Since its introduction, we have implemented several significant integration projects in connection with system projects. Frends enables us to reuse existing components across various processes, leading to significant resource savings."

- Sami Tillgren, Director IT Architecture and Solution, Fazer

The deadline is SAP’s. The strategy is yours.

2027 is a fixed constraint. What happens to your integration architecture after that date is not. The organizations that will come out of this migration in the strongest position are the ones that treat the deadline as a reason to make a deliberate choice — not a reason to default to the most familiar option.

If you are starting to plan your PI/PO migration, the right time to think about the post-migration architecture is now, before the scope is locked and the timeline is running.

FAQ: SAP PI/PO Migration

Answers to the questions organizations most commonly ask when planning a migration off SAP PI/PO.

When does SAP PI/PO support end?

SAP PI/PO standard maintenance ends on December 31, 2027. Organizations can extend support to 2030, though at a significantly higher cost. After the mainstream deadline, SAP will issue no further security patches, bug fixes or regulatory updates. Most organizations should plan for 2027 rather than rely on the extension.

Does PI/PO stop working after 2027?

The software continues running after the deadline. What stops is SAP's obligation to maintain it: no more security patches, regulatory updates or fixes for newly discovered vulnerabilities. Running unsupported middleware is a compliance and security risk for organizations in regulated industries or handling sensitive data.

Why start the migration now rather than waiting until closer to the deadline?

Starting early allows for a phased migration approach, which significantly reduces risk. Organizations that wait until 2027 may face resource scarcity for specialized integration consultants, compressed timelines and pressure toward a high-risk big-bang cutover. A phased approach — starting with lower-criticality integrations to validate the platform and build skills, then moving to business-critical SAP flows — works best with enough runway. It also creates the opportunity for immediate cost savings on legacy infrastructure.

How do I start a SAP PI/PO migration?

The right starting point is a thorough assessment of the current landscape: documenting all existing integrations, dependencies and usage patterns. From there, integrations should be prioritized by business criticality (orders, invoices, logistics and financial flows first) so the migration can be run in waves rather than as a single cutover. The Frends team put together a whitepaper to support enterprises in their migration journeys. The document was created based on hands-on experience handling thousands of migration projects.

Parallel running, where legacy connections stay live until replacements are validated, reduces the risk of disrupting business-critical flows during transition.

How long does a SAP PI/PO migration take?

A full migration process depends on the architecture landscape and tends to last several months for large enterprises with hundreds of interfaces. A complete interface inventory and dependency mapping will determine the exact timeline. Organizations should treat 2027 as a planning deadline rather than an execution deadline to avoid last-minute risk.

What are the migration options after SAP PI/PO end of support?

Organizations have three main paths. The first is SAP Integration Suite, SAP's own successor product for heavily SAP-centric landscapes. The second is a third-party iPaaS — platforms like Frends — which gives more independence from SAP's licensing, high costs and roadmap, and handles broader integration landscapes including non-SAP systems. The third is running on unsupported software past 2027, which carries growing security and operational risk.

Should I migrate to SAP Integration Suite or a third-party iPaaS like Frends?

SAP Integration Suite can be seen as the natural choice for organizations whose integration landscape is primarily SAP-to-SAP and are deeply invested in SAP BTP. For organizations with significant non-SAP integration needs — SaaS platforms, cloud services, EDI partners, legacy systems — a third-party iPaaS keeps the integration layer independent from SAP's licensing model and roadmap.

There is also a meaningful pricing difference. SAP Integration Suite pricing typically scales with message volume or the number of connections, which makes costs harder to predict as integration grows. Frends uses flat-tier pricing with unlimited executions and flows, so there is no cost penalty for expanding the integration footprint.

The key question is how much of your integration landscape sits outside SAP, and how much long-term cost predictability and strategic flexibility matter relative to staying within the SAP ecosystem.

Can Frends run alongside SAP Integration Suite?

Yes. A common pattern for organizations with heterogeneous landscapes is to use Frends to handle the non-SAP part of the integration layer — connecting to OT and field data, legacy file systems, partner APIs and SaaS platforms — while SAP Integration Suite manages core SAP-to-SAP traffic.

This gives organizations a best-of-breed architecture rather than forcing all integration through a single platform that was designed primarily for SAP-to-SAP use cases.

Which SAP protocols and versions does Frends support?

Frends supports both SAP ECC and SAP S/4HANA, including private and public cloud deployments. Connectivity covers RFC and BAPI for calling RFC-enabled function modules, IDoc via both HTTP and file transport, OData, SOAP and REST for modern API integrations, and native EDI handling for EDIFACT, AS2 and X12 for B2B and trading-partner traffic. The full landscape around SAP — 300+ pre-built connectors for SaaS platforms, cloud services and enterprise applications, Enterprise MCP, AI Connector and more  — is managed from the same platform.

What are the risks of staying on SAP PI/PO past 2027?

The immediate risk is security: after the deadline, PI/PO will no longer receive updates, bug fixes or security patches, leaving the environment exposed to cybersecurity threats and compliance failures, particularly in regulated industries. Beyond security, the operational risk compounds over time: no fixes for newly discovered issues, increasing difficulty finding specialists, and a growing gap between the platform and the cloud-first systems it needs to connect.

How do you handle business-critical SAP flows during cutover?

The standard approach on Frends migrations is parallel running: the legacy PI/PO connection stays live until the replacement flow is fully validated against production data. Each interface is tested individually before the legacy connection is retired. End-to-end monitoring, alerting and audit logging are in place from the first integration, so any issues during the transition period are visible before they become incidents.

Has this been done at scale?

Yes. Raisio consolidated eight ERP systems into one SAP S/4HANA environment while managing over 1,000 integrations on Frends. Orion migrated hundreds of SAP interfaces to a hybrid Frends iPaaS to streamline operations. At Fazer, the migration started with EDI flows and progressed to complex SAP core integrations, with reusable components reducing resource costs across each subsequent project.