Migrate WebSphere to JBoss EAP
IBM raised licensing costs. You migrated to JBoss EAP. The operational chaos came with you.
A migration is a one-time event. The consequences of the wrong operating model run for ten years. Switching the server while keeping the same operational mindset leaves the migration half-finished.
lennlay closes the other half: reproducible configuration, automated deployment, a documented hardening baseline. Your WebSphere replacement becomes a JBoss EAP platform you can actually operate long-term.
The server is new. The operating model is not.
WebSphere and JBoss EAP are fundamentally different platforms with fundamentally different operational philosophies. Swapping only the server brings the wrong model along.
EAR/WAR deployments through the admin console. Manual, instance-specific, not reproducible.
JNDI datasources configured in the GUI. No code, no version history, no diff.
Security roles maintained manually in the admin interface. Who has what access only the person who set it up knows for sure.
Configuration details live inside one person's head. When that person is unavailable, so is the knowledge.
Backup means VM snapshot. What configuration is inside only becomes clear after the restore.
Ansible-based deployment pipeline. Every instance receives the same state from the same roles.
standalone.xml and domain.xml managed as code. Every change tracked, every revision reconstructable.
Security subsystem as an automated policy. What applies lives in the repository and can be verified.
A reproducible configuration standard. Every instance can be rebuilt from the codebase.
Version-controlled configuration. The state is always known because it was always defined.
Three patterns we see over and over
Most WebSphere-to-JBoss migrations are technically complete. Operationally, they are not.
The lone expert
One person was the WebSphere expert. Now that same person is the JBoss expert. The single point of failure just changed platforms. When that person is out, operations stall.
The config port
Configuration was ported 1:1 from WebSphere. The default management port is still open. Security hardening was pushed to "later." Later is now the audit deadline.
The snowflake estate
Every JBoss instance is one of a kind. Deploying to instance A works differently than deploying to instance B. Whether the configurations are actually consistent — nobody knows for certain.
Finish the migration, not just run it
Four phases. The goal is not a running JBoss server — it is a permanently operable, documented, and automated operating model.
Analysis
Inventory of the WebSphere environment: which applications are running, which datasources exist, which security configurations are active, which deployment paths are in use. No guesswork entering the migration.
Target baseline
Define what a JBoss EAP instance should look like. CIS-referenced hardening, standardized configuration structure, controlled management interfaces. The target state is specified before the first instance is built.
Migration with rollback option
JBoss EAP comes up in its defined target state. WebSphere stays running in parallel until the cutover is validated. No forced switch, no uncalculated risk.
Automated operations
After cutover, the lennlay.jboss Ansible Collection takes over. Deployment via Ansible. Configuration changes via code. Manual console access is no longer the primary operational path.
What it actually does
The lennlay.jboss Ansible Collection is the foundation of automated JBoss EAP operations. Three areas that directly address the common WebSphere migration failure modes.
EAR/WAR deployment
Standardized, reproducible deployments via Ansible roles. The same application is deployed the same way on every instance. "I deployed it differently this time than last time" is no longer a sentence anyone can say.
Configuration management
standalone.xml and domain.xml under version control, applied via Ansible. Every configuration change is traceable. Every instance carries the same defined state.
Hardening baseline
CIS-referenced hardening on first build. Management interface locked down. Security subsystem configured. Not a post-migration cleanup — built in from the start.
Migrations are risky. The critical phase needs experience.
WebSphere-to-JBoss migrations have a window where mistakes are not reversible. That window needs someone who has been through it before.
Marcel König (RHCA/RHCE) has run these migrations. Matthias Siegl (RHCE) knows JBoss EAP operations at depth. With EaaS, you get that expertise without creating a permanent hire. Embedded in your team, with full documentation as the handover.
EaaS means you pay for project hours, not annual salaries. The expertise stays in your organization through the documentation — not through the expert who might leave next year.
Red Hat Certified Architect. Leads WebSphere-to-JBoss migrations, defines target architectures, and takes technical ownership through the critical migration phase.
Red Hat Certified Engineer. Operates JBoss EAP day-to-day, builds Ansible pipelines, and makes sure automated operations hold up after cutover.
Three situations, one starting point
IBM support is ending
The EOL timeline is set. The migration is not optional, it is deadline-driven. Moving now with a structured approach avoids panic migrations the week before support expires.
Migration done, chaos stays
The move to JBoss EAP is technically complete. But every instance still feels different. No operational standard in sight. The operating model problem is still open.
Audit or certification coming up
The current JBoss EAP state is not documented and not verifiable. What was hardened and what was not cannot be proven. The deadline is approaching.
The migration was the first step. Let us take the second one.
Tell us briefly about your JBoss EAP environment. We will identify what is missing and which path makes sense.
