This guide describes what you should be aware of when you want to migrate an existing WebSphere Application Server (WAS) traditional application to run on Azure Virtual Machines. For an overview of available WAS traditional solutions in Azure Marketplace, see What are solutions to run the IBM WebSphere family of products on Azure?

To ensure a successful migration, before you start, complete the assessment and inventory steps described in the following sections.

This guide, and the corresponding Azure Marketplace offers, are a starting point to accelerate the migration of your WAS traditional 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 of a virtual hard disk. 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.

[!INCLUDE vm-aks-aro-tradeoffs-was-liberty]

IBM 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. For the list of offers, see Run the WebSphere family of products and Liberty on Microsoft Azure, and then choose the one that most closely matches your existing deployment. You can see the list of offers in the overview article What are solutions to run the IBM WebSphere family of products 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 Tutorial: Manually install IBM WebSphere Application Server Network Deployment traditional on Azure Virtual Machines. For more information, see What is IaaS?

Your existing WAS traditional version must be compatible with the version in the IaaS offers. You can find the version information from the overview page of IBM WebSphere Application Server Single Instance on Azure VM and IBM WebSphere Application Server Cluster on Azure VMs. If your existing WAS traditional version isn't compatible with that version, you have to reproduce the deployment by hand using Azure IaaS resources. For more information, see What is IaaS?

[!INCLUDE inventory-server-capacity-virtual-machines]

[!INCLUDE inventory-all-secrets]

[!INCLUDE inventory-all-certificates] For more information, see the IBM document Certificate management in SSL

[!INCLUDE validate-that-the-supported-java-version-works-correctly-was]

[!INCLUDE inventory-was-jndi-resources]

[!INCLUDE inspect-your-profile-configuration]

[!INCLUDE determine-whether-session-replication-is-used]

[!INCLUDE document-datasources]

[!INCLUDE determine-whether-was-has-been-customized]

[!INCLUDE determine-whether-a-connection-to-on-premises-is-needed]

[!INCLUDE determine-whether-jms-queues-or-topics-are-in-use-virtual-machines]

[!INCLUDE determine-whether-you-are-using-your-own-custom-created-shared-java-ee-libraries]

[!INCLUDE determine-whether-osgi-bundles-are-used]

[!INCLUDE determine-whether-your-application-contains-os-specific-code]

[!INCLUDE determine-whether-ibm-integration-bus-is-in-use]

[!INCLUDE determine-whether-your-application-is-composed-of-multiple-wars]

[!INCLUDE determine-whether-your-application-is-packaged-as-an-ear]

[!INCLUDE identify-all-outside-processes-and-daemons-running-on-the-production-servers]

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.

[!INCLUDE static-content]

[!INCLUDE determine-the-network-topology]

[!INCLUDE account-for-the-use-of-jca-adapters-and-resource-adapters]

[!INCLUDE account-for-the-use-of-custom-security-providers-and-jaas]

[!INCLUDE determine-whether-was-clustering-is-used]

[!INCLUDE determine-whether-the-java-ee-application-client-feature-is-used]

The following offers are available for WAS on Azure Virtual Machines.

During the deployment of an offer, you're asked to choose the virtual machine size for your WAS nodes. It's important to consider all aspects of sizing (memory, processor, disk) in your choice of VM size. For more information, see Sizes for Cloud Services (classic).

• IBM WebSphere Application Server Single Instance on Azure VM

  This offer automates most boilerplate steps to provision a single WebSphere instance on an Azure Virtual Machine. It creates an Application server profile with WAS admin console.

• IBM WebSphere Application Server Cluster on Azure VMs

  This offer automates most boilerplate steps to provision a WebSphere cluster on Azure VMs. It creates a deployment manager with WAS admin console on an Azure VM and required numbers of node agents on separated Azure VMs.

After you've selected which offer to start with, provision that offer by following the instructions in Deploy WebSphere Application Server (traditional) Cluster on Azure Virtual Machines.

After you've provisioned the offer, you can examine the profile configuration. For more information, see Profile concepts in the IBM documentation.

After you've migrated the profiles, you can connect the databases by following the instructions in Configuring the WebSphere Application Server data source in the IBM documentation.

You must account for the migration of any SSL KeyStores used by your application. For more information, see Keystore configurations for SSL in the IBM documentation.

After you've connected the databases, you can configure JMS by following the instructions at Setting up JMS in IBM WebSphere Application Server in the IBM documentation.

[!INCLUDE account-for-authentication-and-authorization]

You can configure Elastic Stack by following the instructions at Analyzing WebSphere Application Server logs with Elastic Stack in the IBM documentation. Azure provides support for Elastic. For more information, see What is Elastic integration with Azure? You can combine the knowledge in these two resources to achieve an Azure-optimized logging solution for WAS on VMs.

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 WebSphere Application Server. In other cases, the process can be more manual. One benefit of using Azure Virtual Machines to migrate WAS traditional 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.

You must configure any in-container tests against applications 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.

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:

• Use Azure Storage to serve static content mounted to the virtual machines. For more information, see Attach or detach a data disk for a lab virtual machine in Azure DevTest Labs.

• Deploy your applications to your migrated WAS cluster with Azure DevOps. For more information, see Get started with Azure DevOps documentation.

• If you deployed WAS traditional with Azure Application Gateway, you may want to do more 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.

• Use 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 WAS Java EE authentication and authorization with Microsoft Entra ID. For more information, see Integrating Microsoft Entra ID with applications 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.