SAP Integration
SAP PI/PO to CPI Migration Basics: A Practical Assessment and Cutover Plan
Learn how to assess SAP PI/PO interfaces, map them to SAP Cloud Integration iFlows, plan testing, and execute a controlled migration with clear monitoring and rollback steps.
On this page
SAP PI and SAP PO to SAP Cloud Integration migration is an interface-by-interface engineering exercise. The reliable approach is to inventory the existing landscape, classify integration patterns, rebuild the required flows, validate message behavior, and cut over in controlled waves.
The work covers more than copying configuration. It includes adapters, mappings, routing, security artifacts, schedules, monitoring, operational ownership, and dependencies in connected SAP and non-SAP systems. Use the SAP integration PI, PO, and CPI overview to establish the product boundaries before creating the migration backlog.
Define the migration scope
Start with a signed inventory of every active and dormant interface. Capture the sender, receiver, business process, direction, protocol, message type, frequency, volume, SLA, mapping objects, monitoring owner, and error-recovery procedure.
Separate interfaces into migration waves rather than treating the landscape as one deployment. A useful first wave contains low-volume flows with stable payloads and simple transformations. High-volume interfaces, synchronous business transactions, tightly coupled custom mappings, and flows with complex exception handling deserve dedicated analysis.
Record interfaces that are technically present but operationally unused. Confirm usage through message logs, application owners, schedules, and downstream reconciliation. Retiring an unused flow requires business approval and a retained record of the decision.
Build the PI/PO baseline
For each interface, export or document the complete runtime behavior from PI or PO. Include communication channels, sender and receiver agreements, interface determinations, operation mappings, imported schemas, value mappings, routing conditions, queues, schedules, certificates, credentials, and external endpoint requirements.
The baseline should describe the message journey, not only the design-time objects. Note where headers are created or removed, where namespaces are changed, how retries work, which errors are retried, and which failures require manual replay.
Use a stable identifier for each interface and keep the original object references in the migration register. This makes it possible to compare the old and new flows during parallel testing and to trace production incidents after cutover.
Map PI/PO patterns to CPI
SAP Cloud Integration implements the target behavior through integration flows, adapters, mappings, routing steps, transformations, externalized parameters, and security material. The target design should preserve the business contract while simplifying unnecessary technical coupling.
For each source pattern, decide whether the target requires a request-reply flow, asynchronous message flow, scheduled integration flow, event-driven trigger, or an API-oriented design. Then map the existing adapter and message-processing steps to the corresponding CPI components.
The SAP CPI iFlow basics guide provides a useful design vocabulary for processes, endpoints, mappings, routing, and exception handling. For adapter decisions, use the SAP CPI adapter types comparison while recording protocol, authentication, connection, and payload constraints for each interface.
Do not copy every legacy step automatically. Remove obsolete enrichments, duplicate transformations, unused routes, and technical workarounds only after confirming their business effect with the process owner.
Assess mappings and payload contracts
Compare the source and target payloads using representative production messages. Include normal messages, optional segments, repeated nodes, empty values, special characters, large payloads, and known business exceptions.
Document whether each mapping is message mapping, XSLT, graphical transformation, JavaScript, Groovy, or another implementation. Identify custom functions and lookup dependencies because these often determine the effort more than the number of visible mapping objects.
The SAP CPI message mapping basics guide is relevant when translating operation mappings and field-level transformations. Preserve the agreed payload contract, including mandatory fields, code conversions, date and number formats, namespace behavior, and fault responses.
A successful functional test validates both content and behavior. Confirm that the receiver accepts the message, the sender receives the expected response, duplicate handling remains safe, and business reconciliation produces the same result as the PI/PO flow.
Plan security and connectivity
Create a separate inventory for certificates, private keys, user credentials, OAuth material, keystores, allowlists, proxies, VPN routes, and endpoint certificates. Record the owner, expiration date, renewal procedure, and target environment for each item.
Keep development, test, and production security material distinct. Externalize endpoints and non-secret parameters so that deployment does not require editing the flow. Store secrets in the appropriate security artifacts and restrict access according to operational responsibility.
Test certificate chains and authentication from the CPI runtime to every receiver. A successful design-time configuration does not prove that the runtime can resolve the host, negotiate TLS, authenticate, or reach the required network route.
Test before cutover
Use several test layers: technical connectivity, message transformation, end-to-end business processing, volume and performance, failure recovery, security, and operational monitoring. Define entry and exit criteria for each layer before the migration wave begins.
Replay sanitized production messages where permitted, then compare old and new outputs using a structured result set. Compare status, payload, headers that affect downstream processing, response codes, business documents, and reconciliation totals.
Test failure paths deliberately. Disconnect a receiver, send an invalid payload, expire a test credential, trigger a mapping exception, and submit a duplicate message. Verify retry timing, alert ownership, dead-letter or failed-message handling, and replay procedures.
Execute a controlled cutover
A cutover runbook should list the change owner, technical contacts, business approver, freeze window, prechecks, deployment sequence, endpoint switch, message-drain procedure, validation steps, monitoring period, and rollback decision points.
Choose a cutover pattern that matches the interface. A short controlled outage may suit a simple asynchronous flow. A staged transition, dual delivery, or endpoint switch may be safer for high-volume or business-critical processing. Define how duplicates are prevented when both platforms can receive traffic.
Before enabling the CPI flow, confirm that the PI/PO flow has reached its drain condition, queued messages are accounted for, receiver systems are ready, and the new credentials and routes have been tested. Capture baseline message counts and business reconciliation values.
After activation, monitor both technical and business signals. The SAP CPI monitoring and error handling guide is useful for defining message-status checks, alert routing, retry handling, and operational ownership during the hypercare period.
Measure migration completion
An interface is complete when its target flow is deployed, security and connectivity are validated, business tests pass, monitoring is assigned, operating procedures are available, and the owner accepts the result. Deployment alone is not completion.
Track wave-level metrics such as migrated interfaces, retired interfaces, open defects, failed-message rate, average recovery time, reconciliation exceptions, and post-cutover incidents. Keep evidence for approvals, test results, endpoint changes, and rollback decisions.
Close the old configuration only after the agreed retention period and reconciliation checks have passed. Preserve enough documentation to explain the old interface identifier, the new flow identifier, the cutover date, and the support owner.
Troubleshoot common migration failures
Messages arrive but produce different business results: compare mapping versions, namespaces, default values, code conversions, and receiver-specific formatting. Then compare the old and new outputs with the same input message.
Authentication fails after deployment: verify the target environment's security artifact, certificate chain, credential owner, endpoint hostname, proxy path, and receiver allowlist. Test from the runtime environment rather than from a developer workstation.
The flow works in testing but fails under load: measure payload size, concurrent messages, receiver response time, queue behavior, transformation cost, and retry amplification. Use representative volume and long-running tests before production activation.
Retries create duplicates: inspect the sender retry policy, CPI retry configuration, receiver idempotency behavior, and business key handling. Define a replay procedure that identifies whether the original message reached the receiver before resubmission.
Operations cannot recover failed messages: document where failures appear, who receives alerts, which messages may be safely replayed, which require correction, and how business reconciliation confirms recovery. A migration is operationally ready only when these actions are tested.
Use a migration decision checklist
Use this checklist for every interface:
- Confirm the business owner and technical owner.
- Record the current PI/PO runtime path and all dependent systems.
- Classify the protocol, payload, mapping, routing, schedule, and error behavior.
- Decide whether to migrate, redesign, consolidate, or retire the interface.
- Build the CPI flow and externalize environment-specific values.
- Provision and test security artifacts and connectivity.
- Compare representative outputs and business results.
- Test retries, duplicates, failures, replay, and reconciliation.
- Approve the cutover runbook and rollback conditions.
- Monitor the new flow through hypercare and formally close the old path.
Migration works best as a governed backlog with measurable acceptance criteria. Treat each interface as a production service with an owner, contract, recovery method, and evidence of successful operation.