Why You Need a Migration Strategy, Not Just a Migration Tool
SAP Process Orchestration hits end of mainstream maintenance in 2027. No new features, limited support, and increasing pressure to move to SAP Integration Suite. If you are running PI/PO today, migration is not a question of if but when.
Here is the problem: most teams treat this as a technical lift-and-shift. They run SAP's migration assessment tool, see "Ready to Migrate" on half their interfaces, and start clicking buttons. Six months later they are stuck. Credentials are missing. Exception handling is gone. Parameterized mappings were never migrated. The interfaces that SAP said were "ready" need significant post-migration work before they are production-ready.
This guide covers the actual process from start to finish. Not the marketing version. Not the SAP documentation summary. The real steps, the real challenges, and the real solutions based on what we see in the field migrating hundreds of interfaces for enterprise customers.
If you are an integration architect or Basis consultant tasked with planning or executing a PI/PO migration, this is for you. If you are looking for someone to handle it, we do that too.
Stage 1: Assessment with SAP's Standard Tooling
Before you migrate anything, you need to know what you have. SAP provides a migration assessment capability within Integration Suite that connects to your PO system, extracts your landscape data, and generates an evaluation report.
What the Tool Does
The process has two phases. First, data extraction: the tool connects to your PO system and pulls every IDoc, operation mapping, service interface, communication channel, and configuration scenario. It catalogs your entire integration landscape.
Second, scenario evaluation: the tool analyzes each interface and produces a report with three key outputs.
The Three Assessment Categories
Ready to Migrate means an equivalent pattern exists in Cloud Integration. You can move the artifacts from PO to CI with minimal effort. The adapter types, message mappings, and routing logic all have direct counterparts.
Adjustment Required means the interface can be migrated but needs modifications first. Common examples include interfaces using File Content Conversion (FCC), which is not directly supported point-to-point in CI. Or interfaces with function libraries that require a specific migration sequence to preserve dependencies.
Evaluation Required means significant effort is needed. The interface uses custom adapter modules that cannot be migrated, Java mappings that have no automated conversion path, or patterns with no direct CI equivalent.
What Else the Report Gives You
Beyond the three categories, you get an adapter summary showing every adapter type in use across sender and receiver channels. This is critical because several PI/PO adapters have no native CI equivalent, and you need to identify those gaps before creating a timeline.
You also get complexity sizing (small, medium, large) per interface based on the scenario evaluation. This feeds directly into effort estimation.
What the Tool Does Not Give You
The SAP assessment tool tells you what can be migrated. It does not tell you what should be migrated. That distinction is where the real planning begins.
Stage 2: The Second-Level Assessment — What SAP's Tool Misses
The standard assessment gives you a solid technical baseline. But if you build your migration plan purely from that report, you will migrate interfaces you should have retired, miss functionality gaps that surface in production, and discover landscape inconsistencies too late to fix them cheaply.
What Can Be Migrated vs. What Should Be Migrated
Every PI/PO landscape that has been running for 10+ years has dead weight. Interfaces that were built for a one-time data load and never decommissioned. Interfaces for systems that were replaced years ago but nobody turned off the integration. Interfaces that run daily but nobody consumes the output anymore.
Every interface you retire is one you do not have to migrate, test, monitor, or maintain in Cloud Integration. A thorough second-level assessment typically identifies 20-30% of interfaces as candidates for retirement. That is not a small number when you are looking at 200+ interfaces.
Landscape Consistency Across Environments
Before you start migrating, compare your development, quality, and production PI/PO environments. Are they in sync? Do you have interfaces in development that never made it to production? Do you have configuration differences between QA and production that will cause migrated interfaces to behave differently?
If your environments are out of sync, you need to decide which environment is your source of truth before you start extracting and migrating. Getting this wrong means migrating interfaces that should not exist or missing interfaces that should.
Functionality Gaps in Cloud Integration
Some capabilities that exist in PI/PO do not have a direct equivalent in Cloud Integration. The most significant one is message reprocessing. In PI/PO, you can reprocess failed messages directly. In CI, this functionality is not natively available in the same way.
If your operations team relies on message reprocessing as part of their daily workflow, migrating the interface as-is will break their process even if the interface itself works perfectly. You need to identify these gaps during assessment, not after cutover.
Enhancement Opportunities
Migration is also an opportunity. If you are moving an interface anyway, should you also modernize the pattern? Should you add an event broker for decoupling? Should you consolidate multiple point-to-point interfaces into a single publish-subscribe pattern? These decisions belong in the assessment phase, not the execution phase.
Stage 3: Technical Challenges and How to Handle Them
This is the section most migration guides skip. SAP's "Ready to Migrate" label means the tool can move the artifacts. It does not mean the interface is ready for production. Here are the specific gaps you will encounter and how to address them.
Credentials Are Not Migrated
When you migrate an interface from PO to CI, the security credentials do not come with it. Every communication channel that requires authentication will show an error after migration. For a landscape with hundreds of interfaces, each with sender and receiver channels, manually creating and configuring credentials is a massive time sink.
Solution: Automate credential creation using the CI API. Script the creation of security material (user credentials, OAuth tokens, certificates) and the configuration of credential names in each channel. This turns days of manual work into minutes.
Naming Conventions Differ Fundamentally
PO uses the System Landscape Directory (SLD) with business components, business systems, and parties. CI has no equivalent concept. When you migrate, you get generic names like "BusinessComponent_SenderSystem" or "BusinessComponent_Receiver" which tell you nothing useful.
Solution: Define your CI naming convention before you migrate the first interface. Decide on a standard for iFlow names, sender/receiver component names, and package organization. Common patterns include: Interface ID + Sender + Receiver, or business domain + interface purpose. Apply the naming convention programmatically after migration rather than renaming manually.
Exception Handling Is Not Migrated
SAP's migration tool creates an exception subprocess with a start and end event but nothing in between. Your migrated interfaces have no error handling. When something fails, it fails silently with no alerting, no logging, and no recovery path.
Solution: Build a common exception handling iFlow that every migrated interface calls. This child iFlow handles error logging, email notifications, and any custom error routing your operations team needs. After migration, inject the exception subprocess call into each parent iFlow. This is another strong candidate for automation.
Parameterized Mappings Are Not Supported
If your PO interfaces use parameterized message mappings, the migration tool cannot handle them. It creates a mapping step placeholder but does not import the actual mapping or the parameter values. You are left with an empty block.
Solution: The pattern in CI is to use a Content Modifier to set the parameter values as exchange properties, then reference those properties in a Groovy script within the mapping step. The parameter values should be externalized (configurable, not hardcoded) so they can differ across environments. This requires scripting for each interface that uses parameterized mappings, but the pattern is consistent and automatable.
Value Mappings Are Not Migrated
SAP's tool does not migrate value mappings. If you have 200 value mappings in your PO landscape, each with potentially hundreds of entries, you are looking at weeks of manual data entry to recreate them in CI.
Solution: Use the CI API to automate value mapping creation. Extract the value mapping data from PO programmatically, transform it to CI's format, and import it via API. This handles both the mapping definition and all the individual entries. Critical for avoiding data entry errors when value mappings contain hundreds or thousands of rows.
Java Mappings Must Be Rewritten
Java mappings cannot be migrated to Cloud Integration. There is no automated conversion path. Each Java mapping needs to be rewritten, typically as a Groovy script or XSLT transformation.
Solution: This is the single biggest effort driver in most PI/PO migrations. Triage your Java mappings by complexity. Simple transformations can be rewritten as message mappings or XSLT. Complex business logic mappings need Groovy rewrites. For large portfolios, consider whether AI-assisted code conversion can accelerate the rewrite process. Budget significant time here; underestimating Java mapping effort is the most common planning mistake.
Adapter Modules Are Not Supported
Custom adapter modules developed for PI/PO cannot be migrated. The adapter framework is fundamentally different in CI.
Solution: Analyze what each adapter module does. Many implement functionality that is now available natively in CI through standard adapters or integration flow steps. For the remainder, the logic needs to be reimplemented as part of the integration flow (Groovy scripts, custom adapters, or process orchestration within the iFlow).
Dynamic Configuration Needs Special Handling
PI/PO's dynamic configuration (setting adapter parameters at runtime via message headers) has no direct equivalent in CI. The mechanism for passing runtime values to adapters is different.
Solution: Use CI's exchange properties and headers to achieve the same result. Map dynamic configuration values from the message payload or external parameters into CI's runtime properties. This requires reworking the configuration logic for each affected interface, but the CI approach is actually more transparent and easier to debug.
File Content Conversion Is Not Directly Supported
FCC in PI/PO handles flat file to XML conversion inline within the file adapter. CI does not support this directly in a point-to-point pattern.
Solution: Use a Groovy script or a dedicated conversion step within the iFlow to handle flat file parsing. Alternatively, use the CSV to XML converter available in CI for simpler formats. For complex fixed-width or multi-record flat files, a Groovy-based parser is the most flexible approach.
Function Libraries Need a Specific Sequence
Function libraries can be migrated, but the order matters. If you migrate an interface that references a function library before migrating the library itself, the migration will fail or produce broken references.
Solution: Map your function library dependencies before starting migration. Migrate shared function libraries first, then migrate the interfaces that reference them. This dependency chain should be part of your migration wave planning.
Stage 4: The EDA Pattern for IDoc Migration
If you are migrating IDoc interfaces, do not just recreate the point-to-point pattern in Cloud Integration. This is the most common missed opportunity in PI/PO migrations.
The Problem with Point-to-Point IDoc Migration
In PI/PO, a typical IDoc flow looks like this: SAP sends an IDoc, PO receives it, maps it, and sends it to the target system. One sender, one receiver, direct connection. If you migrate this as-is to CI, you get the same architecture in a new tool. It works, but you have not gained anything beyond moving off deprecated infrastructure.
You have also lost something. PI/PO had built-in message reprocessing. CI does not handle this the same way. Your operations team loses a capability they depend on for handling failed messages.
The Event-Driven Alternative
Instead of point-to-point, introduce an event broker between the sender and receiver. This can be SAP Advanced Event Mesh, SAP Event Mesh, Solace, or any other message broker that fits your landscape.
The architecture becomes: SAP sends the IDoc to CI, CI publishes the event to the broker, and one or more subscribers consume from the broker. This seemingly simple change unlocks several capabilities.
Message reprocessing becomes straightforward. Failed messages sit in the broker queue and can be reprocessed without touching the sender. Your operations team gets their reprocessing capability back, and it is actually better than what PO offered.
Load handling and scalability improve dramatically. The broker absorbs spikes. CI processes at its own pace. You are no longer constrained by the synchronous processing model.
Adding new consumers requires zero changes to the sender integration. Need to send the same IDoc data to a new analytics system? Add a subscriber. No new iFlow development on the sender side. No regression risk to existing consumers.
When to Apply This Pattern
Not every IDoc interface needs an event broker. Apply this pattern when:
- The interface handles high message volumes
- Multiple systems need the same data (current or planned)
- Your operations team needs message reprocessing capability
- You want to decouple sender and receiver lifecycle and availability
For simple, low-volume, single-consumer IDoc flows, a direct migration to CI is perfectly fine. Do not over-engineer interfaces that do not need it.
Stage 5: Post-Migration Enhancement
After SAP's tool migrates your artifacts, you are not done. You are maybe 60% done. These enhancement steps are required before any migrated interface is production-ready.
- Rename artifacts to match your CI naming convention. iFlow names, component names, and descriptions should follow the governance standards you defined during assessment. Automate this; doing it manually for hundreds of interfaces is not viable.
- Add exception handling to every migrated iFlow. Inject the call to your common exception handling iFlow. Verify that errors are caught, logged, and routed to your alerting system.
- Create and configure credentials. Deploy security material (user credentials, certificates, OAuth configurations) to CI's security material store. Configure the credential names in each communication channel. Test authentication end-to-end.
- Handle parameterized mappings. For each interface that used parameterized mappings in PO, create the Content Modifier with externalized properties and update the mapping step to reference them via Groovy.
- Migrate value mappings. Import all value mapping definitions and their entries. Verify the data matches PO. Assign value mappings to the correct iFlows.
- Enable monitoring and alerting. Configure message monitoring, set up alerting rules for failures, and integrate with your existing monitoring tools (Splunk, Datadog, or whatever your operations team uses). If you need end-to-end traceability from sender to receiver, add custom log steps.
- Deploy and test. Deploy each enhanced iFlow. Run unit tests with representative payloads. Validate output messages match what PO produced. Compare before-and-after for critical interfaces.
Do not skip these steps. Do not defer them. Interfaces that go to production without exception handling and proper credentials will fail in ways that are hard to diagnose and expensive to fix under pressure.
Stage 6: Migration Execution — Wave-Based Approach
With assessment complete, challenges identified, and enhancement patterns ready, execution follows a wave-based strategy.
Organize Interfaces into Waves
Group interfaces by business domain, complexity, and dependency. Start with a pilot wave of 10-20 interfaces that span your complexity tiers: a few simple IDOC pass-throughs, a few medium-complexity interfaces with mappings, and one or two complex interfaces with custom logic. The pilot validates your tooling, your automation scripts, and your team's skills.
After the pilot, scale up. Each wave should be large enough to make meaningful progress but small enough that issues are contained. Typical wave sizes are 30-50 interfaces.
Run Parallel Before You Cut Over
For each wave, run PI/PO and CI simultaneously. Send the same messages through both systems and compare outputs. This parallel run catches edge cases that unit testing misses: timezone differences, character encoding issues, payload size limits, and intermittent connectivity problems.
Only cut over to CI when parallel run results match message-by-message for a sustained period. Have rollback plans ready: the ability to switch traffic back to PI/PO within minutes if something goes wrong.
The First 48 Hours
After cutover, monitor aggressively. Set up dashboards for message throughput, error rates, and processing times. Have your team on standby for immediate response. Most issues surface within the first 48 hours as you hit message patterns and edge cases that did not appear during parallel run.
If you want a structured framework for organizing all of this, we are building a PI/PO Migration Readiness Checklist that covers interface inventory, complexity scoring, and migration wave planning.
Getting Started
The 2027 deadline is real, but the bigger risk is rushing without a proper assessment. A well-planned migration is also a chance to rationalize your integration landscape: retire what you do not need, modernize patterns that deserve it, and build a foundation that scales.
Start with the assessment. Understand what you have, decide what should move, and plan the technical approach for the hard parts (Java mappings, custom adapter modules, EDA patterns). The execution becomes straightforward once the planning is solid.
If you are thinking about your S/4HANA migration timeline, PI/PO migration should be coordinated with it. And if you are implementing Clean Core architecture, your new CI integrations should follow API-first patterns from the start.
We help SAP teams plan and execute PI/PO migrations, from initial assessment through post-cutover hypercare. If you want a migration roadmap tailored to your landscape, let's talk.