With the recent features in SAP Integration Suite—such as the ability to migrate Service Interfaces from SAP PI/PO to Cloud Integration and the introduction of the pipeline concept, the topic of migrating XI Proxies to Integration Suite has gained fresh significance. If you’ve been waiting for the right moment to move your proxy-based integrations, this might just be it. The following sections outline key considerations and practical recommendations for a smooth and future-ready transition.
A) Modernize While You Migrate
While SAP supports the migration of legacy protocols such as Proxy, helping customers preserve their existing investments, it’s also a good time to consider modernization. Move away from older or proprietary interfaces toward modern, cloud-native, and interoperable options like SOAP or OData services to ensure long-term stability and easier evolution of your integration landscape.
B) Leverage SAP provided Accelerators
Before you start rebuilding interfaces from scratch, explore what SAP already provides out-of-the-box, from the SAP Business Accelerator Hub.
Prepackaged Integration Content: SAP Integration Suite pre-built content can significantly accelerate migration by making use of pre-delivered integration flows, script collections, etc., spanning across key end-to-end business processes, cutting across your SAP and non-SAP systems.Standard APIs and Events: Consume standard APIs and business events available for your SAP S/4HANA edition to avoid / reduce customization and thus keep the core clean.
C) Migrating ESR Proxy Objects to Integration Suite
In the ECC – PI/PO landscape, the Enterprise Services Repository (ESR) served as the central design-time hub for maintaining and versioning proxy schemas and interface definitions. This enabled the well-established “outside-in” development model, where integration developers first defined the structure in middleware via Data type, Message type and Service Interface, after which ABAPers implemented the Proxy class/method in the backend.
When SAP Integration Suite was first introduced, it lacked an ESR-equivalent capability to host and manage proxy schemas. Consequently, one option for customers was to keep their PI/PO ESR systems running to maintain these schemas, regenerate proxies in S/4HANA, and then use Integration Suite iflows for execution.
Additionally, SAP also introduced the Metadata Repository in S/4HANA, allowing schemas to be maintained directly within the backend (via the transaction SPXNMIG)—removing the dependency on ESR. However, this represented a shift from the earlier outside-in model to a more backend-driven (“inside-out”) approach.
With the new feature released in Q3 2025 allowing migration of Service Interface objects from ESR to Integration Suite, it’s now possible to manage proxy schemas directly within Integration Suite—just as you did in PI/PO. This advancement removes the need to depend on S/4HANA’s metadata repository or continue operating ESR purely for schema governance. It reintroduces the familiar outside-in development model, allowing interface definitions to remain in the integration layer.
Please also read this blog post, for additional details on proxy generation based on Service Interface migrated to Integration Suite.
This step of migrating your Service Interface object from SAP PI/PO is optional, and you need it only if you want to continue maintaining or modifying the proxy schema in the future. Otherwise, you can proceed directly with migrating runtime artifacts via the migration tooling guided wizard (discussed in the next section below).
D) Migrating Proxy-Based Scenarios (Deployable Components)
While we focused earlier on moving design-time definitions such as Service Interfaces (SI) and Message Types (MT), this step deals with the deployable components that enable actual message processing in Integration Suite.
To clarify the distinction — the Service Interface you migrated in the previous step is not deployed in the Integration Suite tenant. It remains as a repository artifact, referenced by the backend system via SPROXY for proxy generation and linkage at runtime. Its purpose ends there. If, at any point in the future, you need to enhance or extend the schema, you would do so by editing the underlying Message Type that the Service Interface references.
In this step, we focus on migrating the ICO objects as iflows — the deployable components responsible for message execution during runtime.
You can use the migration tooling to convert your existing XI proxy-based configurations into equivalent iflows. Depending on your Migration strategy, you can choose between standard approach or pipeline approach. The pipeline approach offers several operational benefits, such as reduced number of JMS queues, artifact reuse, simplified operations with clearly separated error queues, sophisticated restart mechanisms and Exactly Once message processing – to name a few. Especially for Proxy-based scenarios, the pipeline concept helps in Reliable message processing, decoupling, common entry point for inbound scenarios (as described in the next section). Given these advantages, we recommend that you consider and apply the pipeline concept to migrate your Proxy based scenarios to Integration Suite. Read more about the Pipeline concept in this blog post.
E) Establishing a Common Entry Point
Establish a common entry point for all inbound XI Proxy messages either by modelling your own generic inbound iflow for XI, or leveraging the out-of-the-box generic XI inbound iflow that comes as part of the pipeline concept. The common entry point mirrors the Generic XI Sender Channel setup you may recall from SAP PI/PO. The generic XI inbound iflow, shipped as part of the generic pipeline package is impressively versatile—it can handle all QoS (Exactly Once, Exactly Once in Order, and Best Effort) without additional development or configuration effort. That’s yet another strong reason to choose the pipeline approach.
F) Configuring a Single Destination
As a corollary of setting up a common entry-point iflow, only one HTTP destination is required from your SAP S/4HANA system—pointing to this generic inbound iflow. This simplifies connectivity setup and minimizes administrative overhead.
G) Sender/Receiver-Specific Queues and Federated Landscape Design in Pipeline-Based Proxy Migrations
In this section, we’ll discuss two aspects that could come into play at the intersection of XI Proxy migration and the pipeline concept in SAP Integration Suite:
1) Defining Sender/Receiver-Specific Queues
In classic SAP PI/PO, message monitoring could be conveniently filtered by Communication Component, giving operations team a clear view of message traffic per backend system. While Integration Suite does not mirror this behaviour directly, a similar outcome can be achieved within the pipeline setup by defining sender- or receiver-specific JMS queues. This approach allows message segregation per system, targeted retries, and operational isolation without interfering with other integrations. More details on configuring sender / receiver specific JMS queues for pipeline can be found in this Help portal page.
2) setting up separate pipelines for federated landscapes
Many enterprises historically operated multiple ABAP backends—such as Finance, SRM, or CRM—supported by distinct PI/PO systems aligned by Line of Business (LoB) or regional boundaries. As these organizations move toward Integration Suite modernization and consolidate middleware into a single tenant, it remains important to retain autonomy and governance separation across business domains.
The pipeline approach enables this by allowing you to replicate the standard pipeline package into individual design workspaces—one per LoB or region—supported by consistent artifact naming conventions and Access Policies that control visibility and ownership. This setup helps balance consolidation with distributed control, ensuring each domain can manage its proxy-based integration flows independently.
With this rationale in mind, SAP has published the New Integration Packages for the Pipeline for Cloud Integration.
This model preserves the federated operating style of large enterprises while streamlining governance, monitoring, and operations within a single, cloud-native Integration Suite tenant.
While the considerations in this section—queue separation and federated pipelines—are applicable to other interface types and protocols as well, they are highlighted here because proxy-based interfaces typically form a significant portion of many organizations’ legacy landscape. Addressing these design aspects as part of proxy migration ensures that modernization efforts not only move interfaces to the cloud but also align with scalable, operationally sustainable integration practices suited for the long term.
Most PI/PO systems carry a large footprint of Proxy interfaces. Migrating them to Integration Suite is not just about tool-based conversion but about adopting patterns that keep the setup clean and maintainable in the long run. With the right approach in place, the transition becomes less of a migration task and more of a steady move toward a simplified, future-ready integration landscape.
With the recent features in SAP Integration Suite—such as the ability to migrate Service Interfaces from SAP PI/PO to Cloud Integration and the introduction of the pipeline concept, the topic of migrating XI Proxies to Integration Suite has gained fresh significance. If you’ve been waiting for the right moment to move your proxy-based integrations, this might just be it. The following sections outline key considerations and practical recommendations for a smooth and future-ready transition.A) Modernize While You MigrateWhile SAP supports the migration of legacy protocols such as Proxy, helping customers preserve their existing investments, it’s also a good time to consider modernization. Move away from older or proprietary interfaces toward modern, cloud-native, and interoperable options like SOAP or OData services to ensure long-term stability and easier evolution of your integration landscape.B) Leverage SAP provided AcceleratorsBefore you start rebuilding interfaces from scratch, explore what SAP already provides out-of-the-box, from the SAP Business Accelerator Hub.Prepackaged Integration Content: SAP Integration Suite pre-built content can significantly accelerate migration by making use of pre-delivered integration flows, script collections, etc., spanning across key end-to-end business processes, cutting across your SAP and non-SAP systems.Standard APIs and Events: Consume standard APIs and business events available for your SAP S/4HANA edition to avoid / reduce customization and thus keep the core clean.C) Migrating ESR Proxy Objects to Integration SuiteIn the ECC – PI/PO landscape, the Enterprise Services Repository (ESR) served as the central design-time hub for maintaining and versioning proxy schemas and interface definitions. This enabled the well-established “outside-in” development model, where integration developers first defined the structure in middleware via Data type, Message type and Service Interface, after which ABAPers implemented the Proxy class/method in the backend.When SAP Integration Suite was first introduced, it lacked an ESR-equivalent capability to host and manage proxy schemas. Consequently, one option for customers was to keep their PI/PO ESR systems running to maintain these schemas, regenerate proxies in S/4HANA, and then use Integration Suite iflows for execution.Additionally, SAP also introduced the Metadata Repository in S/4HANA, allowing schemas to be maintained directly within the backend (via the transaction SPXNMIG)—removing the dependency on ESR. However, this represented a shift from the earlier outside-in model to a more backend-driven (“inside-out”) approach.With the new feature released in Q3 2025 allowing migration of Service Interface objects from ESR to Integration Suite, it’s now possible to manage proxy schemas directly within Integration Suite—just as you did in PI/PO. This advancement removes the need to depend on S/4HANA’s metadata repository or continue operating ESR purely for schema governance. It reintroduces the familiar outside-in development model, allowing interface definitions to remain in the integration layer.Please also read this blog post, for additional details on proxy generation based on Service Interface migrated to Integration Suite.This step of migrating your Service Interface object from SAP PI/PO is optional, and you need it only if you want to continue maintaining or modifying the proxy schema in the future. Otherwise, you can proceed directly with migrating runtime artifacts via the migration tooling guided wizard (discussed in the next section below).D) Migrating Proxy-Based Scenarios (Deployable Components)While we focused earlier on moving design-time definitions such as Service Interfaces (SI) and Message Types (MT), this step deals with the deployable components that enable actual message processing in Integration Suite.To clarify the distinction — the Service Interface you migrated in the previous step is not deployed in the Integration Suite tenant. It remains as a repository artifact, referenced by the backend system via SPROXY for proxy generation and linkage at runtime. Its purpose ends there. If, at any point in the future, you need to enhance or extend the schema, you would do so by editing the underlying Message Type that the Service Interface references.In this step, we focus on migrating the ICO objects as iflows — the deployable components responsible for message execution during runtime.You can use the migration tooling to convert your existing XI proxy-based configurations into equivalent iflows. Depending on your Migration strategy, you can choose between standard approach or pipeline approach. The pipeline approach offers several operational benefits, such as reduced number of JMS queues, artifact reuse, simplified operations with clearly separated error queues, sophisticated restart mechanisms and Exactly Once message processing – to name a few. Especially for Proxy-based scenarios, the pipeline concept helps in Reliable message processing, decoupling, common entry point for inbound scenarios (as described in the next section). Given these advantages, we recommend that you consider and apply the pipeline concept to migrate your Proxy based scenarios to Integration Suite. Read more about the Pipeline concept in this blog post.E) Establishing a Common Entry PointEstablish a common entry point for all inbound XI Proxy messages either by modelling your own generic inbound iflow for XI, or leveraging the out-of-the-box generic XI inbound iflow that comes as part of the pipeline concept. The common entry point mirrors the Generic XI Sender Channel setup you may recall from SAP PI/PO. The generic XI inbound iflow, shipped as part of the generic pipeline package is impressively versatile—it can handle all QoS (Exactly Once, Exactly Once in Order, and Best Effort) without additional development or configuration effort. That’s yet another strong reason to choose the pipeline approach.F) Configuring a Single DestinationAs a corollary of setting up a common entry-point iflow, only one HTTP destination is required from your SAP S/4HANA system—pointing to this generic inbound iflow. This simplifies connectivity setup and minimizes administrative overhead.G) Sender/Receiver-Specific Queues and Federated Landscape Design in Pipeline-Based Proxy MigrationsIn this section, we’ll discuss two aspects that could come into play at the intersection of XI Proxy migration and the pipeline concept in SAP Integration Suite:1) Defining Sender/Receiver-Specific QueuesIn classic SAP PI/PO, message monitoring could be conveniently filtered by Communication Component, giving operations team a clear view of message traffic per backend system. While Integration Suite does not mirror this behaviour directly, a similar outcome can be achieved within the pipeline setup by defining sender- or receiver-specific JMS queues. This approach allows message segregation per system, targeted retries, and operational isolation without interfering with other integrations. More details on configuring sender / receiver specific JMS queues for pipeline can be found in this Help portal page.2) setting up separate pipelines for federated landscapesMany enterprises historically operated multiple ABAP backends—such as Finance, SRM, or CRM—supported by distinct PI/PO systems aligned by Line of Business (LoB) or regional boundaries. As these organizations move toward Integration Suite modernization and consolidate middleware into a single tenant, it remains important to retain autonomy and governance separation across business domains.The pipeline approach enables this by allowing you to replicate the standard pipeline package into individual design workspaces—one per LoB or region—supported by consistent artifact naming conventions and Access Policies that control visibility and ownership. This setup helps balance consolidation with distributed control, ensuring each domain can manage its proxy-based integration flows independently.With this rationale in mind, SAP has published the New Integration Packages for the Pipeline for Cloud Integration.This model preserves the federated operating style of large enterprises while streamlining governance, monitoring, and operations within a single, cloud-native Integration Suite tenant.While the considerations in this section—queue separation and federated pipelines—are applicable to other interface types and protocols as well, they are highlighted here because proxy-based interfaces typically form a significant portion of many organizations’ legacy landscape. Addressing these design aspects as part of proxy migration ensures that modernization efforts not only move interfaces to the cloud but also align with scalable, operationally sustainable integration practices suited for the long term.Most PI/PO systems carry a large footprint of Proxy interfaces. Migrating them to Integration Suite is not just about tool-based conversion but about adopting patterns that keep the setup clean and maintainable in the long run. With the right approach in place, the transition becomes less of a migration task and more of a steady move toward a simplified, future-ready integration landscape. Read More Technology Blog Posts by SAP articles
#SAP
#SAPTechnologyblog
