
Compatibility Packs in S/4HANA: Ein unterschätztes Risiko?
Ihr SAP-System läuft – aber ist es compliant? Warum Compatibility Packs bis Ende Mai 2026 zum Risiko werden können.

In unserem ersten Artikel haben wir gezeigt, warum Compatibility Packs in S/4HANA ein oft übersehenes Compliance-Risiko darstellen – und weshalb viele Unternehmen betroffen sind, ohne es zu wissen.
Die entscheidende Anschlussfrage lautet: Was bedeutet das konkret für die eigene Systemlandschaft?
In der Praxis liegt die eigentliche Herausforderung genau zwischen Verständnis und Bewertung: in der Analyse der tatsächlichen Nutzung. Erst dann wird klar, ob und in welchem Umfang ein Unternehmen betroffen ist – und was daraus konkret folgt.
Zunächst lohnt sich eine wichtige Einordnung: Nicht jedes S/4HANA-System ist automatisch betroffen. Weder die reine Nutzung von S/4HANA noch das gewählte Betriebsmodell geben darüber verlässlich Auskunft. Entscheidend ist vielmehr, wie weit die S/4-Transformation tatsächlich umgesetzt wurde.
Daraus ergeben sich sehr unterschiedliche Ausgangslagen. Es gibt Unternehmen, die vollständig auf neue S/4-Funktionalitäten umgestellt haben und keinen unmittelbaren Handlungsbedarf haben. Gleichzeitig existieren Systeme, in denen einzelne Übergangsfunktionalitäten weiterhin aktiv sind – oft ohne klare Transparenz darüber.
Die zentrale Erkenntnis ist daher: Die Frage ist nicht, ob S/4 im Einsatz ist – sondern wie es genutzt wird.
Ein häufiger Trugschluss betrifft das Betriebsmodell. Viele Unternehmen gehen davon aus, dass sie mit einem Wechsel in Richtung Cloud automatisch auf der sicheren Seite sind. Tatsächlich entscheidet jedoch nicht das Betriebsmodell, sondern die vertragliche Grundlage der Nutzung.
Für klassische S/4HANA-On-Premise-Systeme gilt: Für den Großteil der Compatibility Packs endet das Nutzungsrecht am 31. Mai 2026. Daraus ergibt sich ein klarer Handlungsrahmen.
In Cloud-basierten Modellen – etwa S/4HANA Private Cloud oder RISE – können sich verlängerte Nutzungsrechte bis Ende 2033 ergeben. Diese greifen jedoch nicht automatisch, sondern sind an konkrete Voraussetzungen geknüpft, etwa an Vertragsmodelle oder die Nutzung entsprechender Ziel- und Nachfolgelösungen.
Damit wird deutlich: Das Betriebsmodell allein beantwortet die Frage nicht.
Zusätzliche Komplexität entsteht dadurch, dass nicht alle Compatibility Packs denselben Regelungen unterliegen. Für drei Bereiche gelten abweichende Fristen:
Hier endet das Nutzungsrecht im On-Premise-Kontext erst Ende 2030. SAP verweist hierfür auf „historische Gründe“ und macht keine weitergehenden Angaben.
Das bedeutet: Selbst innerhalb eines Systems können unterschiedliche Fristen parallel gelten. Eine pauschale Bewertung ist daher nicht möglich – erforderlich ist eine klare Zuordnung der betroffenen Funktionsbereiche und ihrer jeweiligen Regelungen.
In vielen Organisationen beginnt die Analyse auf Systemebene: Was läuft wo und welche Releases sind im Einsatz? Das ist ein sinnvoller Startpunkt – greift jedoch zu kurz.
Entscheidend ist nicht nur, dass eine Funktionalität vorhanden ist, sondern wie und wo sie im Unternehmen genutzt wird. In einem Randbereich ist sie oft leichter zu adressieren, in einem zentralen Geschäftsprozess kann sie kritische Auswirkungen haben. Handlungsbedarf besteht in beiden Fällen – der Unterschied liegt vor allem in Dringlichkeit und Komplexität.
Gleichzeitig zeigt die Praxis: Nicht jede notwendige Anpassung ist automatisch ein Großprojekt. Je nach betroffener Funktionalität lassen sich einzelne Compatibility-Pack-Inhalte mit erfahrenen IT-Dienstleistern oft in überschaubarer Zeit – teilweise innerhalb weniger Stunden – sauber ablösen oder umstellen.
Bevor über Maßnahmen oder Strategien gesprochen werden kann, braucht es eine belastbare Grundlage: Transparenz.
SAP stellt dafür einen spezifischen Report zur Verfügung, der im Rahmen des S/4HANA Readiness Checks genutzt werden kann: Der Compatibility Scope Check. Dieser ermöglicht es, die Nutzung von Compatibility Packs im System sichtbar zu machen und erste Hinweise auf deren Relevanz zu erhalten. („Nutzen Sie unseren Guide zur richtigen Durchführung des Checks“)
Wichtig ist dabei, den Zweck dieses Checks richtig einzuordnen. Er liefert eine technische Sicht auf die Nutzung – ersetzt jedoch keine fachliche oder vertragliche Bewertung.
Denn zwischen „im System gefunden“ und „tatsächlich geschäftskritisch genutzt“ besteht oft ein erheblicher Unterschied.
Genau an dieser Stelle wird aus einem technischen Thema eine inhaltliche Aufgabe. Die Ergebnisse des Checks beantworten nicht automatisch die entscheidenden Fragen:
Diese Einordnung erfordert Kontext, Erfahrung und eine Verbindung von technischer, fachlicher und vertraglicher Perspektive. Ohne diese Einordnung bleibt selbst ein sauber durchgeführter Check nur ein erster Schritt.
Die Einordnung der Ergebnisse erfordert Kontext, Erfahrung und eine Verbindung von technischer und vertraglicher Perspektive.
Andy CaspartSenior Principal Expert Conversion
Auf Basis dieser Transparenz stellt sich die nächste Frage: Wie kann mit bestehenden Compatibility Packs umgegangen werden?
Grundsätzlich existieren verschiedene Wege, um Nutzungsrechte über 2026 hinaus zu verlängern. Dazu zählen beispielsweise Cloud-basierte Betriebsmodelle oder die gezielte Ablösung durch entsprechende Nachfolgelösungen. In bestimmten Konstellationen können sich dadurch verlängerte Nutzungszeiträume – etwa bis 2033 – ergeben.
Entscheidend ist jedoch: Diese Optionen sind an klare Voraussetzungen geknüpft und müssen individuell bewertet werden. Sie lassen sich nicht pauschal übertragen und sind stark abhängig von Systemnutzung, Vertragsmodell und Zielarchitektur.
Viele Unternehmen haben das Thema bereits auf dem Radar. Deutlich weniger verfügen jedoch über eine belastbare Einschätzung ihrer eigenen Situation und gehen somit das Risiko des Compliance-Verlusts ein. Genau darin liegt das Risiko: Nicht das Datum allein ist kritisch, sondern fehlende Transparenz und Einordnung.
Wer jetzt noch prüft, schafft sich Handlungsspielraum. Wer zu spät beginnt, steht unter Zeitdruck – fachlich und vertraglich.
Quellen