Case Study: Legacy-Migration zur Internal Platform

Lernziele

Nach dieser Lektion kannst du ein System-Design für die Migration von Legacy-Infrastruktur auf eine Internal Platform durchspielen — mit Strangler Pattern, Team-Adoption und Risiko-Management. Du verstehst, warum Big-Bang-Migration scheitert, wie du parallelen Betrieb organisierst und welche Metriken den Fortschritt messen. Du kannst Interviewer-Einwände zu „Teams wollen nicht wechseln” und „Legacy kann nicht einfach abgeschaltet werden” beantworten.

Das Szenario

„Euer Unternehmen betreibt seit zehn Jahren VM-basierte Deployments mit Jenkins, manuellen Runbooks und einem Ops-Team, das Tickets abarbeitet. 70 Entwicklungsteams, 400 Services. Management will ‚Cloud-native Plattform’ — ihr soll Platform Engineering aufbauen und migrieren. Kein Greenfield. 45 Minuten.”

Das ist der häufigste Real-World-Case — und der, bei dem Kandidaten am ehesten „alles abschalten und neu bauen” vorschlagen.

Phase 1: Anforderungsklärung (Minuten 0–12)

Legacy-Bestand: 400 Services auf VMs (Mix Linux/Windows), Jenkins-CI (zentral, überlastet), Puppet für Config, kein Container-Standard. 15 kritische Monolithen.

Schmerz: Deployments freitags manuell; MTTR hoch; Ops-Team 40 Leute, Burnout; Security-Patches wochenlang verzögert.

Ziel: 80 % der neuen Deployments über Plattform in 18 Monaten; bestehende Services schrittweise — keine Big-Bang-Abschaltung.

Constraints: Laufender 24/7-Betrieb (Retail); Compliance SOC 2; kein zweites „Shadow-IT”-Kubernetes.

Platform-Team: Neu gegründet, 10 Leute aus Ops und Dev.

Interviewer-Zusatzfrage: „Ops-Team fürchtet Jobverlust — wie gehst du damit um?”

Antwort: „Platform-Team rekrutiert aus Ops — deren Runbook-Wissen fließt in Automatisierung. Rolle verschiebt sich von Ticket-Abarbeitung zu Plattform-Produkt, nicht zu Kündigung. Das kommunizierst du Tag eins mit HR und Management.”

Phase 2: Warum Strangler, nicht Rip-and-Replace

Strangler Fig Pattern: Neue Funktionalität und neue Services laufen auf der Plattform; Legacy wird Stück für Stück abgelöst, nicht an einem Cutover-Tag.

[ Legacy VMs + Jenkins ]  ←── schrumpft über 18 Monate
         │
         ├── Traffic-Router / API-Gateway (schrittweise Umleitung)
         │
[ Neue Plattform: K8s + GitOps + Golden Path ]  ←── wächst

Interviewer-Einwand: „Warum nicht alles containerisieren und umziehen?”

Antwort: „400 Services × unbekannte Dependencies × keine Tests = Migration-Projekt ohne Ende. Strangler priorisiert: Neues auf Plattform, Legacy nur migrieren wenn Business-Grund (Kosten, Security, Feature-Geschwindigkeit). 20 % der Services verursachen oft 80 % des Schmerz — dort startest du. Monolithen erst splitten, wenn nötig — nicht als Vorbedingung.”

Phase 3: Architektur — paralleler Betrieb

Ziel-Plattform (Greenfield-Teil):

• Management-Cluster + Non-Prod + Prod (wie Case Lektion 47)
• Golden Path für neue Services und für migrierte Kandidaten
• GitOps als Single Source of Truth für alles, was auf K8s läuft

Legacy-Bridge (Übergang):

• CI-Abstraktion: Teams, die noch Jenkins nutzen, bekommen zuerst standardisierte Jenkinsfile-Templates — nicht sofort K8s. Niedrige Hürde, erster Schritt zur Standardisierung.
• Deployment-Routing: Ingress/API-Gateway leitet Traffic schrittweise von VM zu K8s (Canary, DNS-Weight). Strangler am Traffic, nicht am Code-Monolith.
• Observability vereinheitlichen: Ein Metrics/Logs-Backend für VM und K8s — sonst siehst du Incidents während Migration nicht.

Daten und Stateful Services: Nicht alles gehört in K8s. Managed DBs (RDS), Message Queues — Plattform bietet Provisioned Services (Lektion 16), Migration der App-Logik getrennt von Daten-Migration.

Interviewer-Einwand: „Zwei Welten — doppelter Betriebsaufwand.”

Antwort: „Ja — temporär. Deshalb Zeitbox: 18 Monate mit monatlichem Migrations-Quota (z. B. 15 Services/Monat). Platform-Team automatisiert jeden migrierten Service-Typ als wiederverwendbares Playbook. Doppelbetrieb ist Investition, kein Dauerzustand — und billiger als gescheiterte Big-Bang.”

Phase 4: Team-Adoption und Risiko-Management

Adoption-Hebel (Reihenfolge wichtig):

1. Champion-Teams — 5 Teams freiwillig, enge Begleitung, öffentliche Erfolgsgeschichten.
2. Golden Path schneller als Legacy — Wenn K8s-Deploy länger dauert als VM-Runbook, verlierst du.
3. Migration-Factory — Checkliste pro Service-Typ: Containerize → CI → Deploy → Traffic-Switch → Decommission VM.
4. Sunset-Policy — Ab Monat 12: keine neuen VMs; nur noch Plattform für Greenfield.

Risiko-Matrix:

Risiko	Wahrscheinlichkeit	Impact	Gegenmaßnahme
Kritischer Service bricht bei Migration	Mittel	Hoch	Canary, Rollback-Runbook, paralleler Betrieb
Platform-Team überfordert	Hoch	Mittel	Enge MVP-Scope; Migration-Playbooks statt Einzelhandarbeit
Teams boykottieren	Mittel	Hoch	Champions, Lead-Time-Daten, Executive-Backing
Legacy-Ops blockiert	Mittel	Mittel	Ops in Platform-Team; Skills-Training
Security-Lücke während Übergang	Mittel	Hoch	Policy auf beiden Seiten; gleiche Scan-Standards

Rollback-Prinzip: Jede Migration muss in unter 30 Minuten auf VM zurück — bis Traffic dauerhaft umgestellt.

Phase 5: Phasen-Rollout (Minuten 35–45)

Phase	Monate	Fokus
0 — Foundation	1–4	Plattform Non-Prod, 2 Golden Paths, 5 Champions
1 — Prove	5–8	Erste Prod-Migrationen (20 Services), CI-Templates für Jenkins
2 — Factory	9–14	15 Services/Monat, Playbooks, Gateway-Routing
3 — Sunset	15–18	Keine neuen VMs, 80 % neuer Deploys auf Plattform, Legacy-Katalog schrumpft

Metriken: Migrations-Fortschritt (% Services), Lead Time vorher/nachher, Incidents während Migration, Platform-Adoption.

Interviewer-Einwand: „Nach 18 Monaten laufen noch 100 Services auf VMs.”

Antwort: „Akzeptabel, wenn die 100 unkritisch oder geplant für Phase 4 sind. Erfolg ist 80 % neuer Velocity auf Plattform und kritische Services migriert — nicht 100 % an Tag 540. Restliches Legacy bekommt Wartungsmodus mit klarem Exit-Datum.”

Praxis

Wähle einen fiktiven Legacy-Service (Java-Monolith auf VM, Jenkins-Deploy, PostgreSQL on VM). Schreibe eine Ein-Seiten-Migrations-Checkliste mit Strangler-Schritten — ohne Big-Bang. Markiere, wo du Daten migrierst vs. nur App-Traffic.

Typische Stolperfallen

Big-Bang-Cutover. Klassischer Migrations-Killer.

Containerize-first ohne Business-Case. Manche VMs bleiben VMs — und das ist ok.

Migration ohne Observability. Blind fliegen während Traffic-Switch.

Platform-Team macht alle Migrationen. Teams müssen lernen — Platform liefert Werkzeug.

Legacy abschalten vor Rollback-Test. Einmal prod down = Vertrauen weg für Jahre.

Interview-Vorbereitung

Pitch: „Strangler Pattern, paralleler Betrieb mit Zeitbox, Golden Path für Neues, Migration-Factory für Bestand, Gateway für Traffic-Umleitung, Champions für Adoption, Rollback immer möglich.”

Follow-ups:

• „Wie priorisierst du, welche Services zuerst?” — Schmerz × Machbarkeit × Business-Kritikalität.
• „Ops-Team skeptisch?” — Einbinden, Rolle transformieren, nicht ersetzen.

Zusammenfassung

Legacy-Migration zur Internal Platform gelingt mit Strangler Pattern statt Rip-and-Replace: neue Workloads auf Golden Paths, Bestand schrittweise über Migration-Factory und Traffic-Routing, paralleler Betrieb zeitlich begrenzt, Adoption über Champions und messbare Lead-Time-Vorteile. Risiko-Management heißt Rollback, Canary und ehrliche Priorisierung — nicht 100 % an Tag eins. Damit hast du drei vollständige Cases durchgespielt; in Lektion 50 ziehen wir den Bogen zum Mock Interview und schließen den Lernpfad.