---
title: Run
description: Run stabilisiert migrierte Workloads auf STACKIT, operationalisiert Betriebsprozesse und sichert langfristigen Nutzen durch kontinuierliche Verbesserung.
hero:
  tagline: Run macht aus Migrationsergebnissen belastbaren Cloud-Betrieb auf STACKIT.
  illustration:
    name: product
    position: left
sidebar:
  label: Übersicht
  order: 0
source_url: "https://framework.stackit.cloud/de/migration/run/"
source_file: "docs/de/migration/run/index.mdx"
---

## Überblick: Diese Phase

Run ist der Zielzustand der Migration: Workloads laufen auf STACKIT mit klarer Verantwortung,
stabilem Betrieb und messbarer Servicequalität.

Die Phase startet mit der Stabilisierung direkt nach dem Cutover und geht in den langfristigen
Regelbetrieb über. Hier wird aus Migration ein tragfähiges Betriebsmodell.

## Überblick

Run ist nicht nur ein Nachgang zur Migration, sondern das strategische Zielbild.
Für viele Programme ist das operative Leitmotiv klar: möglichst viele Workloads in einen
belastbaren "Runs on STACKIT"-Status überführen.

Die Phase verbindet Migrate über Hypercare mit dem laufenden Betrieb und prüft das
Target Operating Model in der Praxis.

## Wann Run startet und endet

<Steps>

1. Start mit Hypercare direkt nach dem Cutover, solange Projekt- und Migrationsteams greifbar sind.
2. Operative Lücken schließen, zum Beispiel fehlendes Monitoring, Alerting und Runbook-Anpassungen.
3. Übergabe in DevOps-Verantwortung oder an ein klassisches Betriebsteam formalisieren.
4. Support- und Service-Request-Modell zwischen Kunde und Anbieter verbindlich aktivieren.
5. In den Regelbetrieb mit kontinuierlicher Optimierung und regelmäßiger Betriebsmodell-Prüfung überführen.

</Steps>

Je nach Betriebsmodell können Teile der Übergabe bereits während Migrate beginnen und mit Wellen überlappen.

Operating Model Handover ist in Migrate verankert und kann bereits vor Start der Run-Phase aktiv sein.

## Run-Phasenmodell und Module

Run verbindet kurzfristige Stabilisierung mit langfristigem Cloud-Betrieb. Das folgende Modell zeigt den
Ablauf von der Migrationsübergabe bis zum stabilen Day-2-Betrieb.

<RunPhaseModuleModelSvg
  style={{ width: "100%", maxWidth: "1320px", height: "auto", display: "block" }}
/>

## Semantische Einordnung

Das Run-Modell arbeitet mit vier semantischen Strömen zur klaren Einordnung von Verantwortung und Zweck:

- **Stabilisierung**: Hypercare schließt Post-Cutover-Risiken, solange Delivery-Teams noch direkt eingebunden sind.
- **Betrieb**: Operate sichert Zuverlässigkeit, Security, Observability und kontrollierte Änderungen im Regelbetrieb.
- **Service**: Support klärt Incident-Verantwortung sowie provider- und kundenseitige Service Requests.
- **Nutzen**: Customer Success sichert dauerhafte Adoption und Business-Outcome.

## Warum diese Phase wichtig ist

<CardGrid>
  <Card title="Brücke von Projekt zu Betrieb">
    Hypercare stabilisiert offene Migrationsthemen, bevor daraus dauerhafte Störungsmuster entstehen.
  </Card>
  <Card title="Klare Ownership und Supportmodell">
    Eindeutige Verantwortungen für Störungen und Service Requests reduzieren Reibung und Eskalationen.
  </Card>
  <Card title="Betriebliche Resilienz">
    Monitoring, Observability und Runbook-Reife stärken Zuverlässigkeit und Wiederherstellungsverhalten.
  </Card>
  <Card title="Dauerhafte Wertrealisierung">
    Kontinuierliche Verbesserungen halten Performance, Kosten und Service-Ergebnisse im Zielbild.
  </Card>
</CardGrid>

## Module in dieser Phase

- [Hypercare](/de/migration/run/hypercare/overview/): Stabilisierungsbrücke von Migrate nach Run mit schneller Rückkopplung und kontrollierter Nacharbeit.
- [Operate](/de/migration/run/operate/overview/): Regelbetrieb in der Cloud auf STACKIT mit Fokus auf Stabilität, Security und Effizienz.
- [Support](/de/migration/run/support/overview/): Betriebsmodell für Störungen und Service Requests zwischen Kunde und Anbieter.
- [Customer Success](/de/migration/run/customer-success/overview/): Baustein mit zentralem Kontakt für Adoption und Outcome-Tracking.

## Typische Ergebnisse

Zum Ende der initialen Run-Etablierung sollten vorliegen:

- **Stabilisierter Post-Cutover-Betrieb**: Kritische Themen aus der Migration sind behoben oder mit klaren Maßnahmen abgesichert.
- **Geschlossene Betriebslücken**: Fehlendes Monitoring, Alerting und betriebliche Nachweise sind umgesetzt.
- **Validiertes Übergabemodell**: DevOps- oder klassisches Betriebsmodell ist in realen Situationen im Betrieb getestet.
- **Aktives Supportmodell**: Incident- und Request-Pfade sind produktiv, dokumentiert und messbar.
- **Belastbare Run-Governance**: Servicequalität, Kostenentwicklung und Verbesserungs-Backlog werden regelmäßig gesteuert.