SAP PI/PO to SAP Integration Suite: Planning orchestration beyond the integration layer
Most SAP customers know the integration platform landscape is shifting. Cloud-native platforms are replacing legacy enterprise service buses, with leading vendors adding event-driven architectures, AI-assisted development and self-service tooling to meet the demands of increasingly distributed IT landscapes. SAP was named a Leader in the 2026 Gartner® Magic Quadrant™ for Integration Platform as a Service for the sixth consecutive year, reflecting how central cloud integration has become to enterprise modernization.
In SAP environments, that shift has a name most teams recognize well: SAP Integration Suite.
What makes the conversation different for SAP customers is that it comes with a specific deadline. Around 10,000 organizations are still running SAP Process Integration/Process Orchestration (SAP PI/PO), formerly SAP Exchange Infrastructure, an on-premises middleware platform built on SAP NetWeaver AS Java that functions as an enterprise service bus for application-to-application and business-to-business integration across SAP and non-SAP systems.
Mainstream maintenance for SAP PI/PO ends December 31, 2027. Extended maintenance runs through the end of 2030. If you haven’t started evaluating your path forward, the window for a considered transition is getting shorter.
What SAP Integration Suite brings to the table
SAP Integration Suite, part of SAP Business Technology Platform (BTP), is SAP’s cloud-based answer to the integration platform question. It brings together process integration, API management, event-driven messaging and B2B capabilities in a single platform designed for hybrid IT landscapes. For organizations adopting RISE with SAP, moving to SAP Cloud ERP or extending their SAP BTP footprint, SAP Integration Suite increasingly serves as the strategic integration layer.
The transition from SAP PI/PO to SAP Integration Suite is not a simple swap. A mature SAP environment may have hundreds of integration flows built over many years, each carrying dependencies, business logic and operational assumptions specific to how the SAP PI/PO environment was configured. Some of those flows are strong candidates for migration. Others are deeply embedded in critical, cross-system processes that will require careful analysis before anything moves.
The integration migration itself is a known problem. Many teams have frameworks for it. The less obvious question is what governs the end-to-end business process once integration moves across cloud services, external systems and specialized tools.
Integration flows aren’t the same as business process control
SAP Integration Suite is built to connect systems and move data. That is its purpose, and it handles it well. But an integration flow completing successfully doesn’t automatically mean the business process it supports has completed correctly.
Think through a straightforward example. A supplier file arrives, is picked up by a managed file transfer process, validated and handed off to SAP Integration Suite for transformation and routing. The integration flow delivers its payload to SAP S/4HANA, where a business object is updated. A downstream reporting job then needs to run before the operations team can confirm the result before the business day starts.
Each component in that chain has its own execution boundary. The file transfer system knows whether the file arrived and was delivered. The integration platform knows whether the flow executed. The ERP knows whether the object was updated. But nothing in that picture inherently knows whether the sequence completed in the right order, with the right inputs and within the expected window.
The question most migration plans don’t address early enough is who owns the sequence once the integration layer has done its part.
Connecting RunMyJobs across the SAP integration transition
RunMyJobs by Redwood is designed to answer that question across the full SAP integration landscape. It supports customers at both stages of the SAP PI/PO migration journey.
For teams still running SAP PI/PO, RunMyJobs can orchestrate business processes that depend on existing SAP PI/PO integration flows. That means you can stabilize current operations and maintain process governance while migration planning proceeds, rather than treating the two as separate workstreams.
For teams moving to SAP Integration Suite, the RunMyJobs connector for SAP Integration Suite – SAP Cloud Integration enables RunMyJobs to deploy, monitor and manage iFlows as part of broader, end-to-end automation chains. RunMyJobs tracks iFlow execution status, waits for confirmed completion and triggers downstream steps only when the integration layer has finished its work.
That matters because most business processes extend well beyond the integration layer. They continue into ERP background jobs, data pipeline runs, file exchanges with external partners, analytics refreshes and exception handling workflows. SAP Integration Suite orchestrates none of that by design. RunMyJobs does.
The same principle applies beyond SAP-native integration. Many enterprise landscapes run more than one integration platform simultaneously. RunMyJobs includes pre-built connectors for non-SAP platforms, including Boomi and Informatica Cloud, allowing teams to coordinate SAP Integration Suite alongside other integration tools from one central control layer.
Browse Redwood’s connector portfolio to see how RunMyJobs connects across cloud, integration, data and business applications.
Where managed file transfer requires separate attention
One area that surfaces consistently in SAP PI/PO migration conversations is file transfer.
SAP PI/PO handled more than message transformation and routing for many customers. It also covered file-based exchange scenarios, including B2B file exchange with trading partners and suppliers. As those customers move to SAP Integration Suite, some of those file transfer requirements need to find a different home.
From conversations with customers working through this transition, we’re seeing a pattern: SAP Integration Suite is the right platform for process integration and integration flows, but certain managed file transfer (MFT) requirements sit outside its design envelope. Handling files larger than 40 MB and supporting certain B2B server protocols are two areas where customers have encountered design constraints.
JSCAPE by Redwood addresses those scenarios directly. JSCAPE supports secure managed file transfer for SAP landscapes, including large file exchange and B2B protocols that require dedicated file transfer capabilities. Where SAP Integration Suite handles the integration and transformation work, JSCAPE handles the secure movement of files that fall outside those boundaries. RunMyJobs sits across that architecture, governing the sequence without asking any single platform to exceed its scope.
For more on how these products work together, see how RunMyJobs and JSCAPE deliver secure, end-to-end process automation.
Tracing a business process
Return to the supplier file example above, now with the specific platforms involved. A typical modernized SAP integration process might run as follows.
- A trading partner delivers a large file through JSCAPE
- JSCAPE validates the transfer and signals RunMyJobs that the file is ready for processing
- RunMyJobs triggers the appropriate iFlow in SAP Integration Suite
- Once the iFlow completes, RunMyJobs launches the relevant SAP S/4HANA job, monitors it to confirm completion and triggers whatever reporting or reconciliation step comes next
If the file doesn’t arrive, the chain doesn’t proceed on a fixed schedule. If the integration flow fails, the ERP job doesn’t run on incomplete data. If the SAP job finishes late, the downstream impact is visible across the full process — not buried inside a single system’s log. And it’s even visible in SAP Cloud ALM due to out-of-the-box integration with RunMyJobs.
This is also consistent with the clean core principles that many SAP customers are already pursuing. Instead of custom scripts, local schedulers or manual operational checks embedded in or adjacent to the ERP, process governance runs through an orchestration layer that sits outside the core and spans the full landscape.
Act before the deadline
The SAP PI/PO maintenance timeline gives teams a clear forcing function, but the goal shouldn’t be to reach the last possible moment and swap one integration platform for another.
The more useful frame is: what should your integration strategy look like in a cloud-first SAP landscape? SAP Integration Suite is a strong foundation for cloud-based process integration. JSCAPE addresses MFT requirements that need dedicated handling. RunMyJobs provides the governance layer that makes the whole process observable and controllable from end to end.
Teams still running SAP PI/PO have a meaningful opportunity right now to identify which interfaces belong in SAP Integration Suite, which file-based scenarios need dedicated MFT capabilities and which business processes need enterprise orchestration to hold together across multiple systems.
That planning reduces migration risk. More importantly, it means the architecture that follows is built to be managed, not just migrated.
Explore the SAP Integration Suite connector to see how integration flows connect into governed enterprise automation and how the SAP PI/PO connector bridges your current landscape and your future one without losing process control in between. For file-based SAP scenarios, see how JSCAPE handles large file transfer in SAP environments.
About The Author
Sven Kohlhaas
Sven Kohlhaas is Vice President – SAP Product Lead at Redwood Software. He is responsible for the global success and evolution of Redwood’s SAP-related product portfolio, helping organizations orchestrate complex business processes across their SAP and non-SAP systems. His vision is to drive operational excellence by empowering enterprises to maximize the value of their technology investments.
With almost 20 years of experience in the IT industry, most of which at SAP in high-impact product and engineering roles, Sven is a seasoned leader with unique subject-matter expertise. His background spans enterprise software, service orchestration and automation, SaaS and PaaS cloud platforms, GenAI and ERP systems. This deep technical foundation allows him to bridge the gap between legacy environments and next-generation cloud architectures.