JBoss EAP 7 Migration: Kapazitätslücken realistisch einschätzen

Eine JBoss-EAP-7-Migration scheitert selten an der Technologie. Sie scheitert an Kapazität. Wer die nötigen Skills intern nicht vollständig abdeckt - JBoss-Internals, Automatisierung, Security-Hardening, Regressionstests - wird entweder zu langsam, zu teuer oder beides.

Dieser Artikel quantifiziert den Ressourcenbedarf konkret: welche Skills in welchem Umfang gebraucht werden, wie viele Personenmonate realistisch anfallen und welche Beschaffungsoptionen für welche Organisationstypen taugen.

Welche Skills eine JBoss-Migration tatsächlich braucht

Eine vollständige JBoss-EAP-7-Migration umfasst mindestens fünf Skill-Cluster, die selten vollständig in einem Team vereint sind.

1. JBoss/WildFly-Internals: Jemand muss die Subsystem-Architektur verstehen - wie das Service-Activation-Framework (SAF) funktioniert, wie JBoss-Module geladen werden, welche Abhängigkeiten im module.xml relevant sind. Ohne dieses Wissen sind Deployment-Fehler nach der Migration kaum diagnostizierbar.

2. Jakarta EE / Java EE Migration: Der Namespace-Wechsel von javax.* auf jakarta.* klingt mechanisch, hat aber subtile Fallstricke in CDI-Scoping, in serialisierten Objekten über Service-Grenzen hinweg und in annotierten Deployment-Descriptoren. Wer Jakarta EE 10 nicht kennt, unterbewertet diese Arbeit systematisch.

3. Automatisierung und IaC: Eine manuelle Migration ist keine Migration - sie ist eine einmalige Handarbeit ohne Reproduzierbarkeit. JBoss-Konfiguration muss in Ansible, Terraform oder ähnlichen Werkzeugen verwaltet werden, damit neue Instanzen konsistent, auditierbar und ohne manuellen Eingriff bereitgestellt werden können. Dieser Skill fehlt in vielen klassischen Operations-Teams.

4. Security-Hardening: JBoss EAP 8 hat eine andere Default-Security-Konfiguration als EAP 7. TLS-Konfiguration, Security-Realms, RBAC-Modell im undertow-Subsystem - all das muss für regulierte Umgebungen explizit konfiguriert sein. Ein Security-Ingenieur, der weiß, wie man JBoss-Deployments gegen CIS Benchmark Level 2 für JBoss absichert, ist kein Standardprofil.

5. Testautomatisierung: Ohne belastbare Regressionstests ist jede Migration ein Glücksspiel. Das bedeutet: API-Tests, Last-Tests für kritische Pfade, Integrationstests gegen downstream-Services. Dieser Aufwand wird in Migrationsplanungen konsistent unterschätzt.

Laut einer 2024 durchgeführten Umfrage von IDC unter 400 europäischen IT-Entscheidungsträgern gaben 67 Prozent an, dass fehlende interne Expertise der häufigste Grund für verzögerte Plattform-Migrationen sei.

Personenmonats-Schätzungen nach Deploymentgröße

Die folgenden Schätzungen gelten für eine Migration auf JBoss EAP 8. Für Wege zu Quarkus oder Spring Boot sind die Werte um 50 bis 100 Prozent höher anzusetzen (Details im Artikel Die drei Ausstiegswege aus JBoss EAP 7).

Kleine Umgebung: 1-5 Applikationen, je unter 100.000 Codezeilen, bis zu fünf JBoss-Instanzen.

Aufgabe	Aufwand
Assessment und Analyse	0,5-1 PM
Namespace-Migration und Code-Fixes	1-3 PM
Konfigurationsautomatisierung (Ansible)	1-2 PM
Security-Hardening	0,5-1 PM
Test und Abnahme	1-2 PM
Gesamt	4-9 PM

Mittlere Umgebung: 5-15 Applikationen, je 100.000-500.000 Codezeilen, fünf bis zwanzig JBoss-Instanzen.

Aufgabe	Aufwand
Assessment und Analyse	1-2 PM
Namespace-Migration und Code-Fixes	4-8 PM
Konfigurationsautomatisierung (Ansible)	2-4 PM
Security-Hardening	1-2 PM
Test und Abnahme	3-5 PM
Koordination / Projektmanagement	1-2 PM
Gesamt	12-23 PM

Große Umgebung: 15+ Applikationen oder Legacy-Monolithen über 500.000 Codezeilen, über zwanzig JBoss-Instanzen.

Aufgabe	Aufwand
Assessment und Analyse	2-4 PM
Namespace-Migration und Code-Fixes	10-20 PM
Konfigurationsautomatisierung	4-8 PM
Security-Hardening	2-4 PM
Test und Abnahme	5-10 PM
Koordination / Projektmanagement	3-5 PM
Gesamt	26-51 PM

Ein Personenmonat entspricht bei einem Tagessatz von 900 bis 1.400 Euro für Junior-bis-Senior-Profilen etwa 19.000 bis 30.000 Euro. Eine mittlere Migration kostet damit intern oder extern zwischen 230.000 und 690.000 Euro an reinen Arbeitskosten - noch ohne Tool-Lizenzen, Red Hat-Subscription und Testinfrastruktur.

Die vier Beschaffungsoptionen im Vergleich

Option 1 - Intern aufstocken (Neueinstellungen):

Für eine mittlere Migration bräuchte man mindestens zwei bis drei spezialisierte Personen für sechs bis neun Monate. Der Markt für Java-EE/Jakarta-EE-Spezialisten mit JBoss-Kenntnissen ist eng. Laut BITKOM-Stellenmarktreport 2025 dauert die Besetzung einer Senior-Java-Position in Deutschland im Schnitt 4,3 Monate. Bis neue Mitarbeiter produktiv sind, vergehen weitere zwei bis drei Monate. Für ein Projekt mit Deadline Oktober 2027 ist das ein enger Zeitplan.

Option 2 - Intern schulen:

JBoss-zu-EAP-8-Schulungen von Red Hat (JB248, JB327) kosten zwischen 2.500 und 4.000 Euro pro Person. Realistisch vermitteln sie Grundlagen, aber keine Migrationsexpertise für komplexe Deployments. Schulung ist sinnvoll als Ergänzung, aber kein Ersatz für Erfahrung.

Option 3 - Outsourcing an Systemintegratoren:

Klassisches Outsourcing an Red Hat-Partner oder Systemintegratoren ist möglich, aber der Markt ist aktuell stark ausgelastet. Viele Dienstleister haben Wartelisten. Tagesätze liegen 2026 zwischen 1.100 und 1.800 Euro für erfahrene JBoss-Spezialisten.

Option 4 - Automatisierung mit externer Expertise kombinieren:

Das ist der Weg, den die meisten Organisationen in der Praxis gehen - und der realistisch die beste Kosten-Qualitäts-Relation hat. Automatisierungs-Werkzeuge übernehmen den mechanischen Teil (Namespace-Fixes, Konfigurationsgenerierung, Drift-Erkennung), externe Spezialisten bringen Migrations-Know-how für die komplexen Teile, das interne Team bleibt in der Verantwortung.

Das reduziert den externen PM-Aufwand um typischerweise 30 bis 50 Prozent und stellt sicher, dass das interne Team am Ende die migrierte Plattform eigenständig betreiben kann.

Warum Automatisierung der Kapazitätsmultiplikator ist

Ohne Automatisierung ist eine JBoss-Migration linear skalierend: jede weitere Instanz, jede weitere Applikation addiert Aufwand. Mit Automatisierung wird ein erheblicher Teil der Arbeit einmalig geleistet und dann repliziert.

Konkrete Beispiele:

Ein Ansible-Playbook für JBoss-EAP-8-Deployment wird einmal entwickelt und dann für alle Instanzen ausgeführt. Der Delta-Aufwand für Instanz Nummer zwölf ist ein Zehntel des Aufwands für Instanz Nummer eins.
Ein Migration-Toolkit-Scan (Red Hat MTA) analysiert alle Applikationen gleichzeitig und gibt einen konsolidierten Bericht. Manuelle Analyse würde linear mit der Anzahl der Applikationen skalieren.
Automatisierte Regressionstests laufen nach jeder Änderung. Manuelle Tests würden bei jeder Änderung wiederholt werden müssen.

Automatisierung ist auch für die Compliance-Anforderungen unter NIS2 und BSI-Grundschutz relevant. Wer Konfigurationsänderungen manuell durchführt, hat per Definition keinen dokumentierten, reproduzierbaren Prozess. Mehr dazu in JBoss EAP 7 Configuration Drift als Compliance-Risiko.

Was interne Teams realistisch leisten können

Ein internes Team kann die Migration steuern, testen und abnehmen - das ist auch die richtige Aufteilung. Es sollte nicht versuchen, Expertenwissen unter Zeitdruck intern aufzubauen, das am externen Markt verfügbar ist.

Konkret: Interne Teams sollten das Assessment führen (sie kennen ihre Applikationen besser als jeder externe Dienstleister), die Testabnahme verantworten (sie kennen die fachlichen Erwartungen), die Automatisierungsartefakte reviewen und übernehmen sowie den Betrieb nach der Migration eigenständig führen.

Externe Spezialisten sollten die technische Migrationsarchitektur liefern, JBoss-spezifische Probleme lösen und die Automatisierungs-Toolchain aufbauen.

Wie Lennlay SPAS diese Kombination unterstützt - mit vorgefertigten Ansible-Rollen für JBoss EAP, automatisierter Drift-Erkennung und Assessment-Workflows - ist auf der Plattformseite beschrieben. Ein kostenloser Plattform-Check dauert 15 bis 30 Minuten und gibt eine realistische Einschätzung der Kapazitätslücken für Ihre spezifische Umgebung.

Häufige Planungsfehler und ihre Konsequenzen

Drei Fehler, die in JBoss-Migrationsprojekten konsistent auftreten:

Fehler 1 - Testaufwand unterschätzen: Teams planen ausreichend Zeit für die Migration, aber nicht für das Testing. Tests finden dann unter Zeitdruck statt und decken kritische Regressionsfehler nicht ab. Faustregel: Testaufwand sollte mindestens 30 Prozent des Migrationsaufwands betragen.

Fehler 2 - Parallelkonfiguration unterschätzen: JBoss EAP 7 und EAP 8 müssen für eine Zeit parallel betrieben werden. Das verdoppelt kurzzeitig den Infrastrukturaufwand und erfordert Datenbankkompatibilität zwischen beiden Versionen.

Fehler 3 - Configuration Drift nicht bereinigen: Wer mit nicht bereinigten Drift-Zuständen migriert, überführt undokumentierte Konfigurationen in die neue Umgebung. Das ist nicht nur ein Qualitätsproblem - in regulierten Umgebungen ist es ein Compliance-Problem.

FAQ

Wie viele Personenmonate braucht eine JBoss-EAP-7-Migration?

Klein (1-5 Apps): 4-9 PM. Mittel (5-15 Apps): 12-23 PM. Groß (15+ Apps/Monolithen): 26-51 PM. Alle Angaben für EAP-8-Upgrade; Cloud-native-Migration kostet 50-100 Prozent mehr.

Welche Skills sind am schwierigsten intern zu finden?

JBoss-Internals-Expertise und Security-Hardening für Jakarta EE sind die engsten Profile am Markt. Automatisierungskenntnisse (Ansible/Terraform) sind breiter verfügbar, aber selten mit JBoss-Spezialisierung kombiniert.

Lohnt sich interne Schulung für die Migration?

Als Ergänzung ja, als Hauptstrategie nein. Red Hat-Schulungen vermitteln Grundlagen in wenigen Tagen, aber Migrationsexpertise für komplexe Enterprise-Deployments entsteht erst durch Projekterfahrung.

Was kostet ein externer JBoss-Migrationsspezialist?

2026 liegen Tagessätze für erfahrene JBoss-/Jakarta-EE-Spezialisten zwischen 1.100 und 1.800 Euro in Deutschland. Systemintegratoren haben Wartelisten - frühzeitige Beauftragung ist empfehlenswert.

Kann man die Migration auf mehrere Jahre strecken?

Technisch ja - aber Extended Support endet Oktober 2027. Danach gibt es keine Sicherheits-Patches mehr. Für NIS2-pflichtige Organisationen ist Betrieb auf nicht gepatchter Software eine klare Pflichtverletzung.

Verwandte Artikel: