PI/PO: why to plan from 2027, not 2030
Ask most SAP teams when PI/PO support ends and you'll hear "2030". It's not wrong. But it's the wrong date to plan against, and teams that do are setting up a rushed, expensive migration.
The dates
- 31 December 2027: mainstream maintenance for SAP PI/PO 7.5 ends.
- 31 December 2030: extended maintenance ends. After that, PO falls into customer-specific maintenance, with no follow-on release.
- 2030 as well: SAP's Java support for NetWeaver AS Java 7.5 ends, so this applies even if you've already moved your ERP to S/4HANA.
Extended maintenance is a paid bridge, not a free extension. It exists to give stragglers time, not to be the plan.
Why 2030 is the wrong planning date
It costs more
Every year on extended maintenance is a year of paying extra to stand still. That money would usually cover a meaningful share of the migration itself.
Skills are getting scarcer
Experienced PI/PO people are moving to Integration Suite work. The closer you get to 2030, the more you compete with everyone else who waited for the same people.
Regulation doesn't wait
Many e-invoicing and B2B flows run through PO. Germany's e-invoicing issuing obligations, for example, widen on 1 January 2028, one day after mainstream maintenance ends. Rebuilding compliance flows twice is a cost nobody budgets for.
Integration is the critical path of everything else
If an ECC to S/4HANA move is also on your roadmap, your interfaces have to be re-pointed anyway. Planning both together avoids doing the same work twice.
What SAP's tools do, and what they don't
SAP provides two useful tools. Migration Assessment connects to your PO system, inventories your scenarios and sizes them. Migration Tooling, inside Cloud Integration, converts supported PO objects into iFlows using pattern templates.
The catch is in the wording. An interface marked "ready to migrate" means the features it needs exist in Integration Suite. It does not mean the conversion is automatic. The assessment also doesn't detect dependencies between interfaces, and it doesn't look inside custom adapter modules.
The assessment tells you what exists. It doesn't tell you what's hard. That gap is where PI/PO migrations slip.
Where projects usually get stuck
- Java user-defined functions and custom adapter modules
- Dynamic configuration that nobody documented
- Large payloads and bulk IDoc processing
- Rebuilding security: OAuth 2.0, certificates and the credential store
- On-premise-to-on-premise flows that need Edge Integration Cell
Working backwards from 2027
A sensible plan runs in this order: a full interface inventory and dependency map first, then a decision for each interface (move as-is, redesign or retire), then a pilot wave to prove mappings, security and monitoring, then migration in waves with automated regression testing, and finally decommissioning PO. Each step depends on the one before it, which is why starting from 2030 leaves no room for surprises.
What to do this quarter
- Count your interfaces, including the ones nobody owns.
- Run SAP's Migration Assessment, then add the dependency map it can't produce.
- Decide which interfaces to retire before you migrate anything.
- Budget for the migration against 2027, and treat extended maintenance as insurance, not the plan.
If you'd like help with the first two steps, our fixed-price Integration Landscape Assessment produces the inventory, the risk ranking and a costed wave plan.