---
title: Umfang, Zeitrahmen und Kundenkommunikation
description: Stimmen Sie Wellenumfang, Zeitfenster und Kundenkommunikation ab, einschließlich Cutover- und Hibernate-Abläufen für die STACKIT-Migrationslieferung heute.
sidebar:
  label: Umfang, Zeit und Kommunikation
  order: 5
source_url: "https://framework.stackit.cloud/de/migration/design-and-mobilize/migration-factory-setup/scope-timeline-and-communications/"
source_file: "docs/de/migration/design-and-mobilize/migration-factory-setup/scope-timeline-and-communications.mdx"
---

## Ziel

Für stabile Wellen braucht es ein abgestimmtes Steuerungsmodell für Umfang, Zeit und Kommunikation.
Das ist besonders in Cutover- und Hibernate-Fenstern entscheidend, da dort technische und fachliche
Risiken zusammenlaufen.

## Baseline für Umfang und Zeit

<CardGrid>
  <Card title="Grenzen des Wellenumfangs">
    Definiert In-Scope-Workloads, zurückgestellte Themen, blockierende Abhängigkeiten und klare
    Ausschlüsse.
  </Card>
  <Card title="Zeitfenster-Architektur">
    Definiert Freeze-, Umsetzungs-, Validierungs- und Rollback-Fenster.
  </Card>
  <Card title="Change-Control-Modell">
    Legt fest, wer Scope-Änderungen bis zu welchem Cut-off freigeben darf.
  </Card>
  <Card title="Lieferzusagen">
    Richtet Durchsatzannahmen und Sicherheitszuschläge mit Partner und Kundenseite aus.
  </Card>
</CardGrid>

## Modell für Kundenkommunikation

- **Adressatengruppen**: Getrennte Kommunikationsstränge für Management, Fachbereiche,
  Betrieb und betroffene Nutzer.
- **Ereignisbasierte Vorlagen**: Vorlagen für Terminbestätigung, Cutover-Start,
  Rollback-Aktivierung und Wiederherstellung.
- **Entscheidungs-Checkpoints**: Go/No-Go-Status zu vereinbarten Meilensteinen kommunizieren.
- **Single Source of Truth**: Ein verbindlicher Statuskanal verhindert widersprüchliche Aussagen.

## Cutover- und Hibernate-Planung

<Steps>

1. Cutover-Ziel, Ausfalltoleranz und Abnahmekriterien mit der Kundenseite festlegen.
2. Hibernate-Kriterien für Services definieren, die während der Umstellung pausieren müssen.
3. Reaktivierungsfolge und Servicevalidierung für den Wiederanlauf abstimmen.
4. Kommunikationstiming mit den technischen Ausführungspunkten proben.
5. Rollback-Kommunikation genauso belastbar vorbereiten wie den Erfolgsfall.

</Steps>

## Häufige Risiken

- Scope-Änderungen werden zu spät im Wellenlebenszyklus akzeptiert.
- Kommunikationsrhythmus passt nicht zu den realen technischen Entscheidungszeitpunkten.
- Hibernate-Dauer wird im Verhältnis zur Datenvalidierung unterschätzt.
- Rollback ist technisch dokumentiert, aber operativ nicht ausreichend kommuniziert.