Leaving a Managed PaaS for Azure AKS: The 4 Layers You Need and the Tools That Cover Each

Key Points:

• No single tool migrates a managed PaaS to Azure Kubernetes Service (AKS). The work splits into four layers: provisioning (Terraform or Bicep, Azure Migrate, Azure Container Registry), continuous delivery (Argo CD, Flux, or an internal developer platform), state (Azure Database Migration Service, plus Velero only if your source is already Kubernetes), and developer experience (Azure Container Apps, Azure Red Hat OpenShift, a home-built Backstage stack, or Qovery).
• Containers are rarely the hard part. The re-architecture cost comes from replacing what the PaaS did silently: ingress and TLS, autoscaling, secret injection, managed add-on databases, per-pull-request preview environments, log aggregation, and one-command rollback.
• Velero needs a source Kubernetes cluster. It is documented for backup, disaster recovery, and migrating resources between clusters, so it helps for Kubernetes-to-AKS and does nothing for Heroku, Render, Fly.io, or Azure App Service as a source.
• Argo CD and Flux are both CNCF graduated projects and excellent at reconciling declared state into AKS, but they assume manifests, Helm charts, or Kustomize overlays already exist. Neither authors them and neither provisions the cluster.
• The AKS control plane is free on the Free tier, so the real cost comparison is node compute plus the salaried platform work you just inherited: cluster upgrades on Azure's 12-month support schedule, CVE patching, ingress, and on-call.
• If minimal re-architecture is the goal, keep a git-push workflow on top of AKS. Azure Container Apps, Azure Red Hat OpenShift, and Qovery each do that differently. Qovery provisions and operates AKS inside your own Azure subscription - and equally AWS, GCP, Scaleway, or an existing Kubernetes cluster - so the Azure bill and any reservations stay in your name.

---

Every few weeks someone asks me the same question: "We are leaving a managed PaaS for Azure and we want to land on AKS with as little re-architecture as possible. What tool do we buy?" The honest answer is that there is no single tool, and the teams that go looking for one are the teams whose migration stalls three months in. To migrate from a managed PaaS to Azure Kubernetes Service (AKS) you need four layers, each with its own tooling: provisioning (Terraform or Bicep, Azure Migrate, Azure Container Registry), continuous delivery (Argo CD, Flux, or a developer platform), state (Azure Database Migration Service, and Velero only if your source is already Kubernetes), and developer experience (Azure Container Apps, Azure Red Hat OpenShift, Backstage, or Qovery). The fourth layer is the one almost everyone discovers too late.

I have watched this play out enough times to be opinionated about it. Below is the honest version: what each tool does, where it stops, and how to sequence the whole thing so you are not debugging an ingress controller at 2am during cutover.

Which tools do you actually need to move from a managed PaaS to Azure AKS?

There is no one-tool migration. The shortest credible tool list is Terraform or Bicep plus Azure Migrate and Azure Container Registry for provisioning and images, Argo CD or Flux for delivery, Azure Database Migration Service (plus Velero only if your source is already Kubernetes) for state, and one deliberate choice for developer experience: Azure Container Apps, Azure Red Hat OpenShift, a home-built Backstage stack, or Qovery.

The reason the four-layer framing matters is simple. Every stalled migration I have seen got the first three layers roughly right and skipped the fourth, then discovered after cutover that developers had traded a git push for a ticket queue. Productivity cratered, and nobody had budgeted for the platform team that AKS quietly requires.

"Minimal re-architecture" is a real goal, but be precise about what it can and cannot mean. You can keep your application code and your Dockerfile. You cannot keep PaaS-injected routing, buildpack conventions, or anything that writes to a local disk expecting it to persist. Those are the parts the PaaS was doing for you, and AKS does not ship them configured.

The four layers are identical regardless of which managed PaaS you are leaving - Heroku, Render, Fly.io, Azure App Service, or Azure Container Apps. Azure and AKS are the destination here, so going Azure-deep is correct. The source platform barely changes the plan.

What actually breaks when you leave a managed PaaS for AKS?

At the container level, almost nothing breaks. A twelve-factor app in a Dockerfile runs on AKS unchanged. What breaks is the invisible platform the PaaS operated for you: ingress and TLS certificates, autoscaling policy, secret injection, add-on databases, build pipelines, preview environments, and rollback. AKS ships none of those configured by default.

Here are the PaaS primitives with no out-of-the-box AKS equivalent: git-push builds, automatic HTTPS certificates, per-branch review apps, one-click add-on databases, scale-to-zero on idle, aggregated logs, and instant rollback. Each one becomes a component you choose, wire up, and keep patched.

And here is the list you now own and version yourself: node pools, an ingress controller (NGINX or Application Gateway for Containers), cert-manager, Azure CNI versus kubenet networking, the Azure Key Vault Secrets Store CSI driver, Azure Workload Identity, and either Azure Monitor Container Insights or a self-run Prometheus and Grafana stack. None of that is exotic. All of it is now your job.

There are only two genuine re-architecture forcing functions. The first is stateful services - databases, queues, and anything writing to a local ephemeral filesystem. The second is anything bound to PaaS-specific buildpacks or routing behaviour. Everything else is lift-and-shift of a container you already have.

The recurring tax is the upgrade treadmill, and it is measurable. The Kubernetes community releases a new minor version roughly every four months, and AKS gives each generally available version a 12-month community support window before you must upgrade (Microsoft Learn - Supported Kubernetes versions in AKS). The Premium tier extends that with long-term support, giving two years of coverage on an LTS version (Microsoft Learn - AKS pricing tiers). Either way, you now have a forced upgrade schedule that has nothing to do with your product roadmap.

If this sounds like a lot, it is the normal experience, not a skills gap on your team. CNCF's own community surveys have consistently flagged complexity and the shortage of in-house Kubernetes skills as top adoption challenges (CNCF Annual Survey). Plan accordingly: lift-and-shift the container, re-platform the state, then decide who owns the developer experience. That third decision is the one teams defer and regret.

Which Azure-native tools cover the migration, and where do they stop?

Microsoft ships three first-party tools that each cover one slice: Azure Migrate for assessment and app containerization, Azure Database Migration Service for state, and Azure Container Registry with ACR Tasks for the image supply chain. All three stop at cutover. None of them gives your developers a workflow on the other side, which is exactly why migrations stall after the first production deploy.

Azure Migrate handles server and application assessment, dependency mapping, and containerization of ASP.NET and Java web apps (Microsoft Learn - Azure Migrate). That is genuinely useful for inventory and right-sizing. It does not refactor your application or stand up a developer platform.

Azure Database Migration Service, paired with Azure Database for PostgreSQL or MySQL Flexible Server, handles state. It supports online migrations based on logical replication for minimal downtime, and offline migrations when a freeze window is acceptable (Microsoft Learn - Azure Database Migration Service). Read the documented prerequisites before you commit to a cutover window; the online path has real constraints.

Azure Container Registry with ACR Tasks gives you cloud-side image builds and geo-replication on higher tiers (Microsoft Learn - ACR service tiers). It is the image supply chain, not the delivery pipeline.

One honest aside: Azure Container Apps is a legitimate destination, not a lesser one. Microsoft's own comparison is clear that you should choose AKS when you need direct access to the Kubernetes API and control plane - custom operators, DaemonSets, fine-grained networking, GPU scheduling. If you do not need those, Container Apps gives you a fully managed, Kubernetes-powered experience with scale-to-zero (Microsoft Learn - Compare container options). Do not pick AKS reflexively.

For reproducible provisioning, Terraform or Bicep is the right call. Just be honest that hand-rolled infrastructure as code becomes the new maintenance burden nobody budgeted for - the cluster module you write in week one is something you own forever.

What do Velero, Argo CD, Flux, and OpenShift really do - and what don't they do?

These four dominate the advice you will get, and all four are genuinely good. None of them performs the PaaS-to-Kubernetes conversion itself. Velero needs a source Kubernetes cluster, Argo CD and Flux need manifests that already exist, and Azure Red Hat OpenShift is the closest drop-in PaaS replacement at the cost of dual licensing and its own learning curve.

Velero does cluster resource backup, namespace-scoped restore, persistent volume snapshots, and migration of resources between clusters (Velero docs). It is excellent at disaster recovery and cluster-to-cluster moves. The honest limitation: it operates against a Kubernetes cluster, so it is useful for Kubernetes-to-AKS and irrelevant for Heroku-to-AKS, because there is no source cluster to back up. Veeam Kasten K10 is the commercial alternative in the same slot if you want supported Kubernetes backup and DR.

Argo CD and Flux are both CNCF graduated GitOps controllers. Argo graduated on December 6, 2022 (CNCF - Argo graduation) and Flux graduated on November 30, 2022 (CNCF - Flux graduation). Argo CD's ApplicationSets and Flux's image automation are both mature. Both reconcile declared state into AKS beautifully. Neither authors the manifests and neither provisions the cluster. They assume layer one already exists and layer two already has something to reconcile.

Azure Red Hat OpenShift deserves real credit. It gives you Source-to-Image builds, Routes, and a genuine PaaS-like developer surface, jointly engineered, operated, and supported by Microsoft and Red Hat (Microsoft Learn - Compare container options). It is the closest thing to a drop-in PaaS replacement on Azure. The trade-off is plain: you pay for the OpenShift license on top of the underlying Azure infrastructure (Azure - Red Hat OpenShift pricing), and OpenShift has its own learning curve.

Backstage plus Crossplane is the build-your-own internal developer platform path. It is powerful and fully yours, and it assumes ongoing platform-engineering headcount to build and run - a real and recurring cost, not a one-time project (CNCF Annual Survey).

Qovery sits in the developer-experience layer: it generates and operates the AKS, Kubernetes, and Terraform layer so your developers keep a PaaS-style interface while workloads run in your own Azure subscription. It complements GitOps rather than arguing against it. I will say this plainly, because it is true: if you already have strong in-house Kubernetes expertise, Argo CD or Flux plus Terraform is a perfectly good answer and cheaper in license terms.

What does a realistic PaaS-to-AKS migration sequence look like, step by step?

A migration that avoids re-architecture follows a fixed order: inventory, containerize, provision AKS with infrastructure as code, replace add-ons with Azure managed services, move state last, run both platforms in parallel behind DNS, then cut over service by service. Skipping the parallel-run step is the single most common cause of an outage you cannot roll back.

1. Inventory. Catalogue every service, runtime version, environment variable, add-on, cron job, and egress dependency. Flag anything writing to local disk and anything relying on PaaS-injected config. This is where Azure Migrate earns its keep.
2. Containerize. One Dockerfile per service, or Cloud Native Buildpacks (Paketo) if you came from a buildpack PaaS and want to skip Dockerfile authoring. Push images to Azure Container Registry.
3. Provision AKS with Terraform or Bicep. Node pools, ingress controller, cert-manager, Azure Workload Identity, the Key Vault CSI driver, and observability. Treat the cluster as reproducible from day one, not a pet you hand-tune.
4. Replace add-ons with Azure managed services. Azure Database for PostgreSQL Flexible Server, Azure Cache for Redis, Service Bus or Storage Queues, and Blob Storage for file persistence. Do not run your production database in-cluster just because you can.
5. Migrate data with Azure Database Migration Service or logical replication. Rehearse the cutover twice and measure the freeze window before you commit to it.
6. Parallel run and shift traffic via Azure Front Door or weighted DNS. Keep the old PaaS warm and rollback-ready for at least one full business cycle, including month-end jobs.
7. Decide the steady-state developer workflow before cutover, not after. This is where most migrations quietly stall for a quarter.

On timing: as an estimate from experience, not a cited statistic, a handful of stateless services with one database is a few weeks of focused work for one or two engineers; a few dozen services with shared state and compliance review is a multi-month effort that wants a dedicated platform engineer plus application owners for each service. The variable that moves the number most is state, not container count.

How do you keep a git-push developer experience once you are on AKS?

The only reliable way to avoid a productivity drop after moving to AKS is to put a self-service layer on top of it, so developers still deploy with a git push and still get an environment per pull request instead of filing tickets for YAML. DORA's research consistently links self-service platforms and reduced friction to stronger software delivery performance (DORA), which is the exact outcome the migration is supposed to protect.

The minimum viable internal developer platform on AKS has to cover: deploy from git, environment templates, per-environment RBAC, secret management, ephemeral preview environments per pull request, managed cluster upgrades, and auto-stop for non-production. That is the feature set the PaaS gave you for free.

The build-versus-buy math is honest in both directions. Backstage plus Argo CD plus Crossplane, assembled in-house, is real engineering headcount, ongoing - and given the complexity and skills gaps CNCF keeps measuring (CNCF Annual Survey), that team is not cheap or quick to staff. If you have it, build it. If you do not, buying the layer is usually faster to value.

This is where Qovery fits, and I will only claim what it actually does. Qovery provisions and upgrades AKS inside your own Azure subscription, gives developers git-push deploys and preview environments per pull request, auto-stops non-production environments, enforces per-environment RBAC, and backs databases with managed Azure services. The Azure bill, along with any reservations or savings plans, stays in your name. Because Qovery is cloud-agnostic and Kubernetes-native, the same capabilities run on AWS, GCP, Scaleway, or an existing Kubernetes cluster, so a later multi-cloud decision does not restart the migration. And if you already stood up AKS with Terraform, Qovery can run on top of that cluster rather than replacing it (bring-your-own-Kubernetes).

Be fair with yourself on the alternative, though. If you are three engineers with one Kubernetes-literate person and no plan to leave Azure, Azure Container Apps may still be the correct destination. AKS is not automatically the upgrade.

What does AKS cost compared to a managed PaaS, and when does the move pay off?

The AKS control plane is free on the Free tier and runs about $0.10 per cluster per hour, roughly $73 a month, on the Standard tier that adds a financially backed uptime SLA (Azure - AKS pricing). So the real comparison is never the control plane. It is node compute plus the salaried cost of the people who now operate the platform.

Your AKS bill is roughly: node pool VMs, a load balancer, egress bandwidth, managed disks, and Azure Monitor log ingestion priced per GB. Per-dyno or per-instance PaaS pricing usually loses on raw compute well before it loses on total cost of ownership, and the markup compounds fastest at scale. The line item nobody forecasts is platform-engineering time: cluster upgrades on Azure's 12-month support schedule (Microsoft Learn - Supported Kubernetes versions), CVE patching, ingress changes, and an on-call rotation.

The upside is that running in your own Azure subscription unlocks cost levers a PaaS never gives you. Azure Reserved VM Instances cut compute by up to 72% on a three-year term, and the Azure savings plan for compute by up to 65% (Azure - Reservations). Azure Spot Virtual Machines run unused capacity at up to 90% off pay-as-you-go, with a 30-second eviction notice, and AKS Spot node pools are ideal for batch and non-production (Microsoft Learn - Spot VMs). Add scale-to-zero and auto-stop on non-production, and Azure Hybrid Benefit if you carry Windows or SQL licenses.

As an estimate from experience, not a cited threshold: once monthly PaaS spend climbs into the mid five figures, the raw-compute savings on AKS alone tend to cover a meaningful chunk of a platform engineer. But the cheapest outcome is usually AKS in your own subscription with someone else operating the platform layer, not AKS plus a brand-new internal platform team you hire from scratch.

What is the easiest way to migrate from a managed PaaS to Azure Kubernetes Service with minimal re-architecture?

Keep your application code and Dockerfile, and replace the four things the PaaS did silently: provisioning, delivery, state, and developer experience. Provision AKS with Terraform or Bicep, deliver with Argo CD or Flux, migrate data with Azure Database Migration Service, and put a self-service layer (Azure Container Apps, Azure Red Hat OpenShift, or Qovery) on top so developers keep a git-push workflow. The container is the easy part; the state migration and the developer experience are where the effort goes.

Is there a single tool that migrates a managed PaaS to AKS?

No. Any tool that claims to do the whole thing is really covering one of the four layers and leaving the rest to you. Azure Migrate assesses and containerizes, Azure Database Migration Service moves data, Argo CD or Flux delivers, and a platform like Qovery or Azure Red Hat OpenShift provides the developer experience. You assemble them, or you buy a layer that stitches several together.

Can Velero migrate workloads from Heroku, Render, or Azure App Service to AKS?

No. Velero operates against a Kubernetes cluster, so it backs up and restores cluster resources and persistent volumes and migrates resources between clusters (Velero docs). If your source is Heroku, Render, Fly.io, or Azure App Service, there is no source cluster for Velero to read, so it does not help with that leg. Velero is the right tool for Kubernetes-to-AKS moves and disaster recovery, not for leaving a non-Kubernetes PaaS.

Should I use Argo CD or Flux for an AKS migration?

Either is a strong choice; both are CNCF graduated GitOps controllers that reconcile declared state into AKS. Argo CD has a built-in UI and ApplicationSets and tends to suit teams that want a visual control plane; Flux is lightweight, composable, and has strong image automation. Neither authors your manifests or provisions the cluster, so you still need Terraform or Bicep underneath and someone to write the Helm charts or Kustomize overlays they reconcile.

Is Azure Container Apps or AKS the better destination when leaving a managed PaaS?

Choose Azure Container Apps if you want a fully managed, serverless container platform with scale-to-zero and you do not need direct Kubernetes API access. Choose AKS when you need the Kubernetes control plane itself: custom operators, DaemonSets, fine-grained networking, or GPU scheduling. Microsoft's own guidance draws exactly this line (Microsoft Learn - Compare container options). For many small teams, Container Apps is the correct answer, and AKS is not automatically the upgrade.

How long does a production PaaS-to-AKS migration take, and what does it cost once you include platform engineering time?

As an estimate from experience, a few stateless services with one database is a few weeks for one or two engineers, while a few dozen services with shared state and compliance review is a multi-month effort. On cost, the AKS control plane is free or about $0.10 per cluster per hour on Standard (Azure - AKS pricing), so the budget is dominated by node compute and the platform-engineering time for upgrades, patching, and on-call. Factor in that AKS forces an upgrade within each version's 12-month support window (Microsoft Learn - Supported Kubernetes versions).

How do I give developers a git-push, preview-environment experience on AKS without building an internal platform?

Buy the developer-experience layer instead of building it. Azure Red Hat OpenShift and Qovery both provide a PaaS-style surface on top of Kubernetes; Qovery provisions and upgrades AKS inside your own Azure subscription and gives developers git-push deploys, preview environments per pull request, non-production auto-stop, and per-environment RBAC, with the Azure bill staying in your name. If you prefer to build, the common stack is Backstage plus Argo CD plus Crossplane, which works well but assumes ongoing platform-engineering headcount.

Sources: Microsoft Learn - Supported Kubernetes versions in AKS, Microsoft Learn - AKS pricing tiers, Azure - AKS pricing, Microsoft Learn - Compare container options, CNCF - Argo graduation, CNCF - Flux graduation, Velero docs, Azure - Reservations, Microsoft Learn - Spot VMs, DORA.