Cloud-Migration ohne Stillstand: So planen Sie Wellen, Umstellung und Rückweg

Marcel Rieger

Managing Director, Cyber Risk

Am Sonntagabend ist die Warenwirtschaft erfolgreich in die Cloud umgezogen. Am Montagmorgen druckt das Lager keine Lieferscheine, weil der Etikettendrucker über eine Freigabe auf einem alten Server angesprochen wurde, den niemand auf der Liste hatte. So sieht ein typischer Stillstand nach einer Migration aus: Die Technik funktioniert, die Abhängigkeit war unbekannt. Dieser Beitrag zeigt, wie Sie als IT-Leitung eine Cloud-Migration so planen, dass der Betrieb weiterläuft, von der Bewertung jeder Anwendung über die Migrationswellen bis zur Umstellung mit Rückweg.

Warum das Thema gerade jetzt auf dem Tisch liegt

Viele Mittelständler müssen in den nächsten Monaten ohnehin an ihre Serverlandschaft. Der erweiterte Support für Windows Server 2016 endet laut Microsoft im Januar 2027. Danach gibt es für diese Version keine regulären Sicherheitsupdates mehr. Dazu kommen Vertragsverlängerungen bei der Virtualisierung, seit Broadcom nach der Übernahme von VMware die Lizenzmodelle umgestellt hat, und Server im eigenen Rechenzentrum, deren Hardware ausläuft.

Zeitdruck verleitet dazu, alles unverändert umzuziehen und erst danach nachzudenken. Das geht schnell, verschiebt aber Altlasten nur an einen teureren Ort. Besser ist es, die Frist als Anlass zu nehmen, jede Anwendung einmal einzeln zu entscheiden.

Jede Anwendung einzeln entscheiden

AWS beschreibt sieben grundlegende Migrationsstrategien, die sogenannten 7 Rs. Sie gelten sinngemäß auch für Azure oder einen deutschen Cloud-Anbieter:

• Retire: Die Anwendung wird abgeschaltet und ihre Daten archiviert.
• Retain: Sie bleibt vorerst, wo sie ist.
• Rehost: Sie zieht unverändert um, oft „Lift and Shift" genannt.
• Relocate: Die ganze Virtualisierungsplattform wird in eine Cloud-Variante derselben Plattform verschoben.
• Repurchase: Sie wird durch ein Cloud-Produkt ersetzt, etwa ein lokaler Exchange-Server durch Exchange Online.
• Replatform: Sie zieht mit gezielten Anpassungen um, zum Beispiel die Datenbank in einen verwalteten Datenbankdienst.
• Refactor: Sie wird für die Cloud neu gebaut.

AWS rät bei großen Migrationen ausdrücklich davon ab, während des Umzugs neu zu bauen, und empfiehlt, erst umzuziehen und danach zu modernisieren. Der Grund ist einfach: Wer Umzug und Umbau gleichzeitig macht, hat bei Problemen zwei mögliche Ursachen statt einer.

Im Mittelstand werden zwei Optionen regelmäßig unterschätzt. Retire, weil in gewachsenen Landschaften oft Anwendungen laufen, die niemand mehr braucht, die aber auch niemand abschalten wollte. Und Retain, weil manche Systeme vor Ort besser aufgehoben sind: Anwendungen mit Hardware-Dongle, Systeme, die direkt mit Maschinen in der Fertigung sprechen, oder große CAD-Dateiablagen, bei denen jede Verzögerung in der Leitung den Konstrukteuren den Tag verdirbt.

Für die Entscheidung brauchen Sie pro Anwendung eine kurze Bestandsaufnahme:

• fachlich verantwortliche Person und Zahl der Nutzer
• Abhängigkeiten zu Datenbanken, Schnittstellen, Lizenzservern, Druckern, Scannern und Maschinen
• Datenmenge und wie schnell sie wächst
• welche Ausfallzeit der Fachbereich verkraftet, in Stunden, nicht in Prozent
• ob die Lizenz in der gewünschten Cloud überhaupt genutzt werden darf

Die Ausfallzeit legt der Fachbereich fest, nicht die IT. Für die Lohnabrechnung kann ein Wochenende unkritisch sein, für den Webshop oder die Versandsteuerung schon eine Stunde zu viel.

Migrationswellen schneiden

Ziehen Sie nicht alles auf einmal um, sondern in Wellen. Die erste Welle ist ein Pilot mit zwei oder drei unkritischen Anwendungen. Er testet weniger die Technik als Ihren Ablauf: Funktioniert die Datensicherung in der neuen Umgebung? Kommen die Meldungen im Monitoring an? Weiß der Servicedesk, wohin er Störungen meldet? Halten Sie fest, was schiefging, und passen Sie das Vorgehen an, bevor es ernst wird.

Für die weiteren Wellen gilt: Was viel miteinander spricht, zieht gemeinsam um. Liegt der ERP-Server schon in der Cloud und die Datenbank noch im eigenen Rechenzentrum, läuft jede Abfrage über die Leitung dazwischen, und die Anwendung wird spürbar langsam. Die Abhängigkeitsliste aus der Bestandsaufnahme bestimmt deshalb den Zuschnitt der Wellen.

Planen Sie die Termine gegen den Geschäftskalender. Monatsabschluss, Inventur, Jahresabschluss und Saisonspitzen sind tabu. Werksurlaub, Brückentage und ruhige Wochenenden sind gute Fenster.

Die Umstellung: wo Stillstand entsteht

Stillstand entsteht selten beim Kopieren der Daten, sondern in den Stunden der Umstellung. Diese Punkte entscheiden darüber, ob sie gelingt:

1. Daten vorab übertragen. Große Datenbestände werden Tage vorher repliziert. Im Umstellungsfenster wird nur noch der Rest seit der letzten Synchronisation übertragen, das hält die Ausfallzeit kurz.
2. Ein Drehbuch schreiben. Jeder Schritt mit Uhrzeit, verantwortlicher Person und Prüfung, ob er geklappt hat. An festgelegten Punkten gibt es eine Go/No-Go-Entscheidung, und vorher ist klar, wer sie trifft.
3. Eine Generalprobe machen. Mindestens ein vollständiger Probelauf mit realistischer Datenmenge zeigt, wie lange die Umstellung wirklich dauert. Die Zeit aus der Probe ist die Planungsgrundlage, nicht die Schätzung.
4. Den Rückweg offen halten. Das alte System bleibt für einen festgelegten Zeitraum betriebsbereit. Legen Sie vorher fest, unter welchen Bedingungen Sie zurückschalten und ab welchem Punkt das nicht mehr geht, typischerweise sobald im neuen System die ersten echten Buchungen entstanden sind.
5. Kleinigkeiten vorbereiten. Die Gültigkeitsdauer der DNS-Einträge einige Tage vorher herabsetzen, damit neue Adressen schnell greifen. Firewall-Freigaben und Zertifikate vorab prüfen. Benutzer informieren, was sich für sie ändert.
6. Fachlich abnehmen. Nach der Umstellung testen Key-User vorbereitete Fälle: einen Auftrag anlegen, einen Lieferschein drucken, eine Rechnung buchen. Erst danach ist die Welle fertig.

Für die ersten ein bis zwei Wochen nach jeder Welle planen Sie eine verstärkte Betreuung ein, mit kurzen Wegen zwischen Servicedesk, Betrieb und Dienstleister.

Die Grundlage vor der ersten Welle

Bevor die erste Anwendung umzieht, braucht die Cloud-Umgebung eine sichere Grundkonfiguration, oft Landing Zone genannt. Dazu gehören eine saubere Struktur der Konten oder Abonnements, die Netzwerkanbindung an Ihre Standorte, eine zentrale Identitätsverwaltung, Protokollierung, Datensicherung und Kostenkontrolle.

Bei der Identität lohnt ein zweiter Blick. Wer nach Azure migriert, baut in der Regel auf demselben Microsoft-Entra-ID-Mandanten auf, über den auch Microsoft 365 läuft. Lücken in dessen Konfiguration, etwa fehlende Mehrfaktor-Anmeldung für Administratoren, gelten dann auch für die neuen Server. Ob Ihr Mandant sicher eingestellt ist, prüft der Cloud Security Check.

Zwei weitere Punkte werden gern übersehen. Der Cloud-Anbieter sichert Ihre virtuellen Maschinen nicht automatisch so, wie Sie es brauchen, also gehören Datensicherung und ein getesteter Wiederherstellungstest zur Landing Zone. Und Server, die eins zu eins aus dem eigenen Rechenzentrum übernommen werden, sind oft größer dimensioniert als nötig. Messen Sie einige Wochen nach dem Umzug die tatsächliche Auslastung und passen Sie die Größen an, sonst zahlen Sie dauerhaft für Reserven, die niemand nutzt.

Den Ausstieg gleich mitplanen

Eine Migration in die Cloud ist auch eine Entscheidung für einen Anbieter. Der europäische Data Act erleichtert den späteren Wechsel: Seit dem 12. September 2025 müssen Cloud-Verträge einen Anbieterwechsel ermöglichen, mit einer Ankündigungsfrist von höchstens zwei Monaten und einem Übergangszeitraum von in der Regel höchstens 30 Tagen. Ab dem 12. Januar 2027 dürfen Anbieter für den Wechsel grundsätzlich keine Entgelte mehr verlangen.

Das Recht auf Wechsel nützt allerdings wenig, wenn die Umgebung technisch nicht übertragbar ist. Dokumentieren Sie deshalb die Konfiguration Ihrer Landing Zone, legen Sie fest, in welchem Format Ihre Daten exportiert werden können, und prüfen Sie bei Diensten, die es nur bei einem Anbieter gibt, ob der Vorteil die Bindung wert ist.

Der erste Schritt

Beginnen Sie mit der Anwendungsliste. Tragen Sie für jede Anwendung die verantwortliche Person, die Abhängigkeiten und die verkraftbare Ausfallzeit ein, und markieren Sie, was auf Windows Server 2016 oder älter läuft. Daraus ergibt sich, welche Anwendungen zuerst entschieden werden müssen und welche Kandidaten für Retire oder Retain sind.

Eine Cloud-Migration ist ein Projekt mit vielen Beteiligten und einem harten Termin. Wenn Sie dafür eine erfahrene Projektleitung brauchen, finden Sie unter IT-Projektmanagement unser Angebot. Warum solche Vorhaben aus dem Ruder laufen und wie Sie das verhindern, lesen Sie im Beitrag Warum IT-Projekte scheitern.