Our SAP PO to CPI Migration Journey: How We Helped a Client Move 100+ Integrations to the Cloud
- Charafeddine Boushabi
- Nov 14
- 3 min read
Over the past few months, our integration team had the opportunity to lead a large-scale SAP Process Orchestration (PO) to SAP Cloud Integration (CPI) migration for one of our clients.
The project involved migrating more than 100 integration interfaces across multiple systems, partners, and business processes, from SAP S/4HANA to external logistics and B2B platforms.
It was a challenging yet rewarding journey that provided valuable insights into strategy, design, and execution within SAP Integration Suite. This post is the first in a short series where we share our experience, including pitfalls, redesign approaches, and advanced use of Trading Partner Management, B2B capabilities, and pipeline concepts.
Project Context and Objectives
The client’s integration landscape had been operating successfully on SAP PO for years. With SAP’s strategic shift toward cloud-based integration and the approaching end of mainstream maintenance for PO, modernization became necessary.
Their main objectives were:
• Move all integrations to SAP Integration Suite for scalability and future readiness.
• Reduce maintenance efforts while improving monitoring and agility.
• Standardize and modernize integration patterns to support both cloud-to-cloud and hybrid scenarios.
Our team managed the entire migration process, including assessment, planning, rebuilding, testing, and deployment.
Migration Scope and Approach We started by analyzing roughly over 100 interfaces that connected various systems:
SAP S/4HANA (on-premise and cloud)
External B2B partners and EDI networks
CRM, logistics, and third-party platforms
Migration Phases
Assessment and Planning We used SAP’s Migration Assessment Tool to evaluate interface complexity, adapter usage, and mapping dependencies. Interfaces were categorized as lift and shift with minimal changes, refactor with partial redesign, or rebuild where unsupported components required full redesign.
Design and Standardization Clear naming conventions, folder structures, and transport guidelines were established to ensure consistency across the CPI landscape.
Rebuild and Testing Interfaces relying on unsupported PO features such as Java modules or specific adapters were rebuilt using CPI-native patterns that offered better maintainability.
Deployment and Validation Transport Management Service was used for streamlined deployments, and we collaborated closely with business teams during end-to-end testing and validation.
Key Challenges We Encountered
Every migration brings its own set of surprises. Here are a few that stood out — and how we addressed them.
1. Complex Mapping Transformations
Many of the PO interfaces relied heavily on graphical mappings and Java UDFs that couldn’t be reused directly.We re-engineered these mappings using Message Mapping and Groovy scripts, reshaping schemas to align with CPI’s structure.
Tip: Centralizing reusable Groovy scripts and mapping fragments significantly speeds up large-scale migrations.
2. Security and Certificate Handling
Transitioning from an on-prem environment to the cloud required a new approach to key management, connectivity, and secure communications.We implemented a controlled process for certificate lifecycle management across tenants, integrated with BTP’s trust configuration and Cloud Connector.
3. Rebuilding Unsupported Functionalities
Some functionalities available in PO (custom modules, certain adapters) were not directly supported in CPI.We redesigned these using Extension Logic, dynamic routing, and modular iFlow structures that maintained the same business outcome with a more flexible architecture.
4. Testing and Validation
Because CPI handles message processing and error handling differently from PO, end-to-end validation took more effort.We used Postman collections, CPI traces, and automated regression tests to accelerate the process and ensure parity between old and new integrations.
Modern Integration Concepts We Applied
Migration was only half the story — we also used the opportunity to modernize the overall architecture.
Trading Partner Management (TPM)
We implemented TPM to centralize partner-specific configuration, message formats, and connection details.This simplified B2B interface maintenance and made onboarding new partners much easier.
B2B Scenarios and Extension Logic
The client’s environment involved CO-OP partners with multiple shipment locations under the same partner profile.We built Extension Logic in CPI that dynamically handled partner-specific rules, avoiding duplication while preserving flexibility.
Pipeline-Based Design
We introduced a pipeline approach to separate stages like validation, transformation, and routing.This modular design made interfaces reusable, easier to test, and simpler to extend in the future.
Key Takeaways 1. A migration is not a copy-paste exercise. Treat it as an opportunity to clean up and modernize your integration landscape.
2. Standardization and automation pay off. Define conventions early and automate deployments and testing wherever possible.
3. Security and governance must evolve. Moving to the cloud requires new processes for certificates, connectivity, and monitoring.
4. Reusability is key. Invest in reusable templates, mappings, and Groovy libraries to save time across multiple iFlows.
5. Enablement matters. Regular knowledge-sharing sessions helped both our team and the client’s internal IT quickly adapt to Integration Suite.
