Mythos: „Die ECC-Deadline 2027 betrifft uns eigentlich nicht"

Die ECC-Deadline 2027 ist nicht das eigentliche Risiko. Das Risiko besteht darin, dass viele Unternehmen die verbleibende Zeit mit verfügbarem Projektspielraum verwechseln. Extended Maintenance kauft Zeit – aber keine Zukunftsfähigkeit.

Erstaunlich häufig erlebe ich noch Unternehmen, die wirklich glauben, die 2027-Deadline sei für sie flexibel. Vor allem im Mittelstand höre ich Sätze wie „wir haben ja noch bis 2027 Zeit" oder „SAP wird die Fristen sowieso wieder verlängern". Warum diese Annahme so gefährlich ist, erkläre ich in diesem Beitrag.

Kalenderzeit ist nicht Projektzeit

Hinter der Annahme, man habe noch reichlich Zeit, steckt meist eine Verwechslung von Kalenderzeit und Projektzeit. Ja, formal läuft die Mainstream-Wartung für SAP ECC noch bis Ende 2027. Aber die entscheidende Frage lautet: Wann muss ein Unternehmen beginnen, damit es rechtzeitig fertig wird?

Eine S/4HANA-Transformation ist kein technisches Upgrade. Sie betrifft Prozesse, Stammdaten, Eigenentwicklungen, Integrationen und oft auch das Betriebsmodell. Allein die Vorbereitungsphase kann 6 bis 12 Monate dauern, größere Programme benötigen zwei bis vier Jahre. Deshalb betrifft die Deadline Unternehmen nicht erst 2027, sondern schon heute. Wer jetzt noch keinen klaren Plan hat, verliert Handlungsspielraum und riskiert, später unter Zeitdruck entscheiden zu müssen.

Was Extended Maintenance in der Praxis wirklich bedeutet

Viele interpretieren Extended Maintenance als „Business as usual gegen Aufpreis". Tatsächlich ist es eher eine Verlängerung der Landebahn, nicht des Flugs. Unternehmen erhalten weiterhin Support von SAP, zahlen dafür aber deutlich höhere Wartungsgebühren, während sich der Fokus von Innovation auf reine Bestandserhaltung verschiebt.

Drei Aspekte werden dabei häufig unterschätzt. Erstens die steigenden Kosten: Die zusätzlichen Wartungsgebühren kommen zu den ohnehin bestehenden Betriebskosten hinzu, ohne dass ein zusätzlicher Geschäftsnutzen entsteht. Zweitens der wachsende Innovationsrückstand: Neue Funktionen entstehen heute primär in S/4HANA und den Cloud-Lösungen. Wer auf ECC bleibt, verzichtet auf vieles im Bereich Analytics, Automatisierung, KI oder moderne Benutzeroberflächen. Drittens zunehmende Risiken: Je länger Altsysteme betrieben werden, desto schwieriger wird es, Know-how zu sichern, Schnittstellen aktuell zu halten und regulatorische Anforderungen umzusetzen.

Ein typisches Beispiel sind Eigenentwicklungen, die über viele Jahre entstanden sind – häufig von einzelnen Mitarbeitenden oder kleinen Teams, die das Unternehmen inzwischen verlassen haben oder kurz vor dem Ruhestand stehen. Werden dann Anpassungen nötig, etwa durch neue gesetzliche Anforderungen, fehlt oft das notwendige Wissen. Gleichzeitig wird es immer schwieriger, Fachkräfte zu finden, die sich mit älteren SAP-Technologien und individuell entwickelten Lösungen auskennen. Und jede Eigenentwicklung erhöht den Aufwand bei zukünftigen Upgrades, weil Abweichungen vom Standard analysiert, getestet und häufig manuell angepasst werden müssen. Extended Maintenance kauft also Zeit, löst aber keines der eigentlichen Probleme.

Die echten Kosten des Wartens

Die größten Kosten erscheinen häufig in keiner Budgetplanung. Unternehmen verlieren vor allem Optionen: Wer heute wartet, steht morgen vor einem kleineren Markt an Beratern, Implementierungspartnern und internen Expertinnen und Experten, während die Nachfrage nach Transformationskapazitäten weiter steigt. Darüber hinaus verpassen Unternehmen konkrete Chancen – schnellere und stärker standardisierte Prozesse, moderne Echtzeit-Analytik, KI-gestützte Automatisierung, einfachere Integration neuer Geschäftsmodelle und bessere Skalierbarkeit für internationale Rollouts. Man könnte sagen: Die Kosten des Wartens entstehen nicht nur durch das, was man bezahlt, sondern durch das, was man nicht nutzen kann.

Ein Beispiel: Teurer als nötig, weil zu spät begonnen

Das Muster, das ich in solchen Fällen sehe, ist oft ähnlich. Viele Unternehmen starten mit der Annahme, ein technisches Upgrade reiche aus. Erst während der Vorbereitung wird sichtbar, wie viele Sonderentwicklungen, individuelle Prozesse und historisch gewachsene Schnittstellen tatsächlich existieren.

Ein typisches Beispiel ist ein mittelständisches Produktionsunternehmen mit stark individualisierten Prozessen, bei dem die eigentliche Systemkonvertierung technisch beherrschbar war. Die Herausforderung lag darin, über Jahre entstandene Eigenentwicklungen zu analysieren und zu entscheiden, was wirklich noch benötigt wird. Weil die Vorarbeiten zu spät begonnen wurden, musste das Unternehmen parallel Prozesse harmonisieren, Daten bereinigen und die Migration vorbereiten – Aufwand, Projektdauer und externe Kosten stiegen deutlich. Wichtige Fachbereiche waren über einen längeren Zeitraum stark eingebunden und hatten dadurch weniger Kapazität für Tagesgeschäft und strategische Initiativen. Entscheidungen mussten unter höherem Zeitdruck getroffen werden, was die Bereitschaft zu kurzfristigen Kompromissen erhöhte.

Am Ende war die Transformation erfolgreich, aber deutlich komplexer und teurer als nötig. Weil für eine vorgelagerte Bereinigung keine Zeit mehr blieb, wurden bestehende Berechtigungen, alte Stammdaten und zahlreiche Eigenentwicklungen im Brownfield-Ansatz per Lift-and-Shift übernommen. So wanderten viele Altlasten unverändert in die neue Umgebung, und das Unternehmen zahlte weiterhin für Prozesse, Datenbestände und Z-Codes, die teilweise keinen geschäftlichen Mehrwert mehr lieferten. Die notwendige Bereinigung musste nach der Migration nachgeholt werden – deutlich aufwendiger und teurer, als diese „alten Zöpfe" bereits vor der Transformation konsequent abzuschneiden. Die wichtigste Erkenntnis daraus: Nicht die Migration selbst wird zum Risiko, sondern die fehlende Vorbereitungszeit.

Die Frage, die ich jedem Mittelstands-CIO stellen würde

Wenn ich mit einem CIO im Mittelstand spreche, der glaubt, noch mehr Zeit zu haben, als tatsächlich der Fall ist, stelle ich eine einfache Frage: „Wenn Sie heute starten müssten – kennen Sie den tatsächlichen Umfang Ihrer Transformation?" Die meisten Unternehmen können diese Frage noch nicht belastbar beantworten.

Gerade im Mittelstand ist die Herausforderung oft größer als in Konzernen. Viele Prozesse wurden über Jahre sehr individuell auf die Bedürfnisse des Unternehmens zugeschnitten – diese Individualisierung ist häufig ein Wettbewerbsvorteil, macht eine Transformation aber komplexer. Während global agierende Unternehmen mit stark standardisierten Prozessen oft leichter in Richtung Public Cloud gehen können, benötigen mittelständische Unternehmen häufiger private Cloud- oder hybride Szenarien, um ihre Besonderheiten abzubilden.

Ein konkretes Beispiel ist ein Maschinenbauer, der seine Fertigungsprozesse über Jahre eng mit individuellen SAP-Eigenentwicklungen für Produktionsplanung, Variantenkonfiguration und Servicegeschäft verzahnt hat. Solche Prozesse lassen sich nicht ohne Weiteres in standardisierte Cloud-Modelle überführen. Das Unternehmen betreibt seine wettbewerbsentscheidenden Eigenentwicklungen im Bereich Production Planning deshalb zunächst weiter im bestehenden ECC-On-Premise-Modell, während die Finanzprozesse bereits in die standardisierte Public Cloud überführt werden. Die Realität endet also selten in einem klaren Entweder-oder – die meisten Unternehmen landen in einer hybriden Zielarchitektur aus Cloud- und On-Premise-Komponenten.

Fazit

Mein Rat: Diskutieren Sie nicht zuerst über die Deadline, diskutieren Sie über Ihren Zielzustand. Denn die eigentliche Frage lautet nicht, ob Sie migrieren müssen, sondern wie viel Gestaltungsfreiheit Sie sich auf dem Weg dorthin erhalten wollen.

Möchten Sie wissen, wie groß der tatsächliche Umfang Ihrer Transformation ist? Wir schauen mit Ihnen gemeinsam auf Ihre Eigenentwicklungen, Ihre Lizenzsituation und Ihren realistischen Zeithorizont – bevor die Deadline die Entscheidung für Sie trifft.