Cutover: Was ich darunter verstehe
Cutover ist der Moment, in dem ein altes System, ein alter Prozess oder eine alte Umgebung auf die neue Lösung umgestellt wird. Kurz: Der Wechsel von „bisher“ zu „ab jetzt“.
Das klingt simpel. Ist es aber nicht. Ein Cutover ist oft der kritischste Teil eines Projekts. Hier entscheidet sich, ob Daten sauber migrieren, Teams arbeitsfähig bleiben und Kunden nichts merken. Genau deshalb plane ich den Cutover nie nebenbei. Ich behandle ihn wie ein eigenes Projekt.
Cutover: Warum er so wichtig ist
Viele Teams investieren Monate in Entwicklung und Testen. Dann kommt der Go-Live und alles wird hektisch. Genau hier entstehen Fehler. Nicht, weil das System schlecht ist. Sondern weil der Übergang nicht klar genug geplant wurde.
Ein guter Cutover reduziert drei Dinge:
- Risiko – weniger Überraschungen am Go-Live-Tag.
- Ausfallzeit – der Wechsel passiert schneller und kontrollierter.
- Stress – jeder weiß, was wann zu tun ist.
Wenn ich einen Cutover sauber aufsetze, habe ich am Ende keine „Hoffentlich klappt’s“-Situation. Ich habe einen Plan, eine Reihenfolge und einen Rückweg.
Cutover: Die wichtigsten Arten
Es gibt nicht den einen Cutover. Ich unterscheide meist zwischen diesen Varianten:
- Big-Bang-Cutover: Alles wird an einem Zeitpunkt umgestellt. Schnell, aber riskant.
- Phasenweiser Cutover: Teile werden schrittweise umgestellt. Weniger Risiko, aber komplexer.
- Parallelbetrieb: Alt und neu laufen gleichzeitig. Sicherer, aber teuer und aufwendig.
- Blue-Green-Ansatz: Neue Umgebung wird vollständig vorbereitet und dann umgeschaltet. Stark für digitale Systeme.
Wenn ich ehrlich bin: Die beste Variante hängt nicht von der Theorie ab. Sie hängt davon ab, wie kritisch das System ist, wie viele Daten betroffen sind und wie viel Ausfallzeit du dir leisten kannst.
Cutover: Die Fragen, die ich vorab kläre
Bevor ich überhaupt an den Go-Live denke, beantworte ich diese Fragen:
- Was genau wird umgestellt?
- Welche Systeme, Teams und Kunden sind betroffen?
- Wie lange darf die Downtime maximal sein?
- Welche Daten müssen migriert werden?
- Was ist der Rollback-Plan, wenn etwas schiefgeht?
- Wer entscheidet im Ernstfall?
Ohne diese Antworten baust du keinen Cutover. Du baust ein Problem mit Timer.
Cutover: So plane ich ihn praktisch
Ich halte den Cutover immer so einfach wie möglich. Nicht einfacher. Nur ohne unnötige Komplexität.
1. Aufgabenliste erstellen
Jede Aktion bekommt einen klaren Owner, eine Reihenfolge und einen Zeitstempel. Keine schwammigen Aufgaben wie „System prüfen“. Stattdessen:
- Datenbank einfrieren
- Letzten Datenexport starten
- Migration validieren
- DNS oder Routing umstellen
- Login testen
- Business-Check freigeben
2. Test-Cutover durchführen
Ich mache mindestens einen Probelauf. Warum? Weil Pläne auf Papier fast immer besser aussehen als in der Realität. Ein Test-Cutover zeigt mir, wo es hakt:
- zu langsame Schritte
- fehlende Zugriffsrechte
- falsche Annahmen über Abhängigkeiten
- unklare Freigaben
Wer den Probelauf auslässt, kauft sich Überraschungen zum Go-Live-Preis ein.
3. Kommunikationsplan definieren
Ein Cutover scheitert nicht nur technisch. Er scheitert oft kommunikativ. Deshalb brauche ich vorher klare Nachrichten für interne Teams, Support, Management und bei Bedarf Kunden.
Jede Nachricht sollte enthalten:
- Was passiert?
- Wann passiert es?
- Was bedeutet das für mich?
- Was muss ich tun?
- Wer ist erreichbar?
Cutover: Die häufigsten Fehler
Ich habe die typischen Fehler immer wieder gesehen. Die meisten sind vermeidbar.
- Kein Rollback: Wenn du nicht zurück kannst, bist du nicht bereit.
- Zu viele offene Punkte: Unklare Abhängigkeiten machen den Go-Live fragil.
- Kein Freeze: Wenn sich Daten während des Wechsels ändern, wird’s schnell chaotisch.
- Kein Owner pro Task: Ohne Verantwortung bleibt alles liegen.
- Keine Prioritäten: Nicht jeder Schritt ist gleich wichtig. Erst kritische Pfade, dann Rest.
Mein Standard: Ich markiere alles, was den Go-Live blockiert, als kritisch. Alles andere ist nachrangig. So bleibt der Fokus klar.
Cutover: Rollback richtig denken
Rollback ist kein Zeichen von Schwäche. Es ist Absicherung. Ein guter Cutover hat immer einen definierten Rückweg.
Ich frage mich vorab:
- Was löst den Rollback aus?
- Wer entscheidet darüber?
- Wie lange dauert der Rückwechsel?
- Gehen dabei Daten verloren?
- Wie informiere ich alle Beteiligten?
Wenn der Rollback länger dauert als der eigentliche Cutover, ist das ein Warnsignal. Dann fehlt meist Vorbereitung oder technische Klarheit.
Cutover: Meine einfache Checkliste
Wenn ich einen Cutover vorbereite, arbeite ich diese Punkte ab:
- Scope klar: Was gehört rein, was nicht?
- Zeiten festgelegt: Start, Ende, Puffer.
- Owner bekannt: Für jeden Schritt eine Person.
- Abhängigkeiten geprüft: Systeme, Daten, Zugriffe.
- Testlauf gemacht: Kein Live-Wechsel ohne Übung.
- Rollback definiert: Klar, schnell, machbar.
- Kommunikation vorbereitet: Intern und extern.
- Monitoring aktiv: Nach dem Wechsel sofort messen.
Cutover: So wird er nach dem Go-Live sauber
Der Cutover endet nicht mit dem Umschalten. Danach kommt die Stabilisierung. Genau hier zeigt sich, ob die Planung gut war.
Ich achte direkt auf:
- Fehlerlogs
- Performance
- Benutzerzugriffe
- Datenkonsistenz
- Support-Anfragen
Wenn die ersten 24 bis 72 Stunden sauber laufen, ist das ein gutes Zeichen. Dann geht es nicht mehr um Panik, sondern um Feinschliff.
Cutover: Welche Tools und Standards helfen
Ich verlasse mich nicht auf Tools allein. Aber gute Standards machen den Cutover deutlich robuster. Für das Change- und Release-Management helfen zum Beispiel diese Ressourcen:
- ITIL – für saubere Change- und Release-Prozesse
- Atlassian Incident Management – nützlich für Kommunikation und Reaktion
- AWS Well-Architected Framework – hilfreich für stabile Übergänge in Cloud-Umgebungen
- Microsoft Learn – gute Praxisdokumentation für technische Umstellungen
Wichtig: Tools helfen nur, wenn der Prozess klar ist. Sonst automatisierst du Chaos.
Cutover: Mein Fazit
Ein Cutover ist kein technischer Akt. Es ist ein kontrollierter Übergang unter Druck. Wer ihn ernst nimmt, plant wie ein Operateur: präzise, vorbereitet, mit Plan B.
Mein Ansatz ist einfach: Scope klären, Schritte reduzieren, Testlauf machen, Kommunikation festziehen, Rollback sichern. Mehr brauchst du oft nicht. Aber das musst du sauber machen.
Cutover ist am Ende keine Frage von Glück. Es ist eine Frage von Vorbereitung, Klarheit und Disziplin.