Migrationswochenende

…oder auch Cut-Over

Endlich Wochenende – das ist häufig der Höhepunkt eines Transitionsprojektes. Auf diesen Termin wurde monatelang hingearbeitet, am Migrationswochenende findet der Produktivwechsel statt. Wie plant man eine solch konzertierte Aktion? Hier braucht es einen Generalstab und teilweise Planung im Minuten-Takt. Trust in Change stellt die Vorgehensweise zum Cut-Over dar und klärt über häufige Fallstricke auf.

Die Terminwahl

Sehr häufig werden Transitionsprojektlaufzeiten mit dem neuen Dienstleister vereinbart, ohne auf den Cut-Over zu schauen. Oft ist auch nicht festgelegt, ob eine Big-Bang Migration oder eine schrittweise Umstellung der Weg der Wahl ist. Dies beeinflusst den Projektablauf immens, daher muss dies vor der Terminfindung klargestellt werden.

Big-Bang oder Schrittweise?

Bei einem Big-Bang werden alle produktiven Systeme an einem einzelnen Wochenende migriert. Dies hat den Vorteil, dass der Übergang zum neuen Dienstleister zu einem klar festgelegten Termin stattfindet und es keine – oder weniger – geteilte Verantwortung gibt, so dass der Mixed Mode vermieden wird. Im ganzen Projekt wird auf einen Termin hingearbeitet. Der Nachteil ist, dass dieses Wochenende mit höherem Risiko und einer deutlich komplexeren Migration einhergeht. Bei guter Koordination und gewissenhaften Testmigrationen ist dieses Risiko jedoch häufig zu beherrschen.

Bei einer schrittweisen Umstellung findet wiederholt ein Cut-Over nach gewissen Kriterien statt. Es werden z.B. Anwendungsgruppen wie SAP / non-SAP Anwendungen gemeinsam migriert, Infrastrukturen wie Domain- und Fileservice zusammengefasst. In anderen Fällen wird je Standort migriert, nach Organisationseinheiten oder nach Kundengruppen. Hier sind die Vorteile ein geringeres Risiko der Migrationen und ein möglicher Start mit weniger Geschäftskritischer Komponenten. Nachteilig wirkt sich hier der Mixed Mode aus. Nicht nur technisch sind aufgrund des geänderten Leistungsschnitts Überraschungen häufig. Alter und neuer Provider betreiben nach jedem Migrationsschritt eine anders aufgeteilte Infrastruktur. Prozesse müssen immer wieder angepasst werden, Supportwege ändern sich und die Zusammenarbeit aller Parteien wird bei jeder größeren Störung belastet.

Unsere Empfehlung ist, möglichst große zusammenhängende Blöcke zu migrieren, wenn möglich als Big Bang. Dies lässt sich mit besonders gutem Projektmanagement, viel Erfahrung und intensiven Testmigrationen erfolgreich umsetzen. Alternativ ist der Aufbau einer Migrationsfabrik für wiederholende Migrationen erforderlich.

Terminfindung

Um möglichst große Migrationen erfolgreich umzusetzen, sind lange Wochenenden sehr beliebt. Migrationen über Ostern, die Maifeiertage und je nach Lage auch dem Tag der Deutschen Einheit. Kompliziert wird es ein langes Wochenende bei International genutzter IT zu finden. Hier sind maximal die Lücken in Target Tagen oder banking days erfolgsversprechend.

Beachten Sie auch die frühzeitige Einbeziehung der Fachbereiche in die Terminfestlegung. Häufig sind Termine rund um Rechnungsläufe, Gehaltsläufe, Quartals- und Jahres-End-Verarbeitung nicht für Migrationen geeignet. Ebenso können große Veranstaltungen und Messen, Schlussverkaufszeiten oder andere Peaks in der Auftragslast die Termine beeinflussen. Wenn vorhanden, sollten Sie den Release Kalender der IT für die Terminfindung intensiv nutzen. Üblicherweise ersetzt eine Migration mindestens einen Ihrer Release Termine – dennoch müssen erforderliche Funktionalitäten, wie z.B. regulatorische Anforderungen, umgesetzt werden.

Zu guter Letzt bereiten Sie immer einen Alternativtermin vor. Dieser sollte nie offiziell und initial nur mit dem Kundenmanagement besprochen werden. Ein nach außen alternativloser Termin sollte nach innen abgesichert werden. Wenn Sie erst nachdem eine Verschiebung nicht mehr vermeidbar ist, nach neuen Terminen suchen, vergrößert sich der Verzögerung signifikant.

Der Cut-Over Plan

Der Cut-Over Plan ist die Checkliste mit der Sie Ihr Migrationswochenende steuern. Es ist prinzipiell mit anderen komplexen Checklisten wie der Vorbereitung eines Fluges, eines Raketenstarts oder ähnlichem vergleichbar. Auch in diese Checkliste sollte sehr viel Sorgfalt in die Entwicklung gesteckt werden und sie kann gar nicht genug getestet werden.

Der Grobplan

Dieser definiert die groben Rahmenbedingungen in der Außenkommunikation mit den Betroffenen. Hier sind rund ein Dutzend Zeitfenster festzulegen in denen folgende Aktivitäten fallen:

1. Ende der aktiven online Nutzung
2. Abschalten End-Anwender Zugriffe & Externe Schnittstellen
3. Reports & Exports für Vorher / Nachher Vergleiche
4. Herunterfahren der Alt-Landschaft
5. Datenmigration
6. Anpassung von Schnittstellen
7. Hochfahren beim Neu-Dienstleister
8. Freischalten Test Anwender & interner Schnittstellen
9. Durchführen der Anwendungs- und Integrationstests
10. Korrektur von Kategorie 1 Findings
11. Go / No-Go Entscheidung
12. Freischalten aller Anwender & externer Schnittstellen
13. Produktiv Start & Hypercare Phase

Zusätzlich ist noch der Point of no Return fest zu legen. Dieser ist abhängig vom spätesten Zeitpunkt zu dem der Betrieb wieder aufgenommen sein muss und von der Dauer des Fallback / Rollback Plans.

Der Detailplan

Jede dieser Phasen sind mit einem vollständigen, häufig Minutenfahrplan oder Cut-Over Plan genannten, Detailplan zu hinterlegen. Hierfür sind zum Teil bestehende Pläne aus dem Continuity Management wie Wiederanlaufpläne des Desaster Recovery als Quelle zu nutzen.

Bei einigen Phasen, zum Beispiel der Datenmigrationsphase, sind wichtige Ressourcenmengen zu beachten. Dies können Mitarbeiter sein, welche Migrationen durchführen, aber auch Netzkapazitäten oder Datenvolumina im Backup. Diese sind en Detail im Plan festzuhalten, damit der Bedarf innerhalb einer jeweiligen Zeiteinheit die vorhandene Menge nicht überschreitet. Gegebenenfalls müssen Laufzeiten angepasst werden.

Checkpoints

Wichtiger Bestandteil des Cut-Over Plans sind Checkpoints oder Meilensteine. Zu jedem Übergang einer Phase definieren Sie mindestens einen Checkpoint, zu dem das Team zusammenkommt und über den Stand berichtet. Hierbei laden Sie zu expliziten Sessions mit den Team-Leads der aktuellen und der nächsten Aktivitäten ein, dazu das Projektleiter Team, sowie ggf. ein Mitglied des Entscheidungsgremiums. Die Ergebnisse der Checkpoints sind unbedingt zu protokollieren und im Anschluss an alle Beteiligten zu publizieren.

Üben, Proben, Testen und die Generalprobe

Ein erfolgreiches Migrationswochenende ist wie eine Theateraufführung. Es werden einzelne Szenen geübt – zum Beispiel die Migration einer einzelnen Anwendung, die Erstellung von Vergleichsreports oder der Wiederanlauf der SAP Landschaft. Dieses Üben wird durch die einzeln für die “Szenen” Verantwortlichen durchgeführt bestätigt die einzelnen Schritte und deren Timing. Dann finden erste gemeinsame Proben statt, bei denen es besonders darauf ankommt, den richtigen Einsatz zu finden. Bisher nicht identifizierte Schnittstellen und Abhängigkeiten tauchen auf und müssen geklärt werden. Eine erste Kostümprobe ohne Publikum zeigt Schachstellen auf, welche behoben werden.

Als nächstes kann getestet werden. Erst können die Nicht-Produktiven Stages der IT-Landschaft migriert werden. Entwicklungs- und Abnahme Umgebungen eignen sich hierfür. Bitte beachten Sie hier bei der Planung, dass Sie nicht im luftleeren Raum umziehen. Auch hier müssen Sie in der Planung Ihren Release Kalender beachten. Von Vorteil ist, dass diese Umgebungen häufig zu normalen Arbeitszeiten umgezogen werden können, Sie also nicht ein weiteres Wochenende blockieren müssen.

Als letztes empfehlen wir die Durchführung einer Generalprobe. Dies ist die Migration Ihrer Produktivlandschaft ohne den finalen Cut-Over. Hierbei werden gewisse Bestandteile des Cut-Over Plans nur simuliert und die Produktive Landschaft muss nicht zwingend abgeschaltet werden. Hierbei können Sie feststellen, das Rechenzentren je nach Zeitfenster ein anderes Antwortverhalten an den Tag legen. An vielen Wochenenden ist zwar der Online Betrieb stark reduziert, gleichzeitig finden jedoch häufig Full-Backups statt, welche wiederum andere Bestandteile der Infrastruktur auslasten.

Der Bereitschaftsplan

Neben dem Cut-Over Plan ist auch ein Bereitschaftsplan zu erstellen. Nur so können Sie sicher sein im Fall der Fälle auf die richtigen Experten zurück greifen zu können, um ein Problem innerhalb Ihrer Migration zu lösen, ohne Die Ihnen nur der Rollback übrig geblieben wäre.

Im Bereitschaftsplan benötigen Sie sowohl Mitarbeiter der aktiv Beteiligten Einheiten, als auch Mitarbeiter von unterstützenden Einheiten, Mitarbeiter von weiteren Dienstleistern und jeweils Eskalationsinstanzen. Stellen Sie sicher, das für alles, welches Ihre Migration fehlschlagen lassen kann, 24×7 das ganze Wochenende über Support bereitsteht. Die Kosten für diese Bereitschaft sind es Wert.

Besonders zu beachten ist, dass der Alt-Provider ausreichend Personal in Bereitschaft hat, nicht zuletzt um die Rollback Aktivitäten durchführen zu können.

Der Schichtplan

Am Migrationswochenende wird häufig rund um die Uhr gearbeitet. Auch wenn dies aufgrund von reduzierten Aufwänden nicht der Fall ist, sollten Sie einen klaren Schichtplan erstellen. Hierbei entdecken Sie Unterbesetzung gewisser Fach-Mitarbeiter, welche Sie möglichst beheben sollten. Beachten Sie besonders, dass Mitarbeiter häufig in dualer Rolle beteiligt sind, zum einen Aktiv Cut-Over Aktivitäten durchführen und davor oder danach in Bereitschaft zur Problembehebung sind. Hier sind unbedingt maximal mögliche Arbeitszeiten zu beachten. Auch wenn an solchen Wochenenden häufig länger gearbeitet wird, als vorgesehen und teilweise auch länger als arbeitsrechtlich zugelassen, haben Sie die Fürsorgepflicht. Wenn ein Mitarbeiter außerhalb der Cut-Over Aktivitäten Unterstützung leisten muss, kann dies gegebenenfalls die nachfolgenden Cut-Over Aktivitäten gefährden. Stellen Sie daher sicher, genügend Personal auch für Ausnahmefälle zu haben.

Zur Schichtorganisation gehört auch die organisatorische Klärung der Rahmenbedingungen. Haben Sie einen “War-Room” von dem aus die Migration gesteuert wird? Oder doch lieber nur eine zentrale Teams-Session mit mehreren Unter-Räumen zur Besprechung aktueller Themen? Wie sieht es mit Verpflegung aus, auch in der Nachtschicht? Ist der Zutritt auch am Wochenende gesichert? Tests müssen mindestens zum Teil vor Ort durchgeführt werden. Stehen für Mitarbeiter, welche 10-12 Stunden gearbeitet haben, Hotelzimmer vor Ort zur Verfügung, da diese nicht mehr selbst fahren dürfen? Dies sind nur ein paar der zu klärenden organisatorischen Themen.

Als letztes ist auch die Hypercare Phase im Schichtplan abzudecken. Am Ende der Migration ist häufig nicht mehr viel Zeit bis zum Hypercare Start, Sie sollten sicherstellen hier unterschiedliche Teams einzuplanen.

Das Migrationswochenende

Und irgendwann ist es so weit. Die letzte Woche vor dem Migrationswochenende hat begonnen. Die Checklisten sollten final vervollständigt und aus allen Proben mit neuen Erkenntnissen angepasst sein. Sie werden in der Woche vor der Migration sich mit Ihrem Team vermutlich in Dailies über den Fortschritt abstimmen. Ein letzter Lenkungsausschuss vor dem Migrationswochenende stellt den Buy-In des Managements in Ihre Vorgehensweise sicher.

Der erste Checkpoint ist oft vor dem Ende der Abschaltung der Online Nutzer. Häufig müssen noch fachliche Aktivitäten vor dem Start der Migration erfolgt sein, welche gesichert beendet und im Stand der Migration enthalten sein müssen. Nachdem Sie von den Fachbereichen im nächsten Checkpoint das OK bekommen, geht es los – das Aussperren der Anwender auf der Alt-Umgebung beginnt. Ihr Service Desk wird vermutlich trotz intensiver Kommunikation an die End-Anwender vermehrt Anfragen bekommen, von Mitarbeitern an denen die anstehende Migration vorbei gegangen ist.

An diesem Wochenende ist besonders die Kommunikationsfähigkeit, Sozialkompetenz und schnelle Auffassungsgabe gefordert. Auch falls alles wie geplant läuft, entsteht an Migrationswochenenden Stress.

Achten Sie darauf in Ihren Checkpoints und gegebenenfalls notwendigen Eskalationsterminen stets:

• ruhig und professionell zu kommunizieren
• bei aufkommenden Emotionen und Ärger zu deeskalieren und den Fokus immer Lösungsorientiert zu halten
• stets die richtige Ebene der Kommunikation zu treffen
• klar zu strukturieren, technische break-out Sessions zur Problemlösung sind besonders wichtig
• klare Erwartungen zu kommunizieren, Rückmeldungen zum Status jeder einzelnen Aktivität zu verarbeiten
• den Zeitplan als Grundlage aller Aktivitäten zu halten
• stets an den Belastungsstand aller Teilnehmer zu denken
• die Techniker in Ihrer Arbeit vom Management abzuschirmen und
• das Management korrekt und ganzheitlich über den technischen Stand der Migration zu informieren
• Erfolge zu benennen und zu würdigen

Ein Cut-Over Wochenende erfolgreich zu steuern ist herausfordernd, aber ein Lohnenswerter Projektbestandteil. Alle Teilnehmer sind nach erfolgreicher Umschiffung steiler Klippen ein besseres Team als vorher – dies trifft auch für die zukünftige Zusammenarbeit zwischen Kunde und Dienstleister zu.

Die Go / No-Go Entscheidung

To Go or not To Go, that is the question.

Tweet von Hamlet

Dies ist der wichtigste aller Checkpoints. Die neue IT-Landschaft ist hochgefahren, Tests wurden durchgeführt, Issues entdeckt, klassifiziert und wenn möglich behoben. Ist Ihre Issues-Liste leer, ist diese Entscheidung einfach. Meist ist dies jedoch nicht der Fall. Einzelne aufgetretene Fehler sind noch mit Kategorie 1 bewertet – sie sind Go-Live verhindernd.

An dieser Stelle gilt es gemeinsam mit allen Stakeholdern eine Entscheidung zu treffen, welche Sie in besonders kurzer Zeit vorbereiten müssen. Ein Rollback mit nachfolgendem Lessons-Learned und einen zweiten Migrationsanlauf ist sehr aufwendig und teuer. Ist eine Interimslösung oder ein Workaround in möglich? Können Sie eventuell einen Teil-Rollback durchführen und das Issue auslösende System nachträglich migrieren, auch wenn das einen Mixed-Mode Betrieb bedeutet? Für jegliche Entscheidung dieser Art benötigen Sie die aktive Zustimmung des Kundenmanagements, in Ihrer IT und in allen betroffenen Fachbereichen, die Zustimmung des Alt-Providers, der ggf. noch länger eine Teilproduktive Landschaft betreuen muss und des Neu-Providers, der sich sicher sein muss die Umgehungslösung möglichst schnell wieder ablösen zu können.

In jedem Fall ist nach der Go/No-Go Entscheidung der Cut-Over Plan noch nicht zu Ende. Entweder geht es direkt weiter mit dem Freischalten der Anwender und der Aktivierung der externen Schnittstellen (welche hoffentlich getestet werden konnten) oder Sie müssen den Rollback aktivieren.

Der Rollback

Ein Plan der niemand wollte.

Niemand beschäftigt sich gerne mit einem Rollback oder Fallback Plan, Sie brauchen ihn dennoch – als Versicherung. An der richtigen Stelle die “Reißleine” gezogen verhindert großen Schaden. Bevor erste Transaktionen in Ihren umgezogenen Systemen verarbeitet wurden, ist ein Rollback in den meisten Fällen relativ einfach zu realisieren und es muss nicht eine komplette Rückwärts-Migration erfolgen.

Abschalten der Infrastruktur beim Neu-Povider. Dies ist besonders wichtig, damit eventuell dennoch umgeschaltete Schnittstellen nicht auf aufnahmebereite, aber nicht produktive Systeme treffen sollten. Fehler aufgrund der Umstellung sind besser als vermeintlich erfolgreiche Transaktionen.

Zurückdrehen der Schnittstellen und Zugriffe. Häufig werden im Rahmen der Umschalten DNS Einträge geändert, andere Adressen eingetragen, VPN Netze gewechselt. Dies muss vor dem Wiederanlauf rückgängig gemacht werden.

Durchlaufen des Wiederanlaufplans beim Alt-Provider. Dieser sollte, da hier schon länger Betrieb stattfindet, relativ sicher die Umgebung wieder in Betrieb bringen. Die Anwender-Zugänge sollten jedoch weiterhin gesperrt bleiben, ebenso wie die externen Schnittstellen.

Aktivieren der Test-User und Durchführen aller Tests. Auch beim Rollback sind alle Testcases für die Inbetriebnahme durch zu führen. Dies gilt auch für Vorher/Nachher Vergleiche, da Sie auch hier häufig noch Wirtschaftsprüfer- und Auditberichte vorlegen müssen.

Auch hier findet eine finale Go Entscheidung statt, wobei ein No-Go keine Option mehr ist. Wenn alle Tests positiv gelaufen sind, können hoffentlich rechtzeitig Betriebsstart wieder alle Anwender und externen Schnittstellen freigeschaltet werden.

Die Hypercare Phase

Fix it forward!

Vermutlich jeder Transition Manager

Meist ist die Woche nach der Migration ebenfalls Ereignisreich. Alle Kategorie 2 Findings des Migrationswochenendes drängen auf Ihre Behebung, vielleicht wurde ein ursprünglich als Kategorie 1 eingestuftes Problem ja gemeinsam mit dem Management auf Kategorie 2 herabgestuft und der implementierte Workaround muss schnell behoben werden?

Auch wenn alles gut gelaufen ist, gibt es erhöhte Anforderungen. Die wenigsten Migrationen gehen gänzlich unbemerkt an den End-Anwendern vorbei und wie bei jeder Anpassung sind erhöhte Call-Mengen und Eskalationen zu bearbeiten.

Falls Sie Ihren Schichtenplan gut für die Hypercare Phase aufgestellt haben, sind Sie vorbereitet auf den Ansturm. Das beste Lob zur Migration ist es jedoch, wenn der Hypercare Support nicht oder nur wenig genutzt werden muss.

Update: Artikel rund um den Hypercare im Detail

Fazit

Dies war ein Ausflug in die Aktivitäten eines Migrationswochenendes. Viel des Erfolges hängt von der Erfahrung aller Beteiligten ab. In welchen Bereichen muss die Planung besonders intensiv erfolgen, wo brauche ich ggf. noch Planung und Dokumentation unterhalb des Minutenplans? Sind alle Betroffenen beteiligt, ist für die Migrationstests genug Zeit im Projektplan vorgesehen? Erhalte ich vom Alt-Provider und anderen Dienstleistern genügend Support? Bekomme ich wichtige Partnerunternehmen, zu denen Schnittstellen bestehen, mit On-Board in die Planung?

Dies ist die Art von reformierender Veränderung, für die IT-Organisationen nur selten alleine gut aufgestellt sind. Hier unterstützt Trust in Change mit viel Erfahrung und Können Ihr Transitionsprojekt.

Marc Buzina