JBoss EAP 7 auf EAP 8 migrieren
Was IT-Leiter vor dem Projekt wissen sollten: Namespace-Wechsel, Automatisierung mit Ansible und ein standardisiertes Betriebsmodell das Audits standhält.
Viele Teams stehen vor der Aufgabe, von JBoss EAP 7 auf EAP 8 zu wechseln. Die technische Migration ist machbar. Der echte Unterschied entsteht, wenn man den Betrieb danach sauber und wiederholbar aufstellt. Hier ist, was IT-Leiter vor dem Start wissen sollten.
Der technische Bruch ist real
Der größte Schritt ist der Wechsel von Java EE / Jakarta EE 8 zu Jakarta EE 10. Das bedeutet vor allem: der Namespace-Wechsel von javax zu jakarta. Viele Anwendungen, Bibliotheken und Build-Prozesse sind betroffen.
Dazu kommen Änderungen bei Konfigurationen, Server-Modulen, Security-Einstellungen, Logging, Datasources und Messaging. Nicht jede Anwendung braucht gleich viel Arbeit. Man muss jede prüfen.
Wer nur per Hand migriert, löst das Versionsproblem, aber schafft neue Unterschiede zwischen Dev, Test und Produktion. Genau das macht Audits später schwer.
Die aktuelle Lage — bestätigt durch Red Hat
Seit dem 30. Juni 2025 ist JBoss EAP 7 nicht mehr im regulären Maintenance Support. Es gilt nur noch Extended Life Cycle Support (ELS). ELS-1 läuft bis Oktober 2027, ELS-2 bis Oktober 2030. Danach gibt es fast keine Sicherheitsupdates mehr.
Red Hat selbst empfiehlt in seinen Dokumenten, entweder auf EAP 8 zu migrieren oder ELS nur als echte Brücke zu nutzen. Viele Unternehmen merken jetzt, dass manuelle Betriebsmodelle mit der Zeit teurer und risikoreicher werden. Audits fragen stärker nach Nachweisen. Das Personal, das die alten Systeme wirklich kennt, wird weniger.
Das ist kein theoretisches Problem. Es ist die reale Situation für alle, die noch auf EAP 7 laufen.
Warum Automatisierung hier entscheidend ist
Eine saubere Migration auf EAP 8 sollte nicht nur die Version wechseln. Sie sollte ein standardisiertes Betriebsmodell hinterlassen.
Mit Ansible Collections geht das. Man definiert klare Zielzustände für Installation, Härtung, Konfiguration und Deployment. Die gleichen Playbooks laufen dann in allen Umgebungen.
Das Ergebnis: Dev sieht aus wie Test. Test sieht aus wie Produktion. Änderungen gehen über Code, nicht über manuelle Eingriffe. Das reduziert Fehler und macht Audits einfacher.
Wie SPAS dabei hilft
Genau hier setzt die Secure Platform Automation Suite (SPAS) an. Das Secure JBoss EAP Platform Automation Modul macht die Migration und den danach laufenden Betrieb sicher, standardisiert und auditierbar.
SPAS liefert fertige Bausteine dafür: die lennlay.jboss Collection für Installation, Härtung, Konfiguration und Deployment. Dazu kommen Golden Images über GIaaS als saubere Basis und der Compliance Scanner, der JBoss-Instanzen prüft. Drift-Erkennung zeigt Abweichungen früh.
Man baut nicht alles neu. Man nutzt die vorgegebene Logik und passt sie an die eigene Umgebung an. Das spart Zeit und schafft gleich von Anfang an Nachvollziehbarkeit für Audits. Das Ziel ist nicht nur EAP 8 zum Laufen zu bringen. Es ist eine Plattform, die man danach einfach und sicher betreiben kann.
Was IT-Leiter vor dem Projekt klären sollten
Stellen Sie sich diese Fragen, bevor das Projekt losgeht:
- Welche Anwendungen bleiben noch länger im Einsatz? Nur die lohnen den vollen Aufwand.
- Wie stark ist der Audit-Druck? NIS2, BSI oder interne Regeln verlangen nachvollziehbare Härtung und Dokumentation. EAP 8 allein reicht nicht. Man braucht den passenden Prozess dazu.
- Wer macht die Arbeit? Interne Teams haben meist Tagesgeschäft. Externe Hilfe kann Tempo und Struktur bringen, ohne dass Wissen danach verloren geht.
- Welches Zielbild wollen wir? Bleiben wir bei klassischen Servern oder planen wir später Container? EAP 8 ist ein guter Zwischenschritt, der später den Weg zu OpenShift erleichtert.
Typische Schritte in der Praxis
- Bestand aufnehmen — Welche Versionen, Konfigurationen und Abhängigkeiten gibt es wirklich?
- Anwendungen bewerten — Wo liegt der Aufwand beim Namespace-Wechsel und bei den Konfig-Änderungen?
- Zielplattform definieren — Golden Images oder automatisierte Builds mit klaren Baselines.
- Automatisierung aufbauen — Collections und Playbooks für Installation, Härtung und Deployment.
- Schrittweise ausrollen — Erst Dev, dann Test, dann höhere Stufen. Immer mit Drift-Prüfung.
- Dokumentation und Nachweise sichern — Für Audits und den laufenden Betrieb.
Was aus echten Projekten bleibt
In Migrationen sehen wir immer wieder: Der erste Aufwand für Automatisierung zahlt sich ab der zweiten Umgebung aus. Danach laufen neue Stages reproduzierbar.
Das Team lernt nicht nur die neue Version. Es lernt, wie man Plattformen künftig sauber betreibt. Das reduziert das Risiko bei nächsten Updates oder Audits.
Fazit
Die Migration von JBoss EAP 7 auf 8 ist mehr als ein Versionssprung. Sie ist die Chance, den Betrieb von manuell und gewachsen auf standardisiert und automatisiert zu stellen.
Wer das nur per Hand macht, löst das aktuelle Problem. Wer Automatisierung einbaut, schafft ein Fundament für die nächsten Jahre.
Prüfen Sie Ihren Bestand und entscheiden Sie, wie stark Sie den Betrieb danach verbessern wollen. Das bestimmt, wie viel Nutzen die Migration wirklich bringt.