31. Dezember 2027
Die Mainstream-Wartung für die Kernanwendungen der SAP Business Suite 7 endet. Für SAP ERP 6.0 betrifft das die letzten drei Enhancement Packages 6, 7 und 8.
SAP-Ablöse
Eine Frist, die Sie sich nicht ausgesucht haben.
Die Wartung für SAP Business Suite 7 endet am 31. Dezember 2027. Dieses Datum entscheidet nicht, welches System Sie danach betreiben. Es entscheidet nur, dass Sie entscheiden müssen.
Die Frist
Was tatsächlich ausläuft.
Vier Daten sind relevant, und sie gelten nicht für alle gleich. Welches Ihres ist, hängt vom Enhancement Package ab, auf dem Ihr System läuft – eine Zahl, die die meisten Unternehmen erst nachsehen müssen.
31. Dezember 2025 – bereits vorbei
SAP ERP 6.0 ohne Enhancement Package sowie mit den Enhancement Packages 1 bis 5 hat die Mainstream-Wartung Ende 2025 verlassen. Wer auf einem älteren Stand läuft, steht nicht vor der Frist, sondern dahinter.
2028 bis 2030
Eine optionale verlängerte Wartung lässt sich für drei weitere Jahre buchen, gegen einen Aufschlag von zwei Prozentpunkten auf die Wartungsbasis. Das kauft Zeit. Die Frage beantwortet es nicht.
2040
SAP hat zugesagt, SAP S/4HANA bis Ende 2040 zu warten. Das ist der Horizont des Wegs, den SAP anbietet – gut zu wissen, wenn man ihn mit einem anderen vergleicht.
Quellen, geprüft im August 2026: SAP zur Wartung bis 2027, 2030 und 2040 · SAP-Wartungsstrategie für Business Suite 7 und S/4HANA. Die Daten stammen von SAP und können sich ändern; gleichen Sie sie mit Ihrem Wartungsvertrag ab, bevor Sie darauf planen.
Drei Wege
Nicht eine Entscheidung. Drei.
Zwei davon führen nach S/4HANA und unterscheiden sich darin, wie viel vom Altsystem mitkommt. Der dritte verlässt die Produktlinie. Die Tabelle vergleicht Architektur, nicht Preis oder Qualität – das beurteilen Sie selbst.
| Eigenschaft | Systemkonvertierung | Neuimplementierung | Plattformwechsel |
|---|---|---|---|
| Was mitkommt | Konfiguration, Customizing und historische Daten des bestehenden Systems | Ausgewählte Stamm- und Bewegungsdaten, die Konfiguration entsteht neu | Die Daten; die Prozesse entstehen neu auf einem Standard, der offen gelesen und geändert wird |
| Was neu gemacht werden muss | Jede Modifikation, die der neue Kern nicht mehr zulässt | Das Prozessdesign, bewusst und von Grund auf | Das Prozessdesign, dazu alles, was an SAP-spezifischen Schnittstellen hing |
| Wo es danach läuft | Cloud oder eigenes Rechenzentrum | Cloud oder eigenes Rechenzentrum | Eigenes Rechenzentrum oder EU-Cloud, Ihre Wahl |
| Wie eigene Logik ansetzt | Freigegebene APIs, ABAP Cloud, neben dem Kern – das Clean-Core-Prinzip | Ebenso; eine Neuimplementierung ändert die Erweiterungsregeln nicht | Eigene Module im selben Prozess wie die Daten |
| Datenbank | SAP HANA | SAP HANA | PostgreSQL, offen lizenziert |
| Was die Frist damit macht | Fixes Enddatum, der Aufwand skaliert mit dem Ausmaß der Modifikationen | Fixes Enddatum, der Aufwand skaliert mit der Zahl neu entworfener Prozesse | Keine Herstellerfrist; den Termin setzen Sie selbst |
In verständlichen Worten: Die Systemkonvertierung ist das, was der Markt Brownfield nennt, die Neuimplementierung Greenfield. Dazwischen liegt die selektive Datenmigration, eine Mischform, die eine Hülle des Altsystems konvertiert oder Teile der Konfiguration in eine frische Installation überträgt. Sie ändert, wie viel mitkommt – nicht die Erweiterungsregeln und nicht die Datenbank.
Quellen, geprüft im August 2026: SAP zur Clean-Core-Erweiterung · SAP zur selektiven Datenmigration · Odoo-Community-Lizenz.
Was es kostet
Die Rechnung hat sechs Zeilen.
Keine davon ist der Projektpreis, und genau das ist der Punkt: Das Projekt endet, die anderen fünf kehren wieder. Verglichen wird, wohin das Geld geht, nicht wie viel – warum auf dieser Seite keine Beträge stehen, steht darunter.
| Kostentreiber | Auf dem SAP-Weg | Beim Plattformwechsel | Was den Ausschlag gibt |
|---|---|---|---|
| Datenbanklizenz | Eine eigene Lizenz neben der Anwendung | Keine; PostgreSQL ist offen lizenziert | Datenmenge und der Vertrag, den Sie ohnehin halten |
| Anwendungslizenz | Je Nutzer und Umfang, nach dem Modell des Herstellers | Je Nutzer, dazu die Module, die Sie tatsächlich einsetzen | Wie viele Menschen wirklich einen Zugang brauchen |
| Erweiterung | Neben dem Kern gebaut, an den Stellen, die der Hersteller öffnet | In den Prozess hinein gebaut, in der Sprache, in der die Plattform geschrieben ist | Wie weit Ihre Prozesse vom Standard entfernt sind |
| Betrieb | Herstellercloud oder eigenes Rechenzentrum, mit den passenden Spezialisten | Eigenes Rechenzentrum oder EU-Cloud, mit Standardadministration | Ob das Wissen im Haus schon vorhanden ist |
| Upgrade-Zyklus | Geplante Releases; Modifikationen verteuern jedes davon | Geplante Releases; eigene Module werden gegen jedes getestet | Wie viel Sie selbst gebaut haben – auf beiden Wegen |
| Wieder aussteigen | Daten exportierbar, Erweiterungen an die Herstellerplattform gebunden | Offene Formate, Kernquellcode öffentlich | Was es Sie kostet, im siebten Jahr die Meinung zu ändern |
Warum hier keine Zahlen stehen
Eine Gesamtkostenrechnung ohne Ihren Lizenzvertrag, Ihre Nutzerzahl und den Zustand Ihrer Daten wäre eine erfundene Zahl. Und sie wäre die Zahl, die hängen bleibt. Deshalb vergleichen wir die Treiber – und legen einen ehrlichen Korridor vor, sobald das Assessment alle drei gesehen hat.
Die Zeile, die meist unterschätzt wird
Nicht die Lizenz – die Modifikationen. Was in fünfzehn Jahren ins Altsystem gebaut wurde, entscheidet den Aufwand auf jedem Weg, auch auf dem, der bei SAP bleibt. Sie zu zählen ist das Erste, was ein Assessment tut, weil alles andere bis dahin geraten ist.
Wie es abläuft
Was an einer SAP-Ablöse anders ist.
Die Abfolge ist die, der jede kontrollierte Ablöse folgt. Drei Dinge sind einem System eigen, das das Geschäft zwei Jahrzehnte lang getragen hat.
-
01
Herausfinden, was tatsächlich drinsteckt
Enhancement-Package-Stand, Modifikationen, Eigenentwicklungen, Schnittstellen und die Auswertung, die jemand 2011 gebaut hat und mit der eine Abteilung bis heute den Monatsabschluss macht. Dieser Schritt entscheidet jede Zahl danach – und wird am häufigsten übersprungen.
-
02
Trennen, was mitkommen muss
Nicht jede Eigenentwicklung ist eine Anforderung; manche sind Behelfe für eine Einschränkung, die es nicht mehr gibt. Über jede wird ausdrücklich entschieden: neu bauen, durch Standard ersetzen oder streichen. Was gestrichen wird, wird festgehalten, damit es nach dem Go-live niemand neu entdeckt.
-
03
In Stufen umziehen, nicht in einer Nacht
Ein Umfang, der produktiv gehen kann und schon Nutzen trägt, dann der nächste. Mit historischen Daten wird bewusst umgegangen: Was migriert wird, was in einem Archiv lesbar bleibt und wie lange das Altsystem für Prüfungen verfügbar sein muss.
-
04
Danach muss es jemand betreiben
Am Tag nach dem Go-live wird die Ablöse beurteilt. Monitoring, Support, Updates und eine benannte Verantwortung werden vor Projektbeginn vereinbart, nicht danach verhandelt.
Risiko und Rückweg
Die Frage, die niemand stellt, bis es zu spät ist.
Was passiert, wenn sich das als der falsche Weg herausstellt. Eine Ablöse, die sich nicht anhalten lässt, ist kein Projekt, sondern eine Wette – deshalb werden die Ausstiege gebaut, bevor die erste Stufe startet.
Parallelbetrieb
Beide laufen
- Das Altsystem bleibt verfügbar, während sich eine Stufe setzt
- Abgeglichen wird gegen die Quelle, nicht gegen eine Kopie
- Umstellung je Bereich, nicht für das ganze Unternehmen auf einmal
Entscheidungspunkte
Vor jeder Stufe
- Jede Stufe endet mit einem beurteilbaren Ergebnis
- Die nächste Stufe wird getrennt beauftragt
- Abbruchkriterien werden vorab festgehalten
Der Rückweg
Lesbar
- Das Altsystem bleibt für die Aufbewahrungsfrist lesbar
- Was archiviert statt migriert wurde, ist dokumentiert
- Prüfungen hängen nicht allein am neuen System
Ihre Daten
Ihre
- Extraktion in offene Formate, nicht in eine Blackbox
- Die Zieldatenbank gehört Ihnen: PostgreSQL, jederzeit exportierbar
- Was wir für Sie bauen, gehört Ihnen
Was wir nicht versprechen
Dass eine Ablöse günstiger ist als zu bleiben. Über eine Wartungsperiode ist sie es meistens, aber das hängt an Ihrem Vertrag, und den kennen wir nicht. Was wir versprechen: Sie sehen die Zahlen, bevor Sie sich festlegen, nicht danach.
Wann Sie bei SAP bleiben sollten
Wenn Ihre Prozesse tief an Branchenlösungen hängen, die SAP für Ihre Branche gebaut hat, wenn weltweite Lokalisierung und tiefe regulatorische Anforderungen Ihren Arbeitsalltag prägen, oder wenn sich zeigt, dass es wenige Modifikationen gibt und der Standard passt – dann ist die Konvertierung der kürzere Weg, und wir sagen das auch.
Fragen
Gestellt im ersten Gespräch.
- Wann genau endet die Wartung für unser SAP-System?
- Für SAP ERP 6.0 mit Enhancement Package 6, 7 oder 8 endet die Mainstream-Wartung am 31. Dezember 2027. Ohne Enhancement Package oder mit den Enhancement Packages 1 bis 5 endete sie bereits am 31. Dezember 2025. Welcher Fall zutrifft, sollte man zuerst prüfen, denn davon hängt ab, wie viel Zeit bleibt.
- Löst die verlängerte Wartung bis 2030 das Problem?
- Sie verschiebt es. SAP bietet drei zusätzliche Jahre an, von Anfang 2028 bis Ende 2030, gegen einen Aufschlag von zwei Prozentpunkten auf die Wartungsbasis. Das ist Zeit, um in Ruhe zu entscheiden statt unter Druck. Eine Entscheidung ist es nicht.
- Muss es S/4HANA sein?
- Nein. Das Wartungsende erzwingt eine Entscheidung darüber, welche Plattform Ihr Geschäft trägt, nicht die Wahl eines bestimmten Produkts. S/4HANA ist eine Antwort, und für manche Unternehmen die richtige. Die einzige ist sie nicht.
- Wie lange dauert eine Ablöse?
- Wir nennen keine Dauer, bevor wir das System gesehen haben, denn die ehrliche Antwort hängt von der Zahl der Modifikationen, dem Zustand der Daten und davon ab, wie viele Prozesse sich ändern. Das Assessment, das diese Antwort liefert, dauert zwei bis drei Wochen und endet mit Roadmap und Budgetkorridor.
- Was passiert mit zwanzig Jahren historischer Daten?
- Ein Teil wird migriert, ein Teil archiviert, und diese Trennung wird bewusst entschieden statt vom Migrationswerkzeug bestimmt. Was wie lange und in welcher Form lesbar bleibt, wird vor der ersten Stufe festgehalten, denn genau danach fragt später eine Prüfung.
- Und wenn sich unterwegs zeigt, dass es der falsche Weg war?
- Jede Stufe wird einzeln beauftragt und endet mit einem beurteilbaren Ergebnis, das Altsystem bleibt verfügbar, während sich eine Stufe setzt, und die Abbruchkriterien werden vorab vereinbart. Das Assessment kann auch mit der Empfehlung enden, das Projekt nicht zu machen – das ist ein mögliches Ergebnis, kein Scheitern der Übung.
Der nächste Schritt