Introduction
This article teaches you about WebLogic to WildFly on AKS. To migrate an existing WebLogic application to run on WildFly in an Azure Kubernetes Service container, there are a few things you should be aware of, as described in this tutorial. Let’s start WebLogic to WildFly on AKS

Pre-migration.
Before you begin for WebLogic to WildFly on AKS, complete the assessment and inventory activities outlined in the following sections to ensure a successful migration.
Inventory capacity of a server
Record the current production server's specifications (memory, CPU, disc), average and maximum request counts, and resource usage. No matter which migration route you take, you'll need this information. For instance, it can help determine the size of the VMs in your node pool, the amount of RAM the container will take, and the number of CPU shares it will require.
Inventory all secrets
There wasn't a clear definition of "secrets" before "configuration as a service" platforms like Azure Key Vault emerged. Instead, you had a confusing array of setup options that served as what we now refer to as "secrets." These secrets are spread throughout various configuration stores and configuration files on app servers like WebLogic Server. Search all properties and configuration files on the production server(s) for any secrets or passwords. Verify weblogic.xml in your WARs, please. Your program may also contain configuration files with passwords or other login information. See the fundamental ideas of Azure Key Vault for additional details.

Inventory of all certificates
used for public SSL endpoints should be documented. Run the following command to view all certificates on the production server(s):
keytool -list -v -Keystore <path to keystore>
Inventory JNDI resources
List all the JNDI resources. For instance, databases and other data sources may have a corresponding JNDI name that enables JPA to connect models of EntityManager to a specific database. See WebLogic Server Data Sources in the Oracle documentation for more details on JNDI resources and databases. Moving or reconfiguring other JNDI-related resources, including JMS message brokers, may be necessary. See Oracle WebLogic Server 12.2.1.4.0 for further details on JMS settings.
Identify the use of session replication
You have two choices if your application depends on session replication, whether it uses Oracle Coherence*Web or not:
-
Rework your program, so that session management relies on a database.
- To externalize the session to Azure Redis Service, refactor your application.
Data sources for documents
You must record the following data if your application uses any databases for WebLogic to WildFly on AKS:
-
What's the name of the data source?
-
What is the configuration of the connection pool?
- What location is the JDBC driver JAR file located?
Check to see if WebLogic has been modified,
if any of the following customizations have been made, and note the details.
-
Have The startup scripts have they been modified? These scripts include startWebLogic, stopWebLogic, commEnv, and setDomainEnv.
-
Do the JVM receive any particular parameters?
- Has the server classpath been updated with JARs?
Check to see if a connection to the on-premises is necessary.
You must set up one of Azure's connectivity services if your application requires access to any of your on-premises services. Choose an option for connecting an on-premises network to Azure for additional details. Alternatively, you'll need to refactor your application to use the open APIs that your on-premises resources offer.
Check whether any JMS (Java Message Service) Queues or Topics are active.
You must move JMS Queues, and Topics from your application to a JMS server hosted elsewhere. For JMS users, migrating to Azure Service Bus and the Advanced Message Queuing Protocol (AMQP) can be a terrific idea. Use JMS with Azure Service Bus and AMQP 1.0 for additional details.
If JMS persistent stores have been set up, you must record their settings and use them after the migration.
Check if you are utilizing your own unique Shared Java EE Libraries.
You have two choices if you use the Shared Java EE library feature:
-
Remove any library dependencies from your application code by refactoring it, and add the functionality directly to your application.
- The libraries should be added to the server classpath.
Check to see if the WebLogic Scripting Tool is installed.
You must evaluate what the WebLogic Scripting Tool (WLST) is doing if you currently utilize it to carry out the deployment. Make sure that any (runtime) parameters of your application that WLST modifies as part of the deployment adhere to one of the following possibilities:
-
The settings for the app are externalized as parameters.
-
Your application contains the parameters already.
- When deploying, the arguments are used using the JBoss CLI.
You'll have more work to accomplish during migration if WLST does tasks beyond those listed above.

Check to see if and how the file system is utilized.
Using the application server's file system necessitates configuration changes or, in rare circumstances, architecture changes. The code in your application or WebLogic shared modules may use the file system. Any or all of the scenarios listed in the following sections may seem familiar to you.
Read-only static content
You'll need a different place for static content if your application currently delivers it. You might want to think about adding Azure CDN for lightning-fast downloads worldwide and migrating static material to Azure Blob Storage. See Hosting Static Websites in Azure Storage and Quickstart for further details. Connect an Azure CDN account to an Azure storage account.
Static material that is published dynamically
Use Azure Blob Storage and Azure CDN as mentioned above, along with an Azure Function to handle uploads and CDN refreshes, if your application permits static content that is uploaded or produced by your application but is immutable after it has been created. Uploading and CDN-preloading static content with Azure Functions contains a sample implementation that you may utilize.
Internal or dynamic content
You can mount Azure Storage shares as persistent volumes for files that are often written to and read by your application (such as temporary data files) or static files that are only visible to your application. See Dynamically create and use a persistent volume with Azure Files in Azure Kubernetes Service for more information.







