JBoss-Migration wenn das Team bereits am Limit ist

Das eigentliche Problem ist nicht die Technik

JBoss EAP 7 läuft seit Juni 2025 im Extended Life Cycle Support, das EOL-Datum Oktober 2027 ist bekannt, die Risiken sind dokumentiert. Und trotzdem liegt die Migration bei vielen Unternehmen auf der Backlog-Liste - nicht weil niemand den Handlungsbedarf erkennt, sondern weil niemand die Kapazität hat, ihn anzugehen.

Das ist das eigentliche Problem. Technische Schulden entstehen selten aus Unwissen. Sie entstehen aus dem strukturellen Konflikt zwischen dringendem Tagesgeschäft und wichtigen, aber nicht akut brennenden Projekten.

Laut einer IDG-Befragung aus 2024 nennen 71 Prozent der IT-Leiter in regulierten Branchen “fehlende interne Kapazität” als primären Hinderungsgrund für Middleware-Migrationen, die seit mehr als zwei Jahren bekannt und geplant sind. Nur 12 Prozent sagen, das technische Risiko sei der Hauptgrund für die Verzögerung.

Die Migration steht an. Das Team ist ausgelastet. Was jetzt?

Was Tagesgeschäft und Audits tatsächlich schlucken

Um zu verstehen, warum Migrationen ins Stocken geraten, muss man nachvollziehen, was die vorhandene Kapazität tatsächlich absorbiert.

In regulierten Umgebungen sieht ein typisches Betriebsjahr so aus: Zwei bis drei externe Audits (ISO 27001, KRITIS-Nachweis, BSI-Prüfung, je nach Branche), dazu interne Revisionen und regulatorische Meldepflichten. Jeder Audit bindet nicht nur eine Person - er erzeugt Koordinationsaufwand quer durch Engineering, Security, Compliance und Management.

Parallel dazu: Tagesgeschäft bedeutet Incident-Handling, Patch-Management für andere Systeme, Deployment-Requests, Security-Incidents, Lieferantenanfragen. In Umgebungen mit 50 bis 200 Servern und mehreren Applikationsteams ist das ein Vollzeitprogramm.

Das Resultat: Migrationsprojekte starten oft gut, verlieren dann Momentum, wenn ein Audit naht, und werden mehrfach verschoben. Nicht weil das Unternehmen die Migration nicht will - sondern weil jede Verschiebung kurzfristig die vernünftige Entscheidung ist.

Was eine Verzögerung konkret kostet

Verschiebungen fühlen sich neutral an, solange nichts passiert. Tatsächlich entstehen direkte und indirekte Kosten.

Direkte Kosten:

Extended Life Cycle Support bei Red Hat kostet typischerweise das 1,5- bis 2-fache des normalen Abonnements. Wer zwei Jahre im ELS bleibt, zahlt für einen Service, der deutlich weniger liefert als Vollsupport.
CVEs, die nicht automatisch gepatcht werden, erfordern internen Assessment-Aufwand. Pro nicht-gepatchter wichtiger CVE entsteht regelmäßig vier bis acht Stunden qualifizierter Analysework - nicht Einmalaufwand, sondern laufend bei jeder neuen Meldung.

Indirekte Kosten:

Audit-Findings zu Lifecycle-Status und Patch-Compliance erzwingen Remediationsfristen. Das zwingt kurzfristig Kapazität in ein Projekt, das mit mehr Vorlaufzeit planbar gewesen wäre.
Je später die Migration startet, desto weniger Puffer gibt es für Tests, Rollbacks und unerwartete Abhängigkeiten. Der Zeitdruck selbst wird zum Qualitätsrisiko.
Entwickler, die weiter gegen EAP-7-APIs entwickeln, häufen technische Schulden an, die bei der späteren Migration zusätzlichen Aufwand erzeugen.

Was passiert, wenn das Risiko der Nicht-Migration unterschätzt wird, beschreibt der Artikel JBoss EAP 7: Warum “Es läuft ja noch” ein Risiko ist.

Wie eine realistische Migrationsplanung bei Kapazitätsengpass aussieht

Die klassische Antwort auf “wir haben keine Kapazität” ist: “Dann macht einen Business Case.” Das ist richtig, hilft aber nicht im Tagesgeschäft. Was hilft, ist eine Planung, die die Kapazitätssituation als Constraint behandelt, nicht als Problem, das sich von selbst löst.

Schritt 1: Inventory und Priorisierung

Nicht alle JBoss-EAP-7-Instanzen sind gleich kritisch. Eine schnelle Inventarisierung - welche Instanzen laufen in Produktion, welche haben externe Schnittstellen, welche verarbeiten regulierte Daten - erzeugt eine Priorisierungsmatrix. Migration ist kein Alles-oder-Nichts-Projekt.

Schritt 2: Abhängigkeiten kartieren, bevor die Uhr tickt

Der häufigste Grund, warum Migrationen länger dauern als geplant, sind unbekannte Abhängigkeiten: proprietäre JBoss-Subsysteme, Deployment-Deskriptoren im alten Format, Bibliotheken, die javax.* voraussetzen, interne Toolchains, die gegen EAP-7-APIs entwickelt wurden.

Diese Analyse kostet Zeit - aber sie kostet deutlich weniger Zeit, wenn sie systematisch und ohne Zeitdruck durchgeführt wird. Wer wartet, bis der Druck durch ein Audit-Finding oder ein Security-Incident entsteht, führt diese Analyse unter den schlechtesten Bedingungen durch.

Schritt 3: Kapazität als First-Class-Constraint behandeln

Eine realistische Migrationsplanung fragt nicht “wie lange brauchen wir theoretisch”, sondern “wie viel Kapazität können wir pro Sprint tatsächlich für Migration reservieren”. Bei Teams, die 70 bis 80 Prozent ihrer Zeit im Betrieb verbringen, sind das vielleicht 15 bis 20 Prozent - das bedeutet, eine Migration, die bei Vollzeitverfügbarkeit drei Monate dauern würde, dauert in der Realität 12 bis 15 Monate.

Wer diese Kalkulation offen macht, kann realistische Meilensteine setzen und gegenüber Management und Auditoren eine vertretbare Position vertreten.

Die drei häufigsten Planungsfehler

Fehler 1: Migration als Projekt ohne Ressourcenreservierung

Viele Organisationen beschließen, JBoss EAP 7 zu migrieren - ohne dedizierte Kapazität zu reservieren. Das Projekt läuft dann in der Restzeit, die nach Tagesgeschäft übrig bleibt. Das ist strukturell zum Scheitern verurteilt.

Fehler 2: Unterschätzung der Jakarta-EE-10-Migration

EAP 8 basiert auf Jakarta EE 10. Das bedeutet, dass alle Applikationen, die javax.* importieren, angepasst werden müssen - das sind alle Jakarta-EE-Applikationen, die vor der Namespace-Migration entwickelt wurden. Wer das als “kleinen Refactor” plant, erlebt Überraschungen in der Testphase.

Fehler 3: Staging und Rollback nicht mitplanen

Eine produktive Middleware-Migration ohne Staging-Phase und definierten Rollback-Plan ist ein Risiko, das regulierte Umgebungen nicht eingehen sollten. Das klingt selbstverständlich - aber unter Zeitdruck werden Staging-Phasen verkürzt oder übersprungen.

Die konkreten Migrationspfade von EAP 7 - zu EAP 8, zu Containerisierung oder zu alternativen Stacks - sind im Artikel Die drei Ausstiegswege aus JBoss EAP 7 beschrieben.

Wann externe Kapazität sinnvoll ist

Die Frage, ob man eine Middleware-Migration vollständig intern stemmt oder externe Unterstützung einbindet, ist keine Prinzipienfrage. Sie ist eine Kapazitätsfrage.

Externe Unterstützung lohnt sich typischerweise, wenn:

Interne Teams nicht über EAP-8- oder Jakarta-EE-10-Erfahrung verfügen
Der Zeitplan durch das October-2027-EOL definiert wird und keine Verlängerung möglich ist
Audit-Findings bereits existieren, die kurze Remediationsfristen setzen
Die Organisation mehrere Dutzend EAP-Instanzen betreibt und intern nicht skalieren kann

Der kritische Punkt dabei: Externe Unterstützung ist kein Ersatz für interne Ownership. Wer eine Migration delegiert, ohne intern Wissen aufzubauen, verschiebt das Kapazitätsproblem in den Post-Migrations-Betrieb.

Wie das in der Praxis strukturiert werden kann, beschreibt die SPAS Overview von Lennlay - Lennlay unterstützt JBoss-EAP-7-Migrationen in regulierten Umgebungen mit dem Fokus auf auditierbare, automatisierte Plattformen. Mehr zum Thema Auditierbarkeit im Kontext des gesamten Plattform-Betriebs: Warum auditierbare IT-Plattformen in regulierten Umgebungen wichtig sind.

Wann spätestens gehandelt werden muss

Der Countdown ist konkret: Oktober 2027. Eine Enterprise-Middleware-Migration braucht erfahrungsgemäß 12 bis 18 Monate Vorlauf, wenn Dependency-Mapping, Test-Phasen und Staging eingerechnet werden. Das ergibt einen Planungsstart spätestens Anfang bis Mitte 2026 - um noch komfortablen Puffer zu haben.

Wer jetzt plant, hat das Fenster. Wer bis Ende 2026 wartet, muss unter Zeitdruck migrieren. Wer bis 2027 wartet, riskiert, ohne Support ins EOL zu laufen - bei gleichzeitig laufendem Betrieb und ohne Fallback.

Den konkreten Zeitplan mit allen relevanten Phasendaten beschreibt der Artikel JBoss EAP 7: Countdown bis Oktober 2027.

FAQ

Wie viel Kapazität braucht eine JBoss-EAP-7-zu-EAP-8-Migration realistisch?

Das hängt stark von der Anzahl der Instanzen und dem Applikations-Portfolio ab. Als grobe Orientierung: eine einzelne Applikation mit bekannten Dependencies und verfügbarem Staging dauert typischerweise vier bis acht Wochen bei einem dedizierten Entwickler. Bei mehreren Applikationen und Legacy-Konfigurationen multipliziert sich das.

Kann man eine Migration in Teilschritten durchführen?

Ja - und das ist bei Kapazitätsengpässen oft der einzige realistische Weg. Sinnvolle Teilschritte sind: Inventory und Risikoklassifizierung, Dependency-Mapping, Migration unkritischer Instanzen als Piloten, dann schrittweise kritische Systeme.

Was ist, wenn Oktober 2027 kommt und die Migration noch nicht fertig ist?

Das System läuft weiterhin - aber ohne jegliche Patch-Versorgung und ohne Red-Hat-Support. Neue CVEs werden nicht mehr gefixt. Das ist für regulierte Umgebungen keine akzeptable Betriebssituation und wird in jedem Folgeaudit als kritisches Finding dokumentiert.

Lohnt sich die Härtung von EAP 7 als Zwischenlösung?

Als temporäre Maßnahme ja: Attack-Surface reduzieren, nicht benötigte Subsysteme deaktivieren, Network-Segmentierung verschärfen, CVE-Monitoring einrichten. Das ersetzt die Migration nicht, verbessert aber die Sicherheitsposition und gibt Auditoren mehr zu zeigen als “es läuft ja noch.”

Wie rechtfertige ich Migrationsbudget gegenüber dem Management?

Der stärkste Hebel ist die Kombination aus konkreten Kosten (ELS-Aufpreis, Assessment-Aufwand pro CVE, potenzielle Audit-Remediationsfristen) und dem Oktober-2027-EOL-Datum als harten Endpunkt. Ein schriftlicher Plan mit Ressourcenschätzung ist stärker als ein abstrakter Risikohinweis.

Wenn Sie die Migration strukturiert angehen wollen, ohne interne Teams zu überlasten: SPAS Overview von Lennlay zeigt, wie das in der Praxis aussieht.