- Deadlines are near: SAP will end mainstream maintenance for PI/PO, ECC, and Business Suite 7 in 2027, with costly extensions only until 2030.
- Legacy carries risks: Running on unsupported systems raises compliance and security issues, increases reliance on scarce talent, and blocks innovation by keeping data siloed.
- Integration Suite is a new logic: It’s not just middleware but a unified iPaaS that enables AI-ready architectures, faster integrations, and cleaner upgrades.
- Two types of expertise are critical: Legacy system veterans and certified SAP specialists with migration experience must work together to ensure continuity and modernization.
The countdown has started.
Mainstream maintenance for SAP PI/PO ends in 2027, with limited extension options (at an additional cost) only stretching to 2030. That may sound like plenty of time, but in enterprise time, it’s not much at all. Migrating from PI/PO to SAP Integration Suite is no small lift. These are complex projects that can take months or even years to prepare, execute, and stabilize.
And then there’s the talent factor. Without the right SAP specialists, the pain of migration can grow exponentially. The good news is there are solutions, and in this article we’ll explore strategies to make the journey more manageable.
So, if your organization is still running critical integrations on PI/PO, the clock is ticking. Now is the time to start planning your move.
How many generations behind is SAP PI/PO?
Most companies running on PI/PO today implemented it years (sometimes decades) ago when SAP NetWeaver PI (2002) and later PO (2011) were the standard for on-premise middleware.
These systems were robust, highly customizable, and tightly integrated into ECC and Business Suite. When SAP introduced Cloud Integration (CI) around 2017, many enterprises hesitated: cloud readiness, regulatory concerns, and talent gaps kept them on their existing PI/PO landscapes.
Now, SAP Integration Suite (part of BTP) represents the fourth generation. It’s not just middleware, but a full iPaaS designed for hybrid and cloud-native environments, with APIs, pre-packaged content, and low-code tools. Yet, many organizations still depend on thousands of PI/PO interfaces – some untouched in over a decade, but still business-critical. This is why the migration is not simply technical, but strategic: the longer you stay on legacy, the bigger the talent and compliance risks become.
But PI/PO is not the only legacy tool facing end of life. SAP has already announced the end of mainstream maintenance for ECC 6.0 and SAP Business Suite 7 by 2027, with only costly extended options stretching to 2030. That means many organizations are under pressure on multiple fronts: not only their middleware layer (PI/PO) but also their core ERP and connected modules are running out of runway.
What SAP Integration Suite Brings to the Table
Integration Suite, however, is not just the next version of middleware. It reflects a new logic: Integration has shifted from being a background IT task to being the layer that holds business operations together. Instead of fragmented tools and point-to-point connections, Integration Suite delivers a unified iPaaS platform that combines APIs, event-driven integration, prepackaged iFlows, low-code tools, and governance in one place.
The business reasoning is simple: today’s value doesn’t come from adding more disconnected apps, it comes from creating a flywheel where applications generate data, data powers AI, and AI feeds intelligence back into processes. This feedback loop only works if your integration layer is unified. Legacy PI/PO environments, no matter how well maintained, break the loop by leaving data and processes siloed.
In that sense, Integration Suite it’s SAP’s way of aligning enterprise architecture to an AI-driven, Suite-as-a-Service world.
Businesses are still struggling to migrate
Even with end-of-support deadlines approaching, many enterprises hold back on migration. And the reasons go beyond PI/PO: the same dynamics are evident in the migration from ECC to S/4HANA.
Recent studies shed light on why. According to Horváth, more than 60% of companies experience deviations in budget, schedule, and result quality during S/4HANA migration. Gartner projects that nearly half of ECC customers may still be on legacy ERP by 2027, even though they know support will expire. Projects take 30% longer on average, only 8% finish on schedule, and in most cases, costs spiral well above initial estimates.
The culprits are familiar: underestimated complexity, weak project management, lack of documentation about legacy integrations, and resource shortages. It’s no coincidence that migration has become one of the most feared words for CIOs and business leaders.
Still, beyond that fear (or respect) for these kinds of processes, we are getting closer to the narrow end of the funnel. In the short term there are only two options: extend support until 2030 by paying the extra fee, or start the migration now.
In the long term there is only one: migrate, because Integration Suite will be the only supported option.
Running without mainstream support is a gamble. Technically, ECC or PI/PO landscapes can keep running after deadlines, but without security patches or vendor maintenance, every new vulnerability could expose sensitive data or disrupt access to core systems. For CIOs, that scenario is almost indefensible in regulated industries or in enterprises where uptime is non-negotiable.
Beyond compliance and security, there’s the hidden opportunity cost:
Legacy integration platforms like PI/PO were built for point-to-point connections, not for the unified architecture that modern AI requires to deliver real value. Instead of serving as a central layer that connects knowledge, they leave systems fragmented. The result is slower data circulation, weaker AI models, and greater difficulty deploying enterprise agents. By clinging to outdated systems, organizations are not just delaying progress; they are undermining their own capacity to innovate.
Urgency doesn’t mean rushing
Large-scale migrations are not projects that can be turned around overnight. Depending on the size of the company, the complexity of its architecture, the depth of customization, and the number of integrations in play, the process can take anywhere from several months to a few years.
The heaviest lifts usually come at the beginning and the end. The opening phase is all about decisions and planning: mapping out every existing integration, deciding which can move as they are, which need to be rebuilt, which are mission-critical, and which are outdated or generating unnecessary cost. The closing phase is just as demanding. It involves testing, validation, and real-world use, often uncovering hidden dependencies—those quiet integrations that automated manual work for years and only reveal their value once they are gone.
The middle phase, implementation, should not be underestimated either. It demands mixed teams: legacy experts who know the old systems inside out working side by side with specialists in new suites, apps, and integration patterns.
That combination is what ensures stability on one side and progress on the other.
The economics of migration
The Forrester Total Economic Impact study, commissioned by SAP, offers a glimpse of what companies could gain by migrating now rather than later. It projects a 345% ROI over three years, payback in under six months, and millions in combined savings from faster project delivery, retiring legacy middleware, and giving teams more self-service integration capabilities.
Of course, these are modeled outcomes, not a guaranteed formula.
But they highlight an important point: companies that modernize their integration layer sooner can start compounding benefits earlier. Every project delivered faster means less time-to-value. Every legacy tool retired means one less line item in the IT budget. And every hour saved from IT bottlenecks frees capacity for higher-value initiatives.
In that sense, the real advantage of acting early is not just in the potential cost savings—it’s in creating room to innovate while competitors are still wrestling with legacy.
First step: assessment or partnership?
SAP offers a free assessment program to help customers evaluate their PI/PO landscapes and start planning. This can be a good starting point, but it often falls short of the full picture. Migration is rarely just about interfaces because it involves a lot of different elements like compliance, data governance, connectivity to legacy systems, and new cloud-ready patterns.
If your organization doesn’t have the resources in-house to cover all these angles, this is where many companies turn to a partner. Working with a certified SAP partner could accelerate the process, reduce the risk of disruption, and ensure you’re on the right track to modernize the modules that are critical for the operations of your company.
Migration Approaches: Brownfield, Greenfield, or Hybrid?
On top of whichever migration path a company chooses, SAP strongly recommends following the clean core principle. In its official guidance, SAP defines clean core as keeping the digital core as standard as possible, while moving extensions and custom logic to the Business Technology Platform (BTP) through APIs, events, and cloud services. The idea is simple: a clean core makes upgrades easier, reduces technical debt, and ensures compatibility with the continuous innovations SAP delivers in S/4HANA and Integration Suite.
With that principle in mind, enterprises usually consider three approaches:
- Brownfield (lift-and-shift): existing PI/PO interfaces are migrated with minimal changes. It’s faster, but carries forward technical debt. A fit for organizations with tight deadlines or fewer resources.
- Greenfield (rebuild): redesign integrations from scratch in Integration Suite, using APIs, prebuilt content, and modern methods. This requires more investment but results in a truly future-ready architecture. Ideal for companies with heavy legacy customizations or those aiming for broader transformation.
- Hybrid (selective): the most common scenario. Some integrations are migrated as-is, others are rebuilt, and outdated ones are retired. This approach allows for quick wins while progressively untangling legacy complexity, aligning the integration layer with the clean core principle over time.
Who Runs the Migration: In-House, Partners, or Both?
We’ve already mentioned that companies can either leverage SAP’s free assessments and attempt to manage the migration in-house, or work with a certified partner to accelerate the journey. But this decision deserves a closer look, because it’s a key strategic part of the planning phase.
Defining who will drive the migration requires an honest evaluation of what you already have and what you’re missing: the expertise of your internal team, the complexity of your PI/PO landscape, the level of customization, and the regulatory requirements you must meet. A straightforward environment may lend itself to an internal project, while highly customized or compliance-heavy landscapes often require outside expertise.
This is where companies weigh different delivery models: in-house execution, fully partner-led projects, staff augmentation to fill critical gaps, or dedicated teams that blend external specialists with internal resources.
Let’s take a look at the alternatives companies have:
1. In-house delivery
The company’s own IT and SAP teams lead the migration end-to-end. This is only feasible if there’s enough internal expertise, which is rare for PI/PO-to-Integration Suite transitions.
2. Partner-led (full outsourcing)
A certified SAP partner designs, executes, and governs the migration. Often chosen by enterprises lacking bandwidth or with complex, global environments.
3. Staff augmentation
Instead of handing over the project, companies bring in external experts (integration architects, developers, project managers) to reinforce their existing teams. This works well if the company wants to retain ownership but lacks specific skills.
4. Dedicated team / Managed services
A middle ground where a partner provides a full, dedicated team that operates almost as an extension of the internal IT department. Unlike augmentation, this model usually comes with accountability for delivery, not just extra hands.
5. Hybrid / Co-managed model
Probably the most common: CIOs keep strategic control, internal staff handle business-critical processes, and partners cover migration execution, accelerators, and integration with newer SAP tools.
The urgency to act and the two kinds of experts you’ll need
By 2027, SAP will end mainstream maintenance not only for PI/PO but also for ECC and Business Suite 7. That means the clock is ticking on multiple fronts. Waiting until the last minute only increases costs and disruption.
CIOs know migrations are never simple. As we’ve seen, there are many factors to weigh before starting: customizations, shadow IT, and fragmented processes all create uncertainty. Yet the alternative (clinging to unsupported systems) is far riskier.
Equally important is assessing the resources your organization already has in-house. On one side, you’ll need professionals deeply familiar with your legacy systems. Their knowledge is essential to understand how integrations were built, where hidden dependencies lie, and how to avoid breaking business-critical processes that may not be fully documented. On the other side, you’ll also need certified experts in SAP’s most modern modules, ideally with hands-on experience migrating from PI/PO or ECC to Integration Suite or S/4HANA. Migration is not the same as a new implementation: it requires knowing how to bridge the gap between old and new architectures, and how to manage complexity without losing business continuity.
If you don’t have this combination in-house, that’s where we can help at Inclusion Cloud. With more than 20 years as an SAP partner, we’ve been through multiple evolutions of the ecosystem and bring expertise that covers the entire journey—from planning to execution.
And to make sure you only work with senior, certified specialists in the exact skills and modules you need, we rely on our AI-powered recruiting engine, inMOVE™ by Inclusion Cloud, designed to accelerate projects while minimizing disruption to your organization.
You can schedule a discovery call with us to map your project scope and explore how we can help you plan and execute your migration with confidence.
Q&A:
Q: Why can’t we just keep running PI/PO after 2027?
A: Technically you can, but without SAP maintenance you won’t receive security patches or fixes. That means every new vulnerability could expose sensitive data or disrupt access to critical systems.
Q: What makes SAP Integration Suite different from PI/PO?
A: PI/PO was built for on-premise, point-to-point connections. Integration Suite is cloud-native, unifies APIs, events, iFlows, and governance in one platform, and is designed to support AI-driven, Suite-as-a-Service architectures.
Q: Why do so many companies delay migration?
A: Studies show projects often overrun in time, cost, and quality. Complexity, undocumented legacy integrations, resource gaps, and organizational resistance make CIOs cautious.
Q: What’s the “clean core” principle, and why does it matter?
A: SAP recommends keeping the core standard while moving customizations and extensions to BTP. This reduces technical debt, makes upgrades smoother, and aligns with continuous innovation.
Q: Which migration approach is best—brownfield, greenfield, or hybrid?
A: It depends. Brownfield is faster but carries old complexity. Greenfield is clean but resource-heavy. Hybrid strikes a balance by modernizing selectively.
Q: Who should lead the migration—in-house or a partner?
A: That depends on your resources. Some companies manage internally, but most choose partner-led or hybrid models for expertise, speed, and reduced risk. Staff augmentation or dedicated teams are also common to fill specific gaps.
Q: How can Inclusion Cloud help?
A: With 20+ years as an SAP partner, we support the full journey—from planning to execution—backed by our AI-powered recruiting engine, inMOVE™, which ensures access to senior, certified SAP talent for every step.