Kubernetes-Migration gescheitert: So retten Sie Ihr Projekt in 6 Wochen

Die Migration sollte 3 Monate dauern. Es sind 8 geworden. Der Cluster existiert, aber die Haelfte der Anwendungen laeuft noch auf den alten VMs. Die andere Haelfte laeuft auf Kubernetes -- instabil, ohne Monitoring, ohne Backup. Das Entwicklerteam hat das Vertrauen verloren. Die Geschaeftsfuehrung fragt, ob die Investition verloren ist.

Wenn Ihnen dieses Bild bekannt vorkommt, sind Sie nicht allein. Eine erhebliche Zahl der Kubernetes-Migrationen im deutschen Mittelstand erreicht die gesetzten Ziele nicht im geplanten Rahmen. Dieser Artikel gibt Ihnen ein strukturiertes Framework, um zu bewerten, ob Ihr Projekt rettbar ist -- und wie der Rettungsplan aussieht.

TL;DR

Gescheiterte Migrationen lassen sich in vier Muster einteilen: Stuck-in-Staging, Partial-Migration, Unstable-Production und Wrong-Architecture
Ein strukturiertes Assessment (5 Dimensionen, Scoring-Modell) zeigt objektiv, ob Reparatur oder Neustart sinnvoller ist
Bei einem Score ueber 60 Prozent lohnt sich die Rettung -- darunter ist ein kontrollierter Neustart oft guenstiger
Der 6-Wochen-Rettungsplan konzentriert sich auf Stabilisierung vor Feature-Arbeit
Die haeufigste Ursache fuer gescheiterte Migrationen ist nicht Technologie, sondern fehlende Betriebskompetenz nach dem Go-Live

Die vier Muster gescheiterter Migrationen

Muster 1: Stuck-in-Staging

Der Cluster existiert, aber kein einziger Production-Workload laeuft darauf. Alles bleibt in der Staging-Umgebung stecken, weil das Vertrauen fuer den Go-Live fehlt.

Stuck-in-Staging Diagnose:

Symptome:
├── Cluster seit 3+ Monaten aufgesetzt
├── 0 Production-Workloads auf Kubernetes
├── Entwickler deployen noch auf alte Infrastruktur
├── Kein definierter Go-Live-Termin
└── Saetze wie "Wir muessen erst noch..." (endlose Vorbedingungen)

Ursachen:
├── Kein Vertrauen in Stabilitaet des Clusters
├── Fehlende Runbooks und Incident-Response-Prozesse
├── Kein Go-Live-Verantwortlicher benannt
└── Scope Creep: Plattform statt Migration

Rettbarkeit: HOCH (80%)
Grund: Technische Basis existiert, es fehlt Betriebsreife

Muster 2: Partial-Migration

Einige Anwendungen laufen auf Kubernetes, andere noch auf der alten Infrastruktur. Zwei Welten parallel zu betreiben ist teurer und komplexer als eine.

Partial-Migration Diagnose:

Symptome:
├── 30-60% der Anwendungen auf Kubernetes
├── Rest laeuft noch auf VMs / Bare Metal
├── Doppelte Infrastruktur-Kosten
├── Doppelter Betriebsaufwand (alte + neue Welt)
└── Team ist hin- und hergerissen

Ursachen:
├── Die "schwierigen" Anwendungen wurden aufgeschoben
├── Datenbank-Migration nicht geloest
├── Abhaengigkeiten zwischen Alt und Neu nicht bedacht
└── Migration wurde nach ersten Erfolgen deprioritisiert

Rettbarkeit: MITTEL (60%)
Grund: Jeder Tag im Dual-Betrieb kostet doppelt

Muster 3: Unstable-Production

Anwendungen laufen auf Kubernetes, aber instabil. Regelmaessige Ausfaelle, unerklaerliche Pod-Restarts, Performance-Probleme. Das Team verbringt mehr Zeit mit Firefighting als mit Weiterentwicklung.

Muster 4: Wrong-Architecture

Die grundlegende Architektur-Entscheidung war falsch. Beispiel: Ein Monolith wurde ohne Refactoring in einen einzigen riesigen Container gepackt. Oder: Jeder Microservice hat seine eigene Datenbank, aber es gibt kein Service Mesh und keine konsistente Kommunikation.

Das Assessment-Framework: Retten oder Neustart?

Bevor Sie entscheiden, ob Sie reparieren oder neu starten, brauchen Sie eine objektive Bewertung. Dieses Framework bewertet fuenf Dimensionen.

Die 5 Bewertungsdimensionen

# migration-assessment.yaml
# Scoring: 0-20 Punkte pro Dimension, Gesamt: 0-100

assessment_dimensions:

  1_cluster_health:
    description: "Technischer Zustand des bestehenden Clusters"
    checks:
      - "Kubernetes-Version aktuell (max 2 Minor hinter latest)?"
      - "Alle Nodes im Ready-Zustand?"
      - "etcd healthy, keine Performance-Probleme?"
      - "Control Plane redundant (3+ Master)?"
      - "CNI-Plugin stabil, keine Netzwerk-Ausfaelle?"
    scoring:
      0_5: "Cluster grundlegend defekt, Rebuild noetig"
      6_10: "Cluster laeuft, aber mit bekannten Problemen"
      11_15: "Cluster stabil, kleinere Luecken"
      16_20: "Cluster produktionsreif"

  2_workload_readiness:
    description: "Wie gut sind die Anwendungen fuer Kubernetes vorbereitet"
    checks:
      - "Container Images mit Health Checks?"
      - "Graceful Shutdown implementiert?"
      - "Konfiguration externalisiert (ConfigMaps/Secrets)?"
      - "Horizontal skalierbar?"
      - "Stateless oder State korrekt verwaltet (PVC)?"
    scoring:
      0_5: "Anwendungen nicht containerisiert"
      6_10: "Container existieren, aber nicht K8s-ready"
      11_15: "Meiste Best Practices umgesetzt"
      16_20: "Cloud-Native ready"

  3_operations_maturity:
    description: "Betriebsfaehigkeit und Prozesse"
    checks:
      - "Monitoring und Alerting eingerichtet?"
      - "Runbooks fuer Top-5-Incidents vorhanden?"
      - "Backup-Strategie implementiert und getestet?"
      - "Incident-Response-Prozess definiert?"
      - "On-Call-Rotation oder Managed Service?"
    scoring:
      0_5: "Kein operativer Betrieb vorhanden"
      6_10: "Grundlegendes Monitoring, keine Prozesse"
      11_15: "Monitoring + Alerting, Runbooks teilweise"
      16_20: "Vollstaendiger operativer Betrieb"

  4_team_capability:
    description: "Kompetenz und Kapazitaet des Teams"
    checks:
      - "Mindestens 2 Personen mit K8s-Erfahrung?"
      - "Troubleshooting-Faehigkeiten vorhanden?"
      - "Erfahrung mit K8s-Upgrades?"
      - "Capacity fuer Betrieb UND Migration gleichzeitig?"
      - "Motivation vorhanden (kein Burnout)?"
    scoring:
      0_5: "Keine K8s-Kompetenz im Team"
      6_10: "1 Person mit Grundkenntnissen"
      11_15: "2+ Personen, grundlegende Erfahrung"
      16_20: "Erfahrenes Team mit Kapazitaet"

  5_business_alignment:
    description: "Passt Kubernetes noch zur Geschaeftsstrategie"
    checks:
      - "Konkreter Business Case noch gueltig?"
      - "Stakeholder-Support vorhanden?"
      - "Budget fuer Fertigstellung verfuegbar?"
      - "Zeitdruck realistisch handhabbar?"
      - "Kein fundamentaler Strategiewechsel?"
    scoring:
      0_5: "Business Case existiert nicht mehr"
      6_10: "Zweifel, aber grundsaetzlich sinnvoll"
      11_15: "Business Case intakt, Budget knapp"
      16_20: "Voller Support und Budget"

Die Entscheidungsmatrix

Gesamtscore	Empfehlung	Begruendung
80-100	Weiter, Scope schaerfen	Solide Basis, Fokus auf Abschluss
60-79	Retten mit externer Hilfe	Luecken schliessen, dann weitermachen
40-59	Teilweiser Neustart	Gute Teile behalten, Rest neu aufsetzen
20-39	Kontrollierter Neustart	Lessons Learned sichern, sauber neu starten
0-19	Kubernetes hinterfragen	Ist K8s die richtige Technologie fuer Sie?

Der 6-Wochen-Rettungsplan

Wenn Ihr Assessment einen Score von 60 oder hoeher ergibt, ist Rettung die bessere Option. Hier ist der Plan.

Woche 1-2: Stabilisierung

Bevor irgendetwas Neues passiert, muss das Bestehende stabil laufen.

#!/bin/bash
# stabilization-checklist.sh
# Woche 1-2: Cluster stabilisieren

echo "=== PHASE 1: Cluster Health ==="
echo "1.1 Kubernetes-Version pruefen"
kubectl version --short
echo "Ziel: Max 2 Minor-Versionen hinter latest"

echo ""
echo "1.2 Node-Zustand pruefen"
kubectl get nodes -o wide
kubectl top nodes
echo "Aktion: NotReady Nodes reparieren oder ersetzen"

echo ""
echo "1.3 Problematische Workloads identifizieren"
kubectl get pods -A --field-selector=status.phase!=Running \
  | grep -v Completed | grep -v Succeeded
echo "Aktion: CrashLoopBackOff und Pending Pods fixen oder entfernen"

echo ""
echo "1.4 Resource Requests und Limits pruefen"
kubectl get pods -A -o json | \
  jq '.items[] | select(.spec.containers[].resources.requests == null) |
  {namespace: .metadata.namespace, name: .metadata.name}'
echo "Aktion: Fehlende Resource Requests setzen"

echo ""
echo "=== PHASE 2: Monitoring ==="
echo "2.1 Prometheus + Grafana vorhanden?"
kubectl get pods -n monitoring
echo "2.2 Alerting konfiguriert?"
kubectl get prometheusrules -A 2>/dev/null || echo "Keine Alerting Rules"
echo "Aktion: Mindestens 5 kritische Alerts einrichten"

Woche 3-4: Betriebsfaehigkeit

# operations-minimum.yaml
# Das Minimum fuer einen stabilen Kubernetes-Betrieb

monitoring:
  tool: "Prometheus + Grafana (kube-prometheus-stack)"
  alerts:
    critical:
      - "NodeNotReady (2min)"
      - "PodCrashLooping (5min)"
      - "PersistentVolumeFillingUp (80%)"
      - "KubernetesAPIServerDown"
      - "etcdHighDiskUsage (70%)"
    warning:
      - "CertificateExpiringSoon (30 Tage)"
      - "DeploymentReplicasMismatch (10min)"
      - "HighMemoryUsage (85%)"

backup:
  tool: "Velero"
  schedule: "taeglich 02:00 UTC"
  retention: "30 Tage"
  test: "Monatlicher Restore-Test in Staging"

runbooks:
  minimum_set:
    - "Node NotReady Recovery"
    - "Pod CrashLoopBackOff Triage"
    - "etcd Disk Full Recovery"
    - "Certificate Renewal"
    - "Rollback eines fehlgeschlagenen Deployments"

ownership:
  verantwortlich: "Name und Kontakt definiert"
  eskalation: "Eskalationspfad dokumentiert"
  on_call: "Erreichbarkeit ausserhalb Geschaeftszeiten"

Woche 5: Migration abschliessen

Priorisieren Sie die verbleibenden Anwendungen nach Business Impact und Komplexitaet. Migrieren Sie zuerst die Anwendungen mit hohem Business Impact und niedriger Komplexitaet.

Prioritaet	Kriterium	Aktion
1 (sofort)	Hoher Impact, niedrige Komplexitaet	Diese Woche migrieren
2 (naechste Woche)	Hoher Impact, mittlere Komplexitaet	Mit zusaetzlicher Vorbereitung
3 (spaeter)	Niedriger Impact	Kann auf Phase 2 warten
4 (nie)	Legacy ohne Zukunft	Auf alter Infrastruktur belassen

Woche 6: Validation und Uebergabe

Die letzte Woche gehoert der Validierung: Laeuft alles stabil? Sind alle Alerts korrekt konfiguriert? Funktioniert der Backup-Restore? Ist die Dokumentation vollstaendig?

Wann ein Neustart besser ist als Reparatur

Es gibt Situationen, in denen Reparatur teurer ist als ein sauberer Neustart. Hier sind die Indikatoren.

Reparatur ist besser wenn

Der Cluster technisch funktioniert (Nodes healthy, Control Plane stabil)
50 Prozent oder mehr der Anwendungen bereits auf Kubernetes laufen
Das Team grundlegende Kubernetes-Erfahrung hat
Die Architektur-Entscheidungen grundsaetzlich korrekt waren
Das Problem primaer in fehlenden Prozessen liegt, nicht in falscher Technik

Neustart ist besser wenn

Fundamentale Architektur-Fehler vorliegen (falsches CNI-Plugin, Single-Node "Cluster", kein RBAC)
Die Kubernetes-Version so alt ist, dass kein Upgrade-Pfad existiert
Die Container-Images nicht den Best Practices entsprechen (Root-User, kein Health Check, keine Resource Limits)
Das Team komplett gewechselt hat und niemand den bestehenden Cluster versteht
Die Kosten fuer Reparatur die Kosten fuer Neuaufbau uebersteigen

Kostenvergleich: Reparatur vs. Neustart

Kosten-Abschaetzung (typischer Mittelstaendler, 5-10 Anwendungen):

Reparatur bestehender Migration:
├── Assessment und Planung:          5.000 - 10.000 EUR
├── Stabilisierung (2 Wochen):       8.000 - 15.000 EUR
├── Betriebsfaehigkeit (2 Wochen):   8.000 - 15.000 EUR
├── Migration abschliessen:         10.000 - 25.000 EUR
├── Validierung und Uebergabe:       5.000 - 10.000 EUR
└── Gesamt:                         36.000 - 75.000 EUR
    Dauer: 6-10 Wochen

Kontrollierter Neustart:
├── Lessons Learned Workshop:         3.000 - 5.000 EUR
├── Neue Architektur und Planung:    10.000 - 20.000 EUR
├── Cluster-Aufbau (neu):           15.000 - 30.000 EUR
├── Migration aller Anwendungen:    25.000 - 50.000 EUR
├── Betriebsfaehigkeit:              8.000 - 15.000 EUR
├── Validierung:                     5.000 - 10.000 EUR
└── Gesamt:                         66.000 - 130.000 EUR
    Dauer: 12-20 Wochen

Fazit: Reparatur ist fast immer guenstiger, wenn der Score
       ueber 60 liegt. Unter 40 wird Neustart wirtschaftlicher.

Die haeufigsten Fehler bei der Rettung

Fehler 1: Weiter machen wie bisher

Das Projekt ist gescheitert, weil etwas fundamental nicht funktioniert hat. Mehr vom Gleichen wird nicht helfen. Aendern Sie den Ansatz, nicht nur den Zeitplan.

Fehler 2: Noch mehr Scope hinzufuegen

Die Versuchung ist gross, bei der Rettung gleich alles richtig zu machen. Widerstehen Sie. Zuerst stabilisieren, dann erweitern.

Fehler 3: Kein externer Blick

Wenn Ihr Team das Projekt nicht zum Erfolg fuehren konnte, brauchen Sie einen externen Blick. Das ist keine Schwaechung, sondern professionelle Praxis. Ein erfahrener Partner sieht Probleme, die das interne Team nicht mehr sieht, weil es zu nah dran ist.

Welche Ueberlegungen bei der Wahl zwischen internem Team und externem Partner relevant sind, lesen Sie im Team-Aufbau Kostenvergleich.

Fehler 4: Alte Infrastruktur vorzeitig abschalten

Schalten Sie die alte Infrastruktur erst ab, wenn die neue nachweislich stabil laeuft. Mindestens 4 Wochen paralleler Betrieb unter Last, mit funktionierendem Rollback-Pfad. Pruefen Sie vor der Abschaltung: Kann DNS innerhalb von 5 Minuten umgeschaltet werden? Laeuft die alte Infrastruktur noch? Sind Daten synchron? Funktioniert Monitoring auf beiden Seiten?

Lessons Learned sichern

Unabhaengig davon, ob Sie reparieren oder neu starten: Dokumentieren Sie, was schiefgelaufen ist. Nicht um Schuldige zu finden, sondern um die gleichen Fehler nicht zu wiederholen.

Frage	Was Sie dokumentieren sollten
Was war der urspruengliche Plan?	Scope, Zeitrahmen, Budget, Verantwortliche
Ab wann lief es schief?	Konkreter Zeitpunkt und Ausloeser
Was waren die Warnsignale?	Die Zeichen, die ignoriert wurden
Was hat gefehlt?	Kompetenz, Kapazitaet, Prozesse, Budget
Was wuerden Sie anders machen?	Konkrete Massnahmen, nicht Allgemeinplaetze

Fazit

Eine gescheiterte Kubernetes-Migration ist kein Totalverlust. In den meisten Faellen laesst sich das Projekt retten, wenn Sie bereit sind, ehrlich zu analysieren, den Scope zu reduzieren und die Betriebsfaehigkeit vor neue Features zu stellen.

Der entscheidende Punkt ist: Stabilisierung vor Migration. Ein Cluster, der nicht stabil betrieben werden kann, ist kein geeignetes Ziel fuer weitere Anwendungen. Erst wenn Monitoring, Alerting, Backup und Incident Response funktionieren, sollten Sie den naechsten Workload migrieren.

Und wenn die Analyse zeigt, dass ein Neustart sinnvoller ist: Dann ist ein kontrollierter Neustart mit den richtigen Lehren wertvoller als jahrelanges Reparieren an einer falschen Architektur.

Kubernetes-Migration gescheitert: Projekt in 6 Wochen retten