Migrating SAP PI to SAP Cloud Integration: A Practical Logistics Scenario

Migrating an interface from SAP PI to SAP Cloud Integration (SAP CI) is often less about changing the business process and more about redesigning the technical integration path around it. That was exactly the case in one of our recent migration scenarios: a logistics-related interface that already worked in production, but still relied on an SAP PI-based integration route.

The business requirement itself stayed unchanged. An external logistics sender delivered shipping-related data, the payload was processed, transformed into an SAP-compatible target format, and handed over to the backend. What changed was the technical architecture: instead of routing the message through SAP PI, the new target design moved the processing path into SAP CI.

To keep the example anonymous, the scenario can be described in generic terms. The sender transmits a JSON-based logistics payload via an internal service layer. In the legacy model, the service layer forwarded the request to SAP PI, which then handled the downstream integration. In the target model, SAP CI replaces SAP PI as the central integration layer.

Keeping the business process stable

One of the most important principles in this migration was to avoid unnecessary functional change. The intention was not to redesign the business logic, but to replace the transport and processing architecture around it.

The backend still expected an IDoc-compatible target structure, so the migration focused on how to:

• receive the payload
• route the message
• transform the structure
• deliver the output to the target system

This reflects a common migration strategy: keep the business process stable and isolate the migration effort to the technical integration design.

The target pattern in SAP CI

The implemented design was intentionally split into reusable processing layers rather than one large iFlow.

At a high level, the new architecture was built from four logical stages:

• HTTP entry flow receiving the inbound JSON payload
• JMS-based handover as an asynchronous decoupling point
• Generic route-resolution flow using Value Mapping
• Business-specific transformation flow followed by a generic outbound IDoc sender

This structure proved useful for two main reasons.

First, it kept the business mapping logic isolated from reusable platform logic such as routing and receiver determination.
Second, it improved runtime transparency, since each major handover point became technically visible and easier to monitor.

Reusing existing mapping logic

A particularly useful aspect of the migration was the reuse of an existing SAP PI transformation.

Instead of rebuilding the mapping logic from scratch, the source-to-target transformation was transported and reused in SAP CI. This preserved the proven mapping behavior while moving execution into the cloud runtime.

This highlights an important practical insight: not every PI-to-CI migration requires a full redesign of transformation logic. In many cases, reuse is both technically feasible and operationally efficient.

Making routing generic

Another design decision was to keep both route resolution and receiver determination generic.

Instead of hardcoding ProcessDirect paths or target-specific endpoints into the business flow, the implementation used Value Mapping to resolve these decisions centrally.

This means:

• business-specific flows focus on transformation and interface logic
• technical routing and connectivity remain configurable

This improves reuse and flexibility, but also introduces a dependency on correct Value Mapping maintenance. As a result, operational quality of configuration becomes more critical in the target architecture.

What the migration teaches

Even in a relatively contained scenario like this, several broader lessons become visible:

• PI-to-CI migration is not a simple 1:1 replacement
• Separation of concerns improves maintainability and clarity
• JMS enables decoupling but requires monitoring discipline
• Successful CI processing does not guarantee end-to-end delivery

These insights apply beyond this specific example and reflect common patterns in cloud-based integration design.

Final thought

A good SAP PI-to-CI migration is not just about moving an interface to the cloud.

It is about deciding:

• what should remain business-specific
• what should become reusable
• where responsibilities should be separated

This is what makes modern integration architectures more modular, more transparent, and better aligned with cloud-native design principles.