Migrate WebLogic Server applications to Azure Virtual Machines
This guide describes what you should be aware of when you want to migrate an existing WebLogic application to run on Azure Virtual Machines. For an overview of available WebLogic Server solutions in Azure Marketplace, see What are solutions for running Oracle WebLogic Server on Azure Virtual Machines?
To ensure a successful migration, before you start, complete the assessment and inventory steps described in the following sections.
Define what you mean by "migration complete"
This guide, and the corresponding Azure Marketplace Offers, are a starting point to accelerate the migration of your WebLogic Server workloads to Azure. It's important to define the scope of your migration effort. For example, are you doing a strict "lift and shift" from your existing infrastructure to Azure Virtual Machines? If so, you may be tempted to work in some "lift and improve" as you migrate.
It's better to stick as close to pure "lift and shift" as possible, accounting for the necessary changes as detailed in this guide. Define what you mean by "migration complete" so that you know when you've reached this milestone. When you've reached your "migration complete", you can take a snapshot of your Virtual Machines as described in Create a snapshot. After you've verified that you can successfully restore from your snapshot, it's safer to do the improvements without fear of losing the migration progress you've achieved thus far.
Ensure that the target is the appropriate target for your migration effort
The first step in a successful migration of a WLS application to Azure is selecting the most appropriate migration target. WLS runs well on Azure virtual machines (VMs) or Azure Kubernetes Service (AKS). The VM target is the easiest choice, because it most closely resembles an on-premises deployment. The administrative and deployment experience for virtual machines is very analogous to what you have on-premises. The trade-off for this ease is economic cost. Generally speaking, the per-minute cost for a VM-based solution is higher compared with AKS. While an AKS-based solution costs less to run, you must constrain your application to fit within the requirements of AKS. If minimizing change is the most important factor for your migration effort, consider a VM-based migration. In this case, see Migrate WebLogic applications to Azure Virtual Machines. If you can tolerate converting your application to run within Kubernetes to reduce runtime cost, consider an AKS-based migration. In this case, continue with Migrate WebLogic Server applications to Azure Kubernetes Service.
Determine whether the pre-built Azure Marketplace offers are a good starting point
Oracle and Microsoft have partnered to bring a set of Azure solution templates to Azure Marketplace to provide a solid starting point for migrating to Azure. Consult the Oracle Fusion Middleware documentation for the list of offers and choose the one that most closely matches your existing deployment. You can see the list of offers in the overview article What is Oracle WebLogic Server on Azure?
If none of the existing offers are a good starting point, you'll have to reproduce the deployment by hand using Azure Virtual Machine resources. For more information, see What is IaaS?.
Determine whether the WebLogic version is compatible
Your existing WebLogic version must be compatible with the version in the IaaS offers. This query will show the offers for WebLogic version 188.8.131.52. If your existing WebLogic version is not compatible with that version, you'll have to reproduce the deployment by hand using Azure IaaS resources. For more information, see the Azure documentation.
Inventory server capacity
Document the hardware (memory, CPU, disk) of the current production server(s) as well as the average and peak request counts and resource utilization. This information must inform the choice of VM size. For more information, see Sizes for Cloud Services.
Inventory all secrets
Before the advent of "configuration as a service" technologies such as Azure Key Vault, there wasn't a well-defined concept of "secrets". Instead, you had a disparate set of configuration settings that effectively functioned as what we now call "secrets". With app servers such as WebLogic Server, these secrets are in many different config files and configuration stores. Check all properties and configuration files on the production server(s) for any secrets and passwords. Be sure to check weblogic.xml in your WARs. Configuration files containing passwords or credentials may also be found inside your application. For more information, see Azure Key Vault basic concepts.
Inventory all certificates
Document all the certificates used for public SSL endpoints. You can view all certificates on the production server(s) by running the following command:
keytool -list -v -keystore <path to keystore>
Validate that the supported Java version works correctly
All of the migration paths for WebLogic to Azure require a specific Java version, which varies for each path. You'll need to validate that your application is able to run correctly using that supported version.
This validation is especially important if your current server is running on an unsupported JDK (such as Oracle JDK or IBM OpenJ9).
To obtain your current Java version, sign in to your production server and run the following command:
When migrating to WLS on Azure virtual machines, the requirements for the specific Java versions are determined by the pre-installed Java on the virtual machines. When migrating to WLS on AKS, the specific Java version is determined by the container image chosen. There are a wide variety of choices, but all of them use the Oracle JDK.
Inventory JNDI resources
Inventory all JNDI resources. For example, datasources such as databases may have an associated JNDI name that allows JPA to correctly bind instances of
EntityManager to a particular database. For more information on JNDI resources and databases, see WebLogic Server Data Sources in the Oracle documentation. Other JNDI-related resources, such as JMS message brokers, may require migration or reconfiguration. For more information on JMS configuration see Oracle WebLogic Server 184.108.40.206.0.
Inspect your domain configuration
The main configuration unit in WebLogic Server is the domain. As such, the config.xml file contains a wealth of configuration that you must carefully consider for migration. The file includes references to additional XML files that are stored in subdirectories. Oracle advises that you should normally use the Administration Console to configure WebLogic Server's manageable objects and services and allow WebLogic Server to maintain the config.xml file. For more information, see Domain Configuration Files.
Inside your application
Inspect the WEB-INF/weblogic.xml file and/or the WEB-INF/web.xml file.
Determine whether session replication is used
If your application relies on session replication, with or without Oracle Coherence*Web, you have three options:
- Coherence*Web can run alongside a WebLogic Server in the Azure virtual machines, but you must manually configure this option after you provision the offer. If you are using standalone Coherence, you can also run it in an Azure virtual machine, but you must manually configure this option after you provision the offer.
- Refactor your application to use a database for session management.
- Refactor your application to externalize the session to Azure Redis Service. For more information, see Azure Cache for Redis.
For all of these options, it's a good idea to master how WebLogic does HTTP Session State Replication. For more information, see HTTP Session State Replication in the Oracle documentation.
If your application uses any databases, you need to capture the following information:
- What is the datasource name?
- What is the connection pool configuration?
- Where can I find the JDBC driver JAR file?
For more information on JDBC drivers in WebLogic, see Using JDBC Drivers with WebLogic Server.
Determine whether WebLogic has been customized
Determine which of the following customizations have been made, and capture what's been done.
- Have the startup scripts been changed? Such scripts include setDomainEnv, commEnv, startWebLogic, and stopWebLogic.
- Are there any specific parameters passed to the JVM?
- Are there JARs added to the server classpath?
Determine whether Management over REST is used
If the lifecycle of your application includes using Management over REST, you need to capture which ports are used to access the REST API and determine how they are authenticated and exposed. After migration, you'll need to ensure that these same ports and authentication mechanisms are exposed so your application lifecycle can operate in a similar fashion as before the migration. For more information, see Administering Oracle WebLogic Server with RESTful Management Services.
Determine whether a connection to on-premises is needed
If your application needs to access any of your on-premises services, you'll need to provision one of Azure's connectivity services. For more information, see Choose a solution for connecting an on-premises network to Azure. Alternatively, you'll need to refactor your application to use publicly available APIs that your on-premises resources expose.
Determine whether Java Message Service (JMS) Queues or Topics are in use
If your application is using JMS Queues or Topics, you'll need to migrate them to an externally-hosted JMS server. Azure Service Bus and the Advanced Message Queuing Protocol can be a great migration strategy for those using JMS. For more information, see Use JMS with Azure Service Bus and AMQP 1.0.
If JMS persistent stores have been configured, you must capture their configuration and apply it after the migration.
If you're using Oracle Message Broker, you can migrate this software to Azure virtual machines and use it as-is.
Determine whether you are using your own custom created Shared Java EE Libraries
If you're using the Shared Java EE library feature, you have two options:
- Refactor your application code to remove all dependencies on your libraries, and instead incorporate the functionality directly into your application.
- Add the libraries to the server classpath.
Determine whether OSGi bundles are used
If you used OSGi bundles added to the WebLogic server, you'll need to add the equivalent JAR files directly to your web application.
Determine whether your application contains OS-specific code
If your application contains any code with dependencies on the host OS, then you'll need to refactor it to remove those dependencies. For example, you may need to replace any use of
\ in file system paths with
Determine whether Oracle Service Bus is in use
If your application is using Oracle Service Bus (OSB), you'll need to capture how OSB is configured. For more information, see About the Oracle Service Bus Installation.
Determine whether your application is composed of multiple WARs
If your application is composed of multiple WARs, you should treat each of those WARs as separate applications and go through this guide for each of them.
Determine whether your application is packaged as an EAR
If your application is packaged as an EAR file, be sure to examine the application.xml and weblogic-application.xml files and capture their configurations.
Identify all outside processes and daemons running on the production servers
If you have any processes running outside the application server, such as monitoring daemons, you'll need to eliminate them or migrate them elsewhere.
Determine whether WebLogic Scripting Tool (WLST) is used
If you currently use WLST to perform your deployment, you'll need to assess what it's doing. If WLST is changing any (runtime) parameters of your application as part of the deployment, you'll need to make sure that this behavior continues to work while testing your application after migration.
Determine whether and how the file system is used
VM filesystems operate the same way as on-premises filesystems with respect to persistence, startup, and shutdown. Even so, it's important to be aware of your filesystem needs and ensure the VMs have adequate storage size and performance.
Read-only static content
If your application currently serves static content, you'll need an alternate location for it. You may wish to consider moving static content to Azure Blob Storage and adding Azure CDN for lightning-fast downloads globally. For more information, see Static website hosting in Azure Storage and Quickstart: Integrate an Azure storage account with Azure CDN.
Dynamically published static content
If your application allows for static content that is uploaded/produced by your application but is immutable after its creation, you can use Azure Blob Storage and Azure CDN as described above, with an Azure Function to handle uploads and CDN refresh. We've provided a sample implementation for your use at Uploading and CDN-preloading static content with Azure Functions.
Determine the network topology
The current set of Azure Marketplace offers is a starting point for your migration. If the offer does not cover aspects of your architecture that you need to migrate, you'll need to capture the network topology of your existing deployment and reproduce that in Azure, even after standing up the basic offer with one of the solution templates.
This is a very broad topic, but the following references can give some direction to your migration efforts:
- This reference enumerates the high level topics relevant to the migration of network topology to Azure: Fast Track Deployment Guide.
- This reference describes important concerns regarding clustering, which has an impact on network topology: WebLogic Server Clustering.
- Because data sources are separate servers in a WebLogic system, you must consider them as part of the network topology analysis. WebLogic Server Data Sources.
- Messaging sources are also separate servers. WebLogic Server Messaging
- Load balancing is a fundamental requirement. This reference covers the WebLogic Server side of load balancing: Load Balancing in a Cluster.
Account for the use of JCA Adapters and Resource Adapters
If your existing application is using JCA Adapters and/or Resource Adapters to connect to other enterprise systems, ensure that the configuration for these artifacts is applied to the WebLogic Server running in Azure Virtual Machines. For more information, see Creating and Configuring Resource Adapters
Account for the use of custom security providers and JAAS
If your application is using JAAS, you need to make sure the configuration of security providers is correctly migrated. For more information, see About Configuring WebLogic Security Providers in the Oracle documentation.
Determine whether WebLogic clustering is used
Most likely, you've deployed your application on multiple WebLogic servers to achieve high availability. You can migrate these clusters directly from your on-premises installation to WebLogic running in Azure Virtual Machines. For more information, see Domain Configuration Files in the Oracle documentation.
Account for load-balancing requirements
Load balancing is an essential part of migrating your Oracle WebLogic Server cluster to Azure. The easiest solution is to use the built-in support for Azure Application Gateway provided in the Azure Marketplace offer for Oracle WebLogic Server cluster. For a tutorial on this topic, see Tutorial: Migrate a WebLogic Server cluster to Azure with Azure Application Gateway as a load balancer.
For a summary of the capabilities of Azure Application Gateway compared to other Azure load-balancing solutions, see Overview of load-balancing options in Azure.
Determine whether the Java EE Application Client feature is used
If your application uses the Java EE Application Client feature, it should continue to work unchanged after migrating to Azure Virtual Machines. For more information, see Using Java EE Client Application Modules.
Select a WebLogic on Azure Virtual Machines offer
The following offers are available for WebLogic on Azure Virtual Machines.
During the deployment of an offer, you'll be asked to choose the Virtual Machine size for your WebLogic server nodes. It's important to consider all aspects of sizing (memory, processor, disk) in your choice of VM size. For more information, see the Azure Documentation for virtual machine sizing
WebLogic Server Single Node with no Admin Server
This offer creates a single VM and installs WebLogic on it, but doesn't configure any domains, which is useful for scenarios where you have a highly customized domain configuration.
WebLogic Server Single Node with Admin Server
This offer provisions a single VM and installs WebLogic Server on it. It creates a domain and starts up the admin server.
WebLogic Server N-Node Cluster
This offer creates a highly available cluster of WebLogic Server VMs.
WebLogic Server N-Node Dynamic Cluster
This offer creates a highly available and scalable dynamic cluster of WebLogic Server VMs
Provision the offer
After you've selected which offer to start with, follow the instructions in documentation for the offers to provision that offer. Make sure to choose the domain name that matches your existing domain name. You can even match the domain password with your existing domain password.
Migrate the domains
After you've provisioned the offer, you can examine the domain configuration and follow this guidance for details on how to migrate the domains.
Connect the databases
After you've migrated the domains, you can connect the databases by following the instructions in the offer documentation. These instructions will help you account for any database secrets and access strings involved.
Account for KeyStores
You must account for the migration of any SSL KeyStores used by your application. For more information, see Configuring Keystores.
Connect the JMS sources
After you've connected the databases, you can configure JMS by following the instructions at Fusion Middleware Administering JMS Resources for Oracle WebLogic Server in the WebLogic documentation.
Account for authentication and authorization
Most applications have some kind of authentication and authorization. If you use LDAP for authentication, you can set up Azure Active Directory Domain Services (Azure AD DS) with secure LDAP and configure LDAP connections in WebLogic Server. For more information, see Create and configure an Azure Active Directory Domain Services managed domain and Configure secure LDAP for an Azure Active Directory Domain Services managed domain.
Account for logging
Use the integration with Elastic on Azure provided by the Oracle WebLogic Server marketplace solution templates. This is the easiest way to account for logging. You can see the list of offers in the overview article What are solutions for running Oracle WebLogic Server on Azure Virtual Machines? Complete tutorials to configure Elastic are provided in:
- Land Oracle WebLogic Server logs to Elasticsearch and Kibana in admin offer
- Land Oracle WebLogic Server logs to Elasticsearch and Kibana in cluster offer
- Land Oracle WebLogic Server logs to Elasticsearch and Kibana in dynamic cluster offer
If the Elastic integration isn't appropriate, you should carry over the existing logging configuration when you migrate the domain. For more information, see Configure java.util.logging logger levels and Configuring Log Files and Filtering Log Messages for Oracle WebLogic Server in the Oracle documentation.
Migrating your applications
The techniques used to deploy applications from the development team into test, staging, and production servers vary greatly from case to case. In some cases, there's a highly evolved CI/CD platform that results in the applications being deployed to the WebLogic Server. In other cases, the process can be more manual. One benefit of using Azure Virtual Machines to migrate WebLogic applications to the cloud is that your existing processes will continue to work.
You'll have to configure the Network Security Group that is provisioned by the offer to allow access from your CI/CD pipeline, or manual deployment system. For more information, see Security groups in the Azure documentation for details.
Any in-container tests against applications must be configured to access the new servers running within Azure. As with the CI/CD concerns, you must ensure the necessary network security rules allow your tests to access the applications deployed to Azure. For more information, see Security groups in the Azure documentation.
After you've reached the migration goals you defined in the pre-migration step, perform some end-to-end acceptance testing to verify that everything works as expected. Some topics for post-migration enhancements include, but are certainly not limited to the following:
Using Azure Storage to serve static content mounted to the virtual machines. For more information, see Attach or detach a data disk to a virtual machine.
Deploy your applications to your migrated WebLogic cluster with Azure DevOps. For more information, see Azure DevOps getting started documentation.
If you deployed WebLogic Server with Azure Application Gateway by following the steps in Tutorial: Migrate a WebLogic Server cluster to Azure with Azure Application Gateway as a load balancer, you may want to do additional configuration on the Application Gateway. For more information, see Application Gateway configuration overview .
Enhance your network topology with advanced load balancing services. For more information, see Using load-balancing services in Azure.
Leverage Azure Managed Identities to managed secrets and assign role based access to Azure resources. For more information, see What are managed identities for Azure resources?.
Integrate WebLogic Java EE authentication and authorization with Azure Active Directory. For more information, see Integrating Azure Active Directory getting started guide.
Use Azure Key Vault to store any information that functions as a "secret". For more information, see Azure Key Vault basic concepts.
Indsend og få vist feedback om