How to test migrated PI/PO interfaces in Integration Suite

Key takeaways

Plan from 31 December 2027, the end of mainstream maintenance for PO 7.5, not from the 2030 extended-maintenance date.
Use the Migration Assessment category of each scenario to set how deep you test it.
Prove parity by replaying captured production messages through the migrated iFlow while PO still runs, then comparing outputs against agreed criteria.
Keep the evidence, the rollback path and the business owner's approval together before PO is switched off.

To prove that a migrated PI/PO interface behaves the same in SAP Integration Suite, define parity criteria per interface, use the Migration Assessment category to set the depth of testing, and run the new iFlow side by side with PO on replayed production messages. Keep PO running until the comparison evidence is signed off by the business owner of that interface. Everything below is how we run that sequence on a real estate.

Why this is a sign-off question now

Mainstream maintenance for SAP Process Integration and SAP Process Orchestration release 7.5 ends on 31 December 2027. As of this writing that is roughly 14 months away. Any roadmap that treats 2030 as the working deadline is planning on the extended period, which is a separate decision. Extended maintenance is available until 31 December 2030, but it is an option you purchase, not a date you inherit.

PO does not stop on 1 January 2028. SAP PI/PO 7.5 will not shut down on January 1, 2028. The software continues running. What changes is the support contract. After December 31, 2027, SAP will no longer issue security patches, regulatory updates, or fixes for newly discovered vulnerabilities. For integration developers, the practical risk is that every interface you have not moved becomes a dependency on a platform SAP no longer patches.

The S/4HANA context matters here. Many PO interfaces carry ECC-era IDoc, RFC and file traffic into partners and satellite systems. When the core moves to S/4HANA, some of those interfaces are re-pointed, re-tested or retired anyway. Testing the migrated iFlow is the moment to decide which ones still need to exist.

Step 1: Use the Migration Assessment category to set test depth

The Migration Assessment capability in SAP Integration Suite reads PO design-time objects and sorts each scenario into a category. The three categories drive the test effort more than any other field in the report.

Category	What SAP says it means	Test depth we set
Ready to migrate	Scenarios fully match SAP Integration Suite capabilities and can be migrated manually or semi-automatically. Minor adaptations or configuration adjustments may still be required post-migration, but no changes to the end-to-end integration design are needed.	Full payload comparison on a volume sample, plus the standard regression set. Do not skip it because the tool says "ready".
Adjustment required	Scenarios partially match SAP Integration Suite capabilities. Migration is possible, but changes to the end-to-end integration design are required, such as protocol conversions or source/target system adjustments.	Design review with the owner, then a parity test of every changed step. Expect the protocol change itself to be the main risk.
Evaluation required	Scenarios cannot be directly migrated and require manual analysis. One SAP-cited example is an unsupported communication adapter such as X.400 (the scenario cannot be transferred to the SAP Integration Suite in this form).	Treat as a design project, not a migration task. Decide retire, rebuild or keep on PO, and write a test strategy for the chosen path.

Two cautions. First, SAP's 'Ready to migrate' status does not guarantee automated migration; manual interventions will likely be necessary for unsupported objects and scenarios. Second, the tooling has its own prerequisites. The assessment supports 7.50 SP06 and above, and the migration tool only converts objects in certain states, since only integration configuration objects in status Adjustment required or Ready to migrate can be migrated. Anything in Evaluation required is a manual build, and it needs its own test cases from the start.

Go deeper in the free course PI/PO to SAP Integration Suite Content Migration: Migration Assessment, Migration Tooling and Mapping Regression Tests, which covers the assessment and the mapping regression side of this step.

Step 2: Write parity criteria before you write test cases

"It works" is not a parity criterion. Parity means the migrated interface produces the same business outcome as its predecessor. Confirming that a migrated interface produces the same business outcome as its PI/PO predecessor involves payload validation, mapping comparison, and end-to-end process testing. For each interface, we record the following in the interface inventory before any build starts:

Message volume per day and per peak window, and the business calendar that drives it.
The normalization rules for the comparison, such as ignoring generated timestamps and message IDs, and what must match byte for byte.
Expected behavior on a bad message: error status, alert, retry count and who gets notified.
Acknowledgement, sequencing and duplicate handling, which often differ between PO and Integration Suite.
The receiver's acceptance check, for example the IDoc status the S/4HANA system returns or the API response code the partner expects.

Test by business process, not by interface. Define regression test sets per business process, not per interface, and plan the cutover in waves so that a failed wave never stops the business. A single order-to-cash flow may touch five PO scenarios. Testing them one at a time hides the handoffs where the parity breaks.

Watch the logic that is hardest to move. PI/PO interfaces frequently pass runtime values between processing steps using dynamic configuration objects. In Integration Suite that logic is usually rebuilt with Groovy scripts and exchange properties, so the resulting behavior requires careful validation to confirm the logic transfers correctly. Also test volume. Interfaces handling large payloads, such as bulk IDoc transfers or high-volume batch files, can exhaust available memory if the original PI/PO design relied on processing entire messages at once. A functional pass on a 20-message sample tells you nothing about that.

Step 3: Run PO and the iFlow side by side on replayed messages

The safest proof is a replay. Capture real inbound messages from PO over a representative window, feed them to the migrated iFlow in a test tenant, and compare the outputs with what PO produced for the same input. Automated regression testing – replaying PI/PO messages through Cloud Integration and comparing the output – is the most efficient way to validate at scale.

Figure 1 shows the sequence we use for each wave.

Freeze inventoryConfirm scope, owners and traffic per interface
ClassifyAssign Migration Assessment category and test depth
ReplaySend captured production messages to the migrated iFlow
CompareCheck payloads, routing, errors and receiver acceptance against PO
Run in parallelKeep PO live until the wave passes its exit criteria

Figure 1. The per-wave parity loop: from inventory to parallel run, with PO still live until the evidence is signed off

Parallel running is the right model because interfaces can be rebuilt, tested, and validated in SAP Integration Suite while PI/PO continues running in parallel. The point at which PI/PO is decommissioned and production traffic moves permanently to Cloud Integration is where the real operational risk occurs. Build the switch-over and the switch-back as separate runbook steps, and test both.

Do not assume that a quiet interface is dead. An interface with no traffic during a short observation window may still support year-end processing. Confirm retirement with its business owner before removing it from scope. For wave sizing, SAP's expert guidance has been to start with a representative pilot rather than the easy interfaces. One practitioner guide suggests 10–100 interfaces, depending on landscape size, covering mappings with function libraries, Java mappings, different adapter types, routing and EDI.

Step 4: Monitor for proof, not just for errors

Monitoring is where parity evidence goes missing. Message processing logs in Cloud Integration are short-lived by default. A message is stored for 30 days. After this time, the message is deleted automatically. A replay that runs on day 1 and gets reviewed on day 40 will have lost its evidence unless you exported it. SAP's KBA on reducing that retention exists for tenants that want less, and the same logic applies in reverse: if you need longer, plan for it. You want to reduce the time that Message Processing Logs or MPLs from the default of 30 days to a lower value. Check the tenant setting on day one of the test window.

Also watch the queue statuses during volume tests. A message can end up in a state where the message was involved in multiple node crashes and was therefore not processed. The message isn't automatically restarted as it was probably this message that caused the node to crash. That is a size or design problem, not a retry problem, and it should go into the defect log as one.

Retention rules also differ by product. A SAP Community answer on S/4HANA Public Cloud's Message Monitoring Overview app says that individual (single) messages are retained for 14 days from creation. After this, they're deleted permanently. That is a different application from Cloud Integration monitoring, so do not reuse one retention assumption for both.

For the monitoring and error-handling side of the migrated flows, the free course Integration Monitoring and Error Handling goes further on message states and retries. The overall test design for the landscape is covered in Integration Testing Strategy for SAP Landscapes.

Step 5: Build the evidence pack and get the right sign-offs

Each wave closes with one pack per interface. We keep it short and specific:

The inventory line with owner, business purpose, category and test depth.
The parity criteria, signed before the replay.
Replay run IDs, date range, message counts and the comparison result.
Every defect, its severity and whether it changed the design or the mapping.
The retention setting used, and where the exported evidence is stored.
The rollback runbook step and a record that it was rehearsed.
The decision to decommission the PO scenario, signed by the business owner and the integration lead.

Your interface inventory is the spine of this pack. If you do not have one, the Interface Inventory & Test Tracker is a practical starting point. Keep the test manager, the integration architect and the business owner on the sign-off line. The CIO signs the decommission of the platform only after every wave is closed.

Frequently asked questions

Does PI/PO stop working on 1 January 2028?

No. PO 7.5 keeps running after mainstream maintenance ends on 31 December 2027, but SAP stops issuing standard security patches and fixes for new issues. Extended maintenance is available to 31 December 2030 as a paid option. Plan the migration to finish inside the mainstream window, and treat 2030 as the backstop.

Does the Migration Assessment test my interfaces for me?

No. It extracts design-time objects, categorizes scenarios and estimates technical effort. It does not know what an interface is for or what breaks if it stops. Those answers come from business owners and from replay testing against real messages.

Which PI/PO versions can the Migration Assessment read?

According to SAP's FAQ, the assessment supports 7.31 SP28 and above, 7.40 SP23 and above, 7.50 SP06 and above. Check the support package on your PO system before you plan the extraction, because a lower level blocks the run.

How long should PO run in parallel after the iFlow passes?

There is no SAP-published number, and it varies by interface. The right answer is the one that covers your business calendar, including period-end and year-end runs, and that has a rehearsed rollback. Set it per wave in the exit criteria, not as a program-wide rule.

Sources

What the SAP PO End of Maintenance Means for SLCM Integrations, SAP Community, 2026
What SAP Process Integration/Process Orchestration Customers Need to Know About the 2030 Timeline, SAP Community, 2026
SAP PI/PO Migration Roadmap: Why 2027 Must Be the Baseline, SAPinsider, 2026
FAQ – Migration from SAP Process Orchestration to SAP Integration Suite, SAP Community, March 2026
Using Migration Assessment to Plan Your SAP Process Orchestration to SAP Integration Suite Migration, SAP Community
Use the Migration Tooling, SAP Developers
Persist Messages, SAP Help Portal, Cloud Integration
Managing Messages Stored in Queues, SAP Help Portal, Cloud Integration
3331385 – Lower the retention time of MPL logs in CPI / Integration Suite tenant, SAP Support KBA
Retention policy of message logs (Message Monitoring Overview app), SAP Community
SAP PO to Integration Suite | Migration Assessment Tool, SAP Community
SAP PI/PO Migration to SAP Integration Suite: Strategy, Challenges, and Best Practices, LeverX
SAP PI/PO to Integration Suite Migration Guide, Figaf
SAP PI/PO: This Is how a Successful Migration to SAP Integration Suite Will Be Achieved, FIS
Automatically assess your migration from SAP Process Orchestration Systems to SAP Integration Suite, SAP Blogs, January 2023
SAP PI/PO Migration to Integration Suite: Strategy & Roadmap, IGT Systems
Checklist: migrating from SAP PI/PO to SAP Integration Suite, Oxory

How this guide is made: researched with AI-assisted search across SAP documentation and practitioner sources, with every fact linked to its source. Found an error or have field experience to add? Tell us.