Kubernetes Migration: Strategie, Kosten und Fallstricke 2026

Pexon Consulting | 14 Min. Lesezeit | 13.04.2026

TL;DR

Kubernetes Migration bezeichnet den Weg von VM-basierten Workloads zu containerisierten Anwendungen auf Kubernetes. Pexon Consulting – 80 Spezialisten, Microsoft Partner, 25+ Migrationsprojekte – empfiehlt den schrittweisen Ansatz: Pilotworkload in 6 Wochen containerisieren, dann sukzessive ausrollen. Unsere Kunden senken ihre Infrastrukturkosten nach der Kubernetes Migration um 30-50% bei gleichzeitig schnelleren Release-Zyklen.

73% der Enterprise-Workloads laufen noch auf VMs

Die Zahl überrascht, wenn man die Kubernetes-Euphorie der letzten Jahre betrachtet. Flexera’s State of the Cloud Report 2025 zeigt: Drei Viertel aller produktiven Workloads in Unternehmen ab 500 Mitarbeitern laufen weiterhin auf virtuellen Maschinen. Kubernetes ist angekommen – aber in der Breite dominieren noch die alten Muster.

Warum? Weil Migration Arbeit ist. Echte Arbeit, nicht nur ein docker build. Die .NET-Monolithen, die seit 2014 auf Windows-VMs laufen. Die Java-Anwendungen mit hartcodierten IP-Adressen. Die Legacy-Systeme, bei denen niemand mehr weiß, welche Ports offen sein müssen. Das sind keine Dockerfiles – das sind Architekturentscheidungen.

Trotzdem lohnt sich die Kubernetes Migration für die meisten Unternehmen. Nicht weil Container hip sind, sondern weil die Betriebskosten von VM-Flotten mit der Zeit explodieren. Patching, Skalierung, Deployment-Fenster am Wochenende – alles Dinge, die Kubernetes löst, wenn man es richtig macht.

Die Vorteile im Überblick, wenn die Infrastruktur-Migration gelingt:

• Skalierbarkeit: Horizontal Pod Autoscaling reagiert in Sekunden auf Lastspitzen, statt manuell neue VMs zu provisionieren.
• Self-Healing: Kubernetes startet abgestürzte Container automatisch neu, ohne Ops-Eingriff.
• Ressourcen-Effizienz: Mehrere Container teilen sich einen Node, statt dass jede VM ungenutzte Kapazität reserviert.
• Schnellere Release-Zyklen: Rolling Updates und Deployment-Automatisierung ersetzen manuelle Wartungsfenster am Wochenende.

Wann sich eine Kubernetes Migration lohnt – und wann nicht

Nicht jeder Workload gehört in einen Container. Das sagen wir unseren Kunden im Erstgespräch, auch wenn es manchmal unbequem ist. Die ehrliche Antwort spart am Ende Geld.

Migration lohnt sich bei:

Microservices und API-basierte Anwendungen, die häufig deployed werden. Wenn Ihr Team mehr als zweimal pro Woche releast, ist Kubernetes der natürliche Betriebsmodus. Stateless Web-Frontends und Backend-Services. Alles, was horizontal skalieren muss – sei es wegen Lastspitzen im Tagesgeschäft oder saisonaler Schwankungen. Batch-Processing-Jobs, die auf dedizierten VMs idle vor sich hin warten.

Migration lohnt sich nicht bei:

Datenbank-Server, die auf bare-metal-nahe Latenz angewiesen sind. SAP-Systeme (ja, wir werden gefragt). Legacy-Anwendungen ohne Maintainer, die niemand mehr anfassen will und die in 18 Monaten abgelöst werden. Mainframe-Workloads. Wenn die Anwendung in zwei Jahren End-of-Life ist, containerisieren Sie sie nicht – lassen Sie sie sterben.

Wir haben bei einem Fertigungsunternehmen 47 Workloads analysiert. 31 waren Kandidaten für Kubernetes, 9 blieben auf VMs, 7 wurden direkt als Managed Services ersetzt (Redis, PostgreSQL, Message Queue). Diese Sortierung vor der Migration hat 4 Monate Arbeit gespart.

Die drei Migrationsstrategien

Es gibt nicht einen Weg von VMs zu Containern. Es gibt drei, und jeder hat seinen Platz.

Lift-and-Shift: Schnell, aber nicht nachhaltig

Sie nehmen die bestehende Anwendung, packen sie in ein Container-Image und deployen sie auf Kubernetes. Keine Code-Änderungen, kein Refactoring. Tools wie Move2Kube oder Konveyor automatisieren Teile dieses Prozesses – sie analysieren VM-Konfigurationen und generieren Dockerfiles und Kubernetes-Manifeste.

# Move2Kube: VM-Konfiguration analysieren und K8s-Manifeste generieren
move2kube plan -s ./vm-configs/
move2kube transform -s ./vm-configs/ -o ./k8s-output/

# Ergebnis: Dockerfiles + Deployment-YAMLs für jeden Workload
ls k8s-output/
# deployment.yaml  service.yaml  Dockerfile  configmap.yaml

Lift-and-Shift ist in 2-4 Wochen pro Workload machbar. Die Anwendung läuft dann auf Kubernetes, nutzt aber keine Kubernetes-Features: kein Autoscaling, keine Health Checks, kein Rolling Update. Sie zahlen die Container-Infrastruktur, ohne den Nutzen zu bekommen.

Unsere Position: Lift-and-Shift ist eine Übergangsstrategie. Wir setzen es ein, wenn ein Rechenzentrum geschlossen wird und die Workloads schnell raus müssen. Als dauerhafte Lösung empfehlen wir es nicht.

Refactor: Der Sweet Spot

Sie passen die Anwendung an Kubernetes an, ohne sie komplett neu zu schreiben. Das bedeutet: Konfiguration über Environment Variables statt Konfigurationsdateien auf der VM. Health- und Readiness-Probes einbauen. Logging auf stdout/stderr umstellen statt in Logfiles. Stateful Storage über Persistent Volumes statt lokale Festplatten.

Das ist der Ansatz, den wir in 80% unserer Migrationsprojekte wählen. Der Aufwand liegt bei 4-8 Wochen pro Workload, dafür bekommen Sie eine Anwendung, die Rolling Updates, Autoscaling und Self-Healing nutzt.

# Refactored Deployment mit Health Checks und Resource Limits
apiVersion: apps/v1
kind: Deployment
metadata:
  name: bestellservice
  namespace: produktion
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1    # Null-Downtime Deployments
  template:
    spec:
      containers:
      - name: bestellservice
        image: meine-acr.azurecr.io/bestellservice:v2.4.1
        resources:
          requests:
            cpu: "250m"
            memory: "512Mi"
          limits:
            cpu: "1000m"
            memory: "1Gi"
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 15
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
        env:
        - name: DB_CONNECTION
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: connection-string

Rewrite: Nur wenn es sich rechnet

Die Anwendung wird von Grund auf neu geschrieben – als Cloud-native Microservices. Das ist der teuerste Weg (3-12 Monate pro Service) und nur dann sinnvoll, wenn die bestehende Architektur so veraltet ist, dass Refactoring genauso lange dauern würde. Oder wenn der Business Case einen vollständigen Umbau rechtfertigt – etwa weil die Anwendung von einem Monolithen zu einer Plattform werden soll.

Wir raten davon ab, Rewrites als Migrationsstrategie zu verkaufen. Ein Rewrite ist ein Neubau-Projekt mit eigenem Business Case. Mischen Sie das nicht mit der Migration.

Kubernetes Migration auf Azure AKS: Der konkrete Weg

Wir arbeiten primär mit Azure AKS, weil der Großteil unserer Kunden im Microsoft-Stack unterwegs ist. Wenn aus der Migration ein produktives AKS werden soll, ist die AKS-Implementierung der nächste Schritt: Landing Zone, Upgrade-Pfad und Nachweis. Die Azure Kubernetes Beratung sitzt auf dieser Seite, nicht im Workshop-Kasten.

Der Migrationspfad sieht in der Praxis so aus:

Woche 1-2: Assessment und Workload-Analyse. Wir inventarisieren alle VMs, klassifizieren die Workloads (migrate / keep / replace) und identifizieren den Pilot-Workload. Der Pilot sollte ein Workload mit geringem Risiko sein – kein SAP, kein Kernbankensystem. Ein interner API-Service oder ein Backend für ein Reporting-Tool eignet sich gut.

Woche 3-4: Pilot containerisieren. Dockerfile schreiben, CI/CD-Pipeline aufbauen (Azure DevOps oder GitHub Actions), AKS-Cluster provisionieren. Den Cluster bauen wir per Terraform – Infrastructure as Code von Anfang an, nicht nachträglich.

# Terraform: AKS-Cluster für Migration
resource "azurerm_kubernetes_cluster" "migration" {
  name                = "aks-migration-prod"
  location            = "germanywestcentral"
  resource_group_name = azurerm_resource_group.k8s.name
  dns_prefix          = "migration"
  kubernetes_version  = "1.30"

  default_node_pool {
    name                = "system"
    vm_size             = "Standard_D4s_v5"
    node_count          = 3
    auto_scaling_enabled = true
    min_count           = 3
    max_count           = 10
    zones               = [1, 2, 3]  # Availability Zones
  }

  identity {
    type = "SystemAssigned"
  }

  network_profile {
    network_plugin = "azure"
    network_policy = "cilium"  # Network Policies von Tag 1
  }

  oms_agent {
    log_analytics_workspace_id = azurerm_log_analytics_workspace.k8s.id
  }
}

Woche 5-6: Parallel-Betrieb und Cutover. Der containerisierte Workload läuft parallel zur VM. Traffic wird schrittweise umgeleitet (Canary oder Blue-Green). Wenn der Container-Workload stabil ist, wird die VM abgeschaltet.

Ab Woche 7: Nächster Workload. Jetzt wiederholt sich der Prozess – aber schneller, weil Cluster, Pipeline und Patterns stehen. Der zweite Workload braucht 2-3 Wochen statt 6.

Die Fallstricke, die niemand im Vortrag erwähnt

Jedes Kubernetes-Migrationsprojekt hat seine Überraschungen. Hier die drei, die wir am häufigsten sehen:

Persistent Storage wird unterschätzt. VMs haben lokale Festplatten. Container sind ephemeral. Jede Anwendung, die Daten lokal speichert – Uploads, Caches, temporäre Dateien – muss auf Persistent Volumes oder Object Storage (Azure Blob) umgestellt werden. Das klingt trivial, betrifft aber überraschend viele Anwendungen. Ein Maschinenbau-Kunde hatte 14 von 31 Workloads, die irgendwo auf die lokale Festplatte schrieben.

Netzwerk-Konfiguration ist anders. Auf VMs haben Sie statische IPs, feste Hostnamen, Firewallregeln. In Kubernetes gibt es Services, Ingress-Controller, Network Policies. Die Anwendung muss Service Discovery nutzen statt hartcodierter Adressen. Wenn Ihre Anwendung 10.0.1.42:5432 als Datenbank-Adresse in einer Config-Datei hat, müssen Sie das ändern – auf postgres-service.database.svc.cluster.local oder besser noch auf eine Environment Variable.

Das Team braucht neue Skills. Ihre Ops-Leute kennen VMware, Hyper-V, vielleicht Ansible. Kubernetes ist ein anderes Betriebsmodell. Ohne Schulung des Teams wird die Migration zum Bottleneck bei den Leuten, nicht bei der Technologie. Wir planen in jedem Migrationsprojekt 3-5 Tage Hands-on-Training ein – kein Frontalunterricht, sondern Pair-Working am echten Cluster.

Security wird nachträglich draufgesetzt statt mitgedacht. Pod Security Standards, Secrets-Management-Tools und RBAC-Rollen sind in der VM-Welt oft implizit durch Netzwerksegmentierung geregelt – in Kubernetes müssen sie explizit konfiguriert werden. Wer Security erst nach dem Go-Live nachrüstet, migriert Compliance-Lücken mit. Wir richten RBAC und Secrets-Management deshalb im selben Sprint ein wie die erste Workload, nicht danach.

Was die Kubernetes Migration kostet

Wir werden in jedem Erstgespräch nach Zahlen gefragt. Hier sind sie.

Der Pilot-Workload (1 Anwendung, Assessment bis Go-Live) kostet zwischen 15.000 und 25.000 EUR bei einer Dauer von 6 Wochen. Darin enthalten: Workload-Analyse, Containerisierung, AKS-Cluster-Setup, CI/CD-Pipeline, Parallel-Betrieb und Cutover.

Jeder weitere Workload kostet 5.000 bis 15.000 EUR, abhängig von der Komplexität. Ein stateless API-Service liegt am unteren Ende, eine Anwendung mit Persistent Storage, Scheduled Jobs und externen Integrationen am oberen.

Die laufenden AKS-Kosten liegen für einen typischen Mittelstands-Cluster (3-10 Nodes, D4s_v5) bei 1.500 bis 4.000 EUR pro Monat. Das ist oft weniger als die VM-Infrastruktur, die er ersetzt – wir sehen Einsparungen von 30-50%, weil Container die Ressourcen besser auslasten. Eine VM mit 16 GB RAM, die dauerhaft 3 GB nutzt, kostet genauso viel wie eine mit voller Auslastung. Container teilen sich den Node.

Für ein typisches Migrationsprojekt mit 15-20 Workloads über 4-6 Monate rechnen Sie mit 80.000 bis 150.000 EUR Gesamtkosten – inklusive Platform Engineering für Golden Paths, damit Ihr Team nach der Migration selbstständig deployen kann.

Nach der Migration: Warum Platform Engineering den Unterschied macht

Die Kubernetes Migration ist nicht das Ende, sondern der Anfang. Der häufigste Fehler, den wir sehen: Das Infrastruktur-Team baut einen Cluster, migriert die Workloads – und dann steht alles still, weil jedes Development-Team einzeln lernen muss, wie man Deployments, Services und Ingress-Regeln schreibt.

Die Lösung heißt Internal Developer Platform. Golden Paths – vorgefertigte Templates für Deployments, CI/CD-Pipelines und Monitoring – die Entwickler nutzen können, ohne Kubernetes-Experten zu sein. Ein Entwickler sollte sagen können: „Ich habe einen Java-Service mit einer PostgreSQL-Datenbank“, und die Plattform liefert ihm alles, was er braucht.

In unseren Projekten investieren wir nach der Migration 2-4 Wochen in den Aufbau dieser Plattform-Schicht. Das zahlt sich sofort aus: Die Deployment-Frequenz steigt von wöchentlich auf täglich, und die Ops-Last verteilt sich vom Infra-Team auf die Entwickler.

Zwei weitere Bausteine gehören in diese Phase: Monitoring und Skalierung (Scalability). Für Monitoring setzen wir auf Azure Monitor in Kombination mit einem Prometheus-Grafana-Stack auf dem Cluster selbst – Azure Monitor liefert die Plattform-Metriken, Grafana macht Anwendungs- und Cluster-Zustand für Entwickler direkt sichtbar, ohne Umweg über das Infra-Team. Für die Skalierung kombinieren wir Horizontal Pod Autoscaler (HPA) für einzelne Workloads mit dem Cluster-Autoscaler, der bei Bedarf automatisch neue Nodes hinzufügt – beides Teil eines Kapazitäts-Managements, das mit der Migration mitwächst. Security ist an dieser Stelle bereits über RBAC und Secrets-Management abgedeckt (siehe Fallstricke oben) – hier geht es nur noch um Betrieb und Wachstum, nicht mehr um die Grundabsicherung. Lässt sich diese Rolle intern nicht dauerhaft besetzen, können wir den Betrieb nach der Migration übernehmen, damit die Kapazität für die Golden Paths bleibt.

Häufig gestellte Fragen

Was kostet eine Kubernetes Migration für ein mittelständisches Unternehmen?

Der Pilot-Workload kostet 15.000-25.000 EUR (6 Wochen). Jeder weitere Workload 5.000-15.000 EUR. Ein vollständiges Migrationsprojekt mit 15-20 Workloads liegt bei 80.000-150.000 EUR über 4-6 Monate. Dazu kommen laufende AKS-Kosten von 1.500-4.000 EUR/Monat – oft 30-50% weniger als die ersetzten VMs.

Wann lohnt sich Kubernetes und wann reichen VMs?

Kubernetes lohnt sich, wenn Sie häufig deployen (mehr als 2x/Woche), wenn Workloads skalieren müssen, oder wenn Sie Infrastrukturkosten durch bessere Ressourcenauslastung senken wollen. VMs sind die bessere Wahl für Legacy-Anwendungen ohne Maintainer, Datenbanken mit Latenz-Anforderungen und Systeme, die in 12-18 Monaten abgelöst werden. Die Faustregel: Wenn der Workload sich in den nächsten 3 Jahren nicht ändert, lohnt sich die Migration selten.

Wie lange dauert eine Kubernetes Migration?

Der erste Workload braucht 6 Wochen (Assessment bis Go-Live). Ab dem zweiten Workload geht es schneller – 2-3 Wochen pro Anwendung, weil Cluster, Pipeline und Patterns stehen. Ein Projekt mit 20 Workloads dauert 4-6 Monate. Wir empfehlen, nicht alles auf einmal zu migrieren, sondern in 3-4 Wellen von je 5 Workloads.

Kann ich bestehende .NET-Anwendungen auf Kubernetes migrieren?

Ja. .NET-6+-Anwendungen laufen nativ in Linux-Containern auf AKS. Ältere .NET-Framework-Anwendungen (4.x) benötigen Windows-Container – das funktioniert auf AKS mit Windows-Node-Pools, ist aber operativ aufwändiger. Unsere Empfehlung: Bei .NET Framework 4.x zuerst auf .NET 8 migrieren, dann containerisieren. Beides gleichzeitig zu machen endet meistens in Chaos.

Brauche ich Kubernetes oder reichen Azure Container Apps?

Kommt auf die Kontrolle an. Azure Container Apps ist einfacher zu betreiben – kein Cluster-Management, kein Node-Patching, kein Ingress-Controller. Dafür haben Sie weniger Kontrolle über Netzwerk, Storage und Runtime-Konfiguration. Für einfache Web-Apps und APIs sind Container Apps oft die bessere Wahl. Für komplexe Microservice-Architekturen mit Custom Networking, Service Mesh oder spezifischen Compliance-Anforderungen nehmen Sie AKS.

Nächster Schritt

Eine Kubernetes Migration beginnt mit der Frage: Welche Workloads lohnen sich? In unserem Kubernetes Workshop analysieren wir Ihre VM-Landschaft, identifizieren den optimalen Pilot-Workload und planen die Containerisierung bis zum produktiven Betrieb auf AKS – inklusive CI/CD-Pipeline und Monitoring.

Verwandte Themen