Zum Inhalt springen
Beta

Run

Run macht aus Migrationsergebnissen belastbaren Cloud-Betrieb auf STACKIT.

In 2 Trails

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.

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.

  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.

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 verbindet kurzfristige Stabilisierung mit langfristigem Cloud-Betrieb. Das folgende Modell zeigt den Ablauf von der Migrationsübergabe bis zum stabilen Day-2-Betrieb.

Seitlich wischen, um das ganze Diagramm zu sehen
Run-Phasen-Modell Von der Migrationsstabilisierung in den belastbaren Cloud-Regelbetrieb auf STACKIT. Run-Phasen-ModellVon der Migrationsstabilisierung in den belastbaren Cloud-Regelbetrieb auf STACKIT.Run-AblaufMigrate-ÜbergabeCutover abgeschlossen, bekannte RestrisikenHypercarePost-Cutover-Stabilisierung, schnelle NacharbeitsbrückeOperateStabiler Cloud-Regelbetrieb: Zuverlässigkeit, Security, EffizienzSupportIncidents und Service Requests, Shared-Responsibility-RegelnCustomer SuccessZentraler Kontaktpunkt, Adoption und WertrealisierungSemantic MapBrückenstufeÜbergangskontext von Migrate zu RunTechnikstromHypercare und Operate im stabilen RegelbetriebBetriebsstromOperate-Ausführung und Governance-KadenzServicestromSupport, Incidents und RequestsWertstromCustomer Success und Adoption

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.

Brücke von Projekt zu Betrieb

Hypercare stabilisiert offene Migrationsthemen, bevor daraus dauerhafte Störungsmuster entstehen.

Klare Ownership und Supportmodell

Eindeutige Verantwortungen für Störungen und Service Requests reduzieren Reibung und Eskalationen.

Betriebliche Resilienz

Monitoring, Observability und Runbook-Reife stärken Zuverlässigkeit und Wiederherstellungsverhalten.

Dauerhafte Wertrealisierung

Kontinuierliche Verbesserungen halten Performance, Kosten und Service-Ergebnisse im Zielbild.

  • Hypercare: Stabilisierungsbrücke von Migrate nach Run mit schneller Rückkopplung und kontrollierter Nacharbeit.
  • Operate: Regelbetrieb in der Cloud auf STACKIT mit Fokus auf Stabilität, Security und Effizienz.
  • Support: Betriebsmodell für Störungen und Service Requests zwischen Kunde und Anbieter.
  • Customer Success: Baustein mit zentralem Kontakt für Adoption und Outcome-Tracking.

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.