Move from AKS to Azure Container Apps without betting production on it
Azure Kubernetes Service (AKS) gives you full control of the cluster and charges you for every hour of it. Azure Container Apps (ACA) runs your containers on Kubernetes you never see, scales to zero, and bills for what actually runs. Winmill assesses your AKS workloads, picks the services that should move, and migrates them one at a time while the cluster keeps serving traffic.
- Enterprise software since 1994
- Microsoft Cloud Solution Provider
- CISSP and CISA certified security leadership
- Fortune 500 clients across North America
The cluster becomes the job
Most teams did not choose Kubernetes for its own sake. They chose it to run containers. After a year on AKS, the work that grows is the work around the cluster, not the application.
Node pools need constant tuning
Sizing, scaling rules, and spot versus reserved decisions that have to be revisited every time the traffic pattern shifts.
Upgrades need a project plan
Every cluster version upgrade has to be scheduled, tested against your workloads, and rolled back if it breaks something.
Overhead grows with every service
Each new microservice adds manifests, ingress rules, and monitoring configuration that someone owns.
You pay for idle capacity
Node pool virtual machines bill by the hour whether your workloads use ten percent of them or all of them.
Container Apps shifts the complexity. It does not erase it.
ACA runs on Kubernetes underneath, with KEDA for scaling and Dapr for service communication. You stop managing the cluster and start managing the application. Both halves of that sentence matter.
You deploy containers, not YAML
The platform handles scheduling, node management, and version upgrades. Your team ships images and revisions.
Scale to zero, pay per replica
Billing follows the vCPU and memory that running replicas consume. A service with no traffic costs nothing while it waits.
HTTP ingress without an ingress controller
Public and internal endpoints, TLS, and traffic splitting between revisions come with the platform.
Stateless is the native pattern
ACA is built for stateless workloads. Persistent storage works through Azure Files, and it is not what the platform is designed around.
No custom operators or admission controllers
If your platform depends on cluster-level extensions, those dependencies do not come along. They have to be redesigned or the workload stays on AKS.
Observability still has to be configured
Azure Monitor and Log Analytics integrate directly, and your applications need to write structured logs to stdout and stderr for that to be useful.
What should move, and what should stay
The assessment is workload by workload. Most estates end up with both platforms for a while, and some keep both on purpose.
Strong candidates for Container Apps
- API services, background workers, and event processors.
- Workloads with variable or unpredictable traffic, where scale to zero pays for itself.
- Services you would rather bill per use than hold reserved capacity for.
- Teams that spend more time on cluster operations than on the application.
Workloads that belong on AKS
- Applications with strict custom networking requirements.
- Workloads running custom admission controllers or Kubernetes operators.
- Services that depend on node-level configuration or GPU access.
- Platforms where the Kubernetes control plane is itself a dependency.
One service at a time, with the cluster still serving
No cutover weekend. Each service moves through the same four steps, and production traffic stays on AKS until the Container Apps version has proven itself.
1. Assess and pick the first candidate
We inventory the AKS workloads, classify each one against the fit criteria above, and start with a stateless service that carries real traffic but not the whole business.
2. Build the parallel environment
The Container Apps environment is defined as infrastructure as code in your Azure tenancy, with managed identity, private endpoints, and VNet integration where compliance requires them. Your pipeline in GitHub Actions or Azure DevOps deploys to both targets.
3. Shift traffic gradually
Azure Front Door or Traffic Manager routes a small share of traffic to Container Apps, then more, while Azure Monitor and Log Analytics show both sides. Rollback is a routing change.
4. Decommission and repeat
Once the service is stable on ACA, the AKS deployment comes down and the next candidate starts. Node pools shrink as workloads leave, and the cluster retires when nothing that needs it remains.
The cost answer depends on your traffic shape
Container Apps is not automatically cheaper. It is cheaper for workloads that idle, and it can cost more for workloads that run flat out all day. We model both before anything moves.
Two different billing models
AKS bills for the virtual machines in your node pools regardless of how much capacity your workloads consume, and it needs at least one system node pool running at all times. Container Apps bills for the vCPU and memory of running replicas, with no charge for idle replicas when scale to zero is configured.
Variable traffic favors Container Apps
A service that runs at ten percent utilization for eighteen hours a day and at full capacity for six costs far less on Container Apps, because the idle hours cost nothing.
Sustained load can favor AKS
A right-sized cluster running close to capacity around the clock can reach competitive per-request economics. In that case we say so, and the workload stays.
Our engineers on AKS and Container Apps
Azure Container Apps migration
What changes, what does not, and a practical path off AKS.
Read the postACA vs AKS cost
How the two billing models behave under sustained and variable load.
Read the postServerless Kubernetes on Azure
Where Container Apps fits between App Service, Functions, and a full cluster.
Read the postServerless GPUs for AI
Running inference workloads on Container Apps instead of a GPU node pool.
Read the postFrequently asked questions
Is Azure Container Apps a replacement for AKS?
For stateless services, background workers, and event processors, yes, and it removes the cluster operations work. For workloads that need custom operators, custom networking, node-level configuration, or GPU access, no. Most estates run both for a period, and some keep both by design.
Will migrating to Container Apps lower our Azure bill?
It depends on the traffic shape. Workloads that idle for hours a day cost less on Container Apps because scale to zero removes the idle spend. Workloads that run near capacity around the clock can be as cheap or cheaper on a right-sized AKS cluster. We model your actual workloads before recommending a move.
Can we migrate without downtime?
Yes. Each service runs in parallel on both platforms, traffic shifts gradually through Azure Front Door or Traffic Manager, and rollback is a routing change. The AKS deployment comes down only after the Container Apps version has held production traffic.
Do we need to change our CI/CD pipeline?
GitHub Actions and Azure DevOps both deploy to Container Apps natively. The pipeline gains a second deployment target during the migration and loses the AKS target when a service finishes moving.
What about compliance and private networking?
Container Apps supports managed identity, private endpoints, and VNet integration. Environments are defined as infrastructure as code in your own Azure tenancy, so your security team reviews the same definitions we deploy.
Who does the work, and whose environment is it?
Winmill’s Cloud Engineering team does the assessment, the environment build, and the migration in your Azure tenancy, with code in repositories under your own accounts. When the engagement ends, your team owns everything, or our Data Center and IT Support practice can run it for you.
Bring us your AKS workload list
We will tell you which services should move to Container Apps, which should stay, and what the first migration looks like. Straight answers, and we respond within one business day.