Partner-Factory-Modell

Warum das wichtig ist

Eine Migration Factory liefert nur dann verlässlich, wenn Partnerkapazität, Fähigkeiten und Governance zum tatsächlichen Migrationsbedarf passen. Ein ungeeignetes Partner-Modell führt zu Engpässen, Qualitätsschwankungen und hoher Eskalationslast.

Was im Partner-Modell festgelegt werden sollte

Kapazitätsprofil für die Lieferung

Basis für FTE und Rollenmix je Wellenphase, inklusive Lastspitzen in Cutover-Zeiten.

Abdeckung der Fähigkeiten

Erforderliche Kompetenzen für Infrastruktur-Migration, Datenumzug, Integration, Test, Security-Nachweise und Release-Koordination.

Governance- und SLA-Modell

Entscheidungsrechte, Eskalationsstufen, Betriebsfenster, Reaktionszeiten und Qualitäts-KPIs.

Compliance-Grenzen

Regulatorische Anforderungen, Vorgaben zur Datenverarbeitung, Nachweisaufbewahrung und Audit-Spuren.

Auswahlkriterien für eine Partner-Factory

• Bedarfs-Fit: Kapazität und Skill-Tiefe passen zu Volumen und Komplexität der Wellen.
• Reife der Ausführung: Nachweisbar saubere Runbook-Disziplin, Qualitätsgates und Rollback-Steuerung.
• Werkzeug-Integration: Fähig zur Integration in den ausgewählten Migrations-Werkzeugkasten.
• Risikoverhalten: Belastbare Reaktion auf Incidents, Eskalationen und Stakeholder-Kommunikation.
• Kommerzielles Modell: Vertragslogik unterstützt Pilot-zu-Skalierung und Qualitätsanreize.

Empfohlener Ablauf für das Setup

1. Migrationsbedarf als Baseline festlegen (Volumen, Komplexität, Kritikalität, Abhängigkeiten).
2. Bewertungsmatrix mit gewichteten Kriterien und Muss-Gates erstellen.
3. Delivery-Nachweise prüfen (Beispiel-Runbooks, Kennzahlen, Incident-Historie, Referenzen).
4. Gemeinsames Operating Model festlegen, inklusive RACI, Entscheidungs-Gates und Governance-Rhythmus.
5. SLA-Paket und Qualitätsgrenzen je Wellenphase abstimmen.
6. Pilotwelle durchführen und Kapazität, Governance sowie Eskalationsmechanik nachschärfen.

Mindestartefakte

• Fähigkeitsabbildung des Partners gegen den Migrationsbedarf.
• Vereinbartes Operating Model (RACI, Governance-Foren, Eskalationsmatrix).
• SLA- und KPI-Baseline je Wellenphase.
• Risiko-Register mit Verantwortlichen und Triggern für Gegenmaßnahmen.
• Pilotwellen-Abnahme mit Go/No-Go-Empfehlung für die Skalierung.

Praxisbeispiel: Gemischte Rehost-/Replatform-Welle

Ein Programm mit 120 Workloads (70 % Rehost, 30 % Replatform auf Kubernetes) benötigt in der Regel zwei gekoppelte Squads: ein Infrastruktur-Migrations-Squad für den Rehost-Durchsatz und ein Plattform-Engineering-Squad für Containerisierung und Cluster-Onboarding. Die Kapazitätsplanung sollte diese Aufteilung explizit abbilden, statt FTEs über eine generische Rolle “Migrations-Ingenieur” zu mitteln, da Rehost- und Replatform-Wellen unterschiedliche Skills, Werkzeuge und Cutover-Risikoprofile benötigen.