Migrate Java applications to Azure
This article provides an overview of recommended strategies for migrating Java applications to Azure.
This migration guidance is designed to cover mainstream Java on Azure scenarios, and to provide high-level planning suggestions and considerations. If you'd like to discuss a specific Java app migration scenario with the Microsoft Java on Azure team, fill out the following questionnaire, and a representative will contact you.
Identifying application type
Before you select a cloud destination for your Java application, you'll need to identify its application type. Most Java applications are one of the following types:
- Spring applications:
- Java EE applications
- Web applications
- Batch / scheduled jobs
These types are described in the following sections.
Spring Boot / JAR applications
Many newer applications are invoked directly from the command line. These applications still handle web requests, but instead of relying on an application server to provide HTTP request handling, they incorporate HTTP communication and all other dependencies directly into the application package. Such applications are frequently built with frameworks such as Spring Boot, Dropwizard, Micronaut, MicroProfile, Vert.x, and others.
These applications are packaged into archives with the .jar extension (JAR files).
Spring applications that use Spring Cloud middleware modules
The microservice architectural style is an approach to developing a single application as a suite of small services. Each service runs in its own process and communicates by using lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and are independently deployable by fully automated deployment machinery. There's a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. Such services are frequently built with frameworks such as Spring Cloud.
These services are packaged into multiple applications with the .jar extension (JAR files).
Java EE applications
Java EE applications (also referred to as J2EE applications or, more recently, Jakarta EE applications) can contain some, all, or none of the elements of web applications. These applications can also contain and consume many more components as defined by the Jakarta EE specification.
Java EE applications can be packaged as archives with the .ear extension (EAR files) or as archives with the .war extension (WAR files).
Java EE applications must be deployed onto Java EE-compliant application servers (such as Oracle WebLogic Server, IBM WebSphere, JBoss EAP, GlassFish, Payara, and others).
Applications that rely only on features provided by the Java EE specification (that is, app-server-independent applications) can be migrated from one compliant application server onto another. If your application is dependent on a specific application server (app-server-dependent), you may need to select an Azure service destination that permits you to host that application server.
Web applications
Web applications run inside a Servlet container. Some of these applications use servlet APIs directly, while many use other frameworks that encapsulate servlet APIs, such as Apache Struts, Spring MVC, JavaServer Faces (JSF), and others.
Web applications are packaged into archives with the .war extension (WAR files).
Batch / scheduled jobs
Some applications are intended to run briefly, execute a particular workload, and then exit rather than wait for requests or user input. Sometimes such jobs need to run once or at regular, scheduled intervals. On premises, such jobs are often invoked from a server's crontab.
These applications are packaged into archives with the .jar extension (JAR files).
Note
If your application uses a scheduler (such as Spring Batch or Quartz) to run scheduled tasks, we strongly recommend that you factor such tasks to run outside of the application. If your application scales to multiple instances in the cloud, the same job will run more than once. Furthermore, if your scheduling mechanism uses the host's local time zone, you may experience undesirable behavior when scaling your application across regions.
Selecting the target Azure service destination
The following sections show you which service destinations meet your application requirements, and what responsibilities they involve.
Hosting options grid
Use the following grid to identify potential destinations for your application type. As you can see, Azure Kubernetes Service (AKS) and Azure Virtual Machines support all application types, but they require your team to take on more responsibilities, as shown in the next section.
| Destination → Application type ↓ |
App Service Java SE |
App Service Tomcat |
App Service JBoss EAP |
Azure Spring Apps |
Azure Container Apps | AKS | Virtual Machines |
|---|---|---|---|---|---|---|---|
| Spring Boot / JAR applications | ✔ | ||||||
| Spring Cloud applications | ✔ | ✔ | ✔ | ✔ | |||
| Web applications | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | |
| Java EE applications | ✔ | ✔ | ✔ | ||||
| Commercial application servers (such as Oracle WebLogic Server or IBM WebSphere) |
✔ | ✔ | ✔ | ||||
| Long-term persistence on local filesystem | ✔ | ✔ | ✔ | ✔ | ✔ | ||
| Application server-level clustering | ✔ | ✔ | ✔ | ||||
| Batch / scheduled jobs | ✔ | ✔ | ✔ | ✔ | |||
| VNet Integration/Hybrid Connectivity | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Azure region availability | Details | Details | Details | Details | Details | Details | Details |
Ongoing responsibility grid
Use the following grid to understand the responsibility each destination places on your team following migration.
Tasks indicated with 
are managed entirely or mostly by Azure. Your team is responsible on a continual basis for the tasks indicated with 👉. We recommend implementing a robust, highly automated process for fulfilling all such responsibilities.
Note
This isn't an exhaustive list of responsibilities.
| Destination → Task ↓ |
App Service |
Azure Spring Apps |
Azure Container Apps |
AKS | Virtual Machines |
|---|---|---|---|---|---|
| Updating libraries (including vulnerability remediation) |
👉 | 👉 | 👉 | 👉 | 👉 |
| Updating the application server (including vulnerability remediation) |
|
|
👉 | 👉 | 👉 |
| Updating the Java Runtime (including vulnerability remediation) |
|
|
👉 | 👉 | 👉 |
| Triggering Kubernetes updates (performed by Azure with a manual trigger) |
N/A | |
|
👉 | N/A |
| Disaster Recovery | |
|
👉 | 👉 | |
| Reconciling non-backward-compatible Kubernetes API changes | N/A | |
👉 | 👉 | N/A |
| Updating container base image (including vulnerability remediation) |
N/A | |
👉 | 👉 | N/A |
| Updating the operating system (including vulnerability remediation) |
|
|
|
1 |
👉 |
| Detecting and restarting failed instances | |
|
|
|
👉 |
| Implementing draining and rolling restart for updates | |
|
|
|
👉 |
| Infrastructure management | |
|
👉 | 👉 | 👉 |
| Monitoring and alert management | 👉 | 👉 | 👉 | 👉 |
1 Some security updates might require node reboots, which aren't done automatically. For more information, see Apply security and kernel updates to Linux nodes in Azure Kubernetes Service (AKS).
If you deploy the servlet container (such as Spring Boot) as part of your application, you should consider it a library and, as such, it's always your responsibility.
Ensuring on-premises connectivity
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.
You should complete this effort before you start any migration.
Inventory current capacity and resource usage
Document the hardware of the current production server(s) plus the average and peak request counts and resource usage. You'll need this information to provision resources in the service destination.
Migration guidance
Use the following grids to find migration guidance by application type and targeted Azure service destination.
Java applications
Use the rows below to find your Java application type and the columns to find the Azure service destination that will host your application.
If you'd like to migrate a JBoss EAP app to Tomcat on App Service, first convert the Java EE app to Java Web Apps (servlets) running on Tomcat, then follow the guidance indicated below.
If you'd like to migrate a Web app on Tomcat to Azure Spring Apps, first convert the app into Spring Cloud applications, then follow the guidance indicated below.
| Destination → Application type ↓ |
App Service Java SE |
App Service Tomcat |
App Service JBoss EAP |
Azure Container Apps |
Azure Spring Apps |
AKS | Virtual Machines |
|---|---|---|---|---|---|---|---|
| Spring Boot / JAR applications |
N/A | N/A | N/A | N/A | guidance | N/A | N/A |
| Spring Cloud / applications |
N/A | N/A | N/A | N/A | guidance | guidance planned |
guidance planned |
| Web applications on Tomcat |
N/A | guidance | N/A | guidance | guidance | guidance | guidance planned |
Java EE applications
Use the rows below to find your Java EE application type running on a specific app server. Use the columns to find the Azure service destination that will host your application.
| Destination → App server ↓ |
App Service Java SE |
App Service Tomcat |
App Service JBoss EAP |
Azure Container Apps |
Azure Spring Apps |
AKS | Virtual Machines |
|---|---|---|---|---|---|---|---|
| WildFly / JBoss AS |
N/A | N/A | guidance | N/A | N/A | guidance | guidance planned |
| Oracle WebLogic Server | N/A | N/A | guidance | N/A | N/A | guidance | guidance |
| IBM WebSphere | N/A | N/A | guidance | N/A | N/A | guidance | guidance planned |
| Red Hat JBoss EAP | N/A | N/A | guidance | N/A | N/A | guidance | guidance |
See also
Feedback
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback.
Submit and view feedback for