Migrate Azure Spring Apps projects to Azure Container Apps
- Dominant language
- Go
- Stars
- 569
- Forks
- 364
- Avg merge
- 2d 19h
- Merged PRs (30d)
- 136
Description
Add Azure Spring Apps migration support to the `azure.springboot` extension. An existing Spring Boot project configured for Azure Spring Apps should be recognized by the extension and translated into an equivalent Azure Container Apps deployment using the standard `azd init` and `azd up` workflows.
Azure Spring Apps retires on March 31, 2028, and Microsoft recommends Azure Container Apps or AKS as replacement services. This issue covers the extension-owned path to Azure Container Apps. The extension should preserve application behavior where Container Apps has a direct equivalent, identify features that require a decision, and stop before deployment when it cannot produce a safe migration.
We need to:
- Implement all Azure Spring Apps migration behavior in `cli/azd/extensions/azure.springboot/`.
- Detect Azure Spring Apps configuration from supported project and deployment artifacts.
- Identify the Azure Spring Apps plan and features used by the application when that information is available.
- Translate each Azure Spring Apps application into the existing Spring Boot project model.
- Use Azure Container Apps as the migration destination.
- Map supported Azure Spring Apps concepts to Container Apps equivalents, including:
- Service instances to Container Apps environments
- Applications to container apps
- Deployments to revisions
- Environment variables and application settings
- Managed identities and role assignments
- Custom domains and certificates
- Health probes
- Scaling configuration
- Log and metric collection
- Config Server for Spring
- Eureka Server for Spring
- Gateway for Spring
- Admin for Spring
- Reuse the existing Container Apps deployment and managed Spring component implementations rather than creating a separate migration deployment path.
- Preserve the application’s Maven or Gradle build and packaging behavior.
- Preserve explicit user configuration over inferred migration settings.
- Identify Azure Spring Apps features with no direct Container Apps equivalent.
- Classify each discovered feature as:
- Automatically translated
- Requires explicit configuration
- Unsupported
- Explain each translation and identify its source in the existing Azure Spring Apps configuration.
- Stop before provisioning when an unsupported feature could change application behavior, security, availability, networking, or data access.
- Provide actionable guidance for each migration blocker.
- Produce deterministic project, infrastructure, and configuration output for the same source project and extension version.
- Support materializing the translated azd project and infrastructure so the developer can inspect and modify the result before deployment.
- Ensure the materialized result represents exactly what the extension would provision and deploy.
- Add fixtures representing Azure Spring Apps Basic, Standard, and Enterprise application configurations.
- Add tests covering single and multiple applications, managed components, custom domains, certificates, identity, networking, scaling, unsupported Tanzu components, and partial configuration.
- Add end-to-end coverage that migrates a representative project to Azure Container Apps through `azd init` and `azd up`.
- Verify that the resulting application uses managed identity and does not depend on credentials copied from Azure Spring Apps.
- Verify that repeated `azd up` operations are idempotent.
- Document supported migration sources, translated features, unsupported features, prerequisites, and known limitations in `cli/azd/extensions/azure.springboot/README.md`.
- Link this issue as blocked by the Spring Boot project detection, project translation, Azure Container Apps deployment, configuration mapping, managed Spring components, and end-to-end validation issues.
## Boundaries
- Do not add Spring-specific commands or verbs.
- Do not add an `azd spring` command namespace.
- Do not add a separate migration command.
- Do not modify azd core behavior.
- Do not modify or extend the Azure CLI `spring` migration tooling.
- Do not provision new Azure Spring Apps resources.
- Do not deploy applications back to Azure Spring Apps.
- Do not modify or delete the source Azure Spring Apps environment.
- Do not perform an in-place production cutover.
- Do not change DNS, redirect production traffic, or remove source resources.
- Do not silently approximate unsupported Azure Spring Apps or Tanzu capabilities.
- Do not copy passwords, connection strings, access keys, certificates, or other credentials from the source environment.
- Do not modify Maven or Gradle build files, Java source, or Spring configuration.
- Do not implement AKS migration in this issue.
- Do not add application modernization, Java upgrades, Spring Boot upgrades, or source-code transformation.
- If migration requires a missing core or extension-framework capability, file the gap against the appropriate core epic rather than adding a workaround, parallel command, or core change in this issue.
Contributor guide
Research direction
Start by reading the existing implementation and tests under cli/azd/extensions/azure.springboot/, plus the extension README and the issues for project detection, translation, Container Apps deployment, configuration mapping, managed Spring components, and end-to-end validation. Done means the extension materializes deterministic Azure Container Apps output, blocks unsafe unsupported migrations, passes the listed fixtures and end-to-end coverage, and documents supported features and limitations.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure, go, spring-boot
- Domain
- cloud, devops, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100