Migrationsreihenfolge: womit anfangen

Die Frage nach der Reihenfolge kommt in fast jedem Migrationsprojekt zu spät. Erst wird entschieden, dass migriert wird, dann welche Cloud es sein soll — und irgendwann steht jemand vor einer Liste aus vierzig Systemen und soll sagen, womit man anfängt.

Die Antwort darauf entscheidet mehr über den Verlauf als die Wahl des Anbieters. Wer mit dem falschen System beginnt, verbrennt Zeit und Vertrauen an einer Stelle, an der beides noch nicht aufgebaut ist.

Zuerst sortieren, dann migrieren

Die verbreiteten Rahmenwerke für Migrationsstrategien — meist als die sechs oder sieben „R“ bezeichnet — sind kein Katalog von Techniken, sondern ein Sortierwerkzeug. Jedes System bekommt vor der Migration eine dieser Einordnungen.

Bemerkenswert ist, was die Praxisleitfäden großer Anbieter zum Refactoring sagen: Für umfangreiche Migrationen wird es ausdrücklich nicht empfohlen. Die üblichen Strategien bei großen Vorhaben sind Rehost, Replatform, Relocate und Retire. Umbauen kann man später — während der Migration bindet es genau die Kapazität, die für den Umzug selbst gebraucht wird.

Retire ist der unterschätzte Posten

In jeder gewachsenen Umgebung laufen Systeme, die niemand mehr braucht: der Dateiserver einer aufgelösten Abteilung, die Anwendung eines beendeten Projekts, die Datenbank hinter einem abgeschalteten Portal. Sie fallen nicht auf, weil sie funktionieren.

Bei einer Migration fallen sie zwangsläufig auf — und genau das ist der Moment, sie loszuwerden. Jedes System, das nicht migriert wird, spart doppelt: die Migrationsarbeit und die laufenden Kosten danach. Es ist die einzige Kategorie mit garantiert positivem Ergebnis, und sie steht deshalb ganz am Anfang der Sortierung, nicht am Ende.

Die Prüffrage dafür ist nicht „läuft das noch?“, sondern „wer würde es merken, wenn es morgen aus wäre?“. Lässt sich das nicht beantworten, ist das System ein Kandidat — nicht zum sofortigen Abschalten, aber zum Nachfragen.

Warum Projekte am Anfang scheitern

Das klingt nach einer Allgemeinplatz-Diagnose, hat aber eine sehr konkrete Folge für die Reihenfolge. Ohne festgelegtes Ziel lässt sich nicht entscheiden, welches System zuerst dran ist — denn die Antwort unterscheidet sich je nach Ziel erheblich.

Geht es um Kostensenkung, kommen zuerst die Systeme mit dem größten Hardware-Anteil und der schlechtesten Auslastung. Geht es um Ausfallsicherheit, beginnt man bei dem, dessen Ausfall am meisten kostet. Geht es um Standortunabhängigkeit, sind es die Systeme, auf die von außen zugegriffen wird. Drei plausible Ziele, drei völlig verschiedene erste Kandidaten.

Auch Fachbeiträge zu häufigen Migrationsfehlern nennen das fehlende Zielbild an erster Stelle — noch vor technischen Problemen. Und ebenso regelmäßig empfohlen wird, schon vor Beginn zu klären, wie Daten im Bedarfsfall wieder aus der Cloud herauskommen. Das ist keine Schwarzmalerei, sondern die Voraussetzung für Verhandlungsspielraum später.

Die Reihenfolge in der Praxis

Nach dem Aussortieren bleiben die Systeme, die wirklich umziehen. Für ihre Reihenfolge haben sich zwei Achsen bewährt: geschäftliche Kritikalität und technische Komplexität.

Der erste Umzug ist eine Übung, kein Meilenstein. Sein Zweck ist, den Ablauf zu erproben: Wie lange dauert die Datenübertragung wirklich? Funktioniert der Rückweg? Wer muss informiert werden? Was kostet es am Monatsende tatsächlich? Diese Antworten sind mehr wert als der eingesparte Betrag beim ersten System — und sie sind nur an einem unkritischen System bezahlbar zu bekommen.

Abhängigkeiten schlagen jede Planung

Die Reihenfolge nach Kritikalität stößt an eine Grenze, sobald Systeme miteinander sprechen. Eine Anwendung, die auf eine Datenbank zugreift, kann nicht ohne sie umziehen — und wenn sie es doch tut, läuft der Verkehr fortan zwischen dem eigenen Rechenzentrum und der Cloud hin und her. Das ist langsam, und es erzeugt genau die Datenübertragungskosten, die in keiner Kalkulation stehen.

Deshalb wird nicht nach einzelnen Systemen sortiert, sondern nach zusammengehörenden Gruppen. Was gemeinsam kommuniziert, zieht gemeinsam um. Diese Gruppen zu ermitteln ist der aufwendigste Teil der Vorbereitung — und der, an dem am häufigsten gespart wird, weil er nach Papierarbeit aussieht.

Der Rückweg gehört in den ersten Umzug

Bevor das erste System produktiv umzieht, sollte einmal der umgekehrte Weg erprobt worden sein: Daten wieder herausholen, an anderer Stelle einspielen, Betrieb aufnehmen. Nicht als Planspiel, sondern tatsächlich durchgeführt.

Der Grund ist weniger die Sorge vor dem Scheitern als die Verhandlungsposition. Wer den Rückweg nie geprüft hat, weiß nicht, wie lange er dauert und was er kostet — und ist damit bei jeder späteren Vertragsverhandlung im Nachteil. Fachbeiträge zu häufigen Migrationsfehlern empfehlen deshalb, schon vor Beginn zu klären, wie die Daten bei Bedarf wieder aus der Cloud abgezogen werden können.

Praktisch bedeutet das drei Fragen, die vor dem ersten produktiven Umzug beantwortet sein sollten: In welchem Format kommen die Daten heraus? Wie lange dauert die Übertragung bei der tatsächlichen Datenmenge? Und welche Übertragungskosten entstehen dabei — der Weg hinein ist bei den meisten Anbietern kostenlos, der Weg hinaus nicht.

Das unkritische erste System ist der richtige Ort für diese Übung. Bei einem ERP wird sie niemand ausprobieren wollen.

Was den Zeitplan realistisch macht

Zwei Dinge verlängern Migrationsprojekte verlässlich, und beide lassen sich vorher einplanen.

Der Parallelbetrieb. Zwischen dem Umzug eines Systems und der Abschaltung des alten liegt eine Phase, in der beides läuft — und beides kostet. Wer diese Phase in der Wirtschaftlichkeitsrechnung übergeht, plant Einsparungen ein, die erst Monate später eintreten.

Die Nacharbeit. Ein migriertes System ist selten sofort fertig: Berechtigungen müssen nachgezogen, Schnittstellen angepasst, Sicherungen neu eingerichtet werden. Als Faustregel taugt, für die Nacharbeit ähnlich viel Zeit zu veranschlagen wie für den Umzug selbst.

Wer beides sauber einplant, bekommt außerdem ein belastbares Argument für die Geschäftsführung: Die Einsparung tritt nicht mit dem Umzug ein, sondern mit der Abschaltung der alten Umgebung — und dazwischen liegen typischerweise Wochen. Diese Erwartung vorher auszusprechen verhindert die Enttäuschung, die sonst nach der ersten Rechnung kommt.

Beides spricht für kleine Schritte statt eines großen Stichtags. Ein Projekt, das in Gruppen über Monate läuft, ist besser steuerbar als eines, bei dem an einem Wochenende alles umzieht — und es lässt Raum, die Reihenfolge nach den ersten Erfahrungen zu korrigieren.

Häufige Fragen

Womit beginnt man bei einer Cloud-Migration?

Mit dem Aussortieren: Welche Systeme sollen gar nicht mitkommen? Danach folgen Systeme mit geringer geschäftlicher Kritikalität und wenigen Abhängigkeiten — sie dienen als Übung für den Ablauf. Kritische Systeme wie ein ERP kommen zuletzt, wenn Routine und Werkzeuge stehen.

Was bedeuten die 6 R der Cloud-Migration?

Es sind Einordnungen für jedes System vor dem Umzug: Retire (abschalten), Retain (bleibt vorerst), Rehost (unverändert verschieben), Replatform (leicht anpassen), Repurchase (durch ein SaaS-Produkt ersetzen) und Refactor (umbauen). Manche Darstellungen führen Relocate als siebte Option, bei der eine ganze Virtualisierungsschicht umzieht.

Sollte man Anwendungen während der Migration modernisieren?

Bei umfangreichen Migrationen raten die Praxisleitfäden großer Anbieter davon ab. Refactoring bindet genau die Kapazität, die der Umzug braucht, und macht Fehler schwerer zuzuordnen — geht etwas schief, ist unklar, ob es am Umzug oder am Umbau liegt. Erst umziehen, dann modernisieren.

Wie geht man mit Abhängigkeiten zwischen Systemen um?

Man migriert sie gemeinsam. Systeme, die ständig miteinander kommunizieren, gehören in dieselbe Migrationsgruppe — sonst läuft der Verkehr dauerhaft zwischen dem eigenen Rechenzentrum und der Cloud, was langsam ist und zusätzliche Übertragungskosten erzeugt. Diese Gruppen zu ermitteln ist der aufwendigste Teil der Vorbereitung.

Wie lange dauert eine Migration im Mittelstand?

Eine belastbare Pauschale gibt es nicht, weil die Zahl der Systeme und ihrer Verflechtungen zu stark schwankt. Realistisch wird die Planung, wenn zwei oft übergangene Posten enthalten sind: die Phase des Parallelbetriebs, in der alte und neue Umgebung gleichzeitig kosten, und die Nacharbeit an jedem migrierten System, die erfahrungsgemäß ähnlich viel Zeit braucht wie der Umzug selbst.