Für NetWeaver AS Java 7.5 gibt es keinen Nachfolger, und die Transition Option hilft nicht weiter. Wo Java in Ihrer Landschaft steckt und wie Sie den Umzug rechtzeitig planen.
Das Wichtigste in Kürze
- Der Java-Support für NetWeaver AS Java 7.5 endet Ende 2030. Ab 2031 läuft AS Java 7.5 ohne Nachfolge-Release in der kundenspezifischen Wartung.
- Weder die kundenspezifische Wartung noch die Transition Option decken Java-abhängige Funktionen ab.
- Betroffen sind auch Komponenten ohne direkten ERP-Bezug, etwa PI/PO und die Adobe Document Services für den Formulardruck.
- Für SAP-eigene Produkte nennt SAP-Hinweis 3464370 die vorgesehenen Übergänge. Eigenentwicklungen müssen Unternehmen selbst umziehen.
Die SAP NetWeaver Java Ablösung ist bis Ende 2030 fällig: Dann enden die Supportvereinbarungen für Java 8 unter NetWeaver AS Java 7.5, und einen Nachfolge-Release gibt es nicht. Portal-Oberflächen, Web-Dynpro-Java-Anwendungen, der Formulardruck über die Adobe Document Services und PI/PO brauchen bis dahin eine Lösung.
Was genau endet für NetWeaver AS Java 7.5?
Ende 2030 laufen die Supportvereinbarungen für Java 8 und JEE5 unter NetWeaver AS Java 7.5 aus. Ab 2031 läuft AS Java 7.5 mit allen Add-ons in der kundenspezifischen Wartung, ohne Folgerelease. SAP schreibt selbst, dass es Java-Themen dann nicht mehr umfassend unterstützen kann, auch nicht in der kundenspezifischen Wartung (SAP News Center, 7.10.2026).
Den Gesamtüberblick über alle Fristen gibt unser Beitrag SAP Drittdatenbank 2030.
Für das Enterprise Portal 7.5 gilt dieselbe Linie: Mainstream-Wartung bis Ende 2027, erweiterte Wartung bis 2030. Schon heute ist SAPUI5 1.71 die letzte Langzeitversion, die SAP für NetWeaver Java ausliefert (SAP Community, Themenseite Enterprise Portal). Wer neue Oberflächenfunktionen braucht, bekommt sie auf diesem Stack nicht mehr.
Wo steckt Java in Ihrer SAP-Landschaft?
Java steckt in mehr Systemen, als in vielen Architekturübersichten steht. Neben dem Enterprise Portal und eigenen Web-Dynpro-Java-Anwendungen laufen die Adobe Document Services für den Formulardruck sowie SAP Process Integration und Process Orchestration auf AS Java. Diese Abhängigkeiten fallen oft erst bei einer gezielten Inventur auf.
| Komponente | Typischer Einsatz | Was zu tun ist |
| Enterprise Portal | Einstieg für Mitarbeiter, Lieferanten oder Kunden | SAP-Übergang nach Hinweis 3464370 prüfen; eigene Inhalte selbst umziehen |
| Web Dynpro Java (Eigenentwicklung) | Erfassungsmasken, Self-Services | selbst neu aufbauen |
| Adobe Document Services | Druck von Formularen wie Lieferscheinen, Bestellungen und Rechnungen | SAP-Übergang nach Hinweis 3464370 prüfen |
| PI/PO | Schnittstellen zwischen SAP und Fremdsystemen | SAP-Übergang nach Hinweis 3464370 prüfen; Schnittstellen migrieren |
| Eigene Java-Anwendungen auf AS Java | Sonderlösungen | selbst neu aufbauen |
PI/PO verdient besondere Aufmerksamkeit, weil es auch Unternehmen betrifft, die ihr ERP längst modernisiert haben. SAP hat Anfang Oktober 2026 klargestellt, dass die Einschränkung für PI/PO unabhängig davon gilt, ob noch SAP Business Suite 7 im Einsatz ist. Für die Private Cloud Edition von PO endet die Wartung am 31. Dezember 2030 (SAP-Blog in der SAP Community, Oktober 2026).
Ein Beispiel aus der Logistik: Der Versand druckt Lieferscheine und Etiketten über Adobe-Formulare. Die Formularlogik liegt im ABAP-System, das Erzeugen der PDF-Dokumente übernehmen die Adobe Document Services auf dem Java-Stack. Läuft dieser Stack ab 2031 ohne umfassenden Support weiter, hängt der Versand an einer Komponente, bei der SAP im Fehlerfall nur noch eingeschränkt hilft.
Warum hilft die Transition Option bei Java nicht?
Die Transition Option verlängert den Betrieb von ECC von 2031 bis 2033, unterstützt aber keine Java-abhängigen Funktionen. Wer sie nutzen will, muss Java-Anwendungen bis Ende 2030 abgelöst haben. Dasselbe gilt für die kundenspezifische Wartung: Auch sie ersetzt den auslaufenden Java-Support nicht (SAP News Center, 7.10.2026).
Was sieht SAP für die eigenen Java-Produkte vor?
Für SAP-eigene Produkte auf AS Java nennt SAP-Hinweis 3464370 die vorgesehenen Übergänge. Der Hinweis ist der erste Abgleich für jede Komponente in Ihrer Inventur. Er beantwortet allerdings nur, wohin SAP das jeweilige Produkt führt. Für eigene Inhalte und Eigenentwicklungen müssen Sie den Umzug selbst planen.
SAP schreibt selbst, dass es für Lösungen auf AS Java lösungsspezifische Übergangsempfehlungen gibt, dokumentiert in den jeweiligen SAP-Hinweisen. Das gilt auch für die Adobe Document Services und PI/PO. Prüfen Sie dort, welche Nachfolger vorgesehen sind und ob sie zu Ihrem Betriebsmodell passen, etwa wenn Sie Integrationen nicht in die Cloud verlagern wollen.
Welche Risiken hat der Weiterbetrieb von Java nach 2030?
Wer AS Java nach 2030 weiterbetreibt, trägt das Sicherheitsrisiko weitgehend selbst. Ohne umfassenden Java-Support kann SAP bei neu entdeckten Schwachstellen im Java-Stack keine verlässliche Abhilfe mehr zusagen. Portale, über die Lieferanten oder Kunden aus dem Internet zugreifen, werden damit zum offenen Risiko für das gesamte Unternehmen.
Hinzu kommt der Betrieb. Wechsel von Betriebssystem oder Hardware setzen kompatible Java-Versionen voraus. Fällt die Unterstützung für eine Plattform weg, lässt sich die Anwendung im Zweifel nicht mehr umziehen. Auch interne Revision und externe Prüfer fragen bei Komponenten ohne Wartung gezielt nach.
SAP NetWeaver Java Ablösung: Wie gehen Sie bei Eigenentwicklungen vor?
Eigene Java-Anwendungen lösen Sie in fünf Schritten ab, vom Inventarisieren bis zum Parallelbetrieb. Der aufwendigste Schritt ist selten der Neubau. Zeit kostet es, die Logik zu verstehen, die über Jahre in Masken und Hintergrundprozessen gewachsen und oft kaum dokumentiert ist. Planen Sie dafür Gespräche mit den Fachbereichen ein.
- Inventarisieren: Welche Java-Anwendungen laufen, wer nutzt sie, wie oft?
- Aussortieren: Was nicht mehr genutzt wird, wird abgeschaltet statt migriert.
- Zuordnen: SAP-Produkte nach Hinweis 3464370, Eigenentwicklungen auf eine eigene Plattform.
- Neu aufbauen: Oberflächen und Prozesslogik als Web- und Mobile-Apps, angebunden an das ERP.
- Parallel betreiben: Die neue App testen, solange die alte noch läuft, dann umschalten.
Ein typischer Fall aus der Instandhaltung: Techniker melden Störungen über eine Web-Dynpro-Java-Maske im Portal. Neu aufgebaut wird sie als Web- und Mobile-App, die dieselben Daten in ECC schreibt und später in S/4HANA. Für die Techniker ändert sich die Oberfläche einmal und nicht bei jedem weiteren Systemwechsel. Dasselbe Vorgehen gilt für ABAP-Eigenentwicklungen, siehe SAP Eigenentwicklungen entkoppeln.
Warum Java-Nachfolger neben das ERP gehören
Unsere These: Wer eine Java-Anwendung jetzt direkt im ERP neu baut, baut sie oft zweimal. Beim Umstieg von ECC auf S/4HANA steht dieselbe Anwendung erneut zur Prüfung an. Läuft sie dagegen neben dem ERP und greift über Standardschnittstellen zu, übersteht sie den Wechsel mit einer angepassten Schnittstelle.
Die technische Ablösung ist dabei nur die halbe Aufgabe. Genauso wichtig ist, wo die Nachfolger danach laufen: mit Rollen, Monitoring, Audit Trail und klarer Verantwortlichkeit im Betrieb. Eine neu gebaute App ohne Betriebsmodell ist die nächste Altlast. Nach welchen Kriterien Sie die Plattform dafür wählen, beschreibt SAP Clean Core ohne BTP.
Das gilt besonders für Anwendungen mit Nutzern außerhalb des Unternehmens. Ein Lieferantenportal, das heute auf dem Enterprise Portal läuft, sollte nicht vom Releasezyklus des ERP abhängen. Lieferanten erwarten eine stabile Oberfläche, egal welches System dahinter läuft.
Planen Sie dabei Anmeldung und Berechtigungen mit. Viele Portale bündeln heute den Single Sign-on für Mitarbeiter. Fällt das Portal weg, braucht der Nachfolger ein eigenes Rollenkonzept und eine Anbindung an den bestehenden Identity Provider. Wer das erst kurz vor dem Go-live klärt, verliert Wochen.
Ihr nächster Schritt
Starten Sie mit einer Java-Inventur, bevor Sie über Nachfolger entscheiden. Erfassen Sie jede Komponente auf AS Java, gleichen Sie sie mit SAP-Hinweis 3464370 ab und sortieren Sie Eigenentwicklungen nach Nutzung. So wissen Sie, was SAP abdeckt, was Sie selbst umziehen müssen und wo Kapazität bis 2030 nötig ist.
Für eigene Portal-Oberflächen, Web-Dynpro-Java-Anwendungen und Self-Services bietet Simplifier einen Weg neben dem ERP. Sie werden als Web- und Mobile-Apps mit Rollenkonzept und Audit Trail neu aufgebaut und greifen über Standardschnittstellen auf SAP zu, heute auf ECC, später auf S/4HANA. Betrieben werden sie mit Rollen, Freigaben, Audit Trail und Monitoring, also kontrolliert statt als Einzelanwendung.
Für die Analyse der bestehenden Anwendungen setzt Simplifier Miri ein, eine KI-Migrations-Agentin. Sie arbeitet auch mit Screenshots und Beschreibungen, wenn Quellcode und Dokumentation schwer zugänglich sind, und erstellt daraus einen priorisierten Migrationsplan.
Migrations-Checkliste herunterladen
Erfahren Sie in dieser Checkliste, wie der Simplifier Migrations-Agent Ihre bestehenden Anwendungen nicht nur analysiert, sondern direkt in lauffähige Apps überführt.
FAQ
Nein, SAP plant keinen Folgerelease für NetWeaver AS Java 7.5 – ab 2031 läuft es nur noch in der kundenspezifischen Wartung, ohne umfassenden Java-Support.
Technisch ja, AS Java lässt sich auch nach 2030 weiterbetreiben, allerdings nur ohne umfassenden SAP-Support – SAP selbst bezeichnet die kundenspezifische Wartung für betroffene Systeme nicht als nachhaltiges Betriebsmodell.
Ja, SAP PI/PO ist auch ohne ECC betroffen, da beide auf NetWeaver AS Java 7.5 laufen und die Einschränkung unabhängig davon gilt, ob noch SAP Business Suite 7 im Einsatz ist.
Nein, die beschriebene Support-Einschränkung für NetWeaver AS Java 7.5 betrifft nur den Java-Stack – für ABAP-Systeme auf einer Drittdatenbank gelten eigene Einschränkungen, die der Hub-Artikel beschreibt.
