S/4HANA Compatibility Check Guide
Prüfen Sie Ihr S/4HANA-System selbst: Schritt-für-Schritt-Anleitung zum Compatibility Scope Check inkl. Einordnung der Ergebnisse.

Wie viele Unternehmen haben Sie den Schritt bereits gemacht: Sie haben ECC verlassen, S/4HANA Private (Cloud) Edition eingeführt und Ihre Transformation gestartet. Damit scheint eine zentrale Frage beantwortet zu sein: Sind Sie jetzt zukunftssicher aufgestellt?
Die ehrliche Antwort lautet jedoch in vielen Fällen: nicht vollständig. Denn in zahlreichen S/4HANA-Systemen steckt mehr „ECC“, als man auf den ersten Blick vermuten würde – und genau darin liegt ein oft übersehenes Risiko.
Bei der Einführung von S/4HANA hat SAP bewusst einen pragmatischen Weg gewählt. Kunden sollten nicht gezwungen sein, alle Prozesse und Funktionen sofort neu zu denken und umzubauen – insbesondere in komplexen Systemlandschaften wäre das weder wirtschaftlich noch organisatorisch realistisch gewesen.
Stattdessen wurde es ermöglicht, bestehende ECC-Funktionalitäten mittels sogenannter „Compatibility Packs“ zunächst weiter zu nutzen und die Transformation in Etappen umzusetzen.
Compatibility Packs sind temporäre Übergangsfunktionen in S/4HANA, mit denen Unternehmen bestimmte ECC-Funktionalitäten zunächst weiter nutzen können. Sie wurden eingeführt, um den Wechsel zu S/4HANA zu erleichtern – sind jedoch zeitlich begrenzt und nicht als dauerhafte Lösung gedacht.
Diese Übergangslogik hat vielen Unternehmen den Einstieg in S/4HANA erleichtert. Sie ermöglichte es, die technische Umstellung umzusetzen, während fachliche Anpassungen schrittweise nachgelagert erfolgen konnten.
Parallel dazu hat SAP zahlreiche Funktionen modernisiert, neu entwickelt oder in andere Lösungen überführt. Compatibility Packs bilden damit die Brücke zwischen alter und neuer Systemwelt – eine Brücke, die bewusst nur auf Zeit ausgelegt ist. „Auf Zeit“ ist hier das richtige Stichwort: Diese Übergangslösung war von Anfang an befristet.
Die Übergangsphase hat bereits zum 31.12.2025 geendet und das Nutzungsrecht der Compatibility Packs läuft am 31. Mai 2026 aus - für einen Großteil der Compatibility Packs im S/4-On-Premise-Kontext.
Dieses Datum wird jedoch häufig falsch eingeordnet. Viele Unternehmen orientieren sich an bekannten Wartungsfristen – etwa dem Ende der Mainstream Maintenance für ECC im Jahr 2027. Mit den Compatibility Packs ist das jedoch nicht vergleichbar.
Denn hier geht es nicht um ein „End of Maintenance“, nach dem die erweiterte Wartung greift - sondern um ein „End of Use Rights“.
Das bedeutet: Ein System kann sich weiterhin in regulärer Wartung befinden und technisch stabil laufen – trotzdem entfällt die vertragliche Grundlage für die Nutzung einzelner Komponenten.
Die Systeme zeigen keine unmittelbaren Auffälligkeiten, Prozesse laufen wie gewohnt – und dennoch verändert sich die Bewertung der Nutzung im Hintergrund.
Die Differenz zwischen „funktioniert noch“ und „darf noch genutzt werden“ wird in der Praxis häufig unterschätzt. Wichtig ist dabei: SAP macht bewusst keine pauschalen Aussagen zu konkreten Konsequenzen im Einzelfall und verweist auf das jeweilige Vertragswerk.
Klar ist jedoch, dass es keine Verlängerung der Frist geben wird und es sich um eine vertragliche Fragestellung handelt – ein Aspekt, der im Alltag oft erst sichtbar wird, wenn er aktiv geprüft wird.
In der Praxis begegnen uns immer wieder ähnliche Annahmen: Viele gehen davon aus, dass das Thema mit der S/4-Einführung abgeschlossen ist oder ausschließlich die alte ECC-Welt betrifft. Auch die Vorstellung, dass alles, was im System läuft, automatisch zulässig ist, ist weit verbreitet.
Diese Sichtweisen sind nachvollziehbar, greifen jedoch zu kurz. Denn Compatibility Packs betreffen genau die Systeme, die bereits transformiert wurden – unabhängig davon, wie stabil sie betrieben werden.
Gleichzeitig bleibt das Thema im Alltag oft unsichtbar. Die betroffenen Funktionalitäten sind tief in bestehende Prozesse integriert, wurden bewusst aus ECC übernommen und laufen seit Jahren zuverlässig. In vielen Projekten wurde die Transformation zunächst technisch umgesetzt, während fachliche Anpassungen auf einen späteren Zeitpunkt verschoben wurden.
Wie sich Compatibility Packs konkret im System zeigen? Unternehmen haben beispielsweise eine Brownfield Conversion durchgeführt und zentrale Prozesse unverändert übernommen. HR- oder EWM-Prozesse laufen weiterhin wie in ECC, weil eine Transformation noch nicht priorisiert wurde. Oder bestimmte Transaktionen und Reports werden weiterhin genutzt, weil sie im Tagesgeschäft etabliert sind.
Diese Konstellationen sind keine Ausnahme, sondern typische Ergebnisse realer Transformationsentscheidungen – und genau deshalb wird die Relevanz des Themas häufig erst spät erkannt.
Ein Punkt, der häufig unterschätzt wird: Nicht jedes S/4HANA-System ist gleich aufgestellt.
Zwei Unternehmen können beide auf S/4 sein – und dennoch völlig unterschiedliche Ausgangslagen haben. Während ein Unternehmen seine Prozesse konsequent transformiert hat und ausschließlich neue Funktionalitäten nutzt, greift ein anderes in Teilbereichen weiterhin auf Compatibility Packs zurück.
Von außen ist dieser Unterschied kaum sichtbar – im System selbst jedoch von großer Bedeutung. Genau darin liegt die strategische Relevanz des Themas: Compatibility Packs sind keine technische Randnotiz, sondern ein Indikator dafür, wie weit die Transformation tatsächlich fortgeschritten ist. Sie werfen Fragen auf wie: Welche Altprozesse sind noch aktiv? Wie konsequent wurde die fachliche Umstellung umgesetzt? Und wie klar ist die Zielarchitektur definiert?
Damit wird aus einem vermeintlich technischen Detail schnell eine strategische Fragestellung – nämlich die, wie „fertig“ die eigene Transformation wirklich ist.
Compatibility Packs sind kein Fehler. Im Gegenteil: Sie waren eine notwendige und sinnvolle Übergangslösung und haben es vielen Unternehmen ermöglicht, den Schritt nach S/4HANA überhaupt zu gehen.
Gleichzeitig ist diese Übergangslösung zeitlich begrenzt – in den meisten Fällen bis Mai 2026. Viele Unternehmen haben sich bislang noch nicht im Detail damit beschäftigt, ob und in welchem Umfang sie betroffen sind – und genau darin liegt das Risiko.
Deshalb ist es entscheidend, dieses Thema jetzt aktiv zu adressieren – nicht als technisches „Nice-to-have“, sondern als notwendige Grundlage für die vertragliche Absicherung des SAP-Systems und als zentraler Bestandteil der eigenen S/4-Transformation.
Quellen