How to Fix Java Migration to Azure

The very first step of any successful Java migration to Azure is knowing exactly what you're migrating. This isn't just about the file extension, it's about the runtime requirements embedded in the application itself.

Open your build configuration (pom.xml for Maven, build.gradle for Gradle) and look at these three things: the packaging type, the framework dependencies, and any application server APIs being imported. Here's a quick reference for what each signals:

<!-- Maven: check the packaging element -->
<packaging>jar</packaging>   <!-- Spring Boot / JAR app -->
<packaging>war</packaging>   <!-- Web app or Java EE (WAR) -->
<packaging>ear</packaging>   <!-- Full Java EE (EAR) -->

Next, check your imports. If you see import javax.ejb.*, import javax.persistence.*, or import javax.jms.*, you have Java EE dependencies that require a Jakarta EE-compliant runtime. If you see import org.springframework.boot.* and an embedded server in your dependencies (like spring-boot-starter-web), you have a self-contained Spring Boot application that runs fine on App Service Java SE.

For Spring Cloud applications, look for dependencies like spring-cloud-starter-config, spring-cloud-starter-eureka, or spring-cloud-gateway. These microservice-oriented apps are generally well-suited for Azure Container Apps, which provides built-in service discovery and managed ingress, features that replace what Spring Cloud Config Server and Eureka do on-premises.

Document your findings in a simple spreadsheet: application name, packaging type, framework, application server dependency (yes/no), and batch jobs included (yes/no). This table becomes the source of truth for every destination decision that follows. If you're migrating more than one application, do this for each one separately, a multi-tier system often has components that need different Azure destinations.

When this step is done correctly, you'll see the right column to target in the hosting options grid immediately. If everything aligns to App Service Tomcat, for instance, you can rule out the complexity of AKS entirely.

After you've done the manual identification above, back it up with the Azure Migrate application and code assessment tool. This is Microsoft's official static analysis utility designed specifically for Java on Azure migration scenarios, and it catches things that manual review misses, especially in large, legacy codebases where no single person knows every corner of the application.

To run it, you'll need the AppCAT (Application and Code Assessment Tool) CLI, which is part of the Azure Migrate toolset. You can also access this capability through GitHub Copilot's AppModernization agent if your team is already on Copilot Enterprise. The CLI approach is more thorough for offline or enterprise environments.

Once installed, run it against your source directory:

# Point AppCAT at your source tree
appcat analyze --source ./my-java-app \
               --target azure-appservice \
               --output ./assessment-report

The report will categorize findings into three buckets: mandatory changes (things that will break in the cloud with certainty), optional changes (things that work but aren't cloud-native), and information only (things to be aware of but require no action). Pay close attention to the mandatory section first.

Common mandatory findings I see in enterprise Java codebases include: file system writes to local paths (the Azure App Service sandbox doesn't give you persistent local disk the way an on-premises server does), hardcoded IP addresses or machine names in configuration files, use of System.exit() calls in web application code, and JNDI lookups that reference on-premises directory services.

Each finding will include a recommended remediation path. Work through these before attempting any deployment to Azure. Deploying an unmodified app and hoping the errors surface one at a time in production is a painful way to learn what the assessment tool would have told you in 20 minutes.

When the assessment comes back clean on mandatory items, you're ready to move to actual destination configuration.

This is the step where most migrations either succeed or doom themselves. Let me walk through the most common scenarios with concrete guidance on what to pick and what to configure.

Spring Boot JAR applications without Spring Cloud dependencies and without commercial server requirements are the simplest case. Go to Azure App Service, Java SE runtime. In the Azure portal, navigate to App Services → Create → Runtime stack → Java 17 (or whichever version your app targets) → Java SE. This runtime will execute your JAR directly. Your app needs to listen on the port provided by the PORT environment variable, which App Service sets automatically:

# In application.properties or application.yml
server.port=${PORT:8080}

Web applications packaged as WAR files should target App Service Tomcat or App Service JBoss EAP, depending on which servlet container they were built for. Select the matching runtime during App Service creation. If you deploy a Tomcat WAR to a JBoss EAP runtime, the deployment will fail or the app will misbehave, they are not interchangeable.

Java EE applications (EAR or WAR files) with dependencies on commercial servers like Oracle WebLogic or IBM WebSphere need either Azure Virtual Machines running a licensed server image, or AKS with the appropriate container image. Microsoft maintains marketplace images for WebLogic on Azure VMs and provides step-by-step tutorials for both AKS and VM deployments. For WebSphere specifically, the recommended path is WebSphere Application Server to Azure VMs or Azure Red Hat OpenShift, depending on your container strategy.

Spring Cloud microservices have a particularly clean path to Azure Container Apps, which handles service mesh, ingress, and scaling natively. This eliminates the need for a self-managed Spring Cloud Config Server and Eureka registry.

After selecting your destination, verify region availability for the specific App Service tier or VM size you need, not every SKU is available in every region, and enterprise-grade VMs for WebLogic can be constrained in certain geographies.

If your Java application contains any scheduled tasks, anything using Spring Batch, Spring's @Scheduled annotation, Quartz Scheduler, or a plain java.util.Timer, stop right here and deal with this before you deploy anything to Azure. This is the single most frequently ignored migration step, and it causes some of the worst production incidents I've seen.

The problem is straightforward: Azure's managed services (App Service, Container Apps, AKS) are designed to scale horizontally. When demand increases, Azure spins up additional instances of your application. If your batch job fires every night at 2 AM and you have four instances running, it fires four times at 2 AM. If that job is a billing run, a data export, or a database cleanup task, the consequences range from bad to catastrophic.

Microsoft's official guidance is explicit: factor scheduled tasks to run outside of the application. Here's how to do that in practice:

# Option 1: Azure Functions timer trigger (recommended for simple jobs)
# In your function app configuration:
{
  "schedule": "0 0 2 * * *",  // 2 AM daily, CRON format
  "name": "myTimerTrigger",
  "type": "timerTrigger",
  "direction": "in"
}

# Option 2: AKS CronJob for containerized batch workloads
apiVersion: batch/v1
kind: CronJob
metadata:
  name: nightly-billing-run
spec:
  schedule: "0 2 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: billing-job
            image: myregistry.azurecr.io/billing-job:latest

Azure Functions with a Timer trigger is the fastest path for simple scheduled jobs. For heavier batch processing workloads, AKS CronJobs give you full container control. Either way, extract the job logic into its own deployable unit before your main application migration begins.

One more thing: if your batch job currently reads from the application's local timezone, set the timezone explicitly in your Azure deployment. Cloud infrastructure defaults to UTC, and a job that ran at 2 AM local time will run at a completely different clock time unless you configure WEBSITE_TIME_ZONE in App Service settings or TZ in your container environment variables.

With the application type identified, the destination selected, and batch jobs decoupled, the final pre-flight step is getting your configuration right in Azure. This is where a surprising number of deployments stall even after the previous steps go perfectly, the app boots, but it can't talk to its database, can't reach on-premises services, or fails on startup because environment variables aren't set correctly.

Connection strings and app settings should never be hardcoded in your packaged artifact. In Azure App Service, navigate to your app → Configuration → Application settings and enter your database connection string, API keys, and service endpoints there. These are injected as environment variables at runtime. In your Spring Boot app, reference them like this:

# application.properties, reads from environment variables at runtime
spring.datasource.url=${DATABASE_URL}
spring.datasource.username=${DATABASE_USER}
spring.datasource.password=${DATABASE_PASSWORD}

VNet Integration is required if your application needs to reach resources inside a private Azure Virtual Network, common when your database is on Azure SQL with a private endpoint, or when you're connecting to on-premises systems through an ExpressRoute or VPN Gateway. All six Azure destination types (App Service, Container Apps, AKS, and VMs) support VNet Integration, but the setup steps differ per service. For App Service, go to your app → Networking → VNet Integration → Add VNet and select the appropriate subnet. The subnet must be delegated to App Service and must have sufficient address space, Microsoft recommends a /26 or larger subnet for App Service VNet Integration.

Managed Identity is the right way to authenticate your Java app to other Azure services (Key Vault, Storage, SQL Database) without storing credentials anywhere. Enable system-assigned managed identity on your App Service instance under Identity → System assigned → On, then grant that identity the appropriate role on the target resource. In your Java code, use the Azure Identity SDK:

// Azure Identity SDK, no credentials in code
DefaultAzureCredential credential = new DefaultAzureCredentialBuilder().build();
SecretClient secretClient = new SecretClientBuilder()
    .vaultUrl("https://my-keyvault.vault.azure.net/")
    .credential(credential)
    .buildClient();

When the app starts successfully and connects to all its downstream dependencies, check the App Service log stream in the Azure portal under Monitoring → Log stream. A healthy Spring Boot startup should show the Spring banner and "Started [AppName] in X.XXX seconds", if you don't see that, the connection or configuration is still broken and the log will tell you exactly where.