Two of the most consequential integration decisions in an SAP project are made before a single flow is configured: which pattern to use, and whether that pattern is even available in the target environment. The second question is the one most often skipped.
Your deployment model (whether you are running SAP Cloud ERP in the public cloud, SAP S/4HANA on-premise or in a private cloud, or a hybrid combination of both) is not just technical context. It actively determines which integration patterns are viable, which require additional infrastructure, and which will create problems that surface late in the project when they are expensive to fix. This post covers what each deployment model means for pattern selection, and closes with the most common integration pattern mistakes and how to avoid them.
This is the fourth and final post in a series on SAP integration patterns. The first covers what integration patterns are and why they matter. The second catalogs the full range of patterns available in SAP landscapes. The third provides a five-question decision framework for choosing between them. This post is where those decisions meet the reality of your environment.
Deployment Model and Its Impact on Pattern Choice
One of the most reliable ways to select the wrong integration pattern is to treat the deployment model as a detail to be confirmed later. The deployment model, whether systems are running in SAP's public cloud, in a private cloud or on-premise environment, or in a hybrid combination of both, determines which patterns are available, which are inadvisable, and which will require additional infrastructure to function at all. Establish this before pattern evaluation begins.
Public Cloud (SAP Cloud ERP)
The deployment model matters enormously, and nowhere is this more consequential than in SAP's public cloud offering. SAP Cloud ERP—the public cloud edition of SAP S/4HANA—no longer supports IDocs as of version 2508. This removes one of the most historically common SAP integration patterns from the equation entirely for organizations running or migrating to this environment.
In public cloud deployments, API-based integration is the expected approach. OData and REST APIs are the interfaces of choice, backed by the 800+ APIs SAP has published for SAP S/4HANA. SAP manages the underlying infrastructure, which limits the degree of customization available at the platform level but also reduces the operational burden on the customer. Any integration design targeting a public cloud system must account for this constraint from the outset. Retrofitting a legacy IDoc-based design to an API-based model later is expensive and disruptive.
Private Cloud and On-Premise
SAP S/4HANA on-premise and private cloud deployments retain full IDoc support. SAP Process Orchestration is still in active use across many of these landscapes, though its end-of-maintenance date of 2027 means organizations running it need a migration plan. SAP Integration Suite (specifically its Cloud Integration capability) is the strategic destination for those migrations.
These environments offer more flexibility in custom adapter development and middleware configuration than public cloud, and they support the full range of integration patterns discussed in this post. However, that flexibility comes with a decision burden: the wider the options, the more important it is to choose deliberately rather than by default or organizational habit.
Hybrid Landscapes
As SAP moves to the cloud, hybrid deployments will play an increasingly major role in businesses. Most organizations running SAP today must maintain existing IT landscapes alongside newer cloud investments. The idea that cloud deployments will completely replace current environments in any near-term timeframe is simply unreasonable. SAP's own product strategy reflects this reality. Hybrid deployments will be the solution of choice for most companies in the years to come, which means hybrid integration is not a transitional problem to be solved once and forgotten. It is an ongoing architectural condition that requires deliberate pattern thinking.
Hybrid landscapes automatically introduce integration complexity: on-premise systems and cloud applications need to exchange data with each other, often using different protocols, different security models, and different interface standards on each side. The typical architecture places Cloud Integration in the center while the Cloud Connector bridges the on-premise side, establishing a secure tunnel between SAP BTP and the on-premise network without requiring inbound firewall ports. In practice this means the on-premise side of a hybrid integration may use IDocs, RFC, or SOAP (patterns native to that environment) while the cloud side uses OData or REST, with Cloud Integration handling the translation between them. Neither side needs to abandon its native integration approach; the middleware layer absorbs the difference.
This is also where composite pattern thinking becomes most relevant. A single end-to-end business process in a hybrid landscape will frequently touch both worlds: a transaction initiated in a cloud application that needs to trigger a process in an on-premise SAP S/4HANA system, or data replicated from on-premise into a cloud analytics platform. Each leg of that process may warrant a different pattern. The hybrid architecture does not change which pattern is right for each leg; it adds the requirement that those patterns be connected through an integration layer capable of spanning both environments. For organizations still running SAP Process Orchestration on-premise, that migration to Cloud Integration is itself a hybrid transition, one where pattern decisions made today need to account for the target architecture, not just the current one.
Common Mistakes and How to Avoid Them
Even with a clear framework in hand, integration pattern decisions go wrong in predictable ways. These are the most common and most consequential.
Defaulting to Point-to-Point at Scale
Point-to-point integration is fast to implement and easy to understand, which makes it the natural first choice in early-stage landscapes or under delivery pressure. The problem is that it works until it doesn't, and the transition point arrives faster than most teams expect. Every new system added to a point-to-point landscape doesn't add just one connection—it potentially adds connections to every system already there. What looked manageable at three or four systems becomes a web of bilateral dependencies that nobody fully understands and everyone is afraid to touch. If point-to-point is chosen deliberately for a specific scenario, document why, define the conditions under which it will be revisited, and plan the migration path before you need it.
Using IDocs in Public Cloud Environments
IDocs remain deeply familiar to SAP practitioners who built their experience on earlier SAP ERP platforms, and that familiarity creates a gravitational pull toward using them even when the target environment no longer supports them. As discussed earlier, IDocs are not supported in SAP Cloud ERP anymore. Designing an integration around IDocs without first confirming the target system's deployment model is a mistake that surfaces late and requires a fundamental redesign rather than a configuration fix. Verify deployment model before selecting message format, not after.
Treating Process Integration and Data Integration as the Same Problem
This is the category error that sits beneath many SAP integration failures. The two require different patterns, different tooling, and different design principles. When a process integration tool is used for bulk data replication, the overhead and brittleness it introduces may not be obvious in a development environment with low data volumes. It may surface under production load. When a data integration approach is applied to a transactional process, the latency and auditability gaps are similarly invisible until the business process fails in a way that is difficult to diagnose. The fix is to apply the process/data distinction as the first filter, before any tool evaluation begins.
Under-Governing APIs
It is technically possible to deploy APIs without API Management in SAP Integration Suite, and many teams do, particularly when moving quickly or treating API Management as a later-phase concern. The consequences accumulate quietly. Without API Management there is no rate limiting, which means a single misbehaving consumer can degrade performance for all others. There is no centralized security policy enforcement, which means each API handles its own authentication and access control inconsistently. There is no consumption visibility, which means you cannot see who is calling what, how often, or whether the integration is healthy. By the time these gaps become painful, the APIs are in production and retrofitting governance is significantly harder than building it in from the start.
Choosing a Pattern Based on Familiarity Rather Than Fit
This is the most pervasive mistake and the hardest to catch because it doesn't feel like a mistake when it's happening. Teams reach for the patterns they have implemented before. Familiarity is a legitimate input into a decision, but it should be a tiebreaker, not the primary criterion. The scenario requirements should determine the pattern. If the familiar pattern happens to fit, use it. If it doesn't, the short-term comfort of choosing it will be paid for in long-term architectural debt.
Conclusion
The series has moved from what integration patterns are, through the full catalog of available options, through a structured framework for choosing between them, and finally to the deployment constraints and failure modes that shape how those choices play out in practice. The through-line across all four posts is the same: pattern selection is an architectural decision, and architectural decisions deserve deliberate thought before implementation begins.
The most expensive integration mistakes covered in this post share a common root cause. They happen when teams move to tools before they have finished thinking about the problem. The framework in this series exists to close that gap.
This post was originally published 6/2026.
Comments