---
title: Partner Factory Model
description: Define how to select and govern the migration partner factory model based on migration demand, risk profile, and delivery targets.
sidebar:
  label: Partner model
  order: 1
source_url: "https://framework.stackit.cloud/migration/design-and-mobilize/migration-factory-setup/partner-factory-model/"
source_file: "docs/migration/design-and-mobilize/migration-factory-setup/partner-factory-model.mdx"
---

## Why This Matters

A migration factory can only deliver predictable wave throughput when partner capacity, capabilities,
and governance fit the migration demand. A weak partner model leads to bottlenecks, quality variance,
and escalation overload.

## What to Define in the Partner Model

<CardGrid>
  <Card title="Delivery capacity profile">
    Baseline FTE and role mix per wave phase, including peak handling for cutover windows.
  </Card>
  <Card title="Capability coverage">
    Required competencies across infrastructure migration, data migration, integration, testing,
    security evidence, and release coordination.
  </Card>
  <Card title="Governance and SLA model">
    Decision rights, escalation tiers, service windows, response times, and quality KPIs.
  </Card>
  <Card title="Compliance boundaries">
    Regulatory obligations, data handling constraints, evidence retention, and audit traceability.
  </Card>
</CardGrid>

## Selection Criteria for a Migration Partner Factory

- **Demand-fit**: Capacity and skill depth match expected wave mix and complexity distribution.
- **Operational maturity**: Proven runbook discipline, quality gates, rollback governance, and reporting.
- **Toolchain interoperability**: Ability to integrate with selected migration tools and customer controls.
- **Risk handling**: Demonstrated incident response, escalation behavior, and stakeholder communication.
- **Commercial model fit**: Contract model aligns with wave variability, pilot-to-scale ramp, and quality incentives.

## Recommended Setup Flow

<Steps>

1. Establish migration demand baseline (volume, complexity, criticality, and dependency profile).
2. Build partner evaluation matrix with weighted criteria and mandatory gate conditions.
3. Run due diligence on delivery evidence (sample runbooks, metrics, incident history, references).
4. Define joint operating model, including RACI, decision gates, and weekly governance cadence.
5. Agree SLA package and quality thresholds per wave stage.
6. Run pilot wave and recalibrate capacity, governance, and escalation mechanics.

</Steps>

## Minimum Artifacts

- Partner capability map against migration demand profile.
- Agreed operating model (RACI + governance forums + escalation matrix).
- SLA and KPI baseline per wave stage.
- Risk register with owner assignments and mitigation triggers.
- Pilot wave acceptance report with go/no-go recommendation for scale.

## Worked Example: Mixed Rehost/Replatform Wave

A program with 120 workloads (70% rehost, 30% replatform to Kubernetes) typically needs two paired
squads: an infrastructure-migration squad sized for rehost throughput, and a platform-engineering squad
covering containerization and cluster onboarding. Capacity planning should reflect this split explicitly
rather than averaging FTEs across a single generic "migration engineer" role, because rehost and
replatform waves draw on different skills, tooling, and cutover risk profiles.