WebSphere zu JBoss EAP migrieren
IBM hat die Lizenzkosten erhöht. Sie haben auf JBoss EAP gewechselt. Aber die Konfigurationslogik aus WebSphere-Zeiten ist geblieben.
Eine Migration ist ein Einmalprojekt. Die Folgen eines falschen Betriebsmodells laufen zehn Jahre weiter. Wer den Server wechselt, aber das Betriebsmodell beibehält, hat die Migration nur zur Hälfte durchgeführt.
lennlay schliesst die andere Hälfte: reproduzierbare Konfiguration, automatisiertes Deployment, dokumentierte Härtungs-Baseline. Aus einer WebSphere-Ablösung wird eine dauerhaft betreibbare JBoss-EAP-Plattform.
Der Server ist neu. Das Betriebsmodell ist alt.
WebSphere und JBoss EAP sind grundlegend unterschiedliche Plattformen mit unterschiedlichen Betriebsphilosophien. Wer nur den Server tauscht, bringt das falsche Modell mit.
EAR/WAR-Deployment über die Admin Console. Manuell, instanz-spezifisch, nicht reproduzierbar.
JNDI-Datasources über die GUI konfiguriert. Kein Code, keine Versionierung, kein Diff.
Sicherheitsrollen manuell im Admin-Interface gepflegt. Wer was hat, weiss nur derjenige, der es gesetzt hat.
Konfigurationsdetails sitzen im Kopf einer Person. Fällt diese Person aus, fällt das Wissen aus.
Backup bedeutet VM-Snapshot. Welche Konfiguration drin ist, sieht man erst nach dem Restore.
Ansible-basierte Deployment-Pipeline. Jede Instanz erhält denselben Zustand aus denselben Rollen.
standalone.xml und domain.xml als Code verwaltet. Jede Änderung ist nachvollziehbar, jede Revision rekonstruierbar.
Security Subsystem als automatisierte Policy. Was gilt, steht im Repository und lässt sich überprüfen.
Reproduzierbarer Konfigurationsstandard. Jede Instanz lässt sich aus der Codebasis neu aufbauen.
Versionskontrollierte Konfiguration. Der Zustand ist immer bekannt, weil er immer definiert wurde.
Drei Muster, die wir immer wieder sehen
Die meisten WebSphere-zu-JBoss-Migrationen sind technisch abgeschlossen. Operativ sind sie es nicht.
Der Einzelkämpfer
Eine Person war der WebSphere-Experte. Jetzt ist dieselbe Person der JBoss-Experte. Der Single Point of Failure hat nur die Plattform gewechselt. Fällt die Person aus, steht der Betrieb.
Die Config-Migration
Die Konfiguration wurde 1:1 aus WebSphere portiert. Der Management-Port ist noch offen. Sicherheitshärtung wurde auf "später" verschoben. Später ist jetzt der Audit-Termin.
Der Snapshot-Betrieb
Jede JBoss-Instanz ist ein Unikat. Deployment auf Instanz A funktioniert anders als auf Instanz B. Ob die Konfigurationen konsistent sind, weiss niemand mit Sicherheit.
Migration abschliessen, nicht nur durchführen
Vier Phasen. Das Ziel ist nicht ein laufender JBoss-Server, sondern ein dauerhaft betreibbares, dokumentiertes und automatisiertes Betriebsmodell.
Analyse
Bestandsaufnahme der WebSphere-Umgebung: welche Anwendungen laufen, welche Datasources existieren, welche Sicherheitskonfigurationen aktiv sind, welche Deployment-Pfade es gibt. Kein Blindflug in die Migration.
Target-Baseline
Definition des Zielzustands: wie eine JBoss-EAP-Instanz aussehen muss. CIS-referenzierte Härtung, standardisierte Konfigurationsstruktur, kontrollierte Management-Schnittstellen. Der Zielzustand ist beschrieben, bevor die erste Instanz aufgebaut wird.
Migration mit Rückfalloption
JBoss EAP kommt im definierten Zielzustand hoch. WebSphere bleibt parallel in Betrieb, bis der Cutover validiert ist. Kein erzwungener Schalter, kein unkalkulierbares Risiko.
Automatisierter Betrieb
Nach dem Cutover übernimmt die lennlay.jboss Ansible Collection den Betrieb. Deployment via Ansible. Konfigurationsänderungen via Code. Kein manueller Console-Zugriff als primärer Betriebsweg.
Was sie konkret tut
Die lennlay.jboss Ansible Collection ist das Fundament des automatisierten JBoss-EAP-Betriebs. Drei Bereiche, die direkt auf die WebSphere-Migrationsszenarien antworten.
EAR/WAR Deployment
Standardisiertes, reproduzierbares Deployment via Ansible-Rollen. Dieselbe Anwendung wird auf jeder Instanz auf dieselbe Weise eingespielt. "Ich habe es diesmal anders deployed als letztes Mal" ist kein möglicher Satz mehr.
Konfigurationsmanagement
standalone.xml und domain.xml stehen unter Versionskontrolle und werden via Ansible angewendet. Jede Konfigurationsänderung ist nachvollziehbar. Jede Instanz hat denselben definierten Zustand.
Härtungs-Baseline
CIS-referenzierte Härtung beim ersten Aufbau. Management-Interface abgesichert. Security Subsystem konfiguriert. Nicht als Post-Migrations-Cleanup, sondern eingebaut von Beginn an.
Migrationen sind riskant. Die kritische Phase braucht Erfahrung.
WebSphere-zu-JBoss-Migrationen haben eine Phase, in der Fehler nicht rückgängig zu machen sind. Diese Phase braucht jemanden, der das schon gemacht hat.
Marcel König (RHCA/RHCE) hat diese Migrationen durchgeführt. Matthias Siegl (RHCE) kennt den JBoss-EAP-Betrieb im Detail. Im EaaS-Modell erhalten Sie diese Expertise, ohne eine Festanstellung zu schaffen. Eingebettet in Ihr Team, mit vollständiger Dokumentation als Übergabe.
EaaS bedeutet: Sie zahlen für Projektstunden, nicht für Jahresgehälter. Die Expertise bleibt in Ihrer Organisation durch die Dokumentation, nicht durch den Experten, der möglicherweise nächstes Jahr weg ist.
Red Hat Certified Architect. Führt WebSphere-zu-JBoss-Migrationen, definiert Zielarchitekturen und übernimmt die technische Verantwortung in der kritischen Migrationsphase.
Red Hat Certified Engineer. Betreibt JBoss EAP im Alltag, baut Ansible-Pipelines und sorgt dafür, dass der automatisierte Betrieb nach dem Cutover funktioniert.
Drei Situationen, ein Ausgangspunkt
IBM-Support läuft aus
Die EOL-Timeline steht. Die Migration ist nicht optional, sondern termin-gebunden. Wer jetzt strukturiert vorgeht, vermeidet Panik-Migrationen kurz vor Ablauf des Supports.
Migration abgeschlossen, Chaos geblieben
Der Wechsel auf JBoss EAP ist technisch fertig. Aber jede Instanz fühlt sich noch anders an. Ein Betriebsstandard ist nicht in Sicht. Das Betriebsmodell-Problem ist noch offen.
Audit oder Zertifizierung steht an
Der aktuelle JBoss-EAP-Zustand ist nicht dokumentiert und nicht prüfbar. Was gehärtet wurde und was nicht, lässt sich nicht belegen. Der Termin naht.
Die Migration war der erste Schritt. Lassen Sie uns den zweiten machen.
Beschreiben Sie uns Ihre JBoss-EAP-Umgebung kurz. Wir klären, was noch fehlt und welcher Weg sinnvoll ist.
