Die Wartung für SAP ECC endet am 31. Dezember 2027: eine Preisstufe, keine Abschaltung

Am 31. Dezember 2027 beendet SAP die Mainstream-Wartung für SAP ECC 6.0 und die übrigen Kernanwendungen der SAP Business Suite 7. Am 1. Januar 2028 wird nichts abgeschaltet. Ihr System läuft weiter, Ihre Anwender buchen weiter Rechnungen, und SAP verkauft Ihnen weiterhin Support. Was sich ändert, ist, wie viel Sie dafür zahlen und was Sie dafür bekommen.

Diese Unterscheidung ist wichtig, weil viele der kursierenden Ratschläge 2027 als Klippe behandeln. Für die meisten Unternehmen, die noch auf ECC sind, ist es keine, und sie wissen das: Die größte Gruppe der verbliebenen ECC-Anwender plant für 2030. Das eigentliche Risiko ist ein anderes. Die Arbeit, die tatsächlich über den Termin entscheidet (Eigenentwicklungen in ABAP, Schnittstellen, Daten), wird spät geplant, und 2030 erweist sich als genauso knapp, wie es 2027 war.

Dieser Artikel richtet sich an CIOs und SAP-Verantwortliche in mittelständischen Unternehmen, die meisten davon im deutschsprachigen Raum, die noch ECC betreiben und entscheiden müssen, wie die nächsten drei Jahre aussehen.

Was SAP tatsächlich zugesagt hat

Die Bedingungen stehen auf der Seite zur Wartungsstrategie von SAP und wurden erstmals im Februar 2020 angekündigt:

• Bis zum 31. Dezember 2027: Mainstream-Wartung für die Kernanwendungen der Business Suite 7, darunter SAP ERP 6.0, auf den jeweils letzten drei Erweiterungspaketen (Enhancement Packages). Wenn Ihr System auf einem älteren Erweiterungspaket steht, prüfen Sie den SAP-Hinweis 2881788 (auf derselben Seite verlinkt), bevor Sie einen Plan auf dem Datum 2027 aufbauen.
• 1. Januar 2028 bis 31. Dezember 2030: optionale erweiterte Wartung (Extended Maintenance), mit „einem Aufschlag von zwei Prozentpunkten auf die Wartungsbasis“. Einfach gesagt: Der Wartungssatz, den Sie heute zahlen, steigt um zwei Punkte.
• Wenn Sie keine erweiterte Wartung abschließen: Sie wechseln automatisch in die kundenspezifische Wartung (Customer-Specific Maintenance). Was diese abdeckt, beschreibt der SAP-Hinweis 52505, verlinkt auf derselben Seite. Lesen Sie ihn, bevor Sie annehmen, dass sie ausreicht.
• Für S/4HANA: SAP hat Wartung bis Ende 2040 zugesagt.

Für eine kleinere Gruppe gibt es einen weiteren Weg. Im August 2025 hat SAP die SAP ERP, private edition, transition option vorgestellt: ein zeitlich begrenztes Abonnement, das ECC von 2031 bis 2033 in der Private Cloud von SAP weiterführt. Die Bedingungen sind streng. „Die Systeme müssen vor dem 31. Dezember 2030 auf SAP ERP, private edition auf SAP HANA migriert sein.“ HANA ist die einzige unterstützte Datenbank, die Option gibt es nur zusammen mit dem Max Success Plan für 2031 bis 2033, und SAP setzt für darunter abonnierte Systeme ein Minimum von 2 TB an. Laut SAP ist sie für „unsere größten und komplexesten SAP-ERP-Kunden“ gedacht. Die „kommerziell gleichwertigen Bedingungen“, die SAP angeboten hat, galten für Kunden, die sich bis Ende 2025 für die private edition entschieden haben.

Welche Stufe Sie auch wählen, stellen Sie SAP und Ihrem Partner eine Frage schriftlich: Welche gesetzlichen Änderungen (Steuern, Lohnabrechnung, Formate für die E-Rechnung) erreichen Ihr ECC-System noch, und bis wann? Für ein deutsches Unternehmen kann allein diese Antwort entscheiden, ob Stillstand eine Option ist.

Was der Rest des Marktes tut

Die DSAG, die Deutschsprachige SAP-Anwendergruppe, hat für ihren Investitionsreport 2026 zwischen dem 8. Dezember 2025 und dem 21. Januar 2026 198 Teilnehmende befragt. Davon betreiben 54 Prozent noch ECC oder die ältere Business Suite, nach 68 Prozent im Jahr 2024.

Beim Zeitpunkt plant fast die Hälfte der Befragten den Umstieg auf S/4HANA bis Ende 2030, was, wie die DSAG anmerkt, bedeutet, für die erweiterte Wartung zu zahlen. Weitere 37 Prozent wollen bis Ende 2027 umsteigen, und nur 4 Prozent peilen 2033 und die private edition transition option an.

Der DSAG-Vorstandsvorsitzende Jens Hungershausen nannte die Gründe offen: Fachkräftemangel, parallele Transformationsprojekte und begrenzte Budgets schieben die Zeitpläne nach hinten, „auch wenn dadurch höhere Wartungskosten entstehen“.

Auch öffentliche Auftraggeber bewegen sich. Unsere eigene Auswertung der EU-weiten Ausschreibungsbekanntmachungen kommt für 2025 und 2026 auf rund 200 Verfahren zur Migration auf S/4HANA pro Halbjahr und für 2026 bis Anfang Oktober auf mehr als 300, die meisten davon in Deutschland. Die Arbeit findet statt. Sie verteilt sich nur über eine längere Strecke, als die Schlagzeilen zu 2027 vermuten lassen.

Wo die Arbeit tatsächlich liegt

Die technische Konvertierung von ECC zu S/4HANA ist bei SAP und seinen Partnern gut mit Werkzeugen unterstützt. Wenn Sie ein wenig angepasstes ECC mit einer Handvoll Standardschnittstellen betreiben, hat Ihr Integrator das schon oft gemacht, und das meiste von dem, was folgt, ist nicht Ihr Problem.

Es wird in dem Maß zu Ihrem Problem, in dem Sie selbst gebaut haben.

Eigenentwicklungen in ABAP: wo Projekte ins Rutschen geraten

S/4HANA ist nicht ECC auf einer neuen Datenbank. Teile des Datenmodells haben sich geändert. Kunden und Lieferanten werden zu Geschäftspartnern. Buchungen in Finanzwesen und Bestandsführung wurden in weniger, dafür breitere Tabellen zusammengeführt. Einige Transaktionen und Funktionen wurden entfernt oder ersetzt.

Eigener Code, der direkt Tabellen liest, sich auf einen Exit verlässt, der verschoben wurde, oder stillschweigend eine Sortierreihenfolge voraussetzt (HANA garantiert keine, wenn die Abfrage nicht danach fragt), kann eine Syntaxprüfung bestehen und trotzdem das Falsche tun. Diese letzte Art ist die schmerzhafte, weil sie im Integrationstest oder nach dem Go-live auffällt, nicht beim Code-Scan.

Das Vorgehen, das funktioniert:

1. Zuerst die Nutzung messen. Schalten Sie in der Produktion die Nutzungsprotokollierung ein (den ABAP Call Monitor, Transaktion SCMON) und lassen Sie sie über einen vollständigen Jahresabschluss laufen. In langlebigen Systemen läuft ein beträchtlicher Teil der Eigenentwicklungen oft nie. Code, den niemand ausführt, wird gelöscht, nicht migriert.
2. Die Analysewerkzeuge auf den Rest anwenden. Die Prüfungen von SAP finden mögliche Probleme. Welche davon für das Geschäft zählen, können sie Ihnen nicht sagen.
3. Jedes Objekt einordnen. Stilllegen, durch Standardfunktionalität ersetzen, an Ort und Stelle korrigieren oder außerhalb des Kerns neu bauen. Eine Entscheidung je Objekt, mit einem namentlich benannten Verantwortlichen aus dem Fachbereich.
4. Nach Prozess testen, nicht nach Objekt. Den Code zu ändern ist der billige Teil. Nachzuweisen, dass Order-to-Cash und Monatsabschluss weiterhin dieselben Zahlen liefern, ist der teure.

Projekte geraten hier aus einem langweiligen Grund ins Rutschen: Niemand hat früh genug gezählt. Der Umfang der Eigenentwicklungen ist nur grob bekannt, die Leute, die sie geschrieben haben, sind oft nicht mehr da, und die echten Befunde kommen im zweiten Testzyklus, nachdem der Termin intern schon verkündet wurde.

Schnittstellen, und PI/PO auf derselben Uhr

ECC steht selten allein. IDocs an das Lager, RFC- und BAPI-Aufrufe aus der Fertigung, Flatfiles an die Bank und den Steuerberater, ein Kundenportal, das einen Datenbank-View liest, den jemand 2011 angelegt hat. Jede davon muss gefunden, getestet und in manchen Fällen neu gebaut werden.

Wenn diese Schnittstellen über SAP Process Integration oder Process Orchestration laufen, gibt es eine zweite Frist zu denselben Terminen. Das Architecture Center von SAP sagt, PI/PO nähere sich „dem Ende der Standardwartung im Jahr 2027“, Kunden könnten die Wartung bis 2030 verlängern, und danach ende der Support von SAP. SAP verweist Kunden von PI/PO auf die SAP Integration Suite, zu der ein Migrationsassessment und assistentengestützte Migrationswerkzeuge gehören.

Die Werkzeuge helfen bei den Standardobjekten. Sie sagen Ihnen nicht, welche Schnittstellen noch irgendetwas bedienen, und eigene Mapping-Logik muss weiterhin ein Mensch lesen. Bauen Sie das Inventar aus der Middleware-Konfiguration, den Protokollen und den eingeplanten Jobs auf, nicht aus einem Fragebogen. Planen Sie dann den Umzug des ERP und den Umzug der Middleware gemeinsam. Nacheinander erledigt, wird jede Schnittstelle zweimal getestet.

Datenmigration

Bei einer Systemkonvertierung zieht Ihr Datenbestand mit dem System um, und seine Qualität ebenso. Die Umstellung auf Geschäftspartner ist meist die erste Kollision: doppelte Kunden, Lieferanten, die zugleich Kunden sind, Adressen in Freitextfeldern, Steuernummern an der falschen Stelle. All das muss vor der Konvertierung bereinigt werden, nicht währenddessen.

Bei einer Neuimplementierung extrahieren, bereinigen, transformieren und laden Sie, und der schwierige Teil ist der Abgleich. Die Finanzabteilung gibt frei, wenn Salden und offene Posten übereinstimmen, nicht wenn der Ladejob fertig ist. Bauen Sie die Migration als wiederholbaren Code, den Sie ein Dutzend Mal gegen zunehmend sauberere Daten laufen lassen können, mit automatischem Vergleich der Ergebnisse bei jedem Lauf.

Auf beiden Wegen gilt: Archivieren Sie zuerst, was Sie nicht mehr brauchen. Weniger Daten bedeuten kürzere Konvertierungsläufe und ein kürzeres Ausfallfenster.

Erweiterungen nach Clean Core

Die Versuchung in einem terminbestimmten Projekt ist, jede Modifikation mitzunehmen und zu versprechen, später aufzuräumen. Später kommt nicht.

SAPs Name für die Alternative ist Clean Core: das Standardsystem unverändert lassen und Erweiterungen gegen Schnittstellen bauen, die SAP veröffentlicht und stabil hält, entweder innerhalb von S/4HANA oder daneben auf der SAP Business Technology Platform. Nicht alles kann am ersten Tag sauber sein. Die Regel, die Sie tatsächlich durchhalten können, ist einfacher: Nichts Neues wird mehr auf die alte Art gebaut. Jede Modifikation, die Sie jetzt vermeiden, müssen Sie nicht bei jedem künftigen Upgrade erneut testen.

Ein Entscheidungsrahmen

Es gibt drei realistische Wege und einen vierten, der weniger Aufmerksamkeit bekommt.

Bis zum 31. Dezember 2027 auf S/4HANA live gehen. Das passt zu Unternehmen, die bereits begonnen haben, ein weitgehend standardnahes System betreiben und einen Partner gebucht haben. Ab heute sind das fünfzehn Monate, und nur wenige Finanzabteilungen akzeptieren eine Umstellung mitten im Jahresabschluss. Wenn Ihre Analyse der Eigenentwicklungen noch nicht gemacht ist, ist das vermutlich nicht Ihr Weg.

Für die erweiterte Wartung zahlen und bis 2030 live gehen. Dorthin bewegt sich der größte Teil des Marktes. Die Kosten sind der Aufschlag von zwei Punkten; klären Sie mit SAP, wie er gilt, wenn Sie mitten im Zeitraum live gehen. Das Risiko ist, 2030 so zu behandeln, wie 2027 behandelt wurde: als fern, bis es das plötzlich nicht mehr ist.

Die private edition transition option bis 2033 nutzen. Das bedeutet einen Vertrag für RISE with SAP, HANA, die Migration Ihres Systems auf SAP ERP, private edition vor dem 31. Dezember 2030, den Max Success Plan und das Minimum von 2 TB. Für ein mittelständisches Unternehmen ist das selten der günstigste Weg, Zeit zu kaufen.

SAP verlassen. Für manche mittelständischen Hersteller und Händler ist ein kleineres ERP eine echte Option. Die Arbeit an Schnittstellen und Daten schrumpft dadurch nicht. Sie wird zum größten Teil des Projekts.

Die nächsten sechs Monate, egal welchen Weg Sie wählen

Von jetzt bis Ende März 2027 zahlt sich all das auf jedem Weg aus:

1. Ihren Ausgangspunkt bestätigen. Erweiterungspaket, Datenbank, Wartungsvertrag. Bitten Sie Ihr SAP-Account-Team schriftlich um die Bedingungen der erweiterten Wartung, die für Sie gelten.
2. Die Nutzungsprotokollierung jetzt einschalten, damit sie den Jahresabschluss 2026 erfasst.
3. Eine Analyse der Eigenentwicklungen durchführen und mit einer Zahl herauskommen, nicht mit einem Eindruck: wie viele Objekte, wie viele davon in Gebrauch, wie viele berühren die geänderten Teile des Datenmodells.
4. Das Schnittstelleninventar aufbauen, einschließlich allem, was über PI/PO läuft, mit einem Verantwortlichen und einer Entscheidung je Schnittstelle.
5. Mit der Stammdatenbereinigung beginnen, zuerst Kunden und Lieferanten.
6. Keine Modifikationen mehr hinzufügen. Neue Entwicklung folgt ab heute Clean Core.
7. Den Wartungsaufschlag für 2028 ins Budget 2027 aufnehmen, als bekannte Kosten statt als Überraschung.
8. Kapazität buchen: den Partner, Ihr internes SAP-Team und die Entwickler, die die Systeme rund um SAP betreuen. Fachkräftemangel ist einer der Gründe, die die DSAG-Mitglieder für rutschende Zeitpläne nennen.

Rückwärts gerechnet von einem Go-live 2030: Testzyklen und Generalproben der Umstellung 2030, Umsetzung und Nacharbeit 2029, Design und Datenbereinigung 2028, Analyse jetzt. Darin steckt weniger Luft, als es aussieht.

Wo Sie Hilfe bekommen

Wir sind keine funktionale SAP-Beratung und führen keine Konvertierungen auf S/4HANA durch; wir arbeiten neben dem Partner, der das tut, am Schnittstelleninventar und am Neubau der Schnittstellen, am Code der Datenmigration und seinem Abgleich und an den Anwendungen rund um ECC, die den Umzug überstehen müssen. Diese Arbeit beschreibt unsere Seite zur ERP-Modernisierung, und die Wartung von Bestandssystemen deckt die Systeme ab, die bleiben, wo sie sind, bis Sie umziehen. Wenn Sie die Systemlandschaft rund um Ihr ERP gezählt haben möchten, bevor Sie ein Programm unterschreiben, schreiben Sie an office@c9group.dev.