SAP Drittdatenbank 2030: Ab 2031 ist Ihr ECC auf sich allein gestellt

Die kundenspezifische Wartung läuft zwar weiter. Für Drittdatenbanken und Java kann SAP aber laut eigener Aussage keine umfassende Unterstützung mehr leisten, nicht einmal bei Kernel-Patches. Was das heißt und wo die vier Jahre wirklich knapp werden.

Das Wichtigste in Kürze

• Ende 2030 laufen die Reseller- und Supportverträge zwischen SAP und den großen Drittdatenbank-Anbietern für SAP Business Suite 7 aus, ebenso der Java-Support für NetWeaver AS Java 7.5.
• Ab 2031 kann SAP für Drittdatenbank-Umgebungen nach eigener Aussage keine umfassende Unterstützung mehr leisten, ausdrücklich auch bei Kernel-Patches und selbst in der kundenspezifischen Wartung.
• Laut SAP ist eine Conversion von ECC auf Drittdatenbank nach S/4HANA nur bis Ende 2030 möglich. Danach bleiben nur Greenfield-Szenarien.
• Der Engpass ist selten die Datenbank. Zeit kosten die Eigenentwicklungen und Java-Anwendungen, die bis dahin eine Lösung brauchen.

SAP Drittdatenbank 2030 heißt konkret: Wer SAP ECC auf einer Drittdatenbank wie Oracle, Microsoft SQL Server oder IBM Db2 betreibt, verliert laut SAP Ende 2030 den datenbankspezifischen Support, auch in der kundenspezifischen Wartung. Für Anwendungen auf NetWeaver AS Java 7.5 endet am selben Stichtag der Java-Support. Eine Conversion nach S/4HANA bietet SAP für diese Systeme nur noch bis Ende 2030 an.

Was hat SAP am 7. Oktober 2026 angekündigt?

Am 7. Oktober 2026 hat SAP-CTO Philipp Herzig im SAP News Center beschrieben, was zum Ende der erweiterten Wartung für SAP Business Suite 7 ausläuft: die Reseller- und Supportverträge mit den großen Drittdatenbank-Anbietern und die Supportvereinbarungen für Java 8 unter NetWeaver AS Java 7.5. Die bekannten Wartungsdaten bleiben unverändert.

Neu ist nicht das Datum. Dass die Datenbankverträge mit Oracle, IBM und Microsoft 2030 auslaufen, wurde in der SAP-Community schon länger diskutiert (E-3 Magazin, Anfang 2025). Neu ist, wie offen SAP die Folgen beschreibt. Das Unternehmen schreibt selbst, dass kundenspezifische Wartung für betroffene Systeme kein nachhaltiges Betriebsmodell ist, und empfiehlt, die eigenen Systeme jetzt zu bewerten.

Welche Fristen gelten für SAP Business Suite 7?

Für SAP Business Suite 7 und damit für ECC 6.0 endet die Mainstream-Wartung am 31. Dezember 2027. Die erweiterte Wartung läuft gegen einen Aufschlag von zwei Prozentpunkten bis 31. Dezember 2030 (SAP-Pressemitteilung vom 4.2.2020). Ab 2031 folgt die kundenspezifische Wartung, für Drittdatenbanken und Java nur noch stark eingeschränkt.

SAP Drittdatenbank 2030: Wer ist betroffen?

Betroffen ist jedes System der SAP Business Suite 7 oder auf SAP NetWeaver, das auf einer Drittdatenbank läuft, etwa auf Oracle, Microsoft SQL Server oder IBM Db2. Das gilt auch dann, wenn die Datenbanklizenz ursprünglich über SAP bezogen wurde. Zusätzlich betroffen ist jede Anwendung, die auf NetWeaver AS Java 7.5 läuft.

Java steckt an mehr Stellen, als viele IT-Leitungen auf dem Schirm haben. Neben dem Enterprise Portal und eigenen Web-Dynpro-Java-Anwendungen gehören in vielen Landschaften die Adobe Document Services dazu, über die viele Unternehmen Formulare wie Lieferscheine oder Bestellungen drucken. Auch SAP Process Integration und Process Orchestration laufen auf AS Java 7.5 und sind betroffen, selbst wenn das ERP längst auf HANA umgezogen ist (SAP-Blog in der SAP Community, Oktober 2026).

Wie Sie diese Anwendungen rechtzeitig umziehen, beschreibt unser Beitrag zur SAP NetWeaver Java Ablösung.

Was bedeutet kundenspezifische Wartung ab 2031?

Kundenspezifische Wartung ist das Wartungsmodell, in das Systeme nach dem Ende der erweiterten Wartung fallen. SAP beschreibt es als Lösung bekannter Probleme zu unveränderten Gebühren (SAP-Pressemitteilung vom 4.2.2020). Für Drittdatenbanken und Java ist selbst dieser Rahmen ab 2031 laut SAP weiter eingeschränkt.

Konkret nennt SAP für Drittdatenbank- und Java-Umgebungen ab 2031:

• Keine umfassende Unterstützung mehr bei Problemen mit Drittdatenbanken oder Java, ausdrücklich auch nicht bei Kernel-Patches und Kernel-Security-Patches.
• Unter Umständen keine Downloads mehr von Datenbank-, Backup-, Upgrade- und Migrationstools.
• Keinen integrierten Weg mehr, über den SAP Datenbank-Tickets an den Hersteller weiterleitet.
• Keinen Nachfolge-Release für NetWeaver AS Java 7.5.

Was das im Betrieb heißt, zeigt ein einfaches Szenario: Nach einem Betriebssystem-Update bricht die Verbindung zwischen SAP-Kernel und Oracle-Datenbank ab. Heute eröffnen Sie ein Ticket bei SAP, und SAP holt den Datenbankhersteller dazu. Ab 2031 fehlt dieser Weg. SAP räumt selbst ein, dass dann Fehler auftreten können, die sich im verfügbaren Supportrahmen nicht lösen lassen.

Welche Wege bleiben bis Ende 2030?

Unternehmen mit ECC auf einer Drittdatenbank haben bis Ende 2030 vier realistische Wege: die Conversion nach S/4HANA oder SAP Cloud ERP, den Umzug auf SAP HANA mit Weiterbetrieb von ECC, die Transition Option für die größten und komplexesten Kunden oder einen späteren Greenfield-Neustart. Daneben bieten unabhängige Supportanbieter den Weiterbetrieb an.

SAPs eigene Empfehlung ist eindeutig: die Transformation zu SAP Cloud ERP mit den passenden Lösungen der SAP Autonomous Suite bis Ende 2030 abzuschließen.

Wie knapp das wird, zeigt die DSAG: Im DSAG-Investitionsreport 2026 plante knapp die Hälfte der ECC-Anwender, die noch in das System investieren, den Wechsel auf S/4HANA erst bis Ende 2030. 37 Prozent zielten auf Ende 2027 (198 Befragte, Dezember 2025 bis Januar 2026). Wer zur ersten Gruppe gehört und auf einer Drittdatenbank sitzt, plant damit exakt bis zur letzten Möglichkeit für die Conversion.

Die DSAG begrüßt, dass SAP früh informiert. Ihr Vorstandsmitglied Michael Bloch rät aber, erst nach Prüfung aller Alternativen und ihrer langfristigen Folgen zu entscheiden (SAP News Center, 7.10.2026).

Einen ausführlichen Vergleich der Wege finden Sie im Beitrag zur S/4HANA Conversion Frist 2030

Warum die Datenbank nicht Ihr Engpass ist

Der Wechsel der Datenbank ist in den meisten Projekten der planbarste Teil. Zeit kosten die Eigenentwicklungen, die in zwanzig Jahren um ECC herum entstanden sind: Z-Transaktionen, Modifikationen, Java-Anwendungen und Schnittstellen zu Excel-Lösungen. Jede davon muss vor der Conversion geprüft und entweder angepasst oder abgeschaltet werden. Genau dort laufen die vier Jahre weg.

Im Einkauf läuft die Freigabe von Bestellanforderungen oft über eine Z-Transaktion mit eigener Logik für Wertgrenzen und Vertretungen. In der Instandhaltung melden Techniker Störungen über eine Web-Dynpro-Java-Maske im Portal. Im Lager werden Lieferscheine über die Adobe Document Services gedruckt. Keine dieser Anwendungen ist SAP-Standard, und jede braucht bis Ende 2030 eine Lösung.

Wie Sie systematisch vorgehen, zeigt unser Beitrag SAP Eigenentwicklungen entkoppeln.

Unsere These: Wer bis Ende 2030 fertig sein will, sollte zuerst klären, was gar nicht erst mit muss, und erst danach die Conversion planen. Viele Projekte gehen umgekehrt vor und entdecken den Ballast in der Testphase.

Christian Kleinschroth, CTO, simplifier AG

Was Sie in den nächsten drei Monaten tun sollten

Der erste Schritt ist eine Inventur, keine Wegentscheidung. Klären Sie in den nächsten drei Monaten, welche Systeme auf welcher Datenbank laufen, wo Java im Einsatz ist und welche Eigenentwicklungen tatsächlich genutzt werden. Erst mit dieser Liste lässt sich seriös beurteilen, ob eine Conversion bis Ende 2030 realistisch ist.

1. Systemliste erstellen, mit der Datenbank je System, auch für Nebensysteme wie BW (siehe SAP-Hinweis 3768400).
2. Java-Anwendungen erfassen, einschließlich Adobe Document Services und PI/PO, und mit SAP-Hinweis 3464370 abgleichen.
3. Eigenentwicklungen nach Nutzung sortieren: abschalten, im Kern behalten oder auslagern.
4. Die Wegentscheidung im Management mit einem festen Termin verankern.

Die eigentliche Managementfrage ist deshalb größer als der Datenbankwechsel: Welche Anwendungen und Integrationen wollen Sie nach 2030 in einem beherrschbaren Betriebsmodell weiterführen, und wo sollen sie laufen? Antworten darauf geben unsere Beiträge zu SAP Clean Core ohne BTP und zu KI für SAP ECC.

Die eigentliche Managementfrage ist deshalb größer als der Datenbankwechsel: Welche Anwendungen und Integrationen wollen Sie nach 2030 in einem beherrschbaren Betriebsmodell weiterführen, und wo sollen sie laufen?

Für die Gruppe „auslagern“ gibt es einen Weg, der vor der Conversion beginnt. Anwendungen mit eigener Oberfläche und eigenem Prozess laufen auf einer Plattform neben dem ERP und greifen über Standardschnittstellen auf SAP zu. So arbeitet Simplifier: Die Anwendung entsteht, solange noch ECC dahinter läuft, und bleibt nach dem Umstieg erhalten. Bauen lässt sich heute vieles schnell, auch mit KI. Der Wert einer Plattform beginnt am ersten Produktivtag: mit Betrieb, Governance, Upgrade-Sicherheit und Auditierbarkeit. Den ersten Überblick liefert ein Migration Checkup mit Miri, unserer KI-Migrations-Agentin: Sie analysiert bestehende Anwendungen und zeigt Abhängigkeiten, Aufwand, Risiken und Prioritäten in einem ersten strukturierten Migrationsplan.