How to Fix Azure Spring Apps Migration Issues
Why This Is Happening
If you've landed here, you're probably staring at a retirement notice in the Azure portal and wondering what to do next. Maybe your CI/CD pipeline just threw an error, or your team lead forwarded a Microsoft email about Azure Spring Apps deprecation and said "handle this." I've seen this exact situation play out across dozens of enterprise Java shops , and the confusion is completely understandable.
Here's the short version of what happened: Microsoft announced that the Azure Spring Apps Basic, Standard, and Enterprise plans entered a retirement period on March 17, 2025. The Standard consumption and dedicated plan actually went further , it retired on September 30, 2024, with a complete shutdown by the end of March 2025. If you're still running workloads on any of these plans and haven't started your Azure Spring Apps migration, you're in a time-sensitive situation.
On top of the plan retirement, there's a second layer of deprecation that catches a lot of Enterprise plan users off guard: VMware Tanzu components. After Broadcom's acquisition of VMware, several commercial Tanzu components bundled with the Azure Spring Apps Enterprise plan hit end-of-life according to Broadcom's product lifecycle. Three specific components are affected:
- Application Configuration Service for VMware Tanzu, used by thousands of teams for centralized config management
- Application Live View for VMware Tanzu, the runtime debugging and monitoring component
- Application Accelerator for VMware Tanzu, the project scaffolding tool
All three hit end of support on August 31, 2025. You can still technically provision these deprecated components and they'll keep running for now, but Microsoft has explicitly stated they're no longer providing updates or customer support for them. Worse, Microsoft reserves the right to forcibly remove these components if a critical security vulnerability is detected, with only early notification before action. That's not a risk worth taking for production workloads.
The error messages and warnings in the Azure portal tend to be vague, you might see generic deprecation banners without clear guidance on what to actually do. That's what this guide is for. We'll walk through each migration path, what replaces each deprecated component, and the specific steps to execute the Azure Spring Apps migration without breaking your running applications.
The Quick Fix, Try This First
Before diving into full migration steps, you need to know which situation applies to you. The fix path is completely different depending on which components you're running.
Identify your plan type first. In the Azure portal, navigate to your Azure Spring Apps instance. In the Overview blade, look at the "Plan" field. This tells you whether you're on Basic, Standard, Enterprise, or the consumption/dedicated plan, and that determines everything that follows.
If you're on the Standard consumption and dedicated plan: This plan already reached full shutdown by end of March 2025. If you're actively using it, you need to migrate immediately to Azure Container Apps, that's Microsoft's recommended destination for this specific plan. There's no in-place fix here; you're doing a full workload migration.
If you're on the Basic, Standard, or Enterprise plan: Your immediate priority is the Tanzu component deprecation. Go to your Azure Spring Apps Enterprise instance in the portal and check which Tanzu components you have enabled. Navigate to each component section in the left menu and look at the provisioning state. Make a list, this becomes your migration checklist.
For Application Configuration Service specifically, the fastest path forward is migrating to managed Spring Cloud Config Server within the same Enterprise plan instance. This is the lowest-disruption option because you're staying in the same Azure Spring Apps environment, you're just swapping out how configuration is fetched. Microsoft provides this as a managed service in the Enterprise plan, and once provisioned, it behaves very similarly to what you're used to with ACS.
The key deadline to tattoo on your calendar: August 31, 2025. That's when the Tanzu components lose all support. Migrate and disable deprecated components before that date to avoid disruptions and potential unpatched security vulnerabilities sitting in your production environment.
This is your starting point for migrating away from Application Configuration Service. You can't configure what isn't provisioned, so enabling Spring Cloud Config Server is the first physical action to take.
In the Azure portal, navigate to your Azure Spring Apps Enterprise plan instance. In the left-hand navigation menu, scroll down and select Spring Cloud Config Server. You'll land on the Config Server management page. Click the Manage button, this shows you the current enabled/disabled state.
If Spring Cloud Config Server isn't already enabled, toggle it on and then hit Apply to save. The provisioning process runs asynchronously, so don't close the tab immediately. After a minute or two, refresh the page and navigate to the Overview tab within the Config Server section. You're looking for the Provisioning State field to read "Succeeded", that's your green light to move on.
If provisioning fails, the most common cause I've seen is insufficient permissions on the service principal or managed identity associated with your Azure Spring Apps instance. Check that the instance has at minimum Contributor role on the resource group. A quick way to verify is to open the Azure Cloud Shell and run:
az spring config-server show \
--name <your-spring-apps-instance> \
--resource-group <your-resource-group>A successful provisioning response shows "provisioningState": "Succeeded" in the JSON output. If you see "Failed", the error details section in that JSON will tell you the specific reason, and it's almost always a permission or quota issue.
This is the most technically detailed step in the Azure Spring Apps migration, and where most teams trip up. Application Configuration Service and Spring Cloud Config Server handle repositories differently, so you can't just copy-paste settings blindly.
In your Azure Spring Apps instance, go back to Spring Cloud Config Server and click the Settings tab. This is where you'll map your ACS repository configurations over.
Here's the decision tree that Microsoft's official guidance is getting at:
- If you had only one repository in ACS: Map it to the default repository in Spring Cloud Config Server. Leave the name and patterns fields blank, the default repository doesn't need them.
- If you had multiple repositories in ACS: Pick one as the default repository (typically your most broadly applicable config repo), then add the remaining ones as additional repositories. Each additional repository needs a name and pattern configuration to tell Config Server which apps should use it.
For each repository you're migrating, transfer these properties exactly: URI, label (branch name), search paths, name, and any authentication credentials (SSH keys or username/password for private repos). Missing any one of these will cause apps to fail to fetch configuration at startup, usually with a Could not locate PropertySource error in the application logs.
After entering all settings, hit the Validate button before applying. This triggers a connectivity test against your Git repository. If validation fails, double-check the URI format and confirm your credentials are still valid, Git tokens expire. Once validation shows success, click Apply.
Provisioning and configuring the Config Server is only half the work. Your individual applications won't use it automatically, you need to explicitly bind them.
Still in the Spring Cloud Config Server section, navigate to the App binding tab. You'll see a list of all apps registered in your Azure Spring Apps instance. Click Bind app and select all the applications that previously used Application Configuration Service for their configuration. Don't guess here, cross-reference your app list with whatever ACS patterns you had configured.
Now here's an important detail that the docs explain in a way that can easily be missed: Spring Cloud Config Server uses your Azure Spring Apps app name as the key to match configuration files in your Git repository. It looks for a configuration file in your Git repo whose filename matches the app name exactly. So if your app is named payment-service in Azure Spring Apps, Config Server will look for payment-service.yml or payment-service.properties in your configured Git repository.
If your app names and config file names already match, great, no code changes needed on this front. If they don't match, you have two choices: rename the config files in your Git repo to match the app names, or create new apps in Azure Spring Apps with names that match the config filenames. The second option is obviously more disruptive, so check your naming alignment early.
After binding, watch the binding status in the portal. Each app should show a bound status. If an app shows an error status after binding, pull its logs immediately, the startup failure message will contain the Config Server connection error.
This step is where the Azure Spring Apps migration touches your actual application code. Application Configuration Service used a different mechanism to inject configuration into apps, it didn't require any Spring Cloud Config client dependency in your application. Spring Cloud Config Server does. So if you're migrating from ACS, your apps need a code change before they'll work correctly.
Open your project's pom.xml (Maven) or build.gradle (Gradle) and add the Spring Cloud Config starter dependency:
<!-- Maven: add to pom.xml -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-config</artifactId>
</dependency>Make sure your Spring Cloud BOM version is compatible with your Spring Boot version. Mismatched BOM versions are a very common source of ClassNotFoundException errors after migration.
Next, the profile configuration. In ACS, you specified profiles as patterns at the Azure Spring Apps deployment level, a portal-side configuration. In Spring Cloud Config Server, the profile is configured inside the application's own source code. Open your bootstrap.yml or application.yml (whichever your app uses) and add the profile configuration:
spring:
cloud:
config:
profile: dev # or prod, staging, whatever matches your environmentOne critical thing to watch: do not set spring.application.name in your application code. Azure Spring Apps automatically provides the application name, and if you hardcode a different value in your source, Config Server will use that hardcoded name to look up config files, which will likely be wrong and cause configuration lookup failures at startup.
With the Spring Cloud Config Server provisioned, configured, apps bound, and code updated, you're ready to redeploy. There's a specific parameter you need to include in your deploy command, and this is the step most people forget, causing their apps to silently keep using the old ACS configuration even after the migration.
Use the Azure CLI to redeploy. The --config-file-patterns '""' parameter is the critical piece, it explicitly clears out the ACS config file patterns that were previously associated with the deployment, signaling to Azure Spring Apps that this app should now rely on Spring Cloud Config Server instead:
az spring app deploy \
--name <your-app-name> \
--resource-group <your-resource-group> \
--service <your-spring-apps-instance> \
--artifact-path <path-to-your-jar-or-war> \
--config-file-patterns '""'After deployment, watch the app logs in real time to verify Config Server connectivity. Open the Log streaming feature in the Azure portal for your app, or tail the logs via CLI:
az spring app logs \
--name <your-app-name> \
--service <your-spring-apps-instance> \
--resource-group <your-resource-group> \
--followA successful startup will show log lines referencing Config Server and the repository it fetched from, something like Fetching config from server at: https://... and Located property source. If you see Could not locate PropertySource or the app starts but environment-specific properties are missing, go back and verify the app name matches the config file name in your Git repo, and that the profile is set correctly in bootstrap.yml.
Advanced Troubleshooting
Some Azure Spring Apps migration scenarios are messier than the happy path. Here's what to do when the standard steps don't get you there.
Migrating Application Live View
If you relied on Application Live View for runtime visibility into your Spring Boot applications, things like request mappings, environment variables, and thread dumps accessible through a web UI, you'll need to replace it with Spring Boot Admin. Unlike the ACS-to-Config-Server migration, there's no managed hosted replacement; you need to set up Spring Boot Admin yourself as a service within your Azure Spring Apps instance.
The setup involves deploying a Spring Boot Admin server application as a new app in your Azure Spring Apps environment, then configuring your existing apps to register with it. Each client app needs the Spring Boot Admin client dependency and a pointer to the Admin server URL. This is a more involved migration than the Config Server swap, but Spring Boot Admin is mature, well-documented open-source software and covers the core use cases of Application Live View.
Application Accelerator Has No Replacement
If your team used Application Accelerator for project scaffolding, generating new microservice projects from templates, there is no managed Azure replacement. Microsoft's official guidance is explicit on this. Your alternatives are community solutions like Spring Initializr, custom Yeoman generators, or Azure DevOps Pipeline templates to replicate the scaffolding behavior. This only affects new project creation, not running applications, so it's lower urgency than the Config or Live View migrations.
Enterprise Plan Migration to Azure Container Apps or AKS
For teams migrating off Azure Spring Apps entirely rather than just swapping components, the two recommended destinations are Azure Container Apps and Azure Kubernetes Service. The choice depends on your team's Kubernetes expertise: ACA is the simpler managed path, AKS gives you full control but requires Kubernetes operational knowledge. Both paths involve containerizing your Spring Boot applications, if you're not already building container images, you'll need a containerization step in your pipeline. The Azure CLI's az containerapp commands are your starting point for ACA; for AKS, look at the Azure Spring Apps to AKS migration guide in Microsoft's documentation.
Diagnosing Config Fetch Failures with Event Logs
When apps fail to start after migration, Azure Spring Apps surfaces errors in the Diagnostic Settings logs. Enable the ApplicationConsole log category and route it to a Log Analytics workspace. Then query:
AppPlatformLogsforSpring
| where AppName == "<your-app-name>"
| where Log contains "Config"
| order by TimeGenerated desc
| take 50This surfaces Config Server communication errors that don't always appear in the basic log streaming view, particularly SSL certificate issues with private Git repos and authentication failures on token rotation.
Prevention & Best Practices
If you're in the middle of a migration crisis right now, "how do I prevent this next time" might feel academic, but these practices genuinely keep you ahead of the next deprecation wave, and Azure has a pattern of announcing these with 12-24 month runways that teams consistently underestimate.
Subscribe to Azure Service Health alerts for your specific resources. The Azure Spring Apps retirement wasn't a surprise, Microsoft sent notifications through Service Health months in advance. But if you're not watching the right channels, those notifications disappear into your Azure portal notifications feed and get lost. Set up Service Health alerts that email your team directly when planned maintenance, health advisories, or retirement notices affect your subscription's specific services. This takes ten minutes to configure and gives you maximum lead time on future deprecations.
Avoid tight coupling to managed platform components. One of the lessons from the Tanzu component deprecations is that commercial bundled components, especially ones from third-party vendors like VMware/Broadcom embedded into Azure services, carry an additional lifecycle risk on top of Azure's own roadmap. Where open-source equivalents exist (like Spring Boot Admin instead of Application Live View), the open-source path often provides more migration flexibility.
Document your configuration dependencies explicitly. If you can't answer "what would break if our configuration service disappeared tomorrow?", your team is in a fragile state. Maintain a living document that maps each microservice to its configuration source, profile, and any service bindings. This makes migration scoping a two-minute exercise instead of a two-day archaeology project.
Run migration tests in a non-production environment first. Azure Spring Apps environments are cheap to spin up. Clone your Enterprise plan instance into a staging environment specifically for migration validation. Complete the full Config Server migration there, verify all apps start and serve traffic correctly, then replicate to production. The cost of a test environment for a few weeks is trivial compared to a production outage during a rushed migration.
- Set up Azure Service Health email alerts for all services in your subscription, catches retirement notices before they become emergencies
- Add
--config-file-patterns '""'to your deployment pipeline templates now so it's ready when you redeploy migrated apps - Audit your Git repo config file naming against your Azure Spring Apps app names before starting the migration, naming mismatches are the #1 cause of post-migration startup failures
- Rotate any Git credentials used by Config Server on a schedule and store them in Azure Key Vault, not hardcoded in portal settings
Frequently Asked Questions
Can I still use Azure Spring Apps after the March 2025 retirement date?
The Basic, Standard, and Enterprise plan instances that already existed were placed in a retirement period starting March 17, 2025, they didn't simply shut off. But being in a retirement period means Microsoft is not accepting new feature requests, and support is limited. More importantly, you can't create new Azure Spring Apps instances on the retired plans. If you're running existing workloads and haven't received shutdown notices yet, check your Azure Service Health and email notifications, Microsoft sends advance warning before forced decommissions. The safest posture is to treat retirement as "migrate now" regardless of whether the lights are still on.
What happens if I don't migrate off Application Configuration Service by August 31, 2025?
Your applications will likely keep running past August 31, 2025, because deprecated components continue to operate even after end-of-support. The serious risk is security: if Microsoft discovers a critical vulnerability in the deprecated Tanzu components after that date, they reserve the right to remove the component with only early notification, potentially taking down your running apps on short notice. You also lose any technical support for ACS-related issues. Given that Spring Cloud Config Server is a well-supported drop-in replacement available in the same Enterprise plan, there's no good reason to stay on the deprecated path.
My app name doesn't match my Git config file name, do I have to rename one of them?
You have two options. The less disruptive one is to add a new configuration file to your Git repository named after the Azure Spring Apps app, for example, if your app is called inventory-api, add inventory-api.yml or inventory-api.properties to the repo alongside your existing config files. The other option is creating a new app in Azure Spring Apps with a name matching the existing config filename, then deploying to that new app. Renaming running apps is risky because it breaks existing service discovery registrations, so the Git repo approach is usually cleaner for production systems.
Do I need to set spring.application.name in my app for Config Server to work?
No, and actually, you should explicitly avoid setting spring.application.name in your application code when running in Azure Spring Apps. The platform automatically injects the app name from the Azure Spring Apps deployment metadata, and Spring Cloud Config Server uses that injected name to match configuration files in your Git repository. If you hardcode spring.application.name in your source code, you'll override the platform-injected value and Config Server will start looking for config files under a potentially wrong name, causing Could not locate PropertySource failures at startup.
Should I migrate to Azure Container Apps or Azure Kubernetes Service?
For most teams migrating Spring Boot microservices off Azure Spring Apps, Azure Container Apps is the lower-friction path. It's a fully managed container runtime that handles scaling, networking, and ingress without requiring Kubernetes operational expertise. Azure Kubernetes Service is the right choice if your team already runs Kubernetes clusters, needs fine-grained control over networking and storage, or has compliance requirements around node-level access. If your team is primarily composed of Spring developers who don't want to become Kubernetes administrators, start with Azure Container Apps, you can always move to AKS later if you hit capability limits.
Can I validate my Spring Cloud Config Server configuration without redeploying apps?
Yes, after entering your repository settings in the Spring Cloud Config Server Settings tab in the Azure portal, use the built-in Validate button before hitting Apply. This triggers a live connectivity test against your configured Git repository, checking URI reachability and credential authentication. It won't test app-to-Config-Server connectivity, but it catches the most common setup errors: typos in the repository URI, expired authentication tokens, and SSH key mismatches. If validation succeeds but apps still fail to fetch config after deployment, the issue is almost always in the app-side configuration, the profile setting in bootstrap.yml or the app name / config file name mismatch.