SAP Integration Suite ist nicht einfach PI/PO in der Cloud. Der Artikel zeigt, was sich bei Architektur, Entwicklung, APIs, Events, Betrieb und Governance wirklich verändert – und welche PI/PO-Szenarien besser migriert, modernisiert oder neu gedacht werden sollten.

SAP PI/PO vs. SAP Integration Suite: Was ändert sich bei Architektur, Entwicklung und Betrieb?

Wer SAP PI oder SAP Process Orchestration seit Jahren betreibt, könnte die SAP Integration Suite zunächst als nächsten technischen Schritt betrachten: neue Plattform, neue Oberfläche, bestehende Schnittstellen migrieren – fertig.

Genau diese Sicht greift zu kurz.

SAP Integration Suite ist nicht einfach PI/PO in der Cloud. Der Wechsel verändert nicht nur die Runtime, sondern auch Integrationsarchitektur, Entwicklungsmodell, Betriebsverantwortung, Monitoring, Governance und die Frage, welches Integrationsmuster für einen Geschäftsprozess überhaupt das richtige ist.

Während SAP PI/PO stark durch klassische Anwendungs- und Prozessintegration geprägt ist, bündelt die SAP Integration Suite mehrere spezialisierte Capabilities: Cloud Integration, API Management, Event Mesh, B2B-Funktionen, Integration Assessment und Migration Tooling. Zusätzlich ermöglicht Edge Integration Cell hybride Szenarien, bei denen Integrationsinhalte zentral in der Cloud designt und überwacht, aber innerhalb einer privaten Landschaft ausgeführt werden.

Für Unternehmen bedeutet die Migration deshalb nicht:

Wie bilden wir jedes PI/PO-Interface möglichst identisch in der Cloud nach?

Sondern:

Welche Integrationsmuster brauchen wir künftig – und welche Teile unserer PI/PO-Landschaft sollten migriert, modernisiert oder vollständig neu gedacht werden?

Das Wichtigste in Kürze

• SAP Integration Suite ist die strategische Integrationsplattform von SAP für die Modernisierung bestehender PI/PO-Landschaften. Sie ist jedoch kein reines Cloud-Rehosting von Process Orchestration.
• Cloud Integration übernimmt viele klassische Anwendungs- und Prozessintegrationsaufgaben, ist aber nur eine Capability innerhalb der gesamten Integration Suite.
• Mit API Management, Event Mesh und B2B-Funktionen können Integrationsprobleme künftig anders gelöst werden als durch klassische Interface-Flows allein.
• Bestehende PI/PO-Artefakte müssen nicht zwingend vollständig neu entwickelt werden. SAP Migration Tooling unterstützt inzwischen zahlreiche Adapter, Message Mappings, Java Mappings, XSLT Mappings und weitere Objekttypen – innerhalb dokumentierter Grenzen.
• Reine oder überwiegend private Integrationsszenarien schließen SAP Integration Suite nicht aus: Edge Integration Cell ermöglicht die Ausführung von Integrationsflows innerhalb einer kundeneigenen privaten Landschaft.
• Migration verändert auch Betrieb und Governance: Cloud-Service-Modell, BTP-basierte Security, neue Monitoring- und Transportprozesse sowie die Verwaltung zusätzlicher Capabilities müssen berücksichtigt werden.

Ist SAP Integration Suite der Nachfolger von SAP PI/PO?

Ja – SAP Integration Suite ist für SAP-Kunden die strategische Zielplattform für die Modernisierung bestehender SAP-PI/PO-Integrationslandschaften.

SAP stellt dafür eigene Architektur-Guidance, Migration Assessment und Migration Tooling bereit und beschreibt den Wechsel von Process Orchestration zur Integration Suite ausdrücklich als strategischen Migrationspfad.

Trotzdem ist der Begriff „Nachfolger“ erklärungsbedürftig.

PI/PO bündelt viele Integrationsaufgaben innerhalb einer NetWeaver-basierten Middleware-Plattform.

Die Integration Suite verfolgt einen breiteren Ansatz. Unterschiedliche Anforderungen können über unterschiedliche Capabilities abgebildet werden:

• Cloud Integration für Anwendungs- und Prozessintegration
• API Management für Bereitstellung und Governance von APIs
• Event Mesh für ereignisbasierte Integration
• Integration Advisor und Trading Partner Management für B2B-Szenarien
• Integration Assessment für Architekturentscheidungen
• Migration Assessment und Migration Tooling für den PI/PO-Übergang
• Edge Integration Cell als optionale private Runtime

SAP beschreibt Integration Suite entsprechend als iPaaS für die Verbindung von Prozessen und Daten über SAP-, Non-SAP-, Cloud- und hybride Landschaften.

Der Unterschied ist deshalb größer als:

altes Middleware-Produkt → neues Middleware-Produkt.

Es ist eher:

klassische zentrale Integrationsplattform → modularere Integrationsplattform mit mehreren Integrationsmustern und hybriden Runtime-Optionen.

SAP PI/PO und SAP Integration Suite: Was ändert sich konkret?

Ein reiner Feature-Vergleich wird der Entscheidung kaum gerecht. Für Unternehmen sind vor allem acht Veränderungen relevant.

Architektur

SAP PI/PO:
NetWeaver-basierte Integrationsplattform, typischerweise innerhalb einer kundenseitig betriebenen On-Premise-Landschaft.

SAP Integration Suite:
Cloudbasierte, von SAP bereitgestellte iPaaS mit mehreren Capabilities und optionalen privaten Runtimes über Edge Integration Cell.

SAP beschreibt die Integration Suite heute ausdrücklich als verteilte hybride Lösung: Design, Konfiguration und zentrale Kontrolle erfolgen über den Cloud-Service, während Integrationsflows je nach Architektur entweder in der Cloud oder in einer Edge Integration Cell innerhalb der privaten Landschaft ausgeführt werden können.

Entwicklung

SAP PI/PO:
Entwicklung und Konfiguration erfolgen über bekannte PI/PO-Werkzeuge und Artefakte wie Enterprise Services Repository, Integration Directory, Mappings und Konfigurationsobjekte.

SAP Integration Suite:
Cloud Integration arbeitet mit Integration Flows (iFlows), Integration Packages, browserbasiertem Design, wiederverwendbaren Artefakten und zusätzlichen Script- beziehungsweise Mapping-Möglichkeiten.

Die Denkweise bleibt teilweise vertraut – Nachrichten werden empfangen, transformiert, geroutet und an Zielsysteme übergeben – die technischen Artefakte und das Lifecycle-Modell ändern sich jedoch.

APIs

In PI/PO können selbstverständlich webbasierte Schnittstellen umgesetzt werden. API Management war jedoch nicht die zentrale integrierte Capability der Plattform.

In SAP Integration Suite ist API Management ein eigener Baustein für Veröffentlichung, Absicherung und Verwaltung von APIs.

Das eröffnet eine wichtige Architekturentscheidung:

Muss ein bestimmter Prozess weiterhin als klassische Punkt-zu-Punkt-Integration aufgebaut werden – oder sollte eine wiederverwendbare API bereitgestellt werden?

Events

Auch asynchrone Integration ist für PI/PO nichts Neues.

Die Integration Suite erweitert diesen Ansatz jedoch um Event Mesh und damit um einen dedizierten Baustein für event-driven Architecture. Event Mesh ermöglicht das Veröffentlichen und Konsumieren von Business Events über Anwendungen hinweg.

Damit wird bei der Migration eine weitere Frage relevant:

Braucht ein Verbraucher wirklich eine direkte Abhängigkeit zum sendenden System – oder genügt es, auf ein Business Event zu reagieren?

B2B

PI/PO wurde in vielen Unternehmen intensiv für EDI- und B2B-Prozesse genutzt.

Die Integration Suite bietet dafür spezialisierte Capabilities wie Integration Advisor und Trading Partner Management, zusätzlich zu Cloud Integration. Dadurch können Partnerbeziehungen, Nachrichtenspezifikationen und B2B-Szenarien stärker als eigener Integrationsbereich behandelt werden.

Monitoring

Mit dem Plattformwechsel ändert sich auch der operative Blick auf Integrationen.

SAP Integration Suite besitzt eigene Monitoring-Funktionen für Integration Content, Messages und APIs. Zusätzlich kann Cloud Integration in SAP Cloud ALM eingebunden werden, unter anderem für Integration & Exception Monitoring und Health Monitoring.

Bestehende PI/PO-Runbooks und Betriebsprozesse können deshalb nicht automatisch unverändert übernommen werden.

Transport und Deployment

Auch der Weg von Entwicklung zu Test und Produktion verändert sich.

SAP Integration Suite unterstützt unter anderem die Integration mit SAP Cloud Transport Management für den Transport von Content zwischen BTP-Landschaften.

Damit müssen im Zielbild Fragen zu:

• Entwicklungs-, Test- und Produktiv-Tenants
• Berechtigungen
• Transportwegen
• Freigaben
• Deployment-Automatisierung
• Versionsmanagement

neu definiert werden.

Governance

PI/PO-Governance konzentriert sich häufig stark auf Interfaces und deren technische Umsetzung.

Mit Integration Suite erweitert sich die Governance-Frage:

• Wer besitzt eine API?
• Wer darf Events veröffentlichen?
• Welche Integrationsmuster sind erlaubt?
• Wann wird ein klassischer iFlow verwendet?
• Wann API Management?
• Wann Event Mesh?
• Welche Artefakte dürfen wiederverwendet werden?
• Wie werden Security und Naming Standards durchgesetzt?

Die Plattform bietet mehr Möglichkeiten – aber genau deshalb braucht sie klarere Architekturregeln.

Die Migration verändert nicht nur die Technologie. Sie verändert die Entscheidungen, die ein Integrationsteam treffen muss.

Was passiert mit klassischen PI/PO-Interfaces?

Bestehende PI/PO-Interfaces müssen weder zwangsläufig komplett neu entwickelt noch automatisch 1:1 übertragen werden.

SAP bietet Migration Tooling innerhalb von Cloud Integration, das PI/PO-Integrationsartefakte anhand unterstützter Patterns in Integration Flows überführen kann.

Aktuell umfasst der unterstützte Scope unter anderem zahlreiche bekannte Komponenten:

• HTTP
• REST
• SOAP
• IDoc
• XI
• RFC
• JDBC
• FTP und SFTP
• Mail
• AS2
• Message Mapping
• Java Mapping
• XSLT Mapping
• Function Libraries
• XML/JSON-Konvertierung
• Routing

SAP weist gleichzeitig ausdrücklich darauf hin, dass Szenarien mit nicht unterstützten Komponenten zusätzlichen manuellen Migrationsaufwand verursachen.

Deshalb entstehen bei einer realen Migration typischerweise vier Kategorien.

Technisch migrieren

Das vorhandene Interface ist weiterhin sinnvoll und lässt sich mit unterstützten Patterns weitgehend übertragen.

Migrieren und anpassen

Das Szenario bleibt bestehen, einzelne Adapter, Mappings, Security-Mechanismen oder Konfigurationen müssen jedoch verändert werden.

Redesign

Der Geschäftsprozess wird weiterhin benötigt, die bisherige technische Umsetzung passt aber nicht mehr zur zukünftigen Integrationsarchitektur.

Stilllegen

Das Interface ist historisch gewachsen, redundant oder nach einer S/4HANA- beziehungsweise Cloud-Transformation nicht mehr erforderlich.

Die wichtigste Entscheidung ist deshalb nicht:

Kann dieses Interface migriert werden?

Sondern:

Sollte es in seiner heutigen Form überhaupt migriert werden?

Was verändert sich für PI/PO-Entwickler?

Für erfahrene PI/PO-Entwickler bleibt vieles fachlich vertraut.

Weiterhin müssen Nachrichten:

• empfangen
• validiert
• transformiert
• geroutet
• angereichert
• abgesichert
• überwacht

werden.

Das Entwicklungsmodell verändert sich trotzdem deutlich.

Von PI/PO-Artefakten zu Integration Flows

Cloud Integration organisiert Integrationslogik in Integration Flows und Integration Packages.

Ein iFlow beschreibt unter anderem:

• Sender und Receiver
• Adapter
• Routing
• Mapping
• Message Processing
• Fehlerbehandlung
• Scripts und weitere Schritte

Das ist konzeptionell nicht völlig fremd, aber die Artefaktstruktur und Entwicklungsumgebung unterscheiden sich von PI/PO.

Groovy wird wichtiger

Neben grafischem Mapping und XSLT wird Groovy häufig für individuelle Transformations- oder Prozesslogik verwendet.

SAP selbst nennt Kenntnisse in XML/XSLT und Groovy als relevante Entwicklungsfähigkeiten für Integration Suite.

Das bedeutet jedoch nicht, dass vorhandene Java Mappings automatisch verloren sind.

Migration Tooling unterstützt Java Mapping als Mapping-Objekt innerhalb seines dokumentierten Scopes.

Ob ein Java Mapping direkt übernommen, angepasst oder besser in Groovy neu umgesetzt wird, sollte je Szenario bewertet werden.

Mehr vorkonfigurierter Content

SAP stellt über den Business Accelerator Hub umfangreiche vorkonfigurierte Integration Content, APIs und weitere Artefakte bereit. Die SAP-BTP-Übersicht für 2026 weist mehrere Tausend verfügbare Built-in Integrations und APIs aus.

Das verändert die Entwicklungsfrage von:

Wie bauen wir diese Integration?

zu:

Existiert bereits ein unterstütztes Standardartefakt, das wir konfigurieren oder erweitern können?

Mehr als nur Interface-Entwicklung

Für Teams entstehen zusätzlich neue Kompetenzfelder:

• API Design
• Event-driven Architecture
• BTP Security
• Cloud Operations
• Governance
• DevOps und Transportautomatisierung
• Observability

Ein guter Migrationsplan sollte deshalb neben der technischen Migration auch den Skill Shift des Integrationsteams berücksichtigen.

Ist CPI dasselbe wie SAP Integration Suite?

Nein. Der heute noch häufig verwendete Begriff SAP CPI bezeichnet im Wesentlichen den früheren Namen der heutigen Cloud-Integration-Capability – nicht die gesamte SAP Integration Suite.

SAP Cloud Integration hieß früher unter anderem:

• SAP HANA Cloud Integration
• SAP Cloud Platform Integration
• häufig abgekürzt CPI

Heute lautet der offizielle Name Cloud Integration, eine Capability der SAP Integration Suite.

Deshalb sind Suchbegriffe wie:

PI vs. CPI
PO vs. CPI

zwar weiterhin verbreitet, technisch ist die heutige Gegenüberstellung aber besser formuliert als:

SAP PI/PO → SAP Integration Suite

und innerhalb davon:

klassische PI/PO-Prozessintegration → Cloud Integration

Der Unterschied ist wichtig, weil die Migration nicht nur Cloud Integration betrifft. APIs, Events, B2B und hybride Runtime-Entscheidungen können ebenfalls Teil des Zielbilds werden.

Was verändert sich im Betrieb?

Die vielleicht am stärksten unterschätzte Veränderung findet nach dem Go-live statt.

PI/PO-Teams haben häufig über Jahre stabile Betriebsprozesse aufgebaut:

• Runtime-Monitoring
• Message Monitoring
• Zertifikatsmanagement
• User und Rollen
• Deployments
• Patches
• Systemwartung
• Incident Management
• Performance-Tuning

Mit SAP Integration Suite verschiebt sich ein Teil dieser Verantwortung.

SAP betreibt die Cloud-Plattform

Die zentrale Integration-Suite-Cloud wird als Managed Service bereitgestellt.

Unternehmen müssen damit nicht dieselbe Infrastruktur wie bei einer klassischen kundenseitig betriebenen Middleware verwalten.

Das bedeutet jedoch nicht:

„Betrieb entfällt.“

Die Verantwortlichkeiten verändern sich vielmehr.

Integration Operations bleiben notwendig

Weiterhin müssen Unternehmen beispielsweise:

• fehlgeschlagene Messages überwachen
• Zertifikate verwalten
• technische Benutzer kontrollieren
• Integrationsflows versionieren
• Berechtigungen pflegen
• Performance überwachen
• Deployments steuern
• Fehler analysieren

SAP Integration Suite bietet hierfür eigene Monitoring-Funktionen; Cloud ALM kann zusätzlich in das Monitoring eingebunden werden.

Releases verändern das Betriebsmodell

Ein Cloud-Service entwickelt sich kontinuierlicher weiter als eine klassische On-Premise-Plattform mit kundenseitig geplanten Upgrade-Zyklen.

Teams müssen deshalb stärker darauf vorbereitet sein:

• Release Notes zu verfolgen
• neue Funktionen zu bewerten
• Regressionen zu testen
• Standards regelmäßig anzupassen

Betrieb wird damit weniger zu:

„Middleware-Server verwalten“

und stärker zu:

„Integrationsplattform und Integrationsprodukte steuern“.

Was verändert sich bei APIs?

Einer der größten strategischen Unterschiede besteht darin, dass API Management innerhalb der Integration Suite eine eigene Capability ist.

Dadurch können APIs über ihren Lifecycle kontrollierter verwaltet werden.

Typische Themen sind:

• Veröffentlichung
• Authentifizierung
• Security Policies
• Traffic Management
• Versionierung
• Analytics
• Developer Consumption

Das kann die Architektur erheblich verändern.

Beispiel

Ein Unternehmen besitzt fünf externe Anwendungen, die jeweils dieselben Kundendaten aus S/4HANA benötigen.

In einer klassischen Landschaft könnten fünf separate Integrationen entstehen.

In einer API-orientierten Architektur kann stattdessen geprüft werden, ob eine wiederverwendbare Customer API sinnvoller ist.

Dann wird Integration nicht mehr nur als Verbindung zwischen zwei Endpunkten betrachtet.

Sie wird zu einem wiederverwendbaren Business Service.

Das bedeutet allerdings nicht, dass jede PI/PO-Schnittstelle automatisch zur API werden sollte.

APIs eignen sich für bestimmte Interaktionsmuster. Asynchrone Integration, große Datenmengen oder langlaufende Prozesse können andere Ansätze erfordern.

Was verändert sich bei Events?

Mit Event Mesh unterstützt SAP Integration Suite ereignisbasierte Integrationsarchitekturen als eigenen Plattformbaustein.

Das verändert vor allem die Kopplung zwischen Systemen.

Klassischer Ansatz

System A kennt System B und sendet eine Nachricht direkt dorthin.

Event-basierter Ansatz

System A veröffentlicht:

Auftrag erstellt.

Andere Systeme können auf dieses Ereignis reagieren, ohne dass das Quellsystem jeden Verbraucher direkt kennen muss.

Das kann beispielsweise interessant sein für:

• Order Events
• Bestandsänderungen
• Logistikstatus
• Produktionsereignisse
• Customer Events
• IoT-nahe Prozesse

Damit kann ein Teil der historisch eng gekoppelten Integrationslandschaft langfristig stärker entkoppelt werden.

Aber auch hier gilt:

Event-driven ist kein automatischer Ersatz für jedes bestehende Interface.

Das passende Muster hängt von Transaktionsverhalten, Konsistenzanforderungen, Fehlerbehandlung und Prozesslogik ab.

Ist SAP Integration Suite nur für Cloud-Szenarien geeignet?

Nein. SAP Integration Suite unterstützt hybride Landschaften und kann auch On-Premise-Systeme integrieren.

Das ist eine wichtige Korrektur gegenüber älteren oder stark vereinfachten Vergleichen.

Standardmäßig können Cloud Integration und entsprechende Connectivity-Mechanismen Cloud- und On-Premise-Systeme miteinander verbinden.

Zusätzlich bietet SAP inzwischen Edge Integration Cell.

Damit können Integrationsinhalte:

• zentral in SAP Integration Suite designt
• zentral verwaltet und überwacht
• aber innerhalb einer privaten Landschaft ausgeführt werden

Bei der Runtime-Kommunikation können die Daten zwischen Sender und Empfänger innerhalb der privaten Landschaft verbleiben. SAP nennt hierfür ausdrücklich Security-, Compliance- und PI-Migrationsszenarien als mögliche Use Cases.

Das ist insbesondere interessant, wenn:

• sensible Daten die private Umgebung nicht verlassen sollen
• regulatorische Anforderungen bestehen
• beide Endpunkte On-Premise liegen
• Latenz eine wichtige Rolle spielt
• bestimmte Legacy-Systeme eingebunden werden müssen

Edge Integration Cell ist allerdings keine kostenlose technische Kopie von PI/PO.

Die Runtime ist Kubernetes-basiert und kundenseitig innerhalb der privaten Landschaft zu betreiben; außerdem bestehen eigene Feature- und Betriebsanforderungen.

Die Entscheidung für Edge sollte deshalb bewusst aus Architektur-, Security- und Betriebsanforderungen abgeleitet werden.

Müssen bestehende PI/PO-Interfaces komplett neu entwickelt werden?

Nein.

SAP bietet heute deutlich mehr Migrationsunterstützung als noch in frühen Phasen der Integration Suite.

Migration Tooling unterstützt zahlreiche Komponenten und kann unterstützte PI/PO-Artefakte semiautomatisiert in Integration Flows übertragen.

Trotzdem gibt es drei wichtige Einschränkungen.

Nicht jeder technische Bestandteil wird unterstützt

SAP veröffentlicht eine konkrete Liste der derzeit unterstützten Adapter, Mapping-Arten und weiteren Komponenten. Was außerhalb dieses Scopes liegt, benötigt zusätzlichen manuellen Aufwand.

Automatische Migration bedeutet nicht produktionsbereit

Nach der technischen Übertragung müssen unter anderem:

• Konfiguration
• Security
• Connectivity
• Fehlerbehandlung
• Performance
• Monitoring

validiert werden.

Technisch migrierbar bedeutet nicht architektonisch sinnvoll

Ein bestehendes Point-to-Point-Interface kann vielleicht problemlos übertragen werden.

Trotzdem kann künftig:

• eine Standardintegration
• eine API
• ein Event
• eine B2B-Capability

die bessere Lösung darstellen.

Deshalb sollte vor der technischen Migration zunächst ein Migration Assessment durchgeführt werden.

Was passiert mit Java-, XSLT- und Message Mappings?

Mapping ist für viele PI/PO-Teams eine der wichtigsten praktischen Fragen.

SAP Migration Tooling unterstützt im aktuellen Scope mehrere Mapping-Arten, darunter:

• Message Mapping
• Java Mapping
• XSLT Mapping
• Function Library
• Imported Archive

Das bedeutet allerdings nicht, dass jedes bestehende Mapping ohne Prüfung übernommen werden sollte.

Message Mapping

Standardisierte Message Mappings können abhängig vom verwendeten Funktionsumfang gute Migrationskandidaten sein.

Komplexe UDFs, Lookups oder andere Abhängigkeiten sollten zusätzlich analysiert werden.

Java Mapping

Java Mapping wird vom Migration Tooling als unterstützte Mapping-Kategorie geführt. Gleichzeitig kann es bei komplexer Java-Logik sinnvoll sein, diese für Cloud Integration anders umzusetzen.

SAP verweist in seinen Entwicklungsressourcen insbesondere auf Groovy als wichtige Script-Sprache für Cloud Integration.

XSLT Mapping

Auch XSLT Mapping gehört zum unterstützten Migrationsscope.

Wie bei allen Mapping-Arten sollte jedoch geprüft werden, welche Abhängigkeiten und Funktionen tatsächlich verwendet werden.

Die richtige Migrationsfrage lautet deshalb:

Was können wir wiederverwenden – und was sollten wir bewusst vereinfachen oder modernisieren?

Wann lohnt sich Redesign statt technischer Migration?

Ein Redesign verursacht zunächst mehr Aufwand.

Trotzdem kann es wirtschaftlich sinnvoller sein, als technische Altlasten für weitere Jahre fortzuführen.

Redesign sollte besonders geprüft werden, wenn:

• Interfaces stark an konkrete Systeme gekoppelt sind
• dieselben Daten über viele separate Schnittstellen bereitgestellt werden
• umfangreiche Custom Logic entstanden ist
• zukünftige S/4HANA-Prozesse den Datenfluss ohnehin verändern
• wiederverwendbare Standard-APIs verfügbar sind
• Events eine bessere Entkopplung ermöglichen
• B2B-Prozesse in spezialisierte Capabilities überführt werden können
• ein Interface fachlich kaum noch benötigt wird

Ein technisch kompliziertes Interface ist allerdings nicht automatisch ein Redesign-Kandidat.

Ebenso sollte ein einfach migrierbares Interface nicht automatisch 1:1 übernommen werden.

Der wirtschaftlich beste Weg liegt häufig zwischen den Extremen „alles neu bauen“ und „alles kopieren“.

In einer größeren Landschaft ist deshalb ein gemischter Ansatz typisch:

migrieren → anpassen → redesignen → stilllegen.

Was bedeutet der Wechsel für Governance und Organisation?

Die technische Migration kann abgeschlossen sein und die Integrationslandschaft trotzdem innerhalb weniger Jahre wieder unübersichtlich werden.

Das passiert, wenn Unternehmen zwar die Plattform wechseln, aber ihre Governance unverändert lassen.

Mit Integration Suite sollten unter anderem folgende Fragen eindeutig beantwortet sein.

Welche Integrationsmuster sind erlaubt?

Wann wird verwendet:

• Cloud Integration?
• API Management?
• Event Mesh?
• B2B?
• Edge Integration Cell?

Wem gehören Integrationsartefakte?

Ownership sollte nicht erst entstehen, wenn ein Interface ausfällt.

Für kritische Integrationen sollten technische und fachliche Verantwortlichkeiten eindeutig sein.

Wie wird Wiederverwendung organisiert?

Wenn jedes Projekt seine eigene API, sein eigenes Mapping und seine eigenen Integrationspatterns erstellt, entsteht trotz moderner Plattform erneut Wildwuchs.

Wer betreibt die Plattform?

Ein sinnvoller Ansatz kann beispielsweise Verantwortlichkeiten zwischen:

• Integration Platform Team
• Integration Architects
• Entwicklungsteams
• API Ownern
• Business Process Ownern
• Operations

verteilen.

Das Organisationsmodell muss nicht in jedem Unternehmen gleich aussehen.

Aber es sollte bewusst gestaltet werden.

PI/PO-Migration, S/4HANA und Clean Core zusammen denken

Eine S/4HANA-Transformation verändert häufig gleichzeitig:

• Geschäftsprozesse
• Datenmodelle
• Schnittstellen
• Erweiterungen
• externe Anwendungen

Deshalb sollte eine PI/PO-Migration nicht isoliert geplant werden.

Ein typischer Fehler wäre:

1. bestehende ECC-Schnittstelle unverändert von PI/PO zur Integration Suite migrieren
2. ECC anschließend durch S/4HANA ersetzen
3. dieselbe Integration erneut verändern

Sinnvoller ist es, zunächst das S/4HANA-Zielbild zu verstehen.

Dann lässt sich prüfen:

• Ist das Interface weiterhin notwendig?
• Gibt es eine Standard-API?
• Gibt es vorkonfigurierten Integration Content?
• Sollte es künftig als Event umgesetzt werden?
• Welche Logik sollte bewusst außerhalb des ERP-Kerns bleiben?

Dadurch unterstützt eine moderne Integrationsarchitektur gleichzeitig das Clean-Core-Prinzip: Integrationslogik und Erweiterungen werden stärker vom ERP-Kern entkoppelt, wo dies technisch und fachlich sinnvoll ist.

Entscheidungs-Check: Migrieren oder modernisieren?

Vor jeder größeren Interface-Welle sollte das jeweilige Szenario anhand einiger Fragen bewertet werden.

Fachlich

• Wird der Prozess weiterhin benötigt?
• Bleiben Sender und Receiver bestehen?
• Verändert S/4HANA den Geschäftsprozess?

Technisch

• Unterstützt Migration Tooling die verwendeten Komponenten?
• Welche Custom Mappings oder Adapter existieren?
• Welche Performance-Anforderungen bestehen?

Architektur

• Ist ein klassischer Integration Flow weiterhin das richtige Muster?
• Wäre eine API wiederverwendbarer?
• Ist ein Event sinnvoller?
• Handelt es sich um einen B2B-Prozess?
• Muss die Verarbeitung privat bleiben?

Wirtschaftlich

• Ist eine direkte Migration günstiger als Redesign?
• Welche technische Schuld würde übernommen?
• Kann das Interface vollständig stillgelegt werden?

Betrieb

• Wie wird das Szenario künftig überwacht?
• Wer trägt Ownership?
• Welche SLAs gelten?
• Wie wird es transportiert und released?

Das Ergebnis sollte für jedes Interface möglichst eindeutig sein:

Migrieren
Anpassen
Redesign
Stilllegen

Eine gute PI/PO-Migration entscheidet nicht nur, wie ein bestehendes Interface in Integration Suite aussieht. Sie entscheidet zuerst, ob dieses Interface in der zukünftigen Landschaft überhaupt noch in derselben Form existieren sollte.

Fazit: Integration Suite ist nicht PI/PO in der Cloud

Der Unterschied zwischen SAP PI/PO und SAP Integration Suite lässt sich nicht sinnvoll auf eine Liste von Features reduzieren.

Die eigentliche Veränderung liegt tiefer.

Mit Integration Suite verändert sich:

• wo Integration läuft
• wie Integrationen entwickelt werden
• welche Integrationsmuster zur Verfügung stehen
• wie APIs und Events eingesetzt werden
• wie Systeme entkoppelt werden können
• wie Integration überwacht und betrieben wird
• welche Governance benötigt wird

Cloud Integration übernimmt dabei viele Aufgaben, die PI/PO-Teams bereits kennen.

Aber Integration Suite geht darüber hinaus.

API Management, Event Mesh, B2B-Capabilities und Edge Integration Cell schaffen zusätzliche Architekturentscheidungen, die es in einer reinen PI/PO-Migration zu berücksichtigen gilt.

Deshalb sollte das Ziel nicht lauten:

„Unsere PI/PO-Landschaft in der Cloud nachbauen.“

Sondern:

„Die bestehende Integrationslandschaft so weit wie sinnvoll wiederverwenden – und dort modernisieren, wo APIs, Events, Standard Content oder neue Betriebsmodelle langfristig einen echten Vorteil schaffen.“

Genau darin liegt der Unterschied zwischen einem technischen Plattformwechsel und einer nachhaltigen Integrationsmodernisierung.

Häufige Fragen zu SAP PI/PO und SAP Integration Suite

Ist SAP Integration Suite der Nachfolger von SAP PI/PO?

Ja. SAP positioniert Integration Suite als strategische Integrationsplattform für die Modernisierung bestehender PI/PO-Landschaften. SAP stellt dafür unter anderem Migration Assessment, Migration Tooling und einen eigenen Migration Guide bereit. Die Plattform ist jedoch kein einfaches Rehosting von PI/PO, sondern kombiniert Cloud Integration mit zusätzlichen Capabilities wie API Management, Event Mesh und B2B-Funktionen.

Ist SAP CPI dasselbe wie SAP Integration Suite?

Nein. SAP CPI ist ein weiterhin gebräuchlicher älterer Begriff für SAP Cloud Platform Integration. Die heutige Capability heißt Cloud Integration und ist ein Bestandteil der SAP Integration Suite. Integration Suite umfasst darüber hinaus weitere Funktionen wie API Management, Event Mesh, B2B-Integration und Assessment-Capabilities.

Kann SAP Integration Suite On-Premise-Systeme integrieren?

Ja. Cloud Integration unterstützt hybride Szenarien zwischen Cloud- und On-Premise-Systemen. Zusätzlich ermöglicht Edge Integration Cell die Ausführung von Integration Flows innerhalb einer privaten Landschaft, während Design und zentrale Verwaltung über SAP Integration Suite erfolgen.

Ist Cloud Integration dasselbe wie SAP PI/PO?

Nein. Cloud Integration übernimmt viele vergleichbare Aufgaben der Anwendungs- und Prozessintegration, besitzt aber ein anderes Entwicklungs-, Deployment- und Betriebsmodell. Zudem ist Cloud Integration nur eine Capability der größeren SAP Integration Suite.

Können bestehende PI/PO-Mappings wiederverwendet werden?

Teilweise. SAP Migration Tooling unterstützt unter anderem Message Mapping, Java Mapping, XSLT Mapping und Function Libraries. Ob ein konkretes Mapping direkt migriert werden kann, hängt jedoch von den verwendeten Funktionen, Abhängigkeiten und bekannten Einschränkungen ab.

Sind alle PI/PO-Adapter in SAP Integration Suite verfügbar?

Nein, eine pauschale 1:1-Abdeckung sollte nicht angenommen werden. SAP veröffentlicht eine konkrete Liste von Komponenten und Adaptern, die aktuell vom Migration Tooling unterstützt werden. Szenarien außerhalb dieses Scopes benötigen zusätzlichen manuellen Aufwand oder gegebenenfalls ein Redesign.

Braucht jedes Unternehmen API Management nach der PI/PO-Migration?

Nein. API Management sollte eingesetzt werden, wenn APIs bewusst veröffentlicht, abgesichert, versioniert und über ihren Lifecycle gesteuert werden sollen. Ein klassischer Integrationsflow benötigt nicht automatisch API Management. Die Capability sollte aus dem Architektur- und Governance-Bedarf abgeleitet werden.

Was ist Edge Integration Cell?

Edge Integration Cell ist eine optionale hybride Runtime der SAP Integration Suite. Integrationsinhalte werden zentral in der Cloud designt und überwacht, können aber innerhalb einer kundeneigenen privaten Landschaft ausgeführt werden. SAP nennt unter anderem Security-, Compliance- und PI-Migrationsszenarien als relevante Anwendungsfälle.