TL;DR

Eine Kubernetes-Migration im Enterprise-Umfeld braucht Struktur. Analysiere dein Application-Portfolio mit einem Scoring-Modell, plane Migration-Waves nach Komplexität und Risiko, und starte mit unkritischen Workloads. Managed Kubernetes senkt den Einstieg, Self-Hosted gibt mehr Kontrolle. Team-Readiness ist der häufigste Engpass.

Kubernetes-Migration im Enterprise planen

Die meisten gescheiterten Kubernetes-Migrationen scheitern nicht an der Technik. Sie scheitern an fehlender Planung. Wer 200 Applikationen auf Kubernetes bringen will, braucht mehr als kubectl apply.

Hier ist ein Bewertungsscript für dein Application-Portfolio:

#!/bin/bash
# migration-assessment.sh — Schnellbewertung einer Applikation
APP_NAME=$1
echo "=== Migration Assessment: $APP_NAME ==="

# Prüfe ob Container-Images existieren
echo "Container-Image vorhanden?"
docker images | grep -q "$APP_NAME" && echo "  ✓ Ja" || echo "  ✗ Nein"

# Prüfe Abhängigkeiten
echo "Externe Abhängigkeiten:"
cat dependencies.json 2>/dev/null | jq ".\"$APP_NAME\".external | length" || echo "  Datei nicht gefunden"

# Health-Check-Endpunkt vorhanden?
echo "Health-Endpunkt:"
curl -s -o /dev/null -w "%{http_code}" "http://$APP_NAME:8080/health" 2>/dev/null || echo "  Nicht erreichbar"

Phase 1: Application-Portfolio-Analyse

Bevor du irgendetwas migrierst, brauchst du ein vollständiges Bild. Jede Applikation wird nach fünf Kriterien bewertet.

Scoring-Regel: Applikationen mit einem Gesamtscore über 18 sind Quick Wins. Unter 10 bedeutet: erst Vorarbeit leisten.

Erfasse das Scoring strukturiert:

# migration-portfolio.yaml
applications:
  - name: customer-api
    scores:
      containerisierbarkeit: 4
      abhaengigkeiten: 3
      geschaeftskritikalitaet: 2
      team_kompetenz: 3
      infrastruktur_reife: 4
    total: 16
    wave: 1
    notes: "Bereits als Docker-Image verfügbar"

  - name: legacy-billing
    scores:
      containerisierbarkeit: 1
      abhaengigkeiten: 1
      geschaeftskritikalitaet: 5
      team_kompetenz: 2
      infrastruktur_reife: 1
    total: 10
    wave: 3
    notes: "Oracle-DB-Abhängigkeit, Session-State"

  - name: internal-wiki
    scores:
      containerisierbarkeit: 5
      abhaengigkeiten: 5
      geschaeftskritikalitaet: 1
      team_kompetenz: 4
      infrastruktur_reife: 5
    total: 20
    wave: 1
    notes: "Perfekter Kandidat für Wave 1"

Phase 2: Migration-Waves planen

Migriere nie alles gleichzeitig. Teile dein Portfolio in Waves auf.

Wave 1 (Monat 1-2): Stateless Services mit Score > 18. Geringstes Risiko, schnellste Ergebnisse. Hier lernt das Team.

Wave 2 (Monat 3-5): Services mit Score 14-18. Moderate Komplexität, eventuell Datenbank-Anbindung. Erste Persistent Volumes kommen ins Spiel.

Wave 3 (Monat 6-9): Komplexe Workloads mit Score 10-14. Stateful Sets, Legacy-Datenbanken, spezielle Netzwerkanforderungen.

Wave 4 (Monat 10-12): Alles unter Score 10. Hier muss vorab refactored werden — oder die Applikation bleibt auf VMs.

Nicht jede Applikation muss migriert werden. Manche gehören auf die Retain- oder Retire-Liste.

Phase 3: Managed vs. Self-Hosted

Die Infrastruktur-Entscheidung hängt von drei Faktoren ab:

Für die meisten Enterprise-Setups ist Managed Kubernetes der richtige Einstieg. Self-Hosted lohnt sich, wenn strenge Datenhoheit gilt oder spezielle Hardware (GPUs, FPGAs) im eigenen RZ steht.

Phase 4: Team-Readiness

Der technische Stack ist lösbar. Der Engpass ist fast immer das Team. Plan mindestens diese Rollen ein:

• Platform Engineer (ab Wave 1): Baut und betreibt die Kubernetes-Plattform
• DevOps-Enabler (ab Wave 1): Hilft Entwicklungsteams bei der Containerisierung
• Security Engineer (ab Wave 2): Network Policies, RBAC, Image Scanning

Ohne dediziertes Platform-Team wird die Migration zum Nebenprojekt — und Nebenprojekte scheitern.

# Team-Readiness prüfen: Haben alle kubectl-Zugang?
for user in $(cat team-members.txt); do
  echo "Prüfe $user..."
  kubectl auth can-i get pods --as=$user 2>/dev/null \
    && echo "  ✓ $user hat Zugang" \
    || echo "  ✗ $user braucht RBAC-Setup"
done

Risikominimierung

Drei Regeln für eine sichere Migration:

Parallel-Betrieb: Jede migrierte Applikation läuft mindestens 2 Wochen parallel auf der alten und neuen Infrastruktur. Traffic wird schrittweise umgeleitet.

Rollback-Plan: Für jede Wave existiert ein dokumentierter Rollback. DNS-Switch zurück zur VM dauert Minuten, nicht Stunden.

Monitoring first: Bevor die erste Applikation migriert wird, steht das Monitoring. Prometheus, Grafana und Alerting sind keine optionalen Extras.

FAQ

Wie lange dauert eine Enterprise-Migration?

Rechne mit 9-12 Monaten für 50-100 Applikationen. Die erste Wave dauert überproportional lang, weil Plattform und Prozesse aufgebaut werden. Ab Wave 2 beschleunigt sich alles.

Soll ich alle Applikationen migrieren?

Nein. Typischerweise bleiben 10-20% der Applikationen auf VMs — entweder weil sie bald abgelöst werden (Retire) oder weil der Migrationsaufwand den Nutzen übersteigt (Retain).

Was kostet eine Kubernetes-Migration?

Die Infrastrukturkosten sind selten das Problem. Der größte Posten ist Personalaufwand: Schulungen, Containerisierung, Plattform-Aufbau. Plane 2-3 Vollzeit-Engineers für 6 Monate als Minimum.

Brauche ich einen externen Berater?

Für Wave 1 ist externer Support sinnvoll — besonders beim Plattform-Setup und den ersten Deployments. Ab Wave 2 sollte das interne Team übernehmen können.