SAP PI/PO läuft 2027 aus dem Standard-Support. Erfahren Sie, welche Migrationspfade (SAP Integration Suite, BTP) jetzt sinnvoll sind – und wie Sie Ausfallrisiken vermeiden.

SAP PI/PO Wartungsende 2027: Was Unternehmen jetzt tun sollten

Für Unternehmen, die SAP Process Integration (PI) oder SAP Process Orchestration (PO) betreiben, rückt eine wichtige Entscheidung näher: Die Mainstream Maintenance für die auf SAP NetWeaver 7.5 basierende PI/PO-Landschaft endet Ende 2027. Optional kann Extended Maintenance bis Ende 2030 genutzt werden.

Das bedeutet allerdings nicht, dass SAP PI/PO am 1. Januar 2028 plötzlich nicht mehr funktioniert.

Genau hier entsteht häufig ein falsches Gefühl von Sicherheit.

Das eigentliche Problem ist nicht ein technischer Abschalttermin, sondern die Frage, wie lange ein Unternehmen eine geschäftskritische Integrationsplattform außerhalb der regulären Mainstream Maintenance betreiben möchte – und wie viel Zeit eine realistische Migration der bestehenden Schnittstellen tatsächlich benötigt.

In über Jahre gewachsenen PI/PO-Landschaften geht es dabei selten nur um den Austausch einer Middleware. Hunderte Integrationsszenarien, Custom Mappings, Adapter, B2B-Verbindungen, Abhängigkeiten zu SAP ECC oder S/4HANA sowie geschäftskritische Prozesse müssen bewertet, priorisiert, migriert oder teilweise neu gestaltet werden.

Deshalb sollte 2027 nicht als Startpunkt der Migration betrachtet werden.

Es ist vielmehr ein Datum, bis zu dem Unternehmen Klarheit über Zielarchitektur, Scope und Migrationsweg geschaffen haben sollten.

Das Wichtigste in Kürze

• Die Mainstream Maintenance für SAP PI/PO auf SAP NetWeaver 7.5 endet Ende 2027.
• Optional steht Extended Maintenance bis Ende 2030 zur Verfügung.
• SAP PI/PO wird am 1. Januar 2028 nicht automatisch technisch abgeschaltet.
• SAP positioniert die SAP Integration Suite als strategische Zielplattform für die Modernisierung bestehender Process-Orchestration-Landschaften.
• Nicht jede bestehende PI/PO-Schnittstelle sollte 1:1 migriert werden.
• Der Migrationsaufwand hängt nicht nur von der Anzahl der Interfaces ab, sondern vor allem von Custom Logic, Adaptern, Abhängigkeiten, B2B-Szenarien und Testaufwand.
• Unternehmen mit paralleler S/4HANA-Transformation sollten beide Roadmaps aufeinander abstimmen.

Wann endet die Wartung für SAP PI/PO genau?

SAP Process Integration und SAP Process Orchestration basieren auf SAP NetWeaver. Für die relevante NetWeaver-7.5-Generation endet die reguläre Wartungsphase Ende 2027. SAP sieht anschließend die Möglichkeit einer Extended Maintenance bis Ende 2030 vor.

Für die Planung sind deshalb drei Zeiträume relevant.

Bis Ende 2027: Mainstream Maintenance

Bis dahin befindet sich die Plattform im regulären Wartungszeitraum.

Für Unternehmen mit PI/PO ist dies der wichtigste strategische Orientierungspunkt: Wer langfristig auf eine andere Integrationsarchitektur wechseln möchte, sollte bis dahin zumindest Scope, Zielbild und eine belastbare Migrationsroadmap definiert haben.

2028 bis Ende 2030: Extended Maintenance

Extended Maintenance kann zusätzlichen zeitlichen Spielraum schaffen.

Sie sollte allerdings eher als Übergangsoption betrachtet werden als als Grund, die Transformationsentscheidung um drei Jahre aufzuschieben.

Denn ein späterer Projektstart verändert die Komplexität der vorhandenen Schnittstellenlandschaft nicht. Gleichzeitig können weitere S/4HANA-, Cloud-, API-, EDI- oder Digitalisierungsprojekte neue Integrationsabhängigkeiten hinzufügen.

Nach 2030

Nach dem derzeit vorgesehenen Extended-Maintenance-Zeitraum endet dieser SAP-Supportpfad für die bestehende PI/PO-Generation.

Unternehmen, die PI/PO heute noch strategisch einsetzen, benötigen deshalb nicht nur einen Wartungsplan, sondern einen Ablöse- beziehungsweise Modernisierungsplan.

Läuft SAP PI/PO nach 2027 weiter?

Ja. Das Ende der Mainstream Maintenance bedeutet nicht, dass SAP PI/PO am 1. Januar 2028 automatisch abgeschaltet wird.

Das ist eine wichtige Unterscheidung.

„Wartungsende 2027“ und „System funktioniert ab 2028 nicht mehr“ sind nicht dasselbe.

Die eigentliche Managementfrage lautet deshalb nicht:

Funktioniert PI/PO am 2. Januar 2028 noch?

Sondern:

Wie lange wollen wir eine zentrale Integrationsplattform außerhalb der Mainstream Maintenance weiterbetreiben – und wann müssen wir mit der Migration beginnen, damit wir nicht unter Zeitdruck geraten?

Für eine kleine, überschaubare PI/PO-Installation kann die Antwort anders aussehen als für eine internationale Landschaft mit hunderten Schnittstellen, B2B-Kommunikation und mehreren geschäftskritischen SAP-Systemen.

Deshalb sollte die Timeline immer aus der eigenen Integrationslandschaft abgeleitet werden – nicht allein aus dem SAP-Datum.

Warum sollten Unternehmen trotzdem jetzt mit der Planung beginnen?

Die technische Installation einer neuen Integrationsplattform ist selten der zeitaufwendigste Teil einer PI/PO-Migration.

Die eigentliche Arbeit liegt häufig darin, herauszufinden, was überhaupt migriert werden muss und wie.

Bestehende Interface-Landschaften sind oft größer als erwartet

Über Jahre entstehen neue Integrationen, temporäre Schnittstellen werden dauerhaft genutzt, Systeme werden ersetzt und Verantwortlichkeiten verändern sich.

Dadurch enthält eine PI/PO-Landschaft häufig:

• produktive Interfaces
• selten genutzte Schnittstellen
• redundante Integrationen
• historische Objekte
• Custom Mappings
• Partnerverbindungen
• nicht vollständig dokumentierte Abhängigkeiten

Eine Migration sollte deshalb mit einem belastbaren Interface-Inventar beginnen.

Nicht jedes Interface lässt sich auf dieselbe Weise migrieren

SAP stellt Migration Assessment und pattern-basiertes Migration Tooling zur Verfügung.

Das bedeutet aber nicht:

„Tool starten – alle PI/PO-Schnittstellen sind migriert.“

Je nach Szenario kann die richtige Entscheidung vielmehr lauten:

• migrieren
• anpassen
• neu gestalten
• konsolidieren
• stilllegen

Custom Logic benötigt zusätzliche Bewertung

Komplexe Mappings, individuelle Java-Logik, spezielle Adapter oder Orchestrierungen können zusätzlichen Entwicklungs- und Testaufwand erzeugen.

Ein technisch funktionierendes Interface sollte außerdem nicht automatisch übernommen werden, wenn seine Architektur im zukünftigen Zielbild nicht mehr sinnvoll ist.

Business-Tests brauchen Fachbereiche

Integrationsmigration ist kein rein technisches IT-Projekt.

Wenn eine Schnittstelle beispielsweise Aufträge, Lieferungen, Rechnungen oder Produktionsdaten transportiert, muss nach der Migration nicht nur die Message erfolgreich übertragen werden.

Der Geschäftsprozess muss weiterhin korrekt funktionieren.

Dafür braucht es Business Owner, Testdaten, End-to-End-Szenarien und ausreichend Zeit für Fehlerbehebung.

Was ersetzt SAP PI/PO?

Für SAP-orientierte Integrationslandschaften ist die SAP Integration Suite die strategische Zielplattform für die Modernisierung bestehender Process-Orchestration-Landschaften.

Der Wechsel sollte allerdings nicht als einfacher Produkttausch verstanden werden.

SAP Integration Suite ist eine cloudbasierte Integrationsplattform auf SAP BTP und deckt verschiedene Integrationsmuster ab, darunter:

• Anwendungs- und Prozessintegration
• APIs
• eventbasierte Integration
• B2B-Szenarien
• hybride Cloud-/On-Premise-Integration

Die wichtigere Frage lautet deshalb nicht:

Welches neue Produkt ersetzt PI/PO?

Sondern:

Welche Zielarchitektur benötigen unsere heutigen und zukünftigen Integrationsprozesse?

Muss wirklich jede PI/PO-Schnittstelle migriert werden?

Nein.

Und genau hier liegt eine der größten Chancen der PI/PO-Ablösung.

Eine historisch gewachsene Middleware-Landschaft enthält häufig technische Entscheidungen, die vor zehn oder fünfzehn Jahren sinnvoll waren, heute aber nicht mehr zur System- oder Integrationsarchitektur passen.

Für jedes Interface sollten deshalb vier Optionen geprüft werden.

1. Migrieren

Der Geschäftsprozess wird weiterhin benötigt, die bestehende Integration ist sinnvoll aufgebaut und ein passendes Migrationsmuster ist verfügbar.

2. Anpassen

Das Interface bleibt fachlich relevant, benötigt aber Änderungen an Adapter, Mapping, Security, Routing oder Konfiguration.

3. Redesign

Der Prozess bleibt bestehen, die bisherige technische Architektur sollte jedoch nicht unverändert übernommen werden.

Das kann beispielsweise sinnvoll sein, wenn APIs, Events oder standardisierte Integrationsinhalte künftig besser zum Use Case passen.

4. Stilllegen oder konsolidieren

Das Interface wird nicht mehr benötigt, ist redundant oder kann durch einen Standardprozess ersetzt werden.

Eine gute PI/PO-Migration maximiert nicht die Zahl migrierter Interfaces. Sie minimiert die Menge unnötiger technischer Altlasten, die in die neue Landschaft übernommen werden.

Welche Faktoren bestimmen den Aufwand einer PI/PO-Migration?

Eine pauschale Aussage wie „500 Interfaces benötigen zwölf Monate“ ist wenig belastbar.

Zwei Landschaften mit derselben Anzahl an Schnittstellen können einen völlig unterschiedlichen Migrationsaufwand erzeugen.

1. Anzahl der tatsächlich aktiven Interfaces

Nicht die Zahl aller Repository-Objekte ist entscheidend, sondern der produktiv relevante Scope.

2. Unterstützte Migrationsmuster

Je höher der Anteil standardisierter und vom SAP Migration Tooling unterstützter Szenarien, desto größer kann der Automatisierungsgrad sein.

3. Custom Mappings und Entwicklungslogik

Individuelle Java-, XSLT- oder Mapping-Logiken können zusätzlichen Prüf- und Anpassungsbedarf erzeugen.

4. Adapter und Kommunikationsprotokolle

Bestehende Sender- und Receiver-Szenarien müssen mit den Möglichkeiten der Zielplattform abgeglichen werden.

5. B2B- und EDI-Szenarien

Partnerintegration bringt zusätzliche Abhängigkeiten mit sich: Formate, Vereinbarungen, Zertifikate, Partner-Onboarding und externe Testzyklen.

6. Business-Abhängigkeiten

Je kritischer der Prozess, desto größer der notwendige Test-, Cutover- und Absicherungsaufwand.

7. Zielarchitektur

Ein reines Lift & Shift kann schneller sein als ein umfassendes Redesign.

Es kann langfristig aber teurer werden, wenn unnötige technische Komplexität einfach reproduziert wird.

Wie lange dauert eine SAP PI/PO-Migration?

Eine belastbare Dauer lässt sich erst nach einem Assessment der tatsächlichen Integrationslandschaft bestimmen.

Die Dauer wird unter anderem beeinflusst durch:

• Anzahl produktiver Interfaces
• technische Komplexität
• Custom Code
• Adapter
• B2B-Partner
• Testumfang
• Verfügbarkeit der Fachbereiche
• gewünschtes Redesign
• Abhängigkeiten zu S/4HANA oder anderen Programmen
• Cutover-Strategie

Große Landschaften sollten deshalb nicht automatisch als Big-Bang-Migration geplant werden.

Eine Migration in priorisierten Wellen reduziert das Risiko und ermöglicht es, Erfahrungen aus frühen Szenarien auf spätere Migrationspakete zu übertragen.

Was zeigt SAP Migration Assessment?

SAP Migration Assessment ist eine Capability innerhalb der SAP Integration Suite, die bestehende Process-Orchestration-Szenarien analysiert und Hinweise auf Migrationsfähigkeit und technischen Aufwand liefert.

Dabei werden Szenarien unter anderem in Kategorien wie:

• Ready to migrate
• Adjustment required
• Evaluation required

eingeordnet.

Das ist ein sehr guter technischer Ausgangspunkt.

Es ersetzt jedoch keine vollständige Migrationsstrategie.

Denn ein technisches Tool kann nicht allein entscheiden:

• ob ein Interface fachlich noch gebraucht wird
• welche Schnittstelle geschäftskritisch ist
• welche Architektur künftig sinnvoll ist
• ob ein Redesign wirtschaftlich besser wäre
• welche Interfaces gemeinsam migriert werden sollten
• wie Cutover und Business Testing organisiert werden

Deshalb sollte das technische Assessment um Business-, Architektur- und Betriebsaspekte ergänzt werden.

PI/PO und S/4HANA: Warum beide Roadmaps zusammengehören

Eine PI/PO-Migration sollte nicht unabhängig von einer laufenden oder geplanten S/4HANA-Transformation betrachtet werden.

Nehmen wir ein einfaches Beispiel:

Ein Unternehmen betreibt SAP ECC und PI/PO.

Eine bestehende Schnittstelle verbindet ECC mit einem externen System.

Wenn zunächst PI/PO durch eine neue Integrationsplattform ersetzt und die alte ECC-Schnittstelle technisch unverändert migriert wird, kann wenige Monate später die S/4HANA-Transformation genau diesen Prozess verändern.

Das Interface muss dann möglicherweise ein zweites Mal angepasst werden.

Sinnvoller ist häufig:

Ist-Landschaft verstehen → zukünftigen S/4HANA-Prozess kennen → Zielarchitektur definieren → nur die langfristig benötigte Integration umsetzen.

Damit wird die PI/PO-Migration Teil einer größeren Architekturentscheidung – nicht nur ein Middleware-Projekt.

2026, 2027 oder 2030: Wann sollte was passieren?

Nicht jedes Unternehmen benötigt dieselbe Timeline.

Aus heutiger Sicht kann folgende Einteilung jedoch als praktische Planungslogik dienen.

2026: Transparenz schaffen

Jetzt sollte vor allem Klarheit entstehen.

Typische Aufgaben:

• PI/PO-Interface-Inventar erstellen
• aktive und obsolete Interfaces unterscheiden
• Migration Assessment durchführen
• Custom Logic und kritische Abhängigkeiten identifizieren
• S/4HANA- und Cloud-Roadmaps abgleichen
• Zielarchitektur definieren
• Lift & Shift versus Redesign bewerten
• erste Migrationswellen priorisieren

Das Ziel für 2026 sollte nicht zwangsläufig sein, jedes Interface bereits zu migrieren.

Das Ziel sollte sein, nicht mehr über Scope und Aufwand raten zu müssen.

2027: Migration kontrolliert umsetzen

Für Unternehmen mit größerem Scope sollte 2027 vor allem der Umsetzung, dem Testing und der kontrollierten Produktivsetzung dienen.

Dazu gehören:

• Migration der priorisierten Interfaces
• Redesign ausgewählter Szenarien
• Regression Tests
• B2B-Partner-Tests
• Cutover-Planung
• Monitoring
• Stabilisierung
• schrittweise Außerbetriebnahme migrierter PI/PO-Szenarien

2028–2030: Übergangszeit gezielt nutzen

Extended Maintenance kann dort sinnvoll sein, wo einzelne komplexe Szenarien bewusst länger benötigen oder große Programme nicht vollständig bis Ende 2027 abgeschlossen werden können.

Diese Jahre sollten jedoch keine ungeplante Verlängerung des Status quo werden.

Wer Extended Maintenance nutzt, sollte wissen:

• welche Interfaces noch auf PI/PO laufen
• warum sie dort verbleiben
• wann sie migriert werden
• welche Abhängigkeiten bestehen
• wann PI/PO endgültig außer Betrieb gehen kann

Readiness Check: Ist Ihr Unternehmen auf die PI/PO-Ablösung vorbereitet?

Beantworten Sie die folgenden Fragen.

Landschaft

• Kennen wir alle produktiv genutzten PI/PO-Interfaces?
• Wissen wir, welche Schnittstellen nicht mehr benötigt werden?
• Sind Sender, Empfänger und Systemabhängigkeiten dokumentiert?

Technik

• Kennen wir unsere Custom Mappings und individuellen Adapter?
• Wissen wir, welche Szenarien durch SAP Migration Tooling unterstützt werden?
• Haben wir B2B- und EDI-Szenarien separat bewertet?

Architektur

• Ist die zukünftige Integrationsplattform festgelegt?
• Haben wir definiert, wo klassische Integration Flows, APIs oder Events eingesetzt werden sollen?
• Ist die Zielarchitektur mit unserer S/4HANA-Strategie abgestimmt?

Projekt

• Gibt es eine Priorisierung der Interfaces?
• Sind Migrationswellen definiert?
• Sind Business Owner für kritische Prozesse bekannt?
• Gibt es eine Regression-Test-Strategie?
• Ist der Cutover- und Fallback-Ansatz geklärt?

Wenn mehrere dieser Fragen noch nicht beantwortet werden können, liegt der dringendste nächste Schritt häufig nicht in der Migration selbst, sondern im Assessment.

Die häufigsten Fehler bei der Planung

Bis 2030 warten, weil Extended Maintenance möglich ist

2030 ist zusätzlicher Handlungsspielraum – kein Grund, die Bestandsaufnahme aufzuschieben.

Die gesamte Landschaft als 1:1-Migration betrachten

Damit werden möglicherweise technische Altlasten reproduziert, die in einer neuen Architektur nicht mehr sinnvoll sind.

Nur technische Migrationsfähigkeit bewerten

Ein Interface kann technisch migrierbar und gleichzeitig fachlich überflüssig sein.

Testing unterschätzen

Eine fehlerfrei deployte Integration ist noch kein Beweis für einen funktionierenden End-to-End-Geschäftsprozess.

PI/PO und S/4HANA getrennt planen

Damit steigt das Risiko, Interfaces innerhalb kurzer Zeit mehrfach anfassen zu müssen.

Erst migrieren und Governance später definieren

SAP Integration Suite verändert nicht nur die technische Runtime, sondern auch Betriebs-, Sicherheits-, Monitoring- und Governance-Fragen.

Vom Wartungsende zur Migrationsroadmap

Das SAP PI/PO Wartungsende sollte nicht als isolierte technische Deadline betrachtet werden.

Es ist ein Anlass, eine seit Jahren gewachsene Integrationslandschaft neu zu bewerten:

• Welche Interfaces benötigen wir weiterhin?
• Welche lassen sich standardisiert migrieren?
• Welche sollten modernisiert werden?
• Welche Abhängigkeiten entstehen durch S/4HANA?
• Welche technischen Altlasten können endgültig entfallen?

Das Ziel sollte deshalb nicht sein:

„Bis 2027 möglichst schnell alles von PI/PO wegzubekommen.“

Sondern:

„Bis zum Ende der PI/PO-Lifecycle-Phase eine Integrationsarchitektur aufzubauen, die die nächsten SAP-, Cloud- und Digitalisierungsinitiativen trägt.“

Fazit: 2027 ist eine Planungsdeadline, kein technischer Abschalttermin

Die Mainstream Maintenance für SAP PI/PO endet Ende 2027; optional kann Extended Maintenance den Zeitraum bis Ende 2030 verlängern.

Damit besteht noch Handlungsspielraum.

Aber genau dieser Spielraum sollte genutzt werden, um die Migration ohne unnötigen Zeitdruck vorzubereiten.

Bei einer gewachsenen PI/PO-Landschaft ist die wichtigste erste Frage nicht:

Wie schnell können wir migrieren?

Sondern:

Was müssen wir überhaupt migrieren – und was sollte in der zukünftigen Architektur anders gelöst werden?

Wer diese Frage früh beantwortet, kann Interfaces nach Business-Kritikalität und technischem Aufwand priorisieren, S/4HANA-Abhängigkeiten berücksichtigen, Migrationswellen sinnvoll planen und vermeiden, historische Integrationskomplexität einfach in die SAP Integration Suite zu übertragen.

2027 ist deshalb nicht der Zeitpunkt, an dem PI/PO plötzlich aufhört zu funktionieren. Es ist der Zeitpunkt, bis zu dem Unternehmen geklärt haben sollten, wie ihre Integrationslandschaft künftig betrieben und modernisiert wird.

Häufige Fragen zum SAP PI/PO Wartungsende

Wann endet die Wartung für SAP PI/PO?

Die Mainstream Maintenance für die relevante SAP-NetWeaver-7.5-basierte PI/PO-Generation endet Ende 2027. SAP sieht optional Extended Maintenance bis Ende 2030 vor. Unternehmen sollten deshalb ihre individuelle Migrationsroadmap auf Basis der eigenen Interface-Landschaft und nicht ausschließlich anhand des letztmöglichen Wartungsdatums planen.

Wird SAP PI/PO am 1. Januar 2028 abgeschaltet?

Nein. Das Ende der Mainstream Maintenance bedeutet keinen automatischen technischen Shutdown von PI/PO. Das System kann technisch weiter betrieben werden; relevant ist jedoch der veränderte Wartungsstatus.

Gibt es SAP-Support für PI/PO bis 2030?

SAP sieht für die relevante Produktgeneration eine optionale Extended Maintenance bis Ende 2030 vor. Sie sollte als Übergangsmöglichkeit betrachtet werden, während Unternehmen ihre langfristige Integrationsstrategie und Migration umsetzen.

Was ist der Nachfolger von SAP PI/PO?

SAP positioniert die SAP Integration Suite als strategische Integrationsplattform für die Modernisierung bestehender Process-Orchestration-Landschaften.

Müssen alle PI/PO-Interfaces migriert werden?

Nein. Vor der Migration sollte jedes Szenario bewertet werden. Abhängig von Nutzung, technischer Eignung und zukünftiger Architektur kann die richtige Entscheidung Migration, Anpassung, Redesign, Konsolidierung oder Stilllegung sein.

Können PI/PO-Interfaces automatisch migriert werden?

Teilweise. SAP Migration Tooling arbeitet pattern-basiert und kann unterstützte Integrationsobjekte in Integration Flows für SAP Integration Suite überführen. Die Unterstützung hängt jedoch vom jeweiligen Objekt, Adapter, Flow Step und Migrationsmuster ab.

Wann sollte eine PI/PO-Migration gestartet werden?

Der richtige Startzeitpunkt hängt von Größe und Komplexität der Landschaft ab. Je umfangreicher und geschäftskritischer die PI/PO-Landschaft ist, desto wichtiger ist ein früher Start mit Assessment und Roadmap.

Sollte die PI/PO-Migration mit S/4HANA abgestimmt werden?

Ja. Wenn eine S/4HANA-Transformation geplant oder bereits in Umsetzung ist, sollten beide Roadmaps architektonisch aufeinander abgestimmt werden. Dadurch lässt sich vermeiden, ECC-basierte Interfaces zunächst unverändert zu migrieren und kurz darauf wegen neuer S/4HANA-Prozesse erneut anzupassen.