Moving JBoss EAP Workloads to OpenShift

More and more customers running traditional Java EE or Jakarta EE workloads are asking the same question: “We already use JBoss EAP. Should we move to Kubernetes or OpenShift, and do we need to replace the application server?”

The answer is not to rush into a rewrite. In many cases, the most realistic and valuable first step is to move the existing JBoss EAP workloads to OpenShift, while modernizing the way they are built, configured, deployed, monitored, and operated.

This is not a simple lift-and-shift. It is a controlled modernization of the runtime and operating model.

The customer scenario: existing JBoss EAP, new platform expectations

A typical customer already has several applications running on JBoss EAP. Some are packaged as WAR files, others as EAR files. They use datasources, JNDI names, security realms or Elytron, JMS, transactions, batch jobs, custom modules, shared libraries, and sometimes clustering or HTTP session replication.

At the same time, the infrastructure team wants to move to Kubernetes or OpenShift to standardize deployments, improve automation, reduce manual operations, and align with a container-based platform strategy.

In this situation, recommending an immediate migration to another runtime such as Quarkus would often be too aggressive. The customer would have to manage two major changes at the same time: a platform migration and an application architecture migration.

A better approach is to keep JBoss EAP as the first target runtime and move to OpenShift.

Red Hat provides specific documentation for using JBoss EAP on OpenShift, including build and deployment approaches based on Helm charts for EAP 8.x. This matters because the customer is not moving to an unsupported or exotic model. They are moving an existing Red Hat middleware platform into a Red Hat container platform.

Why JBoss EAP still makes sense on OpenShift

JBoss EAP remains a strong choice when the application already depends on enterprise Java capabilities. For existing applications, EAP provides continuity. The customer can keep familiar application patterns which reduce risk compared to a full rewrite.

The real value of OpenShift is not simply “running EAP in a container”. The value comes from changing the operational model.

Instead of manually maintaining application servers on virtual machines, the target model should be:

• One application image per application or application group,
• Configuration externalized through ConfigMaps, Secrets, and environment variables,
• Immutable deployments,
• Health checks and probes,
• Centralized logs,
• Controlled resource requests and limits,
• Automated deployments through CI/CD or GitOps,
• Rolling updates and rollback capability,
• Platform-level security and image governance.

Red Hat documents that EAP applications can be built from compiled WAR or EAR archives and deployed onto a JBoss EAP runtime stack for OpenShift. That is important for real-world migration projects because many customers cannot rewrite their packaging model immediately.

For EAP 7.4 customers, there are also Red Hat-provided OpenShift runtime images, such as the JBoss EAP 7.4 OpenJDK 11 runtime image, described as a base image to run an EAP server and application.

The recommendation should therefore be clear: do not reproduce the old VM model inside Kubernetes. Use the move to OpenShift to clean up the runtime model.

A good migration should review:

• EAP and Java versions,
• WAR/EAR packaging,
• Standalone.xml or domain configuration,
• Datasources and JDBC drivers,
• JMS usage and MDBs,
• Security integration,
• Filesystem dependencies,
• Clustering and session handling,
• JVM tuning,
• Startup and shutdown behavior,
• Logging format;monitoring and alerting,
• CI/CD pipeline,
• Backup and recovery constraints.

Some applications will be easy to containerize. Others will need technical adaptation. A few may not be good candidates without refactoring.

Recommended approach

For a customer already using JBoss EAP, my recommendation is:

Start with JBoss EAP on OpenShift. Stabilize the container model. Then identify which applications or components deserve deeper modernization.

This approach avoids unnecessary risk. It gives the customer a supported and realistic path to Kubernetes while preserving the value of the existing EAP investment.

OpenShift does not automatically make an application cloud-native. The right approach is to understand the existing EAP landscape, modernize the operating model first, and only then decide where a lighter, Kubernetes-native runtime brings measurable value.

Conclusion

In the end, the decision should not be driven by trends, but by application reality: architecture, dependencies, operational constraints, risk, and business value.

If you would like more information or need support with JBoss EAP, from troubleshooting and performance optimization to upgrades and patching, feel free to contact me. I can also support you in assessing and planning the migration of your JBoss workloads to OpenShift or Kubernetes.