PI/PO to Cloud Integration: what admins lose in the migration

What PI/PO admins actually had

SXMB_MONI on the dual-stack, or the AEX-Monitor on the Java-only PO 7.5. Payload visible by default. Retry button right there. ccBPM for long-running stateful processes in the same engine. Cross-system trace possible without leaving the cockpit.

The learning curve was steep and the documentation was uneven. But the mental model was compact: one message, one engine, one place to look per path. Operations teams could brief a new admin in days.

What Cloud Integration replaces it with

End-to-end visibility now spans up to seven monitoring surfaces, each with its own retention limits, licensing model, and operational style:

• Integration Suite Monitor — iFlow deployment status, no cross-tenant view.
• Message Processing Logs (MPL) — per-tenant message status via OData; 30-day retention, 32 GB cap, 1 GB/day circuit breaker.
• BTP Cockpit — subaccount health and entitlements; infrastructure-level only.
• SAP Cloud ALM — cross-application monitoring; separately licensed, 14-day detailed retention, 100 req/min API ceiling.
• SAP Focused Run — high-volume monitoring with its own sub-modules; separately licensed.
• Third-party add-on — Figaf IRT, Dynatrace, Splunk, or a custom Grafana build; additional cost and integration effort.

Payload persistence is no longer default — it has to be built into each iFlow. Retry on the message level is no longer a first-class operation (limited to JMS, AS2, and XI adapters). ccBPM has no direct successor; its closest equivalent is SAP Build Process Automation, licensed separately.

Why this is structural, not accidental

Cloud Integration was designed for a different operational model than PI/PO. It assumes a tenant-isolated, API-first, hyperscaler-hosted world where deep introspection on individual messages is the exception, not the daily operation. For SAP shops running production B2B, EDIFACT, or partner-integration paths — where deep introspection is the daily operation — the gap shows up in week one.

DSAG calls the BTP monitoring situation "unnecessarily complicated." Their 2026 Investitionsreport shows the membership is 78% hybrid (on-prem plus cloud), with only 5–7% running live operations in public cloud. The monitoring tooling assumes a cloud-native world that most SAP shops don't yet live in.

The cost-pressure layer underneath

Cloud Integration is sold under CPEA (Cloud Platform Enterprise Agreement) — consumption-based, per-message billing. Payload storage past 32 GB triggers additional 250-KB units. Cloud ALM is a separate line item. Focused Run is a separate line item. A third-party observability add-on adds a third.

For most teams the operational answer to the transparency gap involves buying more SAP licenses, which is the question CFOs ask before approving the migration budget. We hear it every time: is Cloud ALM worth the additional license cost, given that it only closes part of the gap?

How we look at this

The honest position is that Cloud Integration is the content engine — SAP-authored iFlow packages for S/4HANA, SuccessFactors, Ariba, Concur, and 2,700+ APIs in the Business Accelerator Hub. That moat is real and we don't recommend trying to replace it.

What's missing is a provenance layer above Cloud Integration — message persistence, lineage, replay, and a single operations cockpit — that sits as a meta-layer, not as a replacement. We've written this up as a one-pager covering the architecture argument and the trade-offs honestly, including the gaps we don't yet have a customer reference for.