SAP PI/PO Migration Roadmap: Why 2027, Not 2030

Many SAP PI/PO migration roadmaps use 31 December 2030 as their planning horizon. SAP committed to 31 December 2027. The three years in between are extended maintenance, which is optional, priced, and something a person in your organization has to actively decide to buy. As of 29 July 2026, approximately 17 months remain until mainstream maintenance ends, not the 53 months a 2030 plan assumes. Where extended maintenance has not been explicitly approved and budgeted, that creates the first planning error. The larger one often sits in the effort estimate, because SAP's own tooling documentation says something quite different from what many planning decks assume it says. This article works through both, then ends with a check you can run against your own plan in about five minutes.

Key Takeaways

A SAP PI/PO migration roadmap using 2030 as its default deadline is planning against the wrong baseline unless extended maintenance has been explicitly approved and budgeted.
SAP's documentation states that a "Ready to migrate" rating does not mean Migration Tooling will handle the migration automatically.
Automated migration covers Integrated Configuration Objects and Receiver Determination objects only, with 20 further limitation categories published by SAP.
SAP frames 60 to 70 percent time savings as a goal, not an achieved result, and only within supported patterns.
Germany's full e-invoicing issuance mandate begins 1 January 2028, one day after PI/PO mainstream maintenance ends.
Edge Integration Cell requires Kubernetes, a production database, a data store and a load balancer; an SAP HANA database licence is not included.

The Decision in One Minute

Build the roadmap backward from 31 December 2027 unless extended maintenance has already been approved and budgeted.
Do not convert Migration Assessment categories into automation percentages.
Count unsupported objects, ccBPM, B2B, custom code and ground-to-ground scenarios separately from the main estate.
Attach statutory e-invoicing dates to affected interfaces before finalizing the wave plan.
Assign Edge Integration Cell infrastructure to a named platform owner where ground-to-ground scenarios exist.

Source note: This analysis links every material claim to official SAP, European Union or national government sources. Where SAP qualifies a statement, we preserve that qualification. Any item we could not fully verify is clearly identified.

SAP PI/PO Migration Roadmap: Why 2027 Must Be the Baseline

Who This Guide Is For

SAP Program Directors deciding whether a date already committed to the board is still credible.
Enterprise and integration architects who own the target landscape decision and need to know what the tooling will and will not carry.
Integration leads who have run a Migration Assessment and are trying to turn its output into a defensible plan.
PMO and finance owners weighing whether to buy extended maintenance and what it does not solve.

If you are looking for an introduction to what SAP Process Integration is, this is not that article. This one assumes you run it.

When Does SAP PI/PO Support Actually End?

Mainstream maintenance for SAP Process Integration and SAP Process Orchestration release 7.5 ends on 31 December 2027. Extended maintenance is available until 31 December 2030, but it is an option you purchase, not a date you inherit.

The difference between those two sentences is the difference between a plan with 17 months in it and a plan with 53.

Milestone	Time remaining as of 29 July 2026	What it is
PI/PO mainstream maintenance ends, 31 December 2027	Approximately 17 months	The date SAP committed to
Extended maintenance ends, 31 December 2030	Approximately 53 months	Optional and priced, then customer-specific maintenance

Several statutory e-invoicing milestones also land inside that window. They are set out in full later in this article, and two collide directly with the maintenance dates.

What SAP Committed To, in SAP's Words

SAP's NetWeaver maintenance strategy page states it plainly. The maintenance of SAP Process Integration and SAP Process Orchestration release 7.5 was extended in line with SAP NetWeaver 7.5, meaning mainstream maintenance until end of 2027 with the option of extended maintenance until end of 2030 under the same conditions described for SAP Business Suite 7.

Two details in that sentence matter and both get lost in summaries. The first is "option." The second is "under the same conditions," which is the only thread connecting PI/PO extended maintenance to Business Suite 7 pricing.

The same page closes the door on older releases. NetWeaver 7.4, 7.3, 7.31 and 7.1x left mainstream maintenance at the end of 2020 with no extension offered. SAP does carve out Application Server ABAP 7.4 and 7.31, which remain supported for the ABAP-based parts of Business Suite 7, but that carve-out does not extend to PI or PO.

Why 2030 Is a Purchase Decision, Not a Deadline

SAP's maintenance strategy for SAP Business Suite 7 sets out the terms. Extended maintenance runs for three years, from the beginning of 2028 until the end of 2030, and carries a premium of two percentage points on the maintenance basis for all support offerings for the scope of SAP Business Suite 7.

That scope clause matters, because it is routinely dropped when the figure is quoted. SAP publishes the premium against Business Suite 7 core applications. For NetWeaver 7.5, and therefore for PI and PO, SAP's wording is only that extended maintenance comes at the same price and conditions. SAP publishes no separate PI/PO figure. The two percent number is an inference SAP permits you to draw, not a price SAP states for your integration platform. If you are building a business case, say it that way.

What comes after 2030 also needs naming. The same page states that customers who do not opt for extended maintenance, or whose extended maintenance has ended, receive customer-specific maintenance. That is a different service with different expectations, and it is not a place to plan a production integration platform into.

The Date Collision With Your S/4HANA Program

SAP aligned the NetWeaver 7.5 maintenance strategy with SAP Business Suite 7 deliberately, and said why: for a safe transition to SAP S/4HANA.

The consequence of that alignment is operational. Your PI/PO end-of-maintenance date and your ECC end-of-maintenance date are identical because SAP designed them to be. The integration migration and the S/4HANA program are therefore competing for the same architects, the same integration and ABAP specialists, the same test environments, the same change freeze calendar, and the same budget cycle. Where the two programs are planned separately, that contention may not appear clearly on either risk register.

You are not behind because your team was slow. You are behind because two programs of that size were scheduled into one window by design, and they are often planned as though they were independent.

Why "Ready to Migrate" Does Not Mean "Automated"

SAP's Migration Assessment tells you whether SAP Integration Suite has the features your integration scenario uses. It does not tell you whether SAP's migration tool will do the work of moving it. SAP's Migration Assessment documentation distinguishes platform compatibility from tooling automation explicitly, and that distinction is the one most often lost in planning.

The Three Migration Assessment Categories

Migration Assessment sorts your integration scenarios into three categories.

Ready to migrate covers scenarios that match what SAP Integration Suite offers. SAP notes they can be moved manually or semi-automatically, and that manual adaptation or configuration may still be required afterwards to reach full functional compatibility.

Adjustment required covers scenarios that partially match, where further adjustments to the end-to-end integration design are needed to reach functional equivalence. SAP gives protocol conversion and changes to the source or target system as examples.

Evaluation required covers scenarios that cannot be directly migrated. SAP is specific about what triggers it: functionality that is limited or unavailable in Integration Suite, scenarios whose purpose or dependencies the tool could not determine, or the presence of custom code such as a custom adapter module whose behavior cannot be automatically analyzed. SAP states that manual analysis is then required to decide whether the scenario is still business relevant and how it could be redesigned.

That third category is where the interesting work hides, and one of its triggers is simply that the tool could not see clearly enough to judge.

The Warning in SAP's Own Documentation

Here is the passage, from SAP's Migration Assessment concepts page, that should change how you read your own assessment output:

"The Migration Assessment categories classify integration scenarios according to the degree of implementation possible in SAP Integration Suite based on the features used. These categories don't indicate the level of automation or support provided by the Migration Tooling... For example, the Ready to Migrate assessment category means that all features currently used in your Process Orchestration environment are available in SAP Integration Suite. It does not mean that the Migration Tooling will automatically handle the migration process."

Take a scenario rated Ready to migrate that uses a custom adapter module. The feature is available in Integration Suite, so the rating is correct. SAP's Migration Tooling limitations page states the tool will not import that module, so a developer rewrites it in JavaScript or Groovy. Green rating, manual build. Both statements are true at once, and a plan built on the rating alone understates the work by one manual rebuild for every interface of that type.

SAP publishes no benchmark distribution across the three categories, so any percentage split presented to you as typical came from a source other than SAP.

How the Effort Estimate Is Calculated

Each rule holds multiple parameters and each parameter carries a weight. SAP calculates estimated effort from those weights, and because the weights are not equal, some rules move the final number far more than others. SAP's Migration Assessment tutorial adds a sizing model on top: small, medium, large and extra large, with a learning curve factor on the reasoning that similar interfaces migrate faster after the first few. That tutorial also states you cannot currently add custom rules or edit the standard ones.

One sourcing note worth having ready for an architecture board: the sizing bands and learning curve appear in the developer tutorial, while the rules and weights mechanism is in the product documentation. They are not the same tier of source.

So the output is a relative measure produced by weights you did not set and cannot change, tuned by a repeatability assumption about your estate. SAP publishes no conversion into person-days. Any person-day figure quoted to you came from somewhere else, and it is reasonable to ask where.

What the Assessment Cannot See

This changes the shape of a roadmap, not just its numbers. SAP publishes the assessment's own limitations, and they are specific.

What the assessment cannot do	SAP's stated limitation
Trace interface dependencies	Cannot detect dependencies between different interfaces in the landscape, and does not conduct business process analysis to check dependent interfaces
Analyze custom code	Custom adapters and custom adapter modules are identified but their source code, internal logic and parameter-level settings are not analyzed. Only standard SAP adapters are evaluated in detail
Assess B2B and BRM	Both are outside the scope of Migration Assessment
Read process logic	Cannot read or analyze internal BPM or ccBPM process logic. It can identify a ccBPM name and its associated scenario, and for BPM only that BPM is in use
Follow code dependencies	Identifies Java mappings, XSLT, function libraries and UDFs, but does not perform recursive analysis of their dependencies
Group objects into scenarios	Each object is analyzed independently on its metadata, so the output stays object-based rather than scenario-based
Count throughput reliably	Multiple scenario identifiers are counted for the same interface, and SAP states reported values may be inaccurate

Look at that list as a whole and a pattern appears. Custom adapter modules, ccBPM, B2B, dependency-heavy interface chains: those are often among the hardest parts of a PI/PO estate to migrate, and they are precisely the things the assessment sees least clearly.

As a result, the assessment can under-represent some of the estate's most difficult migration risks. That is a property of the instrument, not a failure of anyone using it.

How Much Does SAP's Migration Tool Actually Automate?

SAP's Migration Tooling documentation states that the tool currently supports Integrated Configuration Objects and Receiver Determination objects. It works from a defined pattern set and a published list of supported components, and SAP's supported components page states directly that objects containing components outside that list require additional effort, so migration of those scenarios is not supported in the current scope.

That last clause is the one to take to your planning session.

The 60 to 70 Percent Figure, Read Carefully

You will meet this number in almost every conversation about PI/PO migration. Here it is as SAP's own learning material writes it, typo included:

"The goal with the migration tool is to ultimately delivery a migration time savings of approximately 60 to 70% through automation."

SAP's wording is doing three specific things, and retelling flattens all of them.

It is a goal, not a measured result. "The goal is to ultimately deliver" is forward-looking language, and SAP chose it. The sentence immediately before it hedges further, saying that for cases where artifacts match supported scenarios, much of the migration may be automated with some manual changes still possibly required.

It measures time saved, not artifacts moved. A figure about effort reduction gets repeated as though it described the proportion of your estate that migrates by itself. Those are different claims about different things.

It applies inside the supported scope, which is a subset of your interface estate rather than the whole of it.

What the Supported Scope Covers

SAP's supported components list names, for communication channels, HTTP, REST, SOAP, IDOC, Java Web Service, FTP, SFTP, SFSF, XI, RFC, JDBC, Mail, OData Sender, OData V2 Receiver and AS2 adapters. Fifteen types. For events, Timer. For interface objects, service interface, message type, data type and context object. For service interfaces, RFC and IDoc. For mapping objects, message mapping, Java mapping, XSLT mapping, function library and imported archive. Plus XML to JSON conversion, JSON to XML conversion and routing.

Take your adapter inventory and run it against that list. Anything not on it sits outside automated scope.

One point of precision for vendor conversations. SAP publishes a supported list, not an exclusion list, so adapters absent from it are out of scope by omission rather than by exclusion. The effect on your plan is identical. The wording is what you can defend.

Re-Basing the Automation Estimate on Your Own Estate

Work through it in this order and you get a number you can put your name to.

Count the integration scenarios that are ICO-based or built on Receiver Determination objects. Everything else has no automated path.
From that set, keep only the scenarios that match SAP's supported patterns.
From what remains, keep only the scenarios using the fifteen supported channel types.
Subtract the published exceptions, which the next two sections cover.
Apply the time savings goal to what is left, and to nothing else.

The gap between step one and step five is the gap between the plan you have and the plan you can hold up in a review.

What Cannot Be Migrated Automatically

SAP publishes 20 limitation categories for Migration Tooling. Working through them, the objects that need human hands fall into four groups: adapter modules and value mappings, a specific set of mapping constructs, ccBPM, and anything B2B.

Adapter Modules and Value Mappings

Custom adapter modules are not imported automatically. SAP suggests re-implementing them using standard Cloud Integration functionality in JavaScript or Groovy script.

Standard adapter modules are not imported automatically either, though here SAP offers two routes. You can migrate them manually following SAP's adapter modules guidance, or use a released community package to make some of them available in Groovy script. Useful to know before anyone quotes you a rewrite for all of them.

Value mappings are not migrated automatically. They have to be imported as a standalone artifact and assigned to the appropriate message mapping.

Some of these tasks may be straightforward individually. All of them require effort, and in a mature estate there may be a great deal of that effort. This is also the most countable part of SAP's limitations page, because adapter modules and value mappings can be enumerated directly from the Integration Directory.

The Mapping Constructs That Break Estimates

Message mapping carries seven documented limitations, and this is where migration estimates most reliably come apart.

Parameterized message mappings can be imported, but only where the parameter category is Simple Type of the type Import.

Scenarios involving multiple source or target messages are not supported. SAP is granular here: 1:N mappings can be imported, but message splitting is not supported, and N:1 and N:M scenarios, which were typically built using business process management in PI/PO, are not supported at all.

Message mappings using the standard JDBC lookup function are not supported. In Cloud Integration these have to be implemented through XSLT mapping or Process Direct.

Message mappings using the standard RFC lookup function are not supported by the migration tool, and the functionality has to be recreated using Groovy scripts or user-defined functions. Note SAP's scoping on that one. It says the tool does not handle it, which is a narrower claim than saying Cloud Integration cannot do it.

Sender and receiver standard node functions are not supported in Cloud Integration, and SAP states that message mappings using them must be reviewed and redesigned after migration.

Scenarios using RFC or .xml files as the source message are not migrated at all, because SAP states those inbound structures are not supported in Cloud Integration.

Adapter Specific Message Attributes need manual work. If an imported mapping uses ASMA, you create the equivalent headers or properties yourself in a Content Modifier or Groovy script.

Beyond message mapping, Java mappings with supported functions and methods migrate through a Groovy script wrapper, though SAP hedges that more complex Java mappings might not be supported by that approach. XSLT mappings using simple Java classes, RFC and JDBC calls, or value mapping are not supported by the tool. And SAP states that XSLT mappings referenced within another one are mapped incorrectly after migration, which is a more troubling failure than not migrating at all. SAP's scenario and object assessment guidance adds that ABAP mapping is not supported and the logic has to be reimplemented in graphical mapping, XSLT, or JavaScript or Groovy script.

ccBPM, BPM and the Product Decision Hiding Inside Them

There is no automated path for ccBPM. The assessment can identify a ccBPM name and the scenario it belongs to, and that is the extent of it, because SAP states the tool cannot read or analyze the internal process logic.

The part that catches programs out is not the redesign. It is that the work does not have one destination. SAP's integration patterns guidance splits business process management by type: system-centric processes can be implemented using SAP Integration Suite, and for user-centric processes SAP recommends evaluating SAP Build Process Automation. Deciding which of your processes falls on which side is a design exercise, and it ends in two different products.

That is a second product, which means a second license conversation, a second owner, a second set of skills, and a second implementation. Make the call during planning, while it is still a decision rather than a surprise.

Why B2B Is a Separate Program

If you move meaningful EDI traffic, treat B2B as a parallel program rather than a slice of the main one. SAP's B2B migration limitations explain why.

There is currently no direct support of Trading Partner Management objects like UDF, and no direct import of master data such as partner profiles. The EDI XSD format differs between Cloud Integration and PI/PO, which SAP states means direct migration without modification is not possible. Integration scenarios with a sender or receiver channel adapter and EDI separator currently cannot be migrated directly. And OFTP2, RNIF and the relevant message standards are currently not supported in Cloud Integration, Integration Advisor or Trading Partner Management.

We have kept SAP's qualifiers in that paragraph on purpose. "Currently" appears three times in SAP's text and "like UDF" scopes the first claim. Roadmaps that quote these limitations without the qualifiers make SAP's position sound permanent and universal when SAP states neither.

The Failures That Surface After Go-Live

There is a category of SAP-documented limitation that does not stop your migration. It changes how the migrated interface behaves.

Many of these issues do not surface during the automated migration or the initial build. They emerge during integration testing, production-like load testing or audit review. That timing is what makes them a schedule problem rather than a technical one, and it is the honest answer to why a program that tracked green through build can still slip its date.

Interfaces That Migrate Green but Behave Differently

Every row below is drawn from SAP's Known Limitations of Migration Tooling.

Limitation	What SAP states	When you find out
Quality of Service EOIO	The tool migrates adapters configured with EOIO but does not preserve the specific EOIO functionality. The behavior can be achieved using a JMS queue with access type set to Exclusive	Under production-like volume and concurrency, well after the interface was signed off
REST receiver adapter	REST adapters migrate to Cloud Integration as HTTPS with attributes mapped across. Where path variables are used, they are not supported in HTTPS and it throws an error	At runtime, on the first real call, not during migration
Schema validation	The tool does not support the schema validation property, so post-migration manual adjustment is necessary. The function can be rebuilt using the XML validator in Cloud Integration	Often in an audit or a data quality incident, because nothing fails loudly
Fault messages	Fault message generation as supported in PI/PO is not available. Exception handling has to be implemented using exception subprocesses	When an error path is exercised for the first time, which is rarely during happy-path testing
Extended receiver determination	Scenarios with multiple operations are migrated partially and need enhancement afterwards. Those with receiver wildcard and agreement are not supported	Partially migrated interfaces show as done in a tracker, so usually in test
Maintain Order at Runtime	Single-receiver scenarios migrate, but XPath-based interface conditions are skipped and must be added manually. Multiple receivers are not supported	When a message routes somewhere it should not have

Read the right-hand column down the table. Almost none of these surface during the phase where your plan has slack.

The Redesigns That Reach Outside the Integration Team

One limitation deserves separate attention because the fix is not yours to make.

JDBC sender scenarios that select data and later update it within the same transaction are not supported in SAP Cloud Integration, and the migration tool does not handle the behavior either. SAP goes further and closes off the obvious workaround: even if you replicate the logic using a Timer and Request-Reply pattern, the records selected at the beginning may not match those updated at the end, which risks data inconsistency. SAP's stated remedy is a redesign typically involving stored procedures and intermediate status flags at the database layer.

The fix sits inside a database owned by another team, with its own release calendar and its own change control. If your plan treats it as an integration task, the estimate is wrong by however long that team takes to schedule you in.

File conversion has a similar shape. XSD schema files are not migrated, so a developer downloads each one from the Enterprise Services Repository and re-uploads it into the integration flow. Fixed-length field handling is not supported, so file-based objects built on fixed-length fields cannot migrate directly. And 17 file content conversion parameters are marked not supported. Legacy flat-file interfaces need individual inspection, not a bulk pass.

What Happens to Ground-to-Ground Scenarios?

Everything above assumes the target is the cloud runtime. For a large share of a typical PI/PO estate, it is not.

On-premise to on-premise integrations do not move to the cloud runtime. SAP's answer for them is Edge Integration Cell, which SAP describes as an optional hybrid integration runtime that lets you manage APIs and run integration scenarios within your private landscape. You design and monitor in the cloud, then deploy and run inside your own network. SAP names PI migration as an explicit use case for it, so this is the sanctioned path rather than a workaround.

What Edge Integration Cell Requires You to Build

SAP's setup planning page lists as mandatory a Kubernetes cluster, a database (SAP HANA or PostgreSQL), a data store (SAP HANA, Redis or Valkey), and a load balancer. A container registry and an Identity Authentication Service tenant are optional. SAP adds a useful qualifier: when using SAP HANA, the database and data store can share the same instance, so this is not automatically two separate deployments.

For production, SAP requires the database and data store to be deployed separately from the Edge Integration Cell itself. The built-in PostgreSQL and Redis services that ship with it are for test and demo, and SAP states plainly that they are neither highly available nor scalable enough for production.

The deployment uses a fixed Kubernetes namespace, so multiple Edge Integration Cell deployments in the same cluster are not possible. One cell, one cluster.

And there is a line on that same page that changes business cases: the SAP HANA database license is not included with the Edge Integration Cell.

None of this is unreasonable. It is a hybrid runtime and hybrid runtimes need infrastructure. The risk is that the work was scoped as an interface migration when it is a platform engineering project with its own owner, its own budget line and its own lead time.

What You Take On by Running It Yourself

Edge Integration Cell does not have identical capability to the cloud runtime, and the deltas are documented. SAP's runtime scope page states that OAuth2 Authorization Code credentials are not supported in the edge runtime. tRFC is not supported. Destination-based connectivity for API artifacts is supported on the Integration Cell runtime but not on Edge Integration Cell. Multiple virtual hosts are not supported.

One line in that documentation matters more than the rest of the list: the Delay Software Update feature is not available for Edge Integration Cell, because customers manage the edge nodes themselves.

Consider the direction of that. Teams move to a managed platform partly to hand over operational burden, including control of when updates land. At the edge, some of it comes back. You gain data residency and network control, and take on node management and update cadence in exchange. That is a reasonable trade. It is a bad surprise.

Activation is also gated in two ways rather than one. SAP's activation guidance requires a specific service plan assigned to the subaccount, and states the runtime can only be activated within designated SAP BTP regions and cloud service providers. Confirm your region early, because it is not a question you want to ask late.

The Deadlines That Are Not SAP's

Every constraint so far has been SAP's to set and, in principle, SAP's to change. The next set is not.

Your integration layer carries statutory obligations, and those dates do not negotiate. They cannot be moved into phase two, deprioritized for a quarter, or traded against internal scope. They also land on exactly the middleware you are trying to migrate.

Technical migration plans often omit the statutory calendar. That omission matters, because these are among the least negotiable dates in the program.

The Statutory Calendar Running in Parallel

Date	Country or bloc	What is obligated
1 January 2026	Belgium	Structured B2B e-invoicing compulsory for nearly all transactions between Belgian VAT-liable businesses, in Peppol BIS format compliant with EN 16931
1 February and 1 April 2026	Poland	KSeF issuance mandatory, first for taxpayers above 200 million zloty in 2024 sales including VAT, then for all remaining taxpayers. A transitional relief for businesses invoicing at or below 10,000 zloty monthly runs to 31 December 2026
1 September 2026	France	All VAT taxable persons must be able to receive e-invoices through an approved platform. Large and mid-cap companies must also issue, and transmit transaction and payment data
1 January 2027	Germany	Obligation to issue structured e-invoices where prior-year turnover exceeds 800,000 euros
1 January 2027	Poland	Transitional reliefs end and KSeF penalties begin
1 January 2028	Germany	Obligation to issue extends to all remaining businesses
1 July 2030	European Union	Digital Reporting Requirements for intra-EU B2B, with structured e-invoicing becoming the default method

Two notes on reading that table. In Belgium, Peppol capability is mandatory and Peppol is the default channel, but an alternative format and transmission method remain possible by mutual agreement between both parties provided EN 16931 compliance holds. And in Spain, Real Decreto 238/2026 has been in force since 20 April 2026, but the dates on which B2B obligations start are tied to a ministerial order that had not been published as of 29 July 2026, so any Spanish start date quoted to you now is a draft.

The Two Collisions Worth Putting on a Slide

Germany's obligation to issue extends to all remaining businesses on 1 January 2028. PI/PO mainstream maintenance ends on 31 December 2027.

The EU's Digital Reporting Requirements begin on 1 July 2030. Extended maintenance ends on 31 December 2030.

Those are not near misses. They are consecutive days and a six-month overlap. A team planning only to the maintenance dates is, by construction, planning to deliver one statutory obligation immediately after mainstream maintenance ends and another six months before extended maintenance ends.

If you present one thing from this article internally, present those two pairs of dates.

Why the New Obligations Do Not Fit the Old Patterns

The mandates arriving now are not one-way outbound transformations. They require a response to come back from the tax authority or the counterparty and be matched to the document that triggered it.

Spain's Real Decreto 238/2026 requires the recipient to report commercial acceptance or rejection and full effective payment within four calendar days, excluding Saturdays, Sundays and national holidays. France requires payment data reporting alongside transaction data. Both need inbound status handling and stateful correlation between an outbound document and a later inbound response.

Two PI/PO patterns did exactly that work, and neither survives the move intact. The Sync-Async Bridge handled correlation across an asynchronous and synchronous boundary, and SAP states the tool does not support it, so the integration flow has to be redesigned manually. Multi-message correlation was ccBPM's job, and N:1 and N:M scenarios are not supported either.

That overlap should drive which interfaces you sequence first.

How to Rebuild a Roadmap You Can Defend

SAP publishes its own structure and we see no reason to invent a competing one. SAP's transition guidance sets out a three-step model of assess, transform and move, and SAP's interface migration strategy a six-phase project model covering Discover, Prepare, Explore, Realize, Deploy and Run. Those are SAP Activate phases, the same lifecycle that governs every other SAP delivery program in your organization. SAP frames them as adjustable to your needs and preferred project methodology rather than as a fixed sequence.

Use those phases. What follows are the gates SAP's phases do not include, drawn from the limitations above.

Separate the Inventory From the Estimate

Run the Migration Assessment. Then sit down with its own limitations page and manually enumerate everything it told you it could not see: custom adapter modules, ccBPM and BPM internals, BRM objects, B2B and Trading Partner Management objects, dynamic receiver determinations, and dependencies between interfaces.

That second list is your schedule risk, and no dashboard will produce it.

Re-Baseline Automation Against the Supported Scope

Apply the five-step funnel from earlier. The gate is that the funnel runs on counted objects rather than sampled ones, and that a named person signs off the count.

Write the number down with the method next to it. When somebody challenges the estimate in six months, the method is what defends it.

Build Test Cases for the Late Failures

Take the limitations from the go-live section and turn them into test cases before you need them. Ordering behavior under concurrent load. REST calls carrying path variables. Schema validation on every interface that had it. Error paths, deliberately exercised. Routing conditions that depended on XPath.

Then plan the tooling window deliberately. SAP states that regression test tools made available by partner companies can be used free of charge for a duration of 12 months. Twelve months, fixed, expiring. Starting that clock before your estate is ready to be tested wastes the part of it you will need most.

Sequence the Work You Do Not Control First

SAP's Modernization Recommendations cover clean core, integration style, mapping, monitoring, protocol and security. They are assessment-driven suggestions rather than mandatory steps, and SAP notes that depending on your data and the current ruleset you might receive none at all.

Look at the protocol and security ones specifically: HTTP to HTTPS, basic authentication to client certificate or OAuth 2.0, FTP to SFTP, weak SFTP algorithms to strong ones. Every one of those requires a counterparty to act: a bank, a customs authority, a logistics provider, a trading partner with no commercial reason to move at your pace and a change calendar of their own.

Longest lead time, least control, and almost always scheduled last because it looks like cleanup. Put it first.

Put the Statutory Calendar on the Wave Plan Before You Sign It

Identify every interface that touches French, German, Polish, Belgian or Spanish invoicing, and attach the relevant date to it. Those interfaces have an external deadline that outranks your internal sequencing, and finding that out after the wave plan is agreed means renegotiating the plan instead of writing it correctly.

Doing this before the wave plan is signed costs an afternoon. Doing it after costs a renegotiation.

A Five-Minute Check on Your Current Plan

Run these five questions against the plan you have now.

Which date is on it? If the plan works back from 2030 and nobody can name the person who approved buying extended maintenance, you are 17 months from your real deadline, not 53.
What is the automation assumption applied to? If a percentage is applied to your whole interface estate instead of ICO-based scenarios inside supported patterns and adapters, the estimate is built on the wrong denominator.
Does ccBPM have an owner and a target? If nobody has decided between SAP Integration Suite and SAP Build Process Automation, that decision is sitting in your critical path unowned.
Does Edge Integration Cell have an infrastructure owner and a confirmed region? If you have ground-to-ground scenarios and no named platform engineering owner, a whole workstream is missing rather than late.
Does any interface have a statutory date attached to it? If no interface in the plan carries an external legal deadline, either you have no European invoicing traffic or the mapping has not been done.

A concerning answer to any one of these is worth a conversation. Concerning answers to three or more mean the plan needs rebuilding instead of adjusting, and it is much cheaper to know that now.

How This Analysis Was Built

Every figure in this article comes from SAP's primary documentation, SAP's official learning and developer resources, or government and European Union sources. Each is linked at the point of the claim and listed again at the end.

Each claim was checked against its primary source, then independently re-checked. Where SAP's own pages disagree, we have shown both positions rather than picking the more convenient one. The RFC lookup limitation is one example: SAP's tooling page says the migration tool does not handle it, which is a narrower claim than saying Cloud Integration cannot do it, and the difference matters when you are scoping a rebuild.

Two limits on this analysis are worth stating directly. First, it is a documentation and statute review, not a report on a specific customer landscape, so it tells you what SAP has published rather than what any individual migration will cost. Second, our own expertise is in the SAP delivery lifecycle. AiFA Labs develops SASA, an AI platform for SAP requirements, specifications, ABAP and test generation. That commercial relationship is relevant to the final section of this article, which argues that PI/PO migration is largely a delivery-lifecycle problem. SASA does not migrate PI/PO interfaces, and nothing in this article should be read as suggesting it does.

Verification Pending on One French Instrument

On 28 July 2026, France published an instrument dated 27 July relating to the generalization of electronic invoicing. We have confirmed its existence but have not been able to retrieve or verify its full effect. This article therefore continues to use the previously confirmed 1 September 2026 date, which was reconfirmed by the French Ministry of the Economy on 11 July 2026. This article should not be used as sole legal advice, and anyone making a French sequencing decision should check that instrument directly.

The Work the Tooling Leaves Behind

Much of the work created by these limitations is not automated migration work. It is delivery work: requirements, architecture, specifications, development, testing and governance.

Custom adapter modules become Groovy or JavaScript that somebody writes. ABAP mappings and complex Java mappings become new mappings that somebody designs. Fault message handling becomes exception subprocesses that somebody builds. ccBPM becomes integration flows, or a different product entirely, that somebody specifies. Schema validation becomes XML validator steps that somebody adds and somebody else verifies. Regression testing becomes test cases that somebody writes, inside a twelve-month tooling window that expires.

So the delay is not really caused by the tool's limitations. It is caused by the volume of delivery work those limitations release into a team already delivering an S/4HANA program to the identical deadline, with the same people.

That is the problem our team works on. As stated above, AiFA Labs develops SASA (SAP AI SDLC Assist), which automates the SAP delivery lifecycle across requirements, specifications, ABAP and test generation, with the governance evidence attached rather than added afterwards. It does not migrate PI/PO interfaces. What it addresses is the specification, build and test volume that a migration of this shape generates.

If you take one action from this article, make it the five-minute check above. Run it before you speak to any vendor about tooling, including us. A plan you can defend is worth more than a plan that arrives early.

About the Author

Hari Krishna Adepu is the SAP BTP Integration Practice Head at AiFA Labs, where he leads the Integration Center of Excellence and drives large-scale migration programs from Boomi, MuleSoft and legacy SAP middleware onto SAP Integration Suite. A seasoned SAP Integration Architect with 18+ years of experience delivering enterprise-scale integration across SAP and hybrid landscapes, his expertise spans the SAP BTP Integration Suite (Cloud Integration/CPI), API management, event-driven architecture and B2B/EDI. He is an SAP Certified BTP Solution Architect and SAP Certified Integration Developer who still works hands-on with message mapping, Groovy and API design while building the reusable frameworks, standards and governance that keep migration programs on track. That PI/PO-to-Integration-Suite migration experience is the lens this article applies to the roadmap; the architectural, licensing and regulatory claims here rest on the linked primary sources rather than on personal opinion. Read Hari Krishna Adepu's full profile.

Reviewer

Sagar Chakraborty is Director of Artificial Intelligence Innovations and Strategy at AiFA Labs, where he leads the team building SASA (SAP AI SDLC Assist), the company's AI platform for the SAP delivery lifecycle, and works most closely with Fortune 500 companies in life sciences and healthcare. He holds a PhD and a Master of Technology in Artificial Intelligence from IIT Jodhpur, completed a management program at IIM Calcutta, holds two patents in document-processing neural architectures, and has spent over ten years building AI products, starting as a software engineer in 2014 and previously shipping at Amazon Robotics, Wipro and Allied Media. TradeFlock named him one of India's Top 10 AI Leaders in 2025, and his research is connected to AI labs at IIT Jodhpur and IIT Kharagpur. His SAP expertise is in the delivery lifecycle, which is the lens this article applies to migration planning; the architectural, licensing and regulatory claims here rest on the linked primary sources rather than on personal opinion. Read Sagar Chakraborty's full profile. Connect with Sagar on LinkedIn.

References

Every source below was checked on 29 July 2026. Titles are as published by the issuing organization.

SAP PI/PO Migration Roadmap: Why 2027 Must Be the Baseline