---
title: Partner-Factory-Modell
description: Legen Sie fest, wie das passende Partner-Factory-Modell anhand von Migrationsbedarf, Risikoprofil und Lieferzielen für STACKIT-Migrationswellen ausgewählt wird.
sidebar:
  label: Partner-Modell
  order: 1
source_url: "https://framework.stackit.cloud/de/migration/design-and-mobilize/migration-factory-setup/partner-factory-model/"
source_file: "docs/de/migration/design-and-mobilize/migration-factory-setup/partner-factory-model.mdx"
---

## 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

<CardGrid>
  <Card title="Kapazitätsprofil für die Lieferung">
    Basis für FTE und Rollenmix je Wellenphase, inklusive Lastspitzen in Cutover-Zeiten.
  </Card>
  <Card title="Abdeckung der Fähigkeiten">
    Erforderliche Kompetenzen für Infrastruktur-Migration, Datenumzug, Integration, Test,
    Security-Nachweise und Release-Koordination.
  </Card>
  <Card title="Governance- und SLA-Modell">
    Entscheidungsrechte, Eskalationsstufen, Betriebsfenster, Reaktionszeiten und Qualitäts-KPIs.
  </Card>
  <Card title="Compliance-Grenzen">
    Regulatorische Anforderungen, Vorgaben zur Datenverarbeitung, Nachweisaufbewahrung und
    Audit-Spuren.
  </Card>
</CardGrid>

## 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

<Steps>

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.

</Steps>

## 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.