Runbook

Go-Live-Checkliste für Software

Go-Live-Checkliste für die Einführung eines neuen Systems oder die Ablösung eines alten: Cutover-Plan, Datenmigration, Schulung, Hypercare und Abschaltung.

  • Typischer Rhythmus pro Go-Live
  • Die Checkliste 5 Abschnitte, 23 Punkte
  • Variablen {{system}} {{go_live_date}}
Vorlage verwenden Kostenlos, ohne Kreditkarte. Importiert die Checkliste in Ihre Runbook-Organisation.

Read in English: Software Go-Live Checklist

Diese Checkliste ist für den Moment gedacht, in dem ein neues System zum ersten Mal für echte Nutzer live geht oder ein altes ablöst. Typische Fälle sind ein neues CRM, ERP oder Ticketsystem, ein neu gebautes Kundenportal oder eine interne Anwendung, die Excel-Listen ersetzt. Ein Go-Live ist ein einmaliges Ereignis mit Cutover: Daten werden umgezogen, Nutzer wechseln und das alte System wird eingefroren. Das unterscheidet ihn von einem normalen Release, und die größten Risiken liegen bei Menschen und Daten, nicht im Code.

Wer verantwortlich ist

Eine Go-Live-Leitung, meist die Projektleitung oder die technische Leitung, ist für den Durchlauf verantwortlich und leitet das Go/No-Go-Meeting. Die fachlich verantwortliche Person des Systems gibt Daten und Nutzerbereitschaft frei. Datenmigration, Schulung und Support den Personen zuweisen, die sie tatsächlich erledigen, damit der Durchlauf zeigt, wer was bestätigt hat.

Typische Fehler

  • Keine Cutover-Generalprobe. Die komplette Datenmigration vor dem Go-Live mindestens einmal auf einer Kopie durchspielen und die Zeit messen. Der echte Lauf dauert immer länger als geschätzt.
  • Zu früh oder gar nicht geschult. Eine Schulung einen Monat vorher ist vergessen. Kurz vor dem Termin schulen und eine kurze Anleitung für die erste Woche mitgeben.
  • Das alte System bleibt beschreibbar. Wer nach dem Cutover noch im alten System erfassen kann, erzeugt zwei Datenstände. Es zu einem festen Zeitpunkt auf schreibgeschützt setzen.
  • Keine Hypercare-Phase. Die ersten Tage brauchen zusätzlichen Support und schnelle Korrekturen. Vor dem Termin planen, wer bereitsteht, nicht erst nach den ersten Beschwerden.
  • Kein Entscheidungspunkt für den Rückweg. Vorab festlegen, bis wann eine Rückkehr zum alten System möglich ist und wer darüber entscheidet.

Die Checkliste: Go-Live {{system}} am {{go_live_date}}

Bereitschaft

  • Go-Live-Termin {{go_live_date}} und Cutover-Fenster mit der fachlich verantwortlichen Person bestätigt
  • Abnahmetest (UAT) von der fachlich verantwortlichen Person freigegeben
  • Offene Fehler gesichtet, keiner blockiert den Go-Live
  • Benutzerkonten, Rollen und Berechtigungen eingerichtet und mit einer Stichprobe von Nutzern geprüft
  • Schnittstellen zu anderen Systemen End-to-End mit produktionsnahen Daten getestet
  • Backups, Monitoring und Alerting für {{system}} eingerichtet

Daten und Cutover-Plan

  • Cutover-Plan listet jeden Schritt mit verantwortlicher Person und erwarteter Dauer
  • Komplette Datenmigration auf einer Kopie geprobt und Zeit gemessen
  • Regeln zur Datenprüfung vereinbart, etwa Anzahl Datensätze und Stichproben wichtiger Datensätze
  • Rückfallplan schriftlich festgehalten, mit dem spätesten Zeitpunkt, zu dem er noch nutzbar ist

Menschen

  • Key User geschult und mit einer kurzen Anleitung für die erste Woche versorgt
  • Support-Kontakte und Eskalationsweg allen Nutzern mitgeteilt
  • Go-Live-Ankündigung mit Termin, Ausfallzeit und Änderungen an die Nutzer verschickt

Cutover

  • Go/No-Go-Entscheidung getroffen und mit den Namen der Entscheidenden dokumentiert
  • Altes System zum vereinbarten Zeitpunkt auf schreibgeschützt gesetzt oder Datenerfassung eingefroren
  • Finale Datenmigration ausgeführt und Protokoll auf Fehler geprüft
  • Migrierte Daten gegen die vereinbarten Zahlen und Stichproben geprüft
  • Schnittstellen, DNS oder Links auf {{system}} umgestellt
  • Key User bestätigen, dass sie sich anmelden und ihre Hauptaufgaben erledigen können

Hypercare und Abschluss

  • Hypercare-Team und Zeiten für die ersten Tage nach dem Go-Live besetzt
  • Meldungen aus der Hypercare erfasst, priorisiert und bis zur Lösung verfolgt
  • Übergabe vom Projektteam an den regulären Support abgeschlossen
  • Altes System nach der vereinbarten Aufbewahrungsfrist archiviert und abgeschaltet optional
Checkliste als Markdown

Häufige Fragen

Was ist ein Cutover-Plan?

Ein Cutover-Plan ist der Ablaufplan für den Wechsel vom alten auf das neue System, Schritt für Schritt. Er listet jeden Schritt mit verantwortlicher Person, erwarteter Dauer und den Prüfungen, die den Erfolg bestätigen. Außerdem nennt er den spätesten Zeitpunkt, zu dem eine Rückkehr zum alten System noch möglich ist.

Was bedeutet Hypercare nach dem Go-Live?

Hypercare ist eine kurze Phase mit zusätzlichem Support direkt nach dem Go-Live. Das Projektteam bleibt verfügbar, um Probleme schnell zu beheben, Fragen der Nutzer zu beantworten und die Datenqualität zu beobachten. Sie endet mit einer geplanten Übergabe an den regulären Support.

Wann sollte man einen Go-Live verschieben?

Verschieben, wenn ein blockierender Fehler offen ist, wenn die Generalprobe Datenprobleme gezeigt hat, die noch nicht behoben sind, oder wenn die Key User nicht bereit sind. Die Entscheidung ein bis zwei Tage vor dem Termin im Go/No-Go-Meeting anhand vereinbarter Kriterien treffen. Früh zu verschieben ist viel günstiger als ein Rückweg, nachdem Nutzer schon Daten erfasst haben.

Aktualisiert

Send feedback

Ideas, bugs, questions: we read every message.