Umziehen in Wellen – mit einem Rückweg für jeden Schritt

Am Anfang steht die unbequeme Frage, was überhaupt migrierbar ist. Wir erfassen alle Server, Anwendungen und Datenbestände mit ihren Abhängigkeiten. Besonderes Augenmerk gilt Fachanwendungen mit Hardwareanbindung – Kassensysteme, Maschinensteuerungen, Kartenleser, Etikettendrucker, Zeiterfassung. Diese Systeme sind der häufigste Grund, warum eine vollständige Cloud-Migration nicht sinnvoll ist.

Ebenso wichtig sind Datenmengen und Bandbreite. Zwei Terabyte Dateiserver über eine 100-Mbit-Uploadleitung zu synchronisieren dauert rechnerisch mehrere Tage – das muss im Zeitplan stehen, nicht als Überraschung am Migrationswochenende auftauchen. Bei sehr großen Beständen planen wir eine Vorabsynchronisation über mehrere Wochen ein, sodass am Umstellungstag nur noch die Änderungen übertragen werden.

Aus der Bestandsaufnahme entsteht ein Zielbild. In der Mehrzahl der Fälle ist das keine reine Cloud, sondern eine hybride Architektur: Postfächer, Dokumente, Zusammenarbeit und Identitäten in Microsoft 365, rechenintensive oder hardwaregebundene Systeme weiterhin lokal oder als Azure Virtual Machine, verbunden über Entra ID mit Mehrfaktor-Anmeldung und eine überwachte VPN-Strecke.

Parallel rechnen wir die Betriebskosten über fünf Jahre durch – Lizenzen, Azure-Verbrauch, Betreuung und im Vergleich dazu Hardware, Wartungsverträge, Strom und Ersatzbeschaffung im lokalen Betrieb. Diese Rechnung legen wir offen, inklusive der Annahmen. Wenn der lokale Betrieb günstiger ausfällt, steht das im Ergebnis, auch wenn es das kleinere Projekt bedeutet.

Die Zielumgebung entsteht parallel zum laufenden Betrieb. Wir richten Identitäten, Sicherheitsrichtlinien, Ablagestruktur, Geräteverwaltung und das Backup ein, bevor der erste Anwender umzieht. Erst wenn diese Grundlage steht, beginnt die Pilotphase.

Für die Pilotgruppe wählen wir eine reale Abteilung mit repräsentativem Arbeitsalltag – nicht die technikaffinsten Mitarbeitenden, sondern eine Mischung. Zwei Wochen produktive Arbeit in der Zielumgebung fördern die Probleme zutage, die in keinem Testplan stehen: der Serienbrief, der auf ein Netzlaufwerk zeigt, der Scanner, der in einen bestimmten Ordner ablegt, das Makro, das jemand 2016 gebaut hat. Diese Rückmeldungen sammeln wir strukturiert und arbeiten sie ab, bevor die Wellen starten.

Die Belegschaft zieht in Wellen um, typischerweise 10 bis 25 Personen pro Welle, abteilungsweise geschnitten. Abteilungsgrenzen sind wichtiger als gleich große Gruppen: Wer täglich zusammenarbeitet, sollte in derselben Welle wechseln, sonst entstehen Reibungen bei geteilten Ablagen und Kalendern.

Jede Welle folgt demselben Muster: Vorabsynchronisation der Daten über die Woche, Umstellung am Freitagabend, Kontrolle am Samstag, Erreichbarkeit am Montagmorgen. Für jede Welle definieren wir vorher einen Abbruchzeitpunkt – den Moment, bis zu dem die Entscheidung für den Rollback fallen muss, damit am Montag alles wie gewohnt läuft. Diesen Punkt schriftlich zu fixieren verhindert, dass im Zweifel weitergemacht wird, weil schon so viel Aufwand drinsteckt.

Der am häufigsten übersprungene Teil einer Migration ist das Ende. Alte Server laufen dann noch monatelang weiter, weil niemand sicher ist, ob nicht doch etwas darauf liegt. Das kostet Strom, Lizenzen und Sicherheitsaufwand – und ein ungepatchter Altserver im Netz ist ein reales Risiko.

Wir schalten Altsysteme deshalb kontrolliert ab: zuerst vom Netz trennen und eine definierte Karenzzeit von vier bis sechs Wochen abwarten, dann ein vollständiges Abbild sichern und archivieren, erst danach abbauen. Parallel wird das Backup neu aufgesetzt, denn ein Sicherungskonzept für lokale Server deckt eine Cloud-Umgebung nicht ab. Die Wiederherstellung testen wir vor Projektabschluss einmal vollständig.

Wir nennen die typischen Probleme lieber vorher. Am häufigsten sind es vier: unterschätzte Datenmengen bei knappem Upload, Fachanwendungen mit fest verdrahteten Pfaden auf Netzlaufwerke, gewachsene Berechtigungsstrukturen, die sich nicht sauber abbilden lassen, und Anwender, die ihre Ablagegewohnheiten nicht ändern wollen.

Gegen die ersten drei hilft die Bestandsaufnahme, gegen das vierte nur Kommunikation. Wir planen deshalb Einweisungen vor jeder Welle ein und stellen in den ersten zwei Wochen nach jeder Umstellung erhöhte Supportkapazität bereit. Das Ticketaufkommen steigt in dieser Phase erfahrungsgemäß um das Zwei- bis Dreifache und normalisiert sich nach etwa drei Wochen.