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
- Read-only inventory of domains, clusters, data sources, JNDI names, JMS destinations and stores, and security realms
- Mapping of WebLogic descriptors and APIs to each candidate server, with the unmapped items listed
- Namespace check: javax or jakarta, against each target's published support window
- List of the application code changes each target would force, for the team or another provider
- Rehearsal of one application on a target built from the inventory, with thread, pool and message behaviour compared
- 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.