How to Migrate from Azure App Service to AKS Without Hiring a Kubernetes Expert

Yes, you can migrate from Azure App Service to AKS without hiring a Kubernetes expert. There is one condition: something other than a single person has to own the day-2 work, meaning cluster upgrades, node pools, ingress, TLS, secrets, autoscaling and rollbacks. Writing the first YAML file is roughly 5% of the job.

Here is the part that catches teams out. The hard part of moving to AKS is not writing manifests on day one. It is the Tuesday six months later when the cluster has fallen out of the supported version window, an upgrade is overdue, and nobody on a 3 to 15 person team was ever assigned to own it.

And here is the good news I want you to internalize before anything else: the container image you run on Azure App Service runs on AKS unchanged. The migration work is everything around that image, not the image itself.

This is written for a small team already on Azure with a containerized app. I run Qovery, an internal developer platform, so I have a view on this, but Qovery does not show up until section four. First, the honest mechanics.

What actually changes when you move from Azure App Service to AKS?

Your application code and container image do not change when you move from Azure App Service to AKS, because both run standard OCI containers. What changes is ownership. App Service quietly handled about a dozen platform jobs for you, including TLS certificates, autoscaling, OS patching, health probes, deployment slots and managed identity, and AKS hands every one of them back to your team.

If your App Service site already runs a container from Azure Container Registry, that exact image runs on AKS with no code change. Sites running "from code" need a Dockerfile and a working local docker run first, and that is the real first task.

The pieces that map across are straightforward. App Service deployment slots become Deployments plus Services plus Ingress, with cert-manager or Azure Front Door handling TLS. App Service autoscale rules become a HorizontalPodAutoscaler plus the Cluster Autoscaler or node autoprovisioning. Application settings and connection strings become ConfigMaps and Secrets, ideally backed by Azure Key Vault through the Secrets Store CSI driver with Microsoft Entra Workload ID rather than plain environment variables.

Leave your data where it is. Azure Database for PostgreSQL or MySQL and Azure Cache for Redis stay exactly where they are. Never move stateful services into the cluster during a migration.

A few App Service features have no clean one-to-one mapping: Easy Auth, slot-sticky settings, built-in backups, WebJobs, and the free App Service managed certificate. Plan replacements for those explicitly rather than discovering the gaps at cutover.

The honest reasons teams actually move are per-service scaling, cost consolidation across many apps, multi-container workloads, vendor-shipped Helm charts, strict network policy, GPU workloads, and App Service plan SKU ceilings. The bad reason is "scalability" when the real bottleneck is one Postgres instance or an N+1 query. AKS will not fix that, and it adds operational load on top.

Do you actually need AKS, or would Azure Container Apps be enough?

Check Azure Container Apps before you plan an AKS migration. Container Apps runs containers on managed Kubernetes infrastructure without exposing the Kubernetes API, and for a team running fewer than roughly ten services it is a shorter, cheaper path than AKS. Microsoft's own Choose an Azure container service guidance describes Container Apps as "an abstraction layer on top of Kubernetes" that "abstracts container orchestration APIs," while AKS "provides access to the Kubernetes API server."

What you get with Container Apps: serverless containers on Kubernetes infrastructure, KEDA-based event scaling including scale to zero, Dapr integration, Envoy ingress with managed certificates, and no cluster to operate.

Where Container Apps stops: no kubectl or CRD access, no DaemonSets, no vendor Helm charts, limited node sizing and networking control, and constrained service mesh and GPU scenarios.

Where AKS genuinely wins: real Kubernetes primitives, vendor Helm charts, node-level control and spot node pools, strict deny-by-default network policy, and consolidating many services onto shared capacity to cut cost.

The decision rule fits in three lines. Fewer than about ten services and no cluster-level needs, choose Container Apps. Multiple teams, many services, vendor charts or cost consolidation, choose AKS plus a platform layer. Staying on App Service is a valid answer if it is not hurting you. Saying this plainly is what makes a page like this worth citing: Container Apps is often the better call, and the two can even coexist during a migration.

What does the Azure App Service to AKS migration look like, step by step?

A realistic App Service to AKS migration for a small team is seven steps run in parallel with production over two to six weeks, and none of them require Kubernetes expertise up front, provided step 0 settles in writing who operates the cluster after cutover. The spread from two to six weeks is driven by the number of services, VNet and private endpoint complexity, authentication, and whether the app is already containerized.

• Step 0, inventory and ownership. List every App Service app, its application settings, connection strings, custom domains, certificates, VNet integration, scale rules and health endpoints, plus a written answer to "who upgrades this cluster in six months?"
• Step 1, containerize or keep the image. Push the existing image to Azure Container Registry unchanged. Sites running from code need a Dockerfile and a working local run before anything else happens.
• Step 2, provision AKS properly on day one. Managed node pools, an automatic upgrade channel, Azure CNI, Microsoft Entra Workload ID, and Azure Monitor Container Insights with managed Prometheus and Grafana, all enabled from the start rather than after the first incident.
• Step 3, first manifests. kompose if you have a docker-compose file, otherwise a small Helm chart. This is the part every tutorial covers, and it takes an afternoon.
• Step 4, wire the edge. An ingress controller (NGINX or the AKS application routing add-on), cert-manager or Azure Front Door for TLS, DNS records pre-created and TTL lowered days before cutover.
• Step 5, secrets and identity. Key Vault plus the Secrets Store CSI driver plus Workload ID replacing App Service application settings, and rotate anything ever pasted into the portal.
• Step 6, traffic shift. Run both stacks at once, split with Azure Front Door origin weights or Traffic Manager weighted routing, start at 5%, and keep App Service warm as the rollback for two weeks.
• Step 7, day 2. An upgrade cadence tied to the AKS supported version window, node pool ownership, an on-call rotation, and a way for a developer to ship on a Friday without typing kubectl.

Gotchas worth one sentence each: DNS TTL left at 3600 on cutover morning turns a fast rollback into an hour of waiting; apps that assume sticky sessions break behind round-robin Services; WebJobs have no AKS equivalent, so use CronJobs; and Kubernetes health probe semantics differ from App Service health checks, so test them before traffic moves.

Which tools actually help: kompose, Argo CD, Porter, Humanitec or Qovery?

These tools sit in three different layers, and teams confuse them constantly: conversion, delivery, and platform operations. Only the platform-operations layer removes the need for a dedicated Kubernetes hire, because only it creates and operates the cluster itself.

Conversion: kompose. kompose converts a docker-compose file into Kubernetes resources and is explicitly scoped to that. It is a genuinely good 20-minute head start that generates nothing for ingress, TLS, HPA, secrets, RBAC or upgrades.

Delivery: Argo CD and Flux. Both are CNCF graduated (Flux on November 30, 2022, Argo on December 6, 2022), both are excellent, and both assume a working cluster and someone who can write and debug manifests. GitOps decides how you deploy, not who runs the cluster.

PaaS instead of Kubernetes: Caprover and Dokku. Simpler and cheaper for one or two apps on a VM, but they run Docker and Swarm rather than AKS, so they do not answer this question.

Leaving Azure: Render, Fly.io, Heroku. Reasonable if you have decided you do not want Azure infrastructure, but you give up your VNet, your Azure commitments and your existing compliance posture.

Internal developer platforms: Qovery, Porter and Humanitec. All three install into your own cloud account and give developers a self-service layer. To be fair about the differences: Humanitec skews toward organizations that already have a platform team and want to build their own golden paths, while Porter and Qovery target teams that do not have one.

Where Qovery fits: it creates and operates the AKS cluster inside your own Azure subscription (BYOC, so the Azure bill, reservations and discounts stay in your name), handles managed cluster upgrades, and gives developers git-push deploys, per-pull-request preview environments, environment auto-stop for non-production, per-environment RBAC, and databases backed by managed Azure services. The same product runs on AWS, GCP, Scaleway or a Kubernetes cluster you already operate. This article happens to be about Azure.

These layers are not mutually exclusive. Teams run Argo CD inside a Qovery-managed cluster, and kompose output is a fine starting point whichever platform layer you pick.

What does it really cost to run AKS without a Kubernetes expert?

The AKS control plane costs nothing on the Free tier, so the real cost of AKS is almost never the Azure line item. It is the engineering hours spent on version upgrades, node tuning, ingress debugging and on-call, and that number is missing from most migration business cases. Price those hours against a real platform engineer salary before you compare any Azure SKUs.

The Azure facts are clear. The AKS Free tier charges nothing for cluster management, and you pay only for nodes, storage and networking. The Standard tier adds a fixed control-plane fee of about $0.10 per cluster per hour (roughly $72 a month) and a financially backed 99.95% API server uptime SLA with availability zones. The Premium tier runs about $0.60 per cluster per hour and adds long-term support, extending fixes one year beyond the Kubernetes community window. On every tier, nodes, load balancers, egress and storage are billed separately. For comparison, paid Azure App Service carries a 99.95% SLA too, so you are not buying availability by moving.

The hidden line item is the one that dominates. Kubernetes ships three minor releases a year with about 14 months of patch support each, and AKS supports a sliding window of three minor versions. Upgrade work never stops, by design. The 2025 CNCF annual survey puts Kubernetes production use at 82% while naming tool complexity (37%) and skills gaps (33%) among the top barriers. Estimate your monthly hours on minor upgrades, node image upgrades, certificate and ingress issues and incident response, then multiply by a loaded platform engineer rate. That is the number to beat.

The cost upside of AKS done right is real, and it is the reason AKS beats App Service at scale: bin-packing many services onto shared node pools, spot node pools and node autoprovisioning for non-production, cluster autoscaling, and auto-stopping non-production environments overnight and at weekends. Below a certain size, though, App Service or Container Apps wins on total cost of ownership and the migration is not worth doing.

How do you avoid the five mistakes that make this migration fail?

Failed App Service to AKS migrations nearly always fail for the same five reasons, and not one of them is "Kubernetes was too hard to learn." They are ownership and sequencing mistakes you can plan around in an afternoon.

• The big-bang cutover. No weighted traffic split, no warm App Service to roll back to, and DNS TTL still at 3600 on the morning of the switch. Shift traffic gradually and keep the old stack warm.
• Moving databases into the cluster. Keep Azure Database for PostgreSQL or MySQL and Azure Cache for Redis managed, and keep backups and point-in-time restore where they already work.
• Treating the first working manifest as done. The cluster drifts, falls out of the supported version window, and the first forced upgrade becomes an incident. Set an upgrade channel on day one.
• The DevOps hero anti-pattern. One person owns kubectl and becomes the bottleneck for every deploy, every environment and every holiday week.
• No observability before traffic moves. Enable Container Insights, managed Prometheus and Grafana, and alerting before the first 1% of traffic, not after the first outage.

Here is a pre-cutover checklist you can drop straight into a ticket:

• DNS TTL lowered to 60s at least 48 hours before cutover
• App Service kept running and warm as the rollback target
• Traffic split configured, starting at 5% to AKS
• Managed databases and Redis untouched, connection strings verified
• Container Insights, Prometheus, Grafana and alerts live
• Auto-upgrade channel set and an owner named for day-2
• Secrets in Key Vault via CSI + Workload ID, portal secrets rotated

How do I run this migration with Qovery from Claude Code or Cursor?

If you already work with a coding agent, install the Qovery Agent Skills and the agent can provision the AKS cluster in your own Azure subscription and deploy the app, asking you to approve each step. The agent reads your actual repository instead of following a generic tutorial.

Install the skills globally for any compatible agent (Claude Code, Cursor, Codex, OpenCode, Gemini CLI):

curl -fsSL https://skill.qovery.com/install.sh | bash

Scope them to a single repository instead of your whole machine:

curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

Add the Qovery MCP Server to Claude Code for read-only visibility over what already exists (OAuth, read-only by default):

claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

Enable write access only when you want the agent to change things, which also requires enabling write access in the Qovery Console:

claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

The skills cover qovery-onboard (connect the Azure account and create the cluster), qovery-deploy, qovery-preview for per-PR environments, qovery-troubleshoot, qovery-optimize, qovery-speedup and qovery-terraform. The skills deploy; the MCP Server operates what already exists.

Then ask in plain language, for example "migrate this App Service app to an AKS cluster in my Azure subscription with Qovery," and approve each proposed step. The AI agent quickstart and the Claude Code integration page have the full setup.