SAP Integration Suite: decisions and production trade-offs

SAP Integration Suite is SAP's integration platform on SAP BTP: Cloud Integration (the former CPI) plus API Management, Event Mesh, Integration Advisor, Open Connectors and tools to migrate from PI/PO. It is the default middleware for S/4HANA cloud programmes and the route off PI/PO, whose mainstream maintenance ends in 2027. Interface delays rarely come from the technology. They come from unclear ownership, untested assumptions about legacy systems, and testing designed to pass rather than to find failures. This guide is for integration leads, architects and programme managers. It covers what each component is for, standard versus custom content, the PI/PO migration, legacy and testing risks, and post-go-live governance.

PI/PO is on the clock. SAP Process Integration and Process Orchestration 7.5 are in mainstream maintenance until the end of 2027. Optional extended maintenance runs to the end of 2030, after which SAP support ends. SAP's migration reference architecture describes the route. Integration Suite includes a Migration Assessment application that sizes each PI/PO scenario and wizard-based migration tooling in Cloud Integration. Migrate in waves: low-risk SAP-to-SAP flows first, B2B and EDI in the middle, and high-volume order flows last. A forced cutover under deadline pressure takes longer and costs more.

1. Wave 1Low-risk SAP-to-SAP flowsSize every scenario first with Migration Assessment
2. Wave 2B2B and EDI
3. Wave 3High-volume order flows
4. 2027PI/PO 7.5 mainstream maintenance endsEnd of year. Plan the waves to finish before this
5. 2030Optional extended maintenance endsEnd of year. Then SAP support ends

Source: SAP maintenance dates and migration reference architecture, checked October 2026

Check what your cloud contract covers. RISE and GROW contracts usually include SAP BTP credits that can pay for Integration Suite. Confirm which edition and message volumes your entitlement covers before you compare Integration Suite with MuleSoft or Boomi on features alone. The economics of an included platform change the comparison.

AI is arriving in stages. Cloud Integration has offered generative AI flow generation in its Premium edition since mid-2024. It produces the structure of an iFlow (steps, channels, exception subprocess), not the mappings or scripts. SAP's enhanced edition, launched in March 2026, adds text-to-flow generation and script optimisation, and SAP planned Joule in Integration Suite for general availability in the third quarter of 2026. Useful for standard flows. Complex orchestration with deep business logic still needs senior architects.

Integration Suite is a set of services. Using the right one for the job shapes how well the landscape holds up.

Component	Role	What goes wrong when it is misused
Cloud Integration (CPI)	Message flows, routing and transformation; the default for most iFlows	Everything stuffed into CPI, including APIs and events, becomes hard to support and test
API Management	Governs API exposure: security, rate limits, analytics	Skip it and point-to-point calls multiply; governance is hard to retrofit
Event Mesh	Asynchronous messaging for decoupled triggers	Untracked queues grow silently without alerting anyone
Integration Advisor	Mapping proposals for B2B formats such as EDIFACT, X12 and IDoc	Teams assume high coverage; one team expected 80% and got closer to 40%
Open Connectors	Prebuilt connectors to third-party cloud apps	External API changes break connectors silently unless someone monitors them
Migration Assessment and tooling	Sizes and migrates PI/PO scenarios	Treated as a one-off estimate instead of a working migration plan

Teams that treat Integration Suite as "CPI with add-ons" often ignore API Management and Event Mesh. That works until complexity catches up. My SAP CPI guide goes deeper on Cloud Integration itself.

Prebuilt SAP integration content is genuinely useful when the process is standard. Connecting S/4HANA to SAP Ariba or SuccessFactors with standard processes is often a clean fit. Real processes rarely stay inside SAP's reference lines.

Choose standard content when:

1. The scenario is SAP-to-SAP and close to SAP's reference process
2. The flow is simple and mostly one-way
3. You can live with SAP's mapping and only extend through the provided exits

Choose a custom build when:

1. Years of internal decisions have moved the process away from SAP's model
2. Conditional routing, multi-step logic or legacy quirks are involved
3. Heavy modification would break SAP's support alignment for the standard package

Make the decision in the blueprint phase. When it is made late, teams find mid-project that a "standard" iFlow has been modified so heavily it lost support alignment, and they rebuild it under go-live pressure. I have seen projects lose weeks because teams assumed standard content would absorb custom master data structures, extra fields and legacy authentication all at once. It did not. The analysis that belonged in design happened during UAT.

In large SAP programmes, integration is often the first thing to fall between workstreams. Interfaces cross team boundaries, but nobody owns the coordination. I have seen two project teams build separate integrations for the same business partner, pointing at the same endpoint, without knowing about each other. Neither found out until UAT. That is a structural failure, not a technical one.

Set up central integration governance early:

1. A shared integration backlog visible to every workstream
2. A named owner for each interface, tracked through delivery
3. Coordination checkpoints across workstreams before each major deployment
4. A review of interface dependencies before any go-live commitment, with shared endpoints and queues sequenced in the cutover plan
5. Automated deployment between environments, with credentials documented per landscape

The hardest integration problems are rarely the modern platforms. They are the older systems in the middle of critical processes.

Legacy ERPs often cannot handle concurrent synchronous calls. Send five parallel API calls and the server slows, freezes or drops data silently. Asynchronous integration helps only if the receiving system can process a queue, and many cannot.

Protocol mismatches are common and found late. You design with OAuth2 and REST; the legacy system speaks SOAP with a 30-second hardcoded timeout and handles token refresh badly.

In one client case, a middleware flow failed every Friday because the token issued by a third-party payroll system expired weekly. Nobody noticed until the second UAT cycle. Quirks like this are common, and they eat into timelines.

The table lists the risks to check before design freeze.

Risk	Common problem	What to do in design
Synchronous limits	Legacy locks up under parallel calls	Use asynchronous messaging; stagger calls through Event Mesh or Cloud Integration
Protocol mismatch	Legacy rejects REST or OAuth, or times out on SOAP	Confirm protocols and timeouts before design starts
API rate limits	Batch jobs exceed third-party throttling	Throttle in API Management; add wait logic in the iFlow
Token expiry	Flows fail silently in off-peak windows	Schedule refresh cycles and monitor expiry
Rigid formats	Dynamic payloads break legacy parsing	Validate with real production samples
No fallback	File transfers fail without retry and data gets stuck	Buffer in middleware; build retry and alerting into iFlows

For the cross-cloud version of these problems, see my piece on why ERP integration with Salesforce fails.

Integration does not break the way functional tests check. It fails under timing pressure, when background jobs overlap, and when inputs arrive in volume rather than one at a time. A functional test proves a transaction posts and a message appears in the log. It does not prove what happens when the first payroll run sends a flood of IDocs. On one project, an IDoc that looked clean in system integration testing stalled the queue when real payroll volumes came through. Only load testing found it.

Interface testing needs to cover:

1. Realistic data volumes with concurrent users
2. Service interruptions and recovery behaviour
3. Timeouts and retries across middleware and back ends
4. Batch jobs running alongside real-time calls
5. Month-end and other peak periods

Development environments are clean. Deadlocks, race conditions and throttling show up in UAT and pre-production, where other systems and batch windows are live, so run load tests there. Split ownership clearly: functional teams validate business results across the whole flow, integration teams own logs, retries and exception flows, and project leads confirm coverage. My guide to SAP performance testing covers the load side.

Integration Advisor proposes mappings for structured B2B formats. For partners who follow strict conventions, it saves real setup time. For enterprise integrations with legacy systems, custom fields, conditional logic and undocumented rules, it is a starting point.

One team I worked with expected 80% mapping coverage. Actual coverage was around 40%. The rest had to be customised, validated with the business and manually tested.

It does not resolve business logic that built up informally over years (payment terms, pricing categories, unit conventions), conditional rules based on business context, or exceptions outside the standard format. Those need functional input. Without it, interfaces are technically mapped and logically wrong in specific cases.

Integration degrades after go-live when documentation drifts and ownership is not formal. Useful documentation covers field mappings and transformation logic, and authentication details such as endpoints, token refresh and credential rotation. It also covers error handling, fallback rules and volume expectations for critical windows such as month-end and payroll. The test: could someone who joined the support team next week troubleshoot a failing interface from the documentation alone?

Every interface, even a low-volume one, needs a named owner for monitoring, escalation and lifecycle changes. Without one, failures bounce between Basis, middleware and functional teams while the business waits. After hypercare, monitoring tends to fade. Build regular error log reviews, a formal handover from project to support, and service levels agreed between the business and IT. Neglected integration is behind many of the delayed postings, missing invoices and misaligned financial reports that surface weeks after go-live.

What is SAP Integration Suite and how is it different from CPI?

Cloud Integration, formerly SAP Cloud Platform Integration (CPI), is one capability inside Integration Suite. The suite adds API Management for governed API exposure and Event Mesh for asynchronous messaging. It also includes Integration Advisor for B2B mapping proposals, Open Connectors for third-party cloud apps, and assessment and migration tools for PI/PO. Teams that treat it as CPI with a new name often skip API Management and Event Mesh, and pay for it in governance gaps later.

When does SAP PI/PO support end?

SAP Process Integration and Process Orchestration 7.5 are in mainstream maintenance until the end of 2027. Customers can take optional extended maintenance until the end of 2030, after which SAP support ends. Integration Suite includes a Migration Assessment application to size each scenario and migration tooling to move artefacts semi-automatically. Start with a wave plan rather than waiting for the deadline.

When should SAP integration use standard content versus custom development?

Use standard content when the scenario is SAP-to-SAP, close to SAP's reference process and relatively simple. Build custom when the process has drifted from SAP's model, when legacy quirks need specific handling, or when conditional and multi-step logic would force heavy changes to the standard package. Decide in the blueprint phase; rebuilding an over-modified standard flow under go-live pressure costs more than a clean custom build.

What causes SAP integration failures in complex programmes?

Mostly structural causes. No named owner for monitoring and error resolution, so failures bounce between teams. Two workstreams building integrations that share an endpoint or queue without knowing. Legacy systems that cannot take concurrent calls, found only under load. And testing that runs clean in isolation but never simulates batch overlap or peak volume.

How should integration testing be structured for SAP Integration Suite?

Beyond functional tests, cover realistic volumes such as the first month-end or payroll run. Test batch jobs running alongside real-time interfaces, recovery when a downstream system is unavailable, and third-party rate limits during bulk jobs. Run load and performance tests in environments that resemble production, because clean development systems hide the problems.

How should SAP integration be governed after go-live?

Give every interface a named owner for monitoring, escalation and changes. Keep documentation current: mappings, authentication and credential rotation, error handling and volume expectations. And build a long-term support model with regular error log reviews, a formal handover from project to support and agreed service levels. Integration that becomes invisible gets neglected.