A successful move from SAP Process Integration (PI) or SAP Process Orchestration (PO) to SAP Integration Suite starts long before the first interface is migrated.
For enterprise IT leaders, the most important early step is understanding the existing integration landscape.
A **SAP PI/PO migration assessment** helps organizations determine what they currently have, which integrations are suitable for migration, which scenarios require changes, where technical complexity exists, and what business risks need to be addressed before the migration begins.
SAP provides a Migration Assessment capability within SAP Integration Suite to analyze existing SAP Process Orchestration interfaces and provide information about complexity, dependencies, functionality categories, and estimated technical migration effort.
SAP’s current migration guidance also recommends beginning with a discovery phase that assesses current interfaces and integration requirements and identifies the target architecture before the migration strategy is finalized.
This makes assessment one of the most important foundations of an SAP PI/PO modernization program.
What Is an SAP PI/PO Migration Assessment?
An **SAP PI/PO migration assessment** is a structured evaluation of an organization’s existing SAP PI/PO integration landscape before migration to SAP Integration Suite.
The assessment examines both technical and business considerations.
It can help answer questions such as:
- How many integrations currently exist?
- Which interfaces are active?
- Which interfaces are still required?
- Which scenarios are simple or complex?
- Which integrations contain custom development?
- Which interfaces have dependencies?
- Which scenarios can be migrated?
- Which scenarios require adjustments?
- Which scenarios need further evaluation?
- Which interfaces should be redesigned?
- Which interfaces could potentially be retired?
- Which integrations are business-critical?
- What testing will be required?
- What migration sequence should be considered?
- What resources will be required?
The objective is not simply to create an inventory.
The objective is to create enough understanding of the current environment to make informed migration decisions.
Why Is SAP PI/PO Migration Assessment Important?
PI/PO environments often develop over many years.
During that time, enterprises can accumulate:
- Hundreds of interfaces
- Multiple SAP systems
- Third-party applications
- Legacy applications
- Custom mappings
- Custom code
- B2B integrations
- Different adapters
- Complex routing
- Business-specific transformations
- Undocumented dependencies
Some of these integrations may no longer be used.
Others may be essential to daily operations.
Without an assessment, an enterprise may not know the difference.
A migration project that begins without sufficient discovery can therefore encounter unexpected development effort, testing requirements, dependencies, or business risks.
SAP’s migration methodology explicitly places discovery and preparation before migration execution. The discovery phase includes assessing current interfaces and integration requirements and identifying the target architecture.
What Does SAP Migration Assessment Evaluate?
SAP’s Migration Assessment is designed to analyze existing PI/PO scenarios and provide insights into migration complexity and technical effort.
SAP describes the assessment as providing information about areas including:
- Interface complexity
- Dependencies
- Functionality categories
- Technical migration effort
- Migration status
The resulting statuses include:
Evaluation Required
Adjustment Required
Ready to Migrate
These classifications help organizations understand that not every existing scenario has the same migration path.
Importantly, “Ready to Migrate” should not be interpreted as “no work required.”
SAP’s documentation notes that migration-ready scenarios can still require manual adaptations or configuration.
10 Areas IT Leaders Should Evaluate Before SAP PI/PO Migration
1. Complete PI/PO Interface Inventory
The first step is creating a reliable inventory of the current environment.
The inventory should identify:
- Interfaces
- Integration scenarios
- Integration flows
- Sender systems
- Receiver systems
- Adapters
- Message types
- Mappings
- Routing
- Custom code
- Schedules
- Message volumes
- Business owners
- Technical owners
The organization should also distinguish between active, inactive, obsolete, duplicate, and potentially redundant integrations.
An interface inventory provides the foundation for everything that follows.
Without it, the migration scope remains uncertain.
2. Business Criticality
Technical complexity is only one part of the assessment.
IT leaders should also determine how important each integration is to the business.
For example, an integration supporting order processing may be more business-critical than an integration used for an internal reporting process.
A useful classification could include:
| **Business priority** | **Example** | **Assessment consideration** |
| Critical | Orders, payments, production | Extensive testing and controlled cutover |
| High | Procurement, inventory | Detailed dependency analysis |
| Medium | Internal operations | Standard migration planning |
| Low | Non-critical processes | Potential early migration candidates |
| Obsolete | Retired process | Consider retirement |
Business criticality should influence migration sequencing.
A technically simple interface may still require extensive planning if a failure could interrupt an important business process.
3. Technical Complexity
Each integration should be assessed for technical complexity.
Consider:
- Number of systems involved
- Number of transformation steps
- Routing logic
- Mapping complexity
- Adapter types
- Custom code
- Exception handling
- Message size
- Message volume
- Scheduling
- Dependencies
- Security requirements
A simple file-based integration may have a very different migration profile from a complex integration involving multiple systems and custom processing.
This is why interface count alone cannot provide a reliable estimate of migration effort.
4. Custom PI/PO Development
Custom development deserves specific attention.
Older PI/PO environments may contain:
- Java mappings
- User-defined functions
- Adapter modules
- Custom scripts
- Custom routing logic
- Special transformation logic
- Custom error handling
SAP’s current migration documentation specifically provides guidance for migrating Java mappings to Groovy scripts in Cloud Integration.
This means custom components should be identified before finalizing the migration plan.
For every custom component, ask:
Can it be migrated?
Does it need modification?
Can standard Integration Suite functionality replace it?
Should the underlying business logic be redesigned?
These decisions can materially affect project effort.
5. Adapter and Connectivity Assessment
Adapters are another important part of the assessment.
The organization should identify the adapters currently used across the PI/PO environment.
Examples can include integrations involving:
- HTTP
- SOAP
- REST
- SFTP
- FTP
- IDoc
- RFC
- JDBC
- OData
- AS2
- Other enterprise protocols
The assessment should determine how each existing connectivity pattern will be implemented in the target environment.
This is especially important for integrations involving external systems.
Connectivity requirements may also involve:
- Network configuration
- Certificates
- Authentication
- Firewall rules
- Private connectivity
- Credentials
- IP allowlisting
These requirements should be identified before migration waves begin.
6. Integration Dependencies
One of the most commonly underestimated areas of migration is dependency analysis.
One integration may depend on another system, interface, mapping, process, or scheduled sequence.
For example:
System A → PI/PO → System B → System C
Migrating only one part of that chain may create operational problems.
The assessment should therefore identify:
- Source dependencies
- Target dependencies
- Shared mappings
- Shared systems
- Sequential processes
- Batch dependencies
- Scheduling dependencies
- Authentication dependencies
- Certificate dependencies
Dependency mapping helps determine which interfaces should be migrated together.
7. Message Volume and Performance Requirements
Message volume should also be assessed before migration.
Collect information about:
- Average monthly volume
- Daily volume
- Peak volume
- Message size
- Processing frequency
- Processing windows
- Business-critical peaks
This information can influence:
- SAP Integration Suite capacity planning
- Performance testing
- Architecture
- Monitoring
- Migration sequencing
An integration that processes a few hundred messages per month is different from one processing large volumes continuously.
Performance expectations should therefore be documented during assessment rather than discovered after production migration.
8. Security and Compliance Requirements
Security requirements should be evaluated before migration.
Consider:
- Authentication methods
- Authorization
- Certificates
- Credential management
- Encryption
- Network restrictions
- Firewall requirements
- IP allowlisting
- Sensitive data
- Compliance requirements
- Audit requirements
Security configuration can become a significant dependency during production cutover.
For example, an integration may function correctly in a test environment but fail in production because a certificate, firewall rule, credential, or allowlist requirement was not addressed.
Including security in the assessment helps avoid these problems.
9. Testing Requirements
Testing requirements should be identified before migration begins.
The assessment should determine which integrations require:
- Unit testing
- Integration testing
- Regression testing
- End-to-end testing
- Performance testing
- Security testing
- User acceptance testing
SAP’s migration guidance specifically includes test automation as part of the broader migration process and notes that automated testing can reduce risk to critical business processes and reduce manual effort.
Business-critical interfaces should generally receive more extensive validation than low-risk integrations.
10. Target Architecture
An assessment should not focus only on the current environment.
IT leaders should also ask:
What should the future integration architecture look like?
SAP’s migration guidance recommends identifying the target architecture during the discovery phase and aligning the migration strategy with integration patterns and technology choices.
This is an opportunity to evaluate whether the organization should:
- Modernize existing integration patterns
- Introduce APIs
- Use event-driven integration
- Consolidate integration capabilities
- Simplify architecture
- Remove redundant interfaces
- Standardize integration practices
- Improve monitoring and governance
SAP Integration Suite provides capabilities beyond traditional PI/PO integration, including API Management and event-driven integration capabilities.
SAP PI/PO Migration Assessment Checklist
Before starting a migration project, enterprise IT teams should review the following.
Current Landscape
- PI/PO versions documented
- Interfaces inventoried
- Source systems identified
- Target systems identified
- Adapters documented
- Mappings documented
- Custom development identified
Business
- Business owners identified
- Critical processes identified
- Business priorities documented
- SLA requirements documented
- Downtime requirements identified
Technical
- Interface complexity classified
- Dependencies mapped
- Message volumes measured
- Custom code assessed
- Connectivity requirements documented
- Security requirements documented
Migration
- Migration readiness assessed
- Interfaces categorized
- Obsolete interfaces identified
- Redesign candidates identified
- Migration waves considered
- Pilot candidates identified
Testing
- Test scenarios identified
- Regression requirements identified
- Performance requirements identified
- Business validation requirements identified
- Test automation opportunities identified
Target Architecture
- SAP Integration Suite architecture defined
- Integration patterns reviewed
- API requirements evaluated
- Event-driven requirements evaluated
- Monitoring approach defined
- Governance requirements defined
What Are the SAP PI/PO Migration Assessment Categories?
SAP’s Migration Assessment currently uses three important migration statuses.
Ready to Migrate
This indicates that the scenario is considered suitable for migration based on the assessment.
However, the organization should still plan configuration, validation, testing, and any applicable manual adaptations.
Adjustment Required
These scenarios require changes before or during migration.
The required changes can vary depending on the functionality involved.
Evaluation Required
These scenarios require further analysis before the migration path can be determined.
This category should not automatically be treated as a failed migration candidate.
Instead, it indicates that additional technical investigation is required.
SAP documents these three statuses as part of its current Migration Assessment capability.
What Should Be Done With Obsolete PI/PO Interfaces?
One of the biggest opportunities during assessment is identifying interfaces that no longer provide business value.
An enterprise may have interfaces connected to:
- Retired applications
- Replaced systems
- Old business processes
- Duplicate processes
- Temporary integrations
- Legacy projects
Migrating these interfaces without validating their business relevance can increase project scope unnecessarily.
The assessment should therefore ask:
Is this interface still required?
If the answer is no, retirement may be more appropriate than migration.
This process is often referred to as integration landscape rationalization.
How Should Interfaces Be Prioritized for Migration?
After assessment, interfaces can be organized into migration waves.
A practical prioritization model can consider:
| **Factor** | **Questions** |
| Business criticality | What happens if the integration fails? |
| Technical complexity | How difficult is the migration? |
| Dependencies | Does another process depend on it? |
| Migration readiness | Is it ready, adjustable, or requiring evaluation? |
| Testing effort | How extensive is validation? |
| Business timing | Are there blackout periods or peak seasons? |
| Strategic value | Can modernization provide additional benefits? |
This creates a more structured migration roadmap.
The first migration wave may be used to validate the methodology with selected scenarios before larger and more critical migration waves begin.
What Documents Should an SAP PI/PO Assessment Produce?
A useful assessment should result in practical project documentation.
Depending on the project scope, this may include:
Interface Inventory
A structured list of existing integrations.
Complexity Matrix
Classification of integrations based on technical complexity.
Dependency Map
Relationships between systems and interfaces.
Business-Criticality Matrix
Identification of critical processes.
Migration Readiness Report
Classification of scenarios according to migration status.
Target Architecture
Recommended SAP Integration Suite architecture.
Migration Roadmap
Suggested migration waves and sequencing.
Risk Register
Known technical, business, security, and operational risks.
Effort Estimate
Estimated resources and effort for the migration.
Testing Strategy
Expected testing requirements.
These deliverables give enterprise leadership a basis for approving the next stage of the migration program.
How Long Does an SAP PI/PO Migration Assessment Take?
There is no universal assessment duration.
The timeframe depends on:
- Number of interfaces
- PI/PO landscape size
- Number of connected systems
- Documentation quality
- Custom development
- Number of business units
- Number of environments
- Complexity of integrations
- Required depth of analysis
A small environment with a limited number of well-documented integrations can be assessed more quickly than a global enterprise environment with hundreds or thousands of integrations and multiple business units.
The assessment timeline should therefore be based on the actual landscape rather than a generic number of days.
Can SAP PI/PO Migration Assessment Estimate the Final Project Cost?
It can help improve the estimate, but it should not be treated as an exact final project price.
The assessment can provide information about:
- Technical complexity
- Migration status
- Dependencies
- Functional characteristics
- Estimated migration effort
SAP describes its Migration Assessment as providing technical effort estimation for migration.
However, the final project budget can also depend on:
- Testing
- Architecture
- Project management
- Business validation
- Security
- Connectivity
- Training
- Cutover
- Post-go-live support
- SAP Integration Suite subscription
- Redesign requirements
Therefore, assessment results should become an input into the business case rather than the only basis for the final project budget.
Common SAP PI/PO Assessment Mistakes
Starting Development Before Assessment
Beginning migration work before understanding the landscape can create scope changes later.
Looking Only at Interface Count
Two environments with the same number of interfaces can have very different complexity.
Ignoring Business Criticality
Technical classification does not tell the whole story.
Ignoring Custom Code
Custom mappings and other extensions can materially affect migration effort.
Ignoring Dependencies
A technically independent-looking interface may be part of a larger business process.
Migrating Everything
Obsolete integrations should be evaluated before migration.
Ignoring the Target Architecture
Simply recreating legacy patterns may miss opportunities to modernize.
Treating “Ready to Migrate” as “No Work Required”
SAP explicitly notes that migration-ready scenarios can still require manual adaptations or configuration.
SAP PI/PO Assessment vs SAP PI/PO Migration
These two activities should not be confused.
Assessment
The assessment determines:
What do we have?
What can be migrated?
What needs adjustment?
What needs deeper evaluation?
What risks exist?
What effort should we expect?
Migration
The migration executes the plan.
This can include:
- Integration flow migration
- Redesign
- Configuration
- Development
- Testing
- Deployment
- Cutover
- Stabilization
Assessment therefore comes before large-scale migration execution.
When Should an Enterprise Start Its SAP PI/PO Assessment?
Timing depends on the organization’s current PI/PO version, migration scope, business roadmap, and desired target date.
SAP states that mainstream maintenance for SAP Process Orchestration 7.5 runs through the end of 2027, with an option for extended maintenance through the end of 2030.
That timeline makes migration planning relevant for organizations still operating PI/PO.
An enterprise does not need to wait until the maintenance deadline to begin assessment.
Starting earlier can give the organization time to:
- Understand its landscape
- Remove obsolete interfaces
- Plan architecture
- Estimate budget
- Select a migration partner
- Run a pilot
- Schedule migration waves
- Coordinate business teams
SAP’s current migration program also encourages organizations to analyze their current environment, develop a modernization plan, and then migrate and test the new environment.
Frequently Asked Questions About SAP PI/PO Migration Assessment
What is SAP PI/PO migration assessment?
SAP PI/PO migration assessment is the process of evaluating an existing PI/PO integration landscape to understand its interfaces, dependencies, complexity, migration readiness, and technical migration requirements before moving to SAP Integration Suite.
What does SAP Migration Assessment do?
SAP Migration Assessment analyzes SAP Process Orchestration scenarios and provides information about their complexity, dependencies, functionality categories, and technical migration effort.
What are the SAP migration assessment statuses?
SAP currently identifies scenarios as **Evaluation Required, Adjustment Required, or Ready to Migrate**.
Does Ready to Migrate mean the interface needs no work?
No. SAP notes that scenarios classified as Ready to Migrate can still require manual adaptations or configuration.
Should obsolete interfaces be included in migration?
They should first be evaluated for business relevance. If an interface is no longer required, retirement may be more appropriate than migration.
Can SAP PI/PO migration assessment identify custom code?
The assessment can help identify functionality and complexity, but organizations should also perform detailed technical analysis of custom mappings, scripts, adapter modules, and other extensions.
Does migration assessment provide a complete project estimate?
It can provide technical migration-effort information, but the complete project budget also depends on architecture, testing, security, project management, cutover, support, licensing, and other requirements.
Can SAP PI/PO migration assessment reduce migration risk?
A detailed assessment can help identify dependencies, complexity, migration challenges, and business-critical scenarios before production migration. SAP positions assessment and planning as early stages of its migration approach.
Final Thoughts
A detailed **SAP PI/PO migration assessment** gives enterprise IT leaders visibility before committing to a large migration program.
The assessment should answer five fundamental questions:
What do we have today?
What does the business still need?
What can be migrated?
What needs to change?
How should we move forward?
SAP’s current tooling can help organizations evaluate PI/PO scenarios, while SAP’s migration guidance places discovery and preparation before migration execution.
For CIOs, CTOs, SAP managers, and enterprise architects, the assessment should therefore be treated as a strategic planning exercise rather than simply a technical inventory.
A well-structured assessment can help an enterprise identify obsolete integrations, understand technical complexity, map dependencies, prioritize business-critical interfaces, plan testing, define the target architecture, and develop a more realistic migration roadmap.
The result should be a migration plan based on evidence from the existing integration landscape rather than assumptions about how many interfaces need to be moved.
Related SAP PI/PO Migration Topics
For organizations planning a complete migration program, the next areas to evaluate include:
- **SAP PI/PO Migration Strategy:** How can enterprises move to SAP Integration Suite without business disruption?
- **SAP PI/PO Migration Cost:** What should enterprises budget for the move?
- **How to Choose an SAP PI/PO Migration Partner:** What questions should enterprise IT leaders ask?
- **SAP PI/PO End-of-Life Planning:** What should enterprises do before the maintenance deadlines?
- **How to Select the Right SAP Integration Partner:** What should global enterprises evaluate?
- **SAP Integration Consulting Services:** What should enterprises expect from a strategic partner?
- **When Should Your Enterprise Outsource SAP Integration Services?**
- **How Much Do SAP Integration Services Cost?**
- **SAP Integration Project Planning:** How should enterprises estimate scope, timeline, risk, and cost?
