SAP PI/PO End of Support 2027: How Much of Your Migration Can Actually Be Automated?

SAP PI/PO mainstream maintenance ends 31 December 2027. Extended maintenance provides additional transition time, but SAP Integration Suite remains the strategic platform for new integration capabilities and cloud-based innovation.

For any integration architect who hasn't formally scoped this yet, that's not a distant planning date anymore; it's inside most organisations' next two budget cycles. But the deadline isn't actually the hard part of this decision. The hard part is the question every architect asks right after acknowledging the date: how much of this migration can genuinely be automated, and how much still needs a person rewriting logic by hand? Get that number wrong, and a migration scoped against the wrong assumption is how a project ends up with a Complex-heavy remainder nobody budgeted for.

This article answers that question using what Tarento's iVolve framework delivers through its Migration Automator tool.

Executive Summary: What Determines Your Real Automation Number

• The 2027 deadline is real and close. SAP has confirmed 31 December 2027 as the end of mainstream maintenance for PI/PO 7.5, with extended maintenance available only to 2030 at a steep cost premium.
• "Single-click migration": For Simple interfaces that match supported migration patterns and contain no unsupported custom logic, iVolve can execute a largely automated migration workflow with minimal developer intervention.
• Every PI/PO interface falls into one of three complexity tiers, and which tier it lands in is what actually determines effort, not the platform-level headline number.
• A landscape-level automation average and a per-interface automation rate are two different things. The 70–80% figure quoted for SAP PI/PO to SAP Integration Suite is a portfolio average; any single interface can land anywhere from 20% to 90%.
• Complex-tier work runs in parallel with automation, not after it. Planning a migration as "automate first, then handle the hard interfaces" misreads how the process is actually structured.

The 2027 Deadline: What SAP PI/PO End of Support Actually Means

If you're evaluating a move off SAP PI/PO, the first practical question isn't "should we migrate." SAP has already provided the answer for you, including the maintenance end date. The real question is "how much of this can actually be automated, and how much still needs a person," because that number determines whether a maintenance deadline becomes an actual budget line and timeline.

Key context: After 31 December 2027, organisations must either purchase extended maintenance through 2030 or move into customer-specific maintenance with more restricted coverage. PI/PO continues to run, but the support cost, maintenance scope, and operational risk profile change materially.

Most public guidance at this point stops at "start planning now." That's necessary but insufficient for anyone actually scoping a project. The next section is where the real planning question gets answered.

The Three Complexity Tiers That Determine Your Actual Automation Rate

Every interface in a PI/PO landscape falls into one of three buckets; iVolve classifies assessed interfaces into three migration-complexity tiers:

Simple (fully automated). One-click migration, full automation possible, with no redesign or additional artifact development needed. This is the bucket where "single click" is a literal description of the work involved, not marketing language.

Medium (semi-automated). Partly automated migration, covering interfaces with proxies, EDI, and custom adapter modules. Some redesign or artifact development is factored in here, meaning the tool carries the work part of the way and a developer finishes the rest.

Complex (reengineering). Manual migration effort needed. Specific examples include interfaces with BPM, ABAP mappings, or complex custom adapter modules. These aren't automation candidates in their current form. They need to be rebuilt.

In practice: an interface that looks routine in a landscape inventory can still land in "Complex" if it has an ABAP mapping buried inside it. This is exactly the kind of detail that a platform-level percentage can't surface, which is why interface-level tiering has to happen before a go-live date gets set, not after.

Tier	Typical characteristics	Automation level	Human effort
Simple	Standard mappings, adapters and supported patterns	High	Validation and configuration
Medium	Proxies, EDI or custom adapter modules	Partial	Redesign and artefact completion
Complex	BPM, ABAP mappings or complex custom modules	Low	Reengineering and rebuilding

What the 70–80% Automation Figure Actually Measures

This is where it's easiest to misread a benchmark, and it's worth being precise about it. iVolve's Automation Benchmark lists the automation factor for SAP PI/PO to SAP BTP / SAP Integration Suite at 70–80%. That number is defined at the overall landscape level, an average across an entire portfolio of interfaces, not a guarantee for any single interface.

The spread underneath that average is significant: on a per-interface or per-flow basis, automation can range from as low as 20% to as high as 90%. A landscape with a heavy mix of Simple interfaces lands toward the top of that range. A landscape weighted toward EDI, custom adapter modules, or BPM-driven flows lands lower, even if the headline 70–80% figure is the number that ends up quoted in a business case.

Worth separating clearly: discovery-stage automation figures are a distinct measurement, taken at a different point in the migration lifecycle, and shouldn't be combined into a single derived percentage with the migration-stage number above. If you're comparing benchmarks across different vendors' articles or decks, check which lifecycle stage each number actually describes before it goes into your planning.

How Migration Automator Fits Into the Full Migration Journey

Migration Automator isn't a standalone tool that runs in isolation. It sits inside the Migration phase, which follows Discovery. The Migration phase covers setup and provisioning of the target tenant, deployment of the Migration Automator, the automated migration run itself, unit testing of migrated artifacts, and movement of artifacts to a QA tenant. Manual migration artifacts, for the interfaces that need them, are produced in parallel rather than after the fact.

That parallel-track detail changes how a realistic timeline should be built. It means the plan isn't "run the automation, then start on the hard interfaces." Complex and Medium-tier work runs alongside the automated pass from the outset, which is also why a migration timeline built purely off the headline automation percentage tends to undershoot the actual Complex-tier workload.

What This Means If You're Scoping a PI/PO Migration Now

Before trusting a 70–80% figure for your own landscape, get an interface-level complexity breakdown, not just a platform-level average. That breakdown is what a proper Discovery phase and its complexity classification are for.

Given the 2027 deadline sitting behind all of this, the practical sequencing is: run Discovery and complexity tiering first, size the Complex-tier workload honestly before it becomes a deadline problem, and only then commit to a go-live date. Skipping straight to a timeline based on the landscape-level automation factor is how a project ends up discovering its Complex-heavy remainder with the maintenance clock already running out.

---

SAP PI/PO Migration Automation: Frequently Asked Questions

1. When does SAP PI/PO support actually end? Optional extended maintenance is available through 2030 under SAP’s applicable conditions, including a two-percentage-point premium on the existing maintenance basis.

2. Does SAP PI/PO stop working after 2027? No. The software continues to run. What stops is SAP's obligation to maintain it: no further security patches, bug fixes, or regulatory updates after the mainstream maintenance deadline, which is a growing compliance and security risk the longer an unsupported system stays in production.

3. Can all SAP PI/PO interfaces be migrated automatically? No. Interfaces fall into three complexity tiers. Simple interfaces genuinely qualify for one-click, fully automated migration. Medium-complexity interfaces (proxies, EDI, custom adapter modules) are semi-automated, requiring some redesign. Complex interfaces, those involving BPM, ABAP mappings, or complex custom adapters, need manual reengineering rather than automation.

4. Is the 70–80% SAP PI/PO automation figure accurate for every migration? It's an accurate landscape-level average, not a per-interface guarantee. Individual interfaces can automate anywhere from 20% to 90% depending on their complexity tier, so the actual figure for any specific organisation depends on the mix of Simple, Medium, and Complex interfaces in its own landscape.

5. Should Complex-tier interfaces be migrated before or after the automated interfaces? Neither; they run in parallel. The Migration phase is structured so that manual work on Medium and Complex interfaces happens alongside the automated migration run, not as a separate phase afterward, which is an important distinction when building a realistic project timeline.

---

See how iVolve applied discovery, conversion, validation, and phased deployment across a 230-plus-interface SAP PI/PO migration.