Back to all use cases

AssessmentCross-Industry

Know what the server supplied before choosing the server that replaces it

Enterprise Application Platform Team

Inventorying WebLogic domains, data sources, JMS destinations and clustering and mapping each to Tomcat or WildFly before a target server is chosen.

Overview

A typical request: a platform team that runs several WebLogic domains wants to know whether its applications could run on Tomcat or WildFly, and what each choice would force. AceMQ and a partner WebLogic specialist deliver a written assessment, scope and process, not a migration. Changes to application code are listed for the team and are outside AceMQ's scope.

Challenge

The WAR or EAR file is the small part of a WebLogic application. The domain around it supplies JNDI-bound data sources, JMS destinations and stores, security realms, work managers, session replication and deployment descriptors, and few of them are written down outside config.xml. The namespace matters as well: WebLogic 14.1.2 runs javax and 15.1.1 runs jakarta, so a target has to be matched to the code the team has. A migration scoped as just WAR files meets the EJBs and JMS destinations late.

Environment

WebLogic Server 12.2.1.4 or 14.1.2 on virtual machines in two or more environments, a mix of web applications and applications that use EJB, JMS and JTA, and a team that edits domain configuration partly by hand.

Approach

AceMQ reads each domain without changing it and lists every data source, JNDI name, JMS destination, realm and descriptor setting. It then maps each item to an equivalent on Tomcat, WildFly or JBoss EAP, Payara or Open Liberty, marks the items with no equivalent, and checks each target's support window against the namespace the code uses. One application is deployed to a rehearsal environment built from the inventory to test the mapping.

Solution

  1. Read-only inventory of domains, clusters, data sources, JNDI names, JMS destinations and stores, and security realms
  2. Mapping of WebLogic descriptors and APIs to each candidate server, with the unmapped items listed
  3. Namespace check: javax or jakarta, against each target's published support window
  4. List of the application code changes each target would force, for the team or another provider
  5. Rehearsal of one application on a target built from the inventory, with thread, pool and message behaviour compared
  6. Cutover and rollback outline that keeps the WebLogic domain until a full business cycle has passed on the new server

Outcome

The team receives a written inventory, a mapping table for each candidate target, a list of code changes each target would force, the results of the rehearsal and a cutover outline with the WebLogic domain as the rollback. The decision to move, stay or wait is made on that evidence, and staying on WebLogic remains an option.

Technologies

WebLogicTomcatWildFlyJava

Ready for a WebLogic Health Check?

AceMQ's senior WebLogic engineers have handled this exact type of engagement before. Whether you need architectural guidance, hands-on remediation, or an ongoing managed partnership, we're ready to help.