Your middleware retires in 2027. The migration tool does 60%.

SAP Process Integration and its successor Process Orchestration reach end of mainstream maintenance on December 31, 2027. SAP's own migration tooling automates only 60-70% of the technical work; ccBPM, BPM and user-defined functions come across by hand. Plan for a year-plus program, and expect it to freeze the order-capture, loyalty and returnables features that sit above the bus. The deadline is the easy part.

What exactly retires on December 31, 2027?

Mainstream maintenance for SAP PI/PO ends on December 31, 2027. You can buy an extension to 2030, but per the same analysis it arrives "at a heavy cost increase" and buys nothing architecturally: the same middleware, a larger invoice, a nearer cliff. The sanctioned destination is SAP Integration Suite — specifically Cloud Integration — a different runtime with a different design paradigm. This is not a version upgrade; it is a re-platform of every interface you own.

That distinction matters for a route-to-market estate because PI/PO is rarely quiet plumbing. It is where order IDocs, EDI and ASN feeds, pricing conditions and returnable-asset movements get mapped, enriched and routed between the SAP financial core and everything customer-facing. Retire it and you touch every integration your commerce, loyalty and logistics stack quietly depends on.

What does "the tool does 60%" leave on your desk?

SAP's Migration Assessment and migration tooling are genuinely useful, but SAP's official FAQ is candid about the ceiling: as of February 2026 the tooling automates roughly 60-70% of technical migration efforts. The remaining third is not evenly distributed filler. It concentrates in precisely the places large brewers customised hardest.

Two categories account for most of it. Stateful integration processes are the first:

Cloud Integration does not support the migration of ccBPM or BPM directly.

Every collect-and-bundle, multicast or correlation pattern behind consolidated invoicing, delivery confirmations or returnables reconciliation gets redesigned in the new runtime, not ported. The second category is the Java user-defined functions in your message mappings, which per the same FAQ must be refactored manually — one at a time, with regression tests you probably never wrote for them in the first place.

What makes a beverage estate harder than the average migration?

Route-to-market volume is the first multiplier: telesales, van-sales and B2B-portal orders all funnel into the same order IDocs, so the mapping layer is both high-throughput and business-critical. On top of that sit the things unique to the category — returnable-container and empties tracking, deposit and excise logic embedded in pricing conditions, promotional and listing-price feeds to grocery chains, and EDI relationships with dozens of retail partners, each with its own dialect and its own re-certification cycle. Nearly all of that intelligence lives in the custom UDF and ccBPM layer — the exact code SAP's tooling hands back to you. The more differentiated your route to market, the larger your manual 40%.

Why does a "tool-assisted" migration still take a year-plus?

Because the manual third is the interesting third, and it needs testing against a financial core you cannot afford to get wrong. Independent analysis puts a realistic PI/PO-to-Integration-Suite transition at at least a year, and that is before you account for a beverage estate's peak-season blackout windows, EDI partner re-certification, and the fact that integration defects surface in production, not in unit tests. Assessment and inventory, mapping redesign, ccBPM re-implementation, partner re-testing and a parallel-run window each claim their weeks; run them sequentially, as most finance-adjacent programs do, and the calendar fills itself. A year is the optimistic read for an organisation that starts with a clean interface inventory — and most do not have one.

Why does everything above the bus inherit the freeze?

A migration this size runs a change freeze on the interfaces in scope, because you cannot validate a re-platformed integration against a moving target. The trouble is that the middleware sits underneath the customer-facing estate, so the freeze propagates upward. The team that wanted to ship a new loyalty accrual rule, a returnables deposit change or a promotional pricing feed now waits behind the migration calendar. That is how a backend maintenance deadline quietly becomes a product-roadmap deadline.

Teams already living on vendor-dictated calendars will recognise the shape. It is the same dynamic behind the forced-update treadmill on Dynamics, where a platform's cadence, not the business, decides when you test. And the manual-refactor tax on UDFs and ccBPM rhymes with the WMS modifications that vanish with every upgrade: custom code a vendor's automation quietly declines to carry forward. Stack a frozen integration backlog on top of the build-and-deploy economics of SAP Commerce Cloud v2 and the customer-facing roadmap slows to the pace of the slowest layer beneath it.

What reduces the blast radius?

The structural fix is to stop letting the middleware be a shared point of failure. If your customer-facing services speak to a stable internal event contract rather than directly to PI/PO mappings, the migration becomes a swap behind an interface instead of a synchronised freeze across every consumer — which is why we build route-to-market suites on a single event bus decoupled from the SAP core. It does not make the re-platform free, but it keeps the deadline inside the integration team, where it belongs, instead of leaking into every product roadmap that touches an order.

The 2027 date will not move, and the shape of the work is already visible. Estates that spend 2026 cataloguing their ccBPM processes and UDFs — deciding what to retire outright rather than re-platform — will meet the deadline with a smaller, better-understood surface. The ones that wait for the tooling to deliver its 60% and then discover the other 40% in 2027 will be negotiating the 2030 extension at its "heavy cost increase," which was never anybody's plan.