Edit

Share via

Migrate WebLogic Server applications to Azure Virtual Machines

  • Article

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?

Pre-migration

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, you can 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 prebuilt 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 have to reproduce the deployment by hand using Azure Virtual Machine resources. You can find the step-by-step guidance in Install Oracle WebLogic Server on Azure Virtual Machines manually. 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. To see the offers for WebLogic version 12.2.1.3, query Azure Marketplace for Oracle WebLogic 12.2.1.3. If your existing WebLogic version isn't compatible with that version, you 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.

Note

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:

java -version

Note

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 12.2.1.4.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.

Document datasources

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 / or \ in file system paths with File.Separator or Paths.get.

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. You can also directly deploy the static content to an app in the Azure Spring Apps Enterprise plan. For more information, see Deploy web static files.

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. You can also directly deploy the static content to an app in the Azure Spring Apps Enterprise plan. For more information, see Deploy web static files.

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:

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.

Migration

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're 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 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. For more information, see 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 Microsoft Entra Domain Services with secure LDAP and configure LDAP connections in WebLogic Server. For more information, see Create and configure a Microsoft Entra Domain Services managed domain and Configure secure LDAP for a Microsoft Entra Domain Services managed domain.

Account for logging

Use the integration with Elastic on Azure provided by the Oracle WebLogic Server marketplace solution templates. This approach 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:

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 continue to work.

You have to configure the Network Security Group that the offer provisions to allow access from your CI/CD pipeline or manual deployment system. For more information, see Network security groups.

Testing

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 Network security groups.

Post-migration

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. For guidance on some potential post-migration enhancements, see the following recommendations: