Skip to main content
Mohamed Bekenniche

Case study

Migrating ten applications from Azure Web Apps to Kubernetes

The problem

The platform ran on Azure Web Apps, a model that works as long as applications stay simple and few. At around ten applications, split between legacy and new customer segments, the limits had become structural: little control over the runtime, coarse-grained scaling, insufficient isolation between segments, and costs that tracked actual usage poorly.

The data lived in a managed database pool (one database per customer, 150 in total) that the migration was not to touch.

The solution

The applications were moved to Kubernetes (AKS), spread across multi-region clusters matching the customer segments. Each segment gets its own isolation, maintenance window and sizing.

The second cluster answers a customer requirement: some customers wanted their data to stay in France, while the platform ran in North Europe.

Platform before and after the migration, on AzureBefore: around ten applications hosted on Azure Web Apps, connected to a managed database pool. After: two Kubernetes clusters, one per customer segment, connected to the same pool. The pool holds 150 customer databases, one per customer, and was left untouched by the migration.Microsoft AzureBeforeAzure Web AppsWeb AppWeb AppWeb App≈ 10 applicationsAfterKubernetes (AKS)legacy clusternew clusterManaged database poolAzure SQL · MSSQL…150 customer databasesThe data layer does not change: same pool.Only the runtime changes: Web Apps → AKS clusters.Platform before and after the migration, on AzureBefore: around ten applications hosted on Azure Web Apps, connected to a managed database pool. After: two Kubernetes clusters, one per customer segment, connected to the same pool. The pool holds 150 customer databases, one per customer, and was left untouched by the migration.Microsoft AzureBeforeAzure Web AppsWeb AppWeb AppWeb App≈ 10 applicationsAfterKubernetes (AKS)legacy clusternew clusterManaged database poolAzure SQL · MSSQL…150 customer databasesThe data layer does not change: same pool.Only the runtime changes: Web Apps → AKS clusters.

The migration was carried out without service interruption, one application at a time, with the option to roll back at every step.

Delivery followed the same shift. Azure DevOps pipelines build the images, run the tests and push to Azure Container Registry; ArgoCD then continuously deploys the Helm charts, reconciling the cluster with what the repository describes. What runs in production is what is written down somewhere, not what was applied from someone’s workstation.

Azure DevOpsCI: build · testsACRimage registryGit repositoryHelm chartsArgoCDGitOps deliveryAKS clustersmulti-regionNorth Europeoriginal clusterFrancesecond clusterAzure Key VaultsecretsDatabase pool150 customer DBsAzure DevOpsCI: build · testsACRimage registryGit repositoryHelm chartsArgoCDGitOps deliveryAKS clustersmulti-regionNorth Europeoriginal clusterFrancesecond clusterAzure Key VaultsecretsDatabase pool150 customer DBs

Hover over or select a block to read the details.

The results

  • Around ten applications migrated
  • Multi-region clusters separating customer segments
  • Independent isolation and sizing per segment
  • Controlled, reproducible deployments with Helm
  • Azure DevOps CI/CD pipeline and continuous GitOps delivery with ArgoCD

What I take away from it

Kubernetes is not a gain in itself, and a simpler managed service remains the right choice for many workloads. What justified the migration here was the need to isolate customer segments with different requirements: an architectural need, not a technical preference.

  • Azure
  • Kubernetes (AKS)
  • Helm
  • Docker
  • Azure DevOps
  • ArgoCD

← Back to case studies