SAP Migration Assessment zeigt, welche PI/PO-Szenarien technisch migrierbar sind – aber nicht, welche davon wirklich in Ihre Zielarchitektur gehören. Der Artikel zeigt, wo das Tool hilft, wo seine Grenzen liegen und wie daraus eine belastbare Migrationsroadmap entsteht.

SAP Migration Assessment für PI/PO: Was das Tool zeigt – und was nicht

Wer eine Migration von SAP PI/PO zur SAP Integration Suite plant, steht meist relativ früh vor derselben Frage: Wie groß ist unser tatsächlicher Migrationsaufwand?

Die Anzahl der vorhandenen Interfaces allein liefert darauf keine belastbare Antwort. Zwei PI/PO-Landschaften mit jeweils 300 Schnittstellen können sich bei Komplexität, Custom Code, Adaptervielfalt, Datenvolumen und Abhängigkeiten fundamental unterscheiden.

Genau hier setzt SAP Migration Assessment an. Die Capability innerhalb der SAP Integration Suite analysiert bestehende SAP-Process-Orchestration-Szenarien, bewertet deren technische Migrationsfähigkeit und liefert Hinweise auf den zu erwartenden technischen Aufwand. SAP unterscheidet dabei unter anderem zwischen Ready to migrate, Adjustment required und Evaluation required.

Das macht Migration Assessment zu einem wichtigen Ausgangspunkt für eine PI/PO-Migration.

Aber nicht zu einer fertigen Migrationsroadmap.

Denn das Tool kann beispielsweise nicht vollständig beurteilen, wie geschäftskritisch eine Schnittstelle ist, welche Interfaces voneinander abhängen oder ob eine technisch migrierbare Integration überhaupt noch in die zukünftige Architektur gehört. SAP dokumentiert solche Grenzen ausdrücklich.

Die entscheidende Frage lautet deshalb nicht nur:

Was sagt das Migration Assessment über unsere PI/PO-Landschaft?

Sondern auch:

Welche Entscheidungen müssen wir zusätzlich treffen, bevor aus dem technischen Assessment ein belastbares Migrationsprogramm wird?

Das Wichtigste in Kürze

• SAP Migration Assessment analysiert bestehende PI/PO-Integrationsszenarien und bewertet ihre technische Eignung für die SAP Integration Suite.
• Die wichtigsten Kategorien sind Ready to migrate, Adjustment required und Evaluation required.
• Ready to migrate bedeutet nicht „automatisch migrierbar“. Auch danach können manuelle Konfigurations- oder Anpassungsschritte notwendig sein.
• Das Assessment kann technischen Aufwand, verwendete Objekte sowie Message- und Performance-Daten liefern und wurde 2026 um erweiterte Funktionen für Message-Volumen- und Kostenplanung ergänzt.
• Das Tool erkennt jedoch unter anderem keine vollständigen Abhängigkeiten zwischen unterschiedlichen Interfaces und analysiert interne BPM-/ccBPM-Logik nicht vollständig.
• Auch Abhängigkeiten innerhalb von Java-, XSLT-, Function-Library- oder UDF-Logik werden nicht rekursiv analysiert.
• Für eine belastbare Roadmap müssen technische Ergebnisse deshalb um Business-Kritikalität, Architektur, Stilllegungspotenzial, Testbedarf und Migrationspriorität ergänzt werden.
• Migration Assessment und Migration Tooling sind nicht dasselbe: Assessment bewertet; Migration Tooling unterstützt anschließend die technische Überführung bestimmter unterstützter Objekte.

Was ist SAP Migration Assessment?

SAP Migration Assessment ist eine Capability der SAP Integration Suite, mit der bestehende Integrationsszenarien aus SAP Process Integration und SAP Process Orchestration technisch analysiert und hinsichtlich ihrer Migration zur SAP Integration Suite bewertet werden können.

Dazu werden Daten aus der bestehenden PI/PO-Landschaft extrahiert und anhand definierter Regeln ausgewertet. Das Assessment betrachtet beispielsweise verwendete Integrationsobjekte, Adapter, Mappings und weitere technische Eigenschaften eines Szenarios.

Auf dieser Basis werden unter anderem zwei Fragen beantwortet:

1. Wie gut lässt sich das vorhandene Szenario mit Funktionen der SAP Integration Suite abbilden?
2. Welcher technische Migrationsaufwand ist voraussichtlich zu erwarten?

SAP verwendet für die Aufwandseinschätzung Gewichtungen und Größenklassen und stellt Ergebnisse pro Integrationsszenario zur Verfügung.

Damit ersetzt das Tool die oft sehr grobe Vorgehensweise:

„Wir haben 400 Interfaces, also planen wir 400 Migrationen.“

Stattdessen entsteht eine datenbasierte Sicht darauf, welche dieser Interfaces vergleichsweise unkompliziert sind und wo tiefer analysiert werden muss.

Was bedeuten Ready to migrate, Adjustment required und Evaluation required?

Die drei Kategorien gehören zu den wichtigsten Ergebnissen des Migration Assessments.

Sie werden aber häufig falsch interpretiert.

Ready to migrate

Ready to migrate bedeutet, dass die im Integrationsszenario verwendeten Funktionen grundsätzlich in SAP Integration Suite abgebildet werden können.

Das bedeutet ausdrücklich nicht, dass das Interface per Knopfdruck vollständig produktionsbereit migriert wird.

SAP weist darauf hin, dass auch bei dieser Kategorie nach der Migration manuelle Anpassungen oder Konfigurationsschritte erforderlich sein können – beispielsweise bei Connectivity-Parametern oder Abhängigkeiten von Custom Code. Das End-to-End-Design muss dabei jedoch grundsätzlich nicht verändert werden.

Praktisch heißt das:

technisch guter Kandidat ≠ fertiger Integration Flow.

Adjustment required

Adjustment required bedeutet, dass das Szenario grundsätzlich in SAP Integration Suite umgesetzt werden kann, dafür aber Änderungen am End-to-End-Design erforderlich sind.

Das kann beispielsweise betreffen:

• Protokollkonvertierung
• Anpassung von Sender- oder Empfängersystemen
• Adapter
• Routing
• technische Prozesslogik
• Konfiguration

SAP beschreibt diese Kategorie als Szenarien, die nur teilweise mit den vorhandenen Integration-Suite-Funktionen übereinstimmen.

Diese Interfaces verdienen besondere Aufmerksamkeit in der Aufwandsschätzung.

Evaluation required

Evaluation required bedeutet, dass eine automatische technische Bewertung nicht ausreicht und das Szenario manuell analysiert werden muss.

Gründe können beispielsweise sein:

• Funktionen sind in SAP Integration Suite nur eingeschränkt oder nicht verfügbar
• Zweck oder Nutzung des Szenarios können nicht vollständig bestimmt werden
• Abhängigkeiten sind nicht ausreichend erkennbar
• Custom Code oder Custom Adapter Module sind vorhanden
• das Szenario benötigt möglicherweise ein Redesign

SAP weist hier ausdrücklich darauf hin, dass manuell geprüft werden sollte, ob das Szenario überhaupt weiterhin fachlich relevant ist und wie es gegebenenfalls in einer Cloud-Architektur neu umgesetzt werden kann.

Die Assessment-Kategorie beschreibt die technische Ausgangslage. Sie trifft noch keine Entscheidung darüber, ob ein Interface wirtschaftlich oder architektonisch tatsächlich migriert werden sollte.

Welche Daten liefert SAP Migration Assessment?

Migration Assessment geht deutlich über eine einfache Liste von Interfaces hinaus.

Je nach verfügbarer System- und Monitoring-Konfiguration können unter anderem folgende Informationen in die Bewertung einfließen.

Integrationsszenarien und technische Objekte

Das Assessment identifiziert relevante Konfigurations- und Designobjekte der bestehenden PI/PO-Landschaft und analysiert die technischen Eigenschaften der Szenarien.

Dazu können beispielsweise gehören:

• Integrated Configuration Objects
• Receiver Determination
• Sender und Receiver
• Kommunikationskanäle
• Adapter
• Service Interfaces
• Message Mappings
• Java- oder XSLT-Mappings
• weitere technische Abhängigkeiten

Assessment Category

Jedes bewertete Szenario erhält eine technische Einordnung:

• Ready to migrate
• Adjustment required
• Evaluation required

Damit können Unternehmen ihre Landschaft bereits nach technischer Migrationskomplexität segmentieren.

Gewichtung und T-Shirt Size

SAP verwendet Regeln mit unterschiedlichen Gewichtungen, aus denen eine technische Komplexitätseinschätzung entsteht.

Daraus kann unter anderem eine T-Shirt Size abgeleitet werden.

Das ist hilfreich, um nicht jedes Interface zunächst einzeln detailliert schätzen zu müssen, sondern eine erste vergleichbare Sicht auf die gesamte Landschaft zu erhalten.

Technischer Migrationsaufwand

Das Assessment kann Mindest- und Maximalwerte für den geschätzten technischen Migrationsaufwand je Szenario ausgeben.

Wichtig ist das Wort technisch.

Darin sind nicht automatisch sämtliche Projektaktivitäten enthalten, etwa:

• Business-Analyse
• Fachbereichstests
• Governance
• Projektmanagement
• Cutover
• Partnerkoordination
• Hypercare
• organisatorische Veränderungen

Die Werte sollten deshalb als Input für die Projektplanung verstanden werden, nicht als fertiges Projektbudget.

Was hat sich 2026 bei Message- und Kostenanalyse verbessert?

Für Unternehmen, die Migration Assessment aktuell einsetzen, ist eine neue Entwicklung besonders relevant.

SAP hat die Funktionen für Message Throughput, Performance und Integration-Suite-Sizing 2026 erweitert. Die aktuelle Version ermöglicht unter anderem längere Betrachtungszeiträume für Message-Volumen und stellt zusätzliche Kennzahlen für die Planung der zukünftigen Landschaft bereit.

Message-Volumen über längere Zeiträume

Statt lediglich einen begrenzten Zeitraum zu betrachten, können nun unter anderem Message-Volumen über:

• 1 Monat
• 3 Monate
• 6 Monate

analysiert werden.

Das ist besonders wertvoll bei saisonalen Prozessen.

Eine Schnittstelle, die im Mai kaum Nachrichten verarbeitet, kann zum Jahresabschluss oder in einer Peak-Season völlig anders aussehen.

Message Size und Processing Time

Wenn die notwendigen Monitoring-Daten in SAP Process Orchestration verfügbar sind, können unter anderem auch Informationen zu:

• durchschnittlicher Message-Größe
• maximaler Message-Größe
• Verarbeitungszeit
• Messages pro Sekunde

in die Analyse einfließen.

Hinweise für Lizenz- und Architekturplanung

Die aktuellen Reports können Message-Metriken bereitstellen, die als Input für die Dimensionierung beziehungsweise Lizenzsimulation der SAP Integration Suite genutzt werden können.

Auch Architekturfragen können dadurch besser bewertet werden – beispielsweise wenn besonders hohe Volumina, Message-Größen oder Performance-Anforderungen berücksichtigt werden müssen.

Das macht Migration Assessment heute nicht nur für die reine Migrationsfähigkeit interessant, sondern zunehmend auch für Sizing und Business-Case-Planung.

Was bedeutet „Ready to migrate“ wirklich?

Diese Frage verdient einen eigenen Abschnitt, weil sie für Projektplanung und Budgetierung entscheidend ist.

Ready to migrate bedeutet nicht: „Dieses Interface kann ohne weitere Arbeit automatisch migriert werden.“

SAP unterscheidet ausdrücklich zwischen:

Assessment Category
und
Automatisierungsgrad des Migration Tooling.

Ein Interface kann also als Ready to migrate klassifiziert werden, obwohl das Migration Tooling nicht jeden Bestandteil automatisch überträgt.

Nach einer technisch unterstützten Migration können weiterhin Aufgaben notwendig sein, beispielsweise:

• Connectivity konfigurieren
• Security anpassen
• Parameter setzen
• Custom-Code-Abhängigkeiten bearbeiten
• Ressourcen hinzufügen
• Monitoring konfigurieren
• Integration Flow testen

Deshalb sollte „Ready to migrate“ in einer Roadmap eher so interpretiert werden:

„Technisch guter Migrationskandidat mit überschaubarem Designrisiko.“

Nicht:

„Erledigt.“

Was erkennt Migration Assessment nicht automatisch?

Hier liegt die wichtigste Grenze des Tools.

SAP dokumentiert ausdrücklich mehrere Situationen, in denen Migration Assessment keine vollständige Bewertung liefern kann.

Business-Kritikalität

Das Tool kann technische Eigenschaften eines Interfaces analysieren.

Es weiß jedoch nicht automatisch:

• ob darüber Millionenumsätze laufen
• ob eine Schnittstelle nur einmal pro Monat genutzt wird
• ob ein Produktionsprozess davon abhängt
• ob ein Interface regulatorisch kritisch ist
• welcher Ausfallzeitraum akzeptabel wäre

Diese Informationen müssen aus Fachbereichen und Betriebsorganisation ergänzt werden.

Abhängigkeiten zwischen verschiedenen Interfaces

Migration Assessment analysiert Interfaces objektbasiert.

SAP weist ausdrücklich darauf hin, dass Abhängigkeiten zwischen verschiedenen Interfaces innerhalb der Landschaft nicht automatisch erkannt werden.

Das ist für die Wave-Planung entscheidend.

Ein Interface kann technisch einfach sein, aber nicht separat migriert werden, wenn fünf andere Prozesse davon abhängen.

Interne BPM- und ccBPM-Logik

Migration Assessment kann erkennen, dass ein Szenario BPM verwendet.

Es kann die interne BPM- beziehungsweise ccBPM-Prozesslogik jedoch nicht vollständig analysieren. SAP empfiehlt für solche Fälle eine zusätzliche detaillierte Analyse im Process-Orchestration-System.

Rekursive Custom-Code-Abhängigkeiten

Java Mappings, XSLT, Function Libraries und User-Defined Functions können erkannt werden.

Aber das Tool analysiert deren interne Abhängigkeiten nicht rekursiv.

Wenn beispielsweise ein Java Mapping eine weitere Java-Klasse oder Function Library aufruft, wird diese abhängige Logik nicht automatisch vollständig mitbewertet.

Dynamische Receiver-Logik

Bei bestimmten dynamischen Receiver-Determination-Szenarien kann das Tool nicht alle möglichen Empfänger zur Designzeit bestimmen.

Dadurch können einzelne Teile eines Szenarios nur partiell bewertet werden.

Vollständige Performance-Transparenz

Auch bei Performance- und Throughput-Daten gibt es Grenzen.

Für bestimmte Komponenten können die notwendigen Daten nicht über die verfügbaren APIs erhoben werden. Bei Java-Komponenten hängt die Verfügbarkeit unter anderem davon ab, ob entsprechendes Performance Monitoring aktiviert wurde. Bei bestimmten Konstellationen kann auch Message Throughput ungenau sein.

Migration Assessment reduziert Unsicherheit erheblich. Es ersetzt aber keine Architektur-, Business- und Dependency-Analyse.

Wie erkennt man ungenutzte PI/PO-Interfaces?

Eine der wirtschaftlich interessantesten Fragen lautet:

Welche Interfaces müssen wir vielleicht gar nicht migrieren?

Message-Throughput-Daten können dafür einen wichtigen Hinweis liefern.

Wenn über einen längeren Zeitraum keine Messages verarbeitet wurden, kann ein Interface ein Kandidat für eine Stilllegung sein. SAP weist jedoch darauf hin, dass ein Null- oder Niedrigvolumen allein noch keine belastbare Decommissioning-Entscheidung darstellt.

Das liegt auf der Hand:

Eine Schnittstelle kann beispielsweise nur für:

• Monatsabschluss
• Quartalsprozesse
• Jahresabschluss
• seltene Stammdatenänderungen
• Notfallprozesse
• saisonale Geschäftsprozesse

verwendet werden.

Die 2026 eingeführte Betrachtung von 1-, 3- und 6-Monats-Zeiträumen verbessert diese Analyse deutlich, weil längerfristige Nutzungsmuster sichtbar werden.

Ein sinnvolles Decommissioning Assessment kombiniert deshalb:

Message-Daten + technische Nutzung + Process Owner + Business-Relevanz.

Erst dann sollte entschieden werden, ob ein Interface tatsächlich stillgelegt werden kann.

Vom Tool-Report zur Migrationsroadmap

Der größte Fehler wäre, den Excel- oder PDF-Report des Migration Assessments direkt als Projektplan zu behandeln.

Zwischen technischem Assessment und Migrationsroadmap liegen mehrere Entscheidungen.

1. Technische Bewertung

Welche Szenarien sind:

• Ready to migrate
• Adjustment required
• Evaluation required?

2. Business-Kritikalität

Welche Geschäftsprozesse hängen an den Interfaces?

Welche Ausfallzeiten sind akzeptabel?

3. Dependency Analysis

Welche Interfaces, Systeme und Partner hängen voneinander ab?

Welche Szenarien müssen gemeinsam migriert werden?

4. Zielarchitektur

Soll das bestehende Integrationsmuster überhaupt erhalten bleiben?

Oder sind künftig beispielsweise APIs, Events oder standardisierte Integrationsinhalte sinnvoller?

5. Migration, Anpassung, Redesign oder Stilllegung

Jedes Interface sollte einer konkreten Zielstrategie zugeordnet werden.

6. Wave Planning

Erst danach können sinnvolle Migrationswellen aufgebaut werden.

Dabei können beispielsweise folgende Faktoren kombiniert werden:

• Business-Bereich
• Quell- oder Zielsystem
• technische Komplexität
• Abhängigkeiten
• Kritikalität
• S/4HANA-Roadmap
• verfügbare Testressourcen

Das Assessment sagt, wie ein Interface technisch aussieht. Die Roadmap entscheidet, wann, warum und auf welche Weise es migriert werden sollte.

Was sollte ein vollständiges PI/PO Migration Assessment zusätzlich enthalten?

Ein belastbares Assessment sollte die SAP-Daten mit zusätzlichen Architektur- und Business-Informationen verbinden.

Vollständiges Interface-Inventar

Welche Integrationen existieren tatsächlich und welche befinden sich im produktiven Scope?

Business-Kritikalität

Welcher Geschäftsprozess hängt am jeweiligen Interface und welche Konsequenzen hätte ein Ausfall?

Abhängigkeiten

Welche Anwendungen, Integrationen, Jobs und Partner sind miteinander verbunden?

Nutzung und Performance

Wie häufig wird das Interface genutzt?

Welche Volumina, Message-Größen und Performance-Anforderungen existieren?

Security

Welche Zertifikate, technische Benutzer, Keys, Trust-Beziehungen und Authentifizierungsverfahren müssen berücksichtigt werden?

Custom Logic

Welche Mappings, Java-Komponenten, Adapter Modules und sonstigen individuellen Entwicklungen existieren?

Decommissioning-Potenzial

Welche Interfaces können konsolidiert oder vollständig stillgelegt werden?

Zielarchitektur

Soll das Szenario künftig über einen klassischen Integration Flow, API, Event, B2B-Funktion oder ein anderes Muster umgesetzt werden?

Testing

Welche Regression- und End-to-End-Tests sind notwendig?

Welche Fachbereiche und Partner müssen beteiligt werden?

Migrationspriorität

Welche Interfaces sollten zuerst migriert werden – und welche bewusst später?

Das Ergebnis sollte deshalb nicht nur eine technische Statistik sein.

Es sollte beantworten:

Was migrieren wir, wie migrieren wir es, in welcher Reihenfolge – und warum?

Migration Assessment vs. Migration Tooling: Was ist der Unterschied?

Die Begriffe werden häufig miteinander vermischt.

Dabei erfüllen beide Funktionen unterschiedliche Aufgaben.

Migration Assessment bewertet

Migration Assessment hilft dabei:

• bestehende Integrationsszenarien zu analysieren
• technische Migrationsfähigkeit zu bewerten
• Komplexität zu verstehen
• technischen Aufwand einzuschätzen
• Szenarien zu priorisieren

Migration Tooling migriert unterstützte Objekte

Migration Tooling ist eine pattern-basierte Funktion innerhalb von Cloud Integration, die unterstützte Integrationsobjekte aus SAP PI/PO in Integration Flows der SAP Integration Suite überführen kann.

Aktuell unterstützt SAP unter anderem die Migration von:

• Integrated Configuration Objects
• Receiver Determination Objects

und eine definierte Auswahl an Kommunikationskanälen, Mapping-Arten und weiteren Komponenten.

Dazu gehören beispielsweise unterstützte Varianten von:

• HTTP
• REST
• SOAP
• IDoc
• FTP/SFTP
• RFC
• JDBC
• Mail
• AS2
• Message Mapping
• Java Mapping
• XSLT Mapping

Die konkrete Unterstützung ist jedoch an dokumentierte Komponenten, Patterns und bekannte Einschränkungen gebunden.

Deshalb gilt:

Assessment beantwortet „Wie sieht unsere Ausgangslage aus?“
Migration Tooling unterstützt anschließend „Wie können bestimmte technische Objekte übertragen werden?“

Keines der beiden ersetzt die Migrationsstrategie.

Was sollte nach dem Migration Assessment passieren?

Ein gutes Assessment führt zu konkreten nächsten Entscheidungen.

1. Scope bereinigen

Nicht mehr benötigte Interfaces aus dem Migrationsprogramm entfernen.

2. Interfaces klassifizieren

Für jedes Szenario festlegen:

• Migration
• Anpassung
• Redesign
• Stilllegung

3. Zielarchitektur bestätigen

Integration Patterns, Security, Governance und Betriebsmodell definieren.

4. Migrationswellen bilden

Szenarien nach Systemen, Geschäftsbereichen, Kritikalität und Abhängigkeiten gruppieren.

5. Pilot beziehungsweise erste Wave starten

Eine erste kontrollierte Gruppe von Interfaces liefert echte Erkenntnisse über:

• Migration Tooling
• Entwicklungsaufwand
• Testing
• Deployment
• Monitoring
• Cutover

Diese Erfahrungen können anschließend in die weiteren Migrationswellen einfließen.

Wie aussagekräftig ist die Aufwandsschätzung?

Die technische Aufwandsschätzung aus Migration Assessment ist wertvoll, sollte aber richtig interpretiert werden.

Sie hilft insbesondere dabei:

• einfache und komplexe Szenarien voneinander zu unterscheiden
• den technischen Scope zu strukturieren
• potenzielle Aufwandstreiber zu erkennen
• erste Größenordnungen zu entwickeln

Sie beantwortet jedoch nicht automatisch die Frage:

„Was kostet unser gesamtes PI/PO-Migrationsprojekt?“

Zum Gesamtaufwand können zusätzlich gehören:

• Architektur
• Infrastruktur und Tenant Setup
• Security
• Business-Analyse
• Redesign
• Testautomatisierung
• manuelle Fachbereichstests
• B2B-Partnerkoordination
• Projektmanagement
• Cutover
• Hypercare
• Training
• Support

Die technische Schätzung sollte deshalb in ein vollständiges Projektmodell überführt werden.

Wann lohnt sich ein Migration Assessment besonders?

Migration Assessment ist besonders wertvoll, wenn:

• die Zahl der produktiven Interfaces nicht vollständig bekannt ist
• die PI/PO-Landschaft über viele Jahre gewachsen ist
• mehrere Teams oder Länder Integrationen aufgebaut haben
• umfangreiche Custom Logic vorhanden ist
• S/4HANA parallel eingeführt wird
• der Aufwand einer Migration intern schwer abzuschätzen ist
• Extended Maintenance als Übergangsoption bewertet wird
• ein Business Case für SAP Integration Suite erstellt werden muss
• Lizenz- und Message-Volumen geplant werden müssen
• eine Migration in mehreren Wellen vorgesehen ist

Je größer die Unsicherheit über die bestehende Landschaft, desto wertvoller ist die strukturierte Datengrundlage.

Fazit: Migration Assessment liefert Daten – die Roadmap braucht Entscheidungen

SAP Migration Assessment ist eines der wichtigsten Werkzeuge für Unternehmen, die ihre bestehende PI/PO-Landschaft zur SAP Integration Suite migrieren möchten.

Es schafft Transparenz über:

• technische Integrationsszenarien
• Migrationskategorien
• Komplexität
• potenziellen technischen Aufwand
• Message-Volumen
• Performance-Daten
• mögliche Migration-Kandidaten

Gerade mit den 2026 erweiterten Funktionen für Message- und Performance-Analyse liefert das Tool eine immer bessere Datengrundlage für Sizing, Architektur- und Kostenplanung.

Aber eine wichtige Grenze bleibt:

Ein technischer Report ist noch keine Migrationsstrategie.

Migration Assessment weiß nicht vollständig:

• welche Prozesse geschäftskritisch sind
• welche Interfaces untereinander abhängen
• welche Integrationen langfristig überhaupt benötigt werden
• welche historische Architektur technisch zwar migrierbar, strategisch aber überholt ist
• welche Interfaces gemeinsam in eine Migrationswelle gehören
• welche Risiken beim Cutover bestehen

Deshalb sollte das Ergebnis nicht lauten:

„Wir haben 180 Ready-to-migrate-Interfaces.“

Sondern:

„Wir wissen, welche Interfaces wir migrieren, welche wir verändern oder stilllegen, welchen Aufwand sie verursachen und in welcher Reihenfolge wir vorgehen.“

Genau an diesem Punkt wird aus Migration Assessment eine belastbare PI/PO-Migrationsroadmap.

Häufige Fragen zu SAP Migration Assessment

Ist SAP Migration Assessment kostenlos?

Die Verfügbarkeit von Migration Assessment hängt vom verwendeten SAP Integration Suite Service Plan ab. SAP weist in seiner Produktdokumentation darauf hin, dass Funktionen je nach Service Plan verfügbar sein können. Im Rahmen bestimmter SAP-Migrationsprogramme werden Assessments teilweise kostenlos angeboten; das sollte jedoch nicht mit einer generellen kostenlosen Produktnutzung gleichgesetzt werden.

Was bedeutet „Ready to migrate“?

Ready to migrate bedeutet, dass die vom Szenario verwendeten Funktionen grundsätzlich in SAP Integration Suite abgebildet werden können. Es bedeutet nicht, dass das Interface vollständig automatisch und ohne Nacharbeit migriert werden kann. SAP weist ausdrücklich darauf hin, dass nach der Migration noch manuelle Konfigurations- oder Anpassungsarbeiten erforderlich sein können.

Migriert Migration Assessment automatisch meine Interfaces?

Nein. Migration Assessment analysiert und bewertet bestehende PI/PO-Szenarien. Die eigentliche technische Unterstützung bei der Überführung bestimmter Integrationsobjekte übernimmt das separate Migration Tooling innerhalb von Cloud Integration. Dieses arbeitet pattern-basiert und unterstützt definierte Objekte und Komponenten.

Kann Migration Assessment Custom Java Mappings analysieren?

Migration Assessment kann Java-Mapping-Objekte identifizieren, analysiert deren interne Abhängigkeiten jedoch nicht vollständig rekursiv. Wenn ein Java Mapping beispielsweise weitere Java-Klassen oder Function Libraries aufruft, werden diese Abhängigkeiten nicht automatisch vollständig bewertet. Solche Szenarien benötigen zusätzliche manuelle Analyse.

Kann Migration Assessment ungenutzte Interfaces erkennen?

Message-Throughput-Daten können Hinweise auf möglicherweise ungenutzte Interfaces liefern, sind aber allein keine ausreichende Grundlage für eine Stilllegung. Besonders seltene, saisonale oder periodische Prozesse können über kürzere Zeiträume fälschlicherweise inaktiv erscheinen. Die 2026 erweiterten 1-, 3- und 6-Monats-Auswertungen verbessern die Datengrundlage für diese Entscheidung.

Berechnet Migration Assessment die Kosten der PI/PO-Migration?

Migration Assessment liefert technische Aufwandsschätzungen und inzwischen zusätzliche Daten für Sizing und Lizenzplanung, aber kein vollständiges Projektbudget. Die Gesamtkosten hängen zusätzlich von Architektur, Redesign, Tests, Partnerabhängigkeiten, Cutover, Projektmanagement und weiteren Projektleistungen ab. Die aktuellen Message-Metriken können jedoch als Input für SAP-Integration-Suite-Lizenzsimulationen genutzt werden.

Wie lange dauert ein SAP Migration Assessment?

Die Dauer hängt von Größe, Zugänglichkeit und Qualität der PI/PO-Landschaft ab. SAP nennt im Kontext seiner Migration Factory für Integration Suite häufig etwa ein bis zwei Wochen für ein Assessment, abhängig von Landschaft und Systemzugang. Das ist eine Orientierung aus diesem SAP-Programm und keine allgemeine Projektgarantie.

Was passiert nach dem Migration Assessment?

Nach dem Assessment sollten die technischen Ergebnisse mit Business-Kritikalität, Interface-Abhängigkeiten, Zielarchitektur und Stilllegungspotenzial kombiniert werden. Daraus werden Interfaces als Migration-, Anpassungs-, Redesign- oder Decommissioning-Kandidaten klassifiziert und anschließend in priorisierte Migrationswellen überführt. Erst dadurch entsteht aus dem technischen Assessment eine belastbare Migrationsroadmap.