JBoss EAP 7: Drei realistische Ausstiegswege im Vergleich

Mit dem Ende des Extended Support für JBoss EAP 7 im Oktober 2027 gibt es drei realistische Wege nach vorn: Upgrade auf JBoss EAP 8, Wechsel zu WildFly oder Migration auf eine alternative Plattform wie Quarkus oder Spring Boot. Keiner dieser Wege ist trivial. Keiner ist für jede Organisation der richtige.

Dieser Artikel vergleicht alle drei Optionen mit konkreten Aufwandsschätzungen, Risikoprofilen und Teamanforderungen - ohne Vendorbindung.

Weg 1: Upgrade auf JBoss EAP 8

JBoss EAP 8 ist der direkte Nachfolger und basiert auf Jakarta EE 10 mit WildFly 29 als Upstream. Für Organisationen, die bereits einen Red Hat-Supportvertrag haben, ist das der naheliegendste Pfad.

Was sich technisch ändert:

Der größte Bruch liegt im Namespace. Jakarta EE 10 hat den javax.*-Namespace vollständig auf jakarta.* umgestellt. Das betrifft alle Import-Statements, alle Deployment-Descriptoren und alle Konfigurationsdateien, die javax-Klassen referenzieren. Tools wie das Red Hat Migration Toolkit for Applications (MTA) erkennen betroffene Stellen automatisch, aber das Fix-Volumen ist direkt proportional zur Codebasis-Größe.

Weitere Änderungen: CDI 4.0 hat Breaking Changes in der Bean-Discovery und im Programmatic Lookup. EJB Remoting nutzt in EAP 8 standardmäßig EJB-over-HTTP statt dem alten JBoss-Remoting-Protokoll. Deployment-Descriptoren wie jboss-web.xml und jboss-ejb3.xml bleiben kompatibel, aber jboss-deployment-structure.xml hat neue Modulbeziehungsregeln.

Aufwandsschätzung:

Umgebungsgröße	Anzahl Applikationen	Geschätzter Aufwand
Klein	1-5 Apps, je unter 100 KLOC	3-6 Personenmonate
Mittel	5-15 Apps, je 100-500 KLOC	8-18 Personenmonate
Groß	15+ Apps oder Legacy-Monolithen	20-40+ Personenmonate

Risikoprofil: Mittel. Die Migration ist gut dokumentiert, toolgestützt und hat eine klare Ziellinie. Das Hauptrisiko liegt in undokumentierten Abhängigkeiten auf JBoss-proprietäre APIs und im Namespace-Fix-Aufwand bei Legacy-Code.

Teamanforderungen: JBoss-/WildFly-Kenntnisse, Java EE / Jakarta EE Erfahrung, Testkapazität für Regressionstests. Red Hat bietet Migrations-Support im Rahmen von Enterprise-Subscriptions.

Kosten: Red Hat EAP 8 Subscription liegt aktuell zwischen 12.000 und 25.000 Euro pro Jahr für typische Deployments. Dazu kommen Migrationsaufwände intern oder extern.

Weg 2: Migration zu WildFly

WildFly ist der Community-Upstream von JBoss EAP, kostenlos, ohne Supportvertrag. Technisch ist WildFly 34 (Stand Mai 2026) leistungsfähig und aktuell - WildFly Glow ermöglicht Layer-basierte Deployments, WildFly Preview unterstützt MicroProfile 7.

Was das bedeutet:

WildFly und JBoss EAP 8 teilen denselben Kern. Wer auf EAP 8 upgraden kann, kann technisch auch auf WildFly upgraden - der Namespace-Bruch ist identisch. Der Unterschied liegt im Support-Modell.

Bei WildFly gibt es keinen kommerziellen Support, keine SLAs, keine CVE-Patches mit definierten Reaktionszeiten. Community-Releases erscheinen schnell - oft alle vier bis sechs Wochen - was für regulierte Umgebungen intern getestete Updates erfordert.

Was das in regulierten Umgebungen bedeutet:

Für KRITIS-Betreiber, Finanzinstitute unter BAFIN-Aufsicht oder Gesundheitseinrichtungen unter DSGVO/KHZG ist WildFly problematisch. NIS2 Artikel 21 verlangt Maßnahmen zur Sicherstellung der Lieferkettensicherheit - inklusive der eingesetzten Software. Ein Community-Produkt ohne kommerziellen Support und ohne definierte Patch-SLA lässt sich in einem Audit schwer begründen.

Aufwandsschätzung: Identisch zu EAP 8-Upgrade (Tabelle oben), da der technische Kern gleich ist. Zusätzlich: interner Aufwand für Community-Release-Bewertung und Patch-Testing.

Risikoprofil: Hoch für regulierte Umgebungen. Mittel für interne Tools oder unkritische Services.

Teamanforderungen: Wie EAP 8, plus operative Kapazität für eigenständiges Patch-Management ohne Vendor-Support.

Kosten: Keine Lizenzkosten. Aber der interne Betriebsaufwand kompensiert die Einsparungen oft vollständig.

Weg 3: Migration auf alternative Plattformen

Quarkus, Spring Boot oder containerisierte Cloud-native Stacks sind der fundamentalste Wechsel - und der mit dem höchsten Potenzial, aber auch dem höchsten kurzfristigen Aufwand.

Quarkus:

Quarkus, ebenfalls von Red Hat, ist auf Kubernetes, Container und niedrige Startzeiten ausgelegt. Es implementiert MicroProfile und Jakarta EE teilweise, aber nicht vollständig. Eine Migration von JBoss EAP 7 zu Quarkus ist keine Plattform-Migration - es ist eine Applikations-Neuentwicklung in Teilen.

CDI, JAX-RS und JPA funktionieren mit Quarkus, aber EJBs sind nicht nativ unterstützt. JBoss-Messaging-Integrationen, Remoting-Protokolle und proprietäre JBoss-APIs brauchen Ersatz. Für Monolithen mit starker EJB-Nutzung ist Quarkus nur sinnvoll, wenn gleichzeitig eine Modularisierung geplant ist.

Spring Boot:

Spring Boot ist die breitest genutzte Java-Plattform außerhalb von Enterprise-Java-Traditionsumgebungen. Die Migration von Jakarta-EE-Code zu Spring erfordert substantielle Umbauarbeit: Dependency Injection wird ersetzt, JPA bleibt, aber das Transaktionsmodell ändert sich, EJBs werden durch Spring-Services ersetzt.

Vorteil: Das Ökosystem ist groß, die Community aktiv, kommerzieller Support über VMware Tanzu verfügbar. Nachteil: Der Migrationsaufwand ist signifikant höher als bei Weg 1 oder 2.

Aufwandsschätzung (Quarkus/Spring Boot):

Umgebungsgröße	Geschätzter Aufwand
Klein	6-12 Personenmonate
Mittel	18-36 Personenmonate
Groß	36-80+ Personenmonate

Risikoprofil: Hoch kurzfristig, niedrig langfristig. Cloud-native Architekturen haben bessere Skalierbarkeit, besseres Container-Support und aktive Entwicklungs-Ökosysteme. Aber die Migrations-Komplexität ist erheblich.

Teamanforderungen: Zusätzlich zu JBoss-Kenntnissen: Zieltechnologie-Expertise (Quarkus oder Spring), Containerisierung (Kubernetes, Helm), CI/CD-Modernisierung.

Vergleichstabelle

Kriterium	EAP 8-Upgrade	WildFly	Cloud-native
Aufwand (mittel)	8-18 PM	8-18 PM	18-36 PM
Namespace-Migration	Pflicht	Pflicht	Pflicht + Refactoring
Kommerzieller Support	Ja (Red Hat)	Nein	Ja (Tanzu/andere)
NIS2-Compliance	Gut begründbar	Schwer begründbar	Gut begründbar
Kurzfristiges Risiko	Mittel	Mittel-Hoch	Hoch
Langfristige Plattform-Fitness	Mittel	Mittel	Hoch
Lizenzkosten	12.000-25.000€/Jahr	0	Variabel

Was Lennlay zu allen drei Wegen sagt

Lennlay hat bewusst kein Interesse daran, einen der drei Wege als einzig richtigen darzustellen. Die SPAS-Plattform unterstützt alle drei Migrationspfade mit automatisierten Assessment-Workflows, Konfigurationsanalyse und Deployment-Automatisierung.

Was bei der Entscheidung tatsächlich ausschlaggebend ist:

Regulatorische Umgebung: Wer unter NIS2, BSI-Grundschutz oder BAFIN steht, braucht kommerziellen Support.
Applikationsarchitektur: Starke EJB-Nutzung macht Cloud-native kurzfristig unrealistisch.
Interne Kapazitäten: Weg 3 erfordert deutlich mehr Expertise. Dazu mehr in JBoss-Migration: Kapazitätslücken realistisch einschätzen.
Zeithorizont: Bis Oktober 2027 bleiben weniger als 18 Monate. Für große Umgebungen ist Weg 3 bis dahin kaum realisierbar.

Eine erste Einschätzung, welcher Weg zu Ihrer spezifischen Situation passt, gibt es im Plattform-Check von Lennlay - kostenlos, 15 bis 30 Minuten.

FAQ

Welcher Weg ist der schnellste?

EAP 8 ist der schnellste Weg für Umgebungen mit bestehenden Red Hat-Verträgen. Die technische Migration ist toolgestützt und gut dokumentiert, der Namespace-Fix lässt sich weitgehend automatisieren.

Kann ich WildFly in einer KRITIS-Umgebung betreiben?

Technisch ja, aber es ist im Audit schwer zu begründen. Ohne kommerziellen Support und definierte Patch-SLAs ist die NIS2-Anforderung an Lieferkettensicherheit nur mit erheblichem internem Aufwand erfüllbar.

Wie viel kostet eine JBoss-EAP-8-Subscription?

Red Hat EAP 8 liegt bei Enterprise-Subscriptions typischerweise zwischen 12.000 und 25.000 Euro pro Jahr, abhängig von Anzahl der Cores und Support-Level.

Ist Quarkus rückwärtskompatibel zu JBoss EAP 7?

Nein. EJBs werden nicht nativ unterstützt, das Programmiermodell ist grundlegend anders. Quarkus ist nur sinnvoll, wenn gleichzeitig eine Applikationsmodernisierung stattfindet.

Wie lange hat man noch Zeit?

Offizielles End of Extended Support für JBoss EAP 7 ist Oktober 2027. Bei mittleren Umgebungen bleibt damit realistisch noch bis Ende 2026 Zeit, um eine Migration zu starten und abzuschließen.

Verwandte Artikel: