Checkliste zur Migrationsmachbarkeit für IT-Führungskräfte

Was Migrationsdurchführbarkeit wirklich bedeutet

Kernaussage: Machbarkeit ist eine Frage der Priorisierung, die vor der Strategie kommt. Die Fünf-Fragen-Prüfung liefert ein „jetzt, später oder erst die Hindernisse beseitigen“, bevor sich jemand mit einer Zielarchitektur befasst. Die Strategie verdient ihren Platz erst, wenn die Machbarkeitsprüfung „jetzt“ ergibt.

Machbarkeit kommt vor der Strategie. Bevor jemand eine Zielarchitektur entwirft, ein Runbook erstellt oder sich auf ein Multicloud-Betriebsmodell festlegt, lautet die Frage: Ist die Migration jetzt der richtige Schritt, und was könnte dazu führen, dass sie scheitert? Das ist wichtig, weil cloud-Migrationen regelmäßig das Budget überschreiten und hinter dem Zeitplan zurückbleiben – oft, weil Kapazitätslücken und Abhängigkeiten zu Beginn unterschätzt wurden.

Eine Machbarkeitsprüfung ist ein kurzes Gespräch mit dem Team, das für die Workload verantwortlich ist, und dreht sich um fünf Fragen. Das Ergebnis ist eine klare Entscheidung: „Jetzt handeln“, „später handeln“ oder „zuerst die Hindernisse beseitigen“.

Die fünf Fragen, die du beantworten musst, bevor du eine Migration priorisierst

Das Wichtigste auf einen Blick: Fünf Antworten geben dir ein „Go/No-Go“-Signal. Die früheren Fragen beeinflussen die späteren, daher ist die Reihenfolge entscheidend. Überspringst du eine davon, wird das Signal unzuverlässig, da sich die Variablen gegenseitig überlagern oder verstärken.

Dieselben fünf Variablen entscheiden darüber, ob die meisten Migrationen reibungslos verlaufen. Beantworte sie der Reihe nach; die früheren Antworten beeinflussen die späteren.

1. Komplexität des aktuellen Zustands. Wie stark hängt die Anwendung von anbieterspezifischen Diensten ab (verwaltete queues, Identitätsmanagement, proprietäre Datenspeicher, Edge-Funktionen)? Je höher dieser Anteil, desto mehr Neuprogrammierungsaufwand ist mit der Migration verbunden.
2. Anbieterabhängigkeit. Gibt es Architekturmuster, die eine Neuprogrammierung statt einer erneuten Bereitstellung erfordern würden? Häufige Übeltäter: anbieterspezifische SDKs, native Ereignisdienste und laufzeitspezifischer Edge-Code.
3. Betriebliche Abhängigkeiten. Welche nachgelagerten Tools setzen die aktuelle cloud voraus? Überwachung, CI/CD, Sicherheitsscans, FinOps-Berichte und Ticket-Integrationen haben oft anbieterbezogene Konfigurationen, die mit der Workload mitwandern.
4. Sequenzierungsrisiko. Kann die Migration nach Umgebung oder Dienst schrittweise erfolgen oder erfordert sie eine einmalige Umstellung? Eine Workload, die in Teilschritten verschoben werden kann, lässt sich mit deutlich geringerem Risiko umsetzen als eine, die eine synchronisierte Umstellung erfordert.
5. Erforderliche Kompetenzen. Verfügt dein Team bereits über die Fähigkeiten, den Zielzustand zu betreiben, oder musst du dafür Personal einstellen, schulen oder Partner hinzuziehen? Die Kompetenzlücke ist die Variable, die am häufigsten unterschätzt wird.

Häufige Anzeichen dafür, dass eine Migration noch nicht bereit ist

Das Wichtigste zum Mitnehmen: Eine Migration ohne Auslöser und ohne Rollback-Pfad ist ein Backlog-Punkt. Die meisten verfrühten Migrationen scheitern, weil der Auslöser ein vager Wunsch war, die Bindung zu verringern, ohne dass ein konkreter Vertrag, eine Frist oder ein Vorfall dahintersteckte. Lege den Auslöser fest, bevor du den Umzug planst.

Warte noch ab, wenn einer der folgenden Punkte zutrifft:

• Die Anwendung weist ungelöste, anbieterspezifische Abhängigkeiten auf, die noch nicht abgebildet wurden.
• Die Betriebswerkzeuge sind eng an die aktuelle cloud gekoppelt, und es gibt keine dokumentierte Alternative.
• Ein geplanter Cutover würde ein einziges, unumkehrbares Zeitfenster ohne Rollback-Möglichkeit erfordern.
• Das Team müsste den Zielzustand ausführen, der noch nicht existiert, und es gibt keinen Plan, ihn aufzubauen oder in Auftrag zu geben.
• Das Geschäftsszenario lautet „Wir sollten die Bindung verringern“, ohne dass ein auslösendes Ereignis vorliegt (ein Vertrag, eine Kundenanforderung, ein Ausfall, eine behördliche Frist).

Jeder dieser Punkte würde bedeuten, dass die Arbeit auf dem Backlog stehen sollte, nicht im nächsten Quartal.

Buche eine Multicloud-Bewertung

Häufige Anzeichen dafür, dass es jetzt realistisch sein könnte

Eine Migration ist in der Regel machbar, wenn:

• Die anbieterabhängigen Bereiche der Anwendung gering sind oder im Voraus dokumentiert wurden.
• Ein Zielbetriebsmodell bereits ausgewählt wurde und das Team in der Lage ist, es umzusetzen.
• Die Arbeitslast schrittweise verlagert werden kann und jede Phase unabhängig validiert werden kann.
• Ein klarer geschäftlicher Auslöser vorliegt: eine Vertragsverlängerung, eine regionale Expansion, ein regulierter Kunde, ein Anbieter, der jede Änderung zu einem Ticket macht, oder ein explizites Kosten- oder Ausfallsicherheitsziel.
• Ein Rollback-Pfad ist in jeder Phase möglich, auch wenn er nie genutzt wird.

Wenn drei dieser Punkte zutreffen, lohnt es sich, das Gespräch jetzt zu führen.

Ein einfacher Phasenüberblick: Bewerten, Vorbereiten, Umstellen, Validieren

Die Arbeit lässt sich in der Regel in vier Phasen unterteilen. Jede Phase wird durch ein bestimmtes Ergebnis abgegrenzt.

1. Bewerten. Erfasse anbieterspezifische Abhängigkeiten und bewerte sie. Ergebnis: eine Liste der umzustrukturierenden Elemente und des damit verbundenen Aufwands.
2. Vorbereiten. Baue das Zielbetriebsmodell in einer kleinen, risikoarmen Umgebung auf. Ergebnis: eine funktionierende Pipeline, die denselben Governance-Standards entspricht.
3. Umsetzen. Migriert die Arbeitslast in der kleinsten Einheit, die die Geschäftsfunktion aufrechterhält. Ergebnis: gleichwertiges oder besseres Verhalten in der neuen Umgebung.
4. Validieren. Anhand der ursprünglichen Erfolgskriterien überprüfen. Ergebnis: eine dokumentierte Freigabe und die Aufhebung des Rollback-Plans.

Jede Phase ist eine Kontrollstelle. Wenn eine Phase ihr Ergebnis nicht erreicht, bleibst du dort, bis sie bestanden ist.

Nächster Schritt

Wenn drei der fünf Fragen ein sicheres „Ja“ ergeben und ein Auslöser vorliegt, plane die Bewertung ein. Wenn zwei oder mehr mit „Wir wissen es nicht“ beantwortet werden, plane eine 30-minütige interne Besprechung mit dem Team ein, das für die Arbeitslast verantwortlich ist. Die Kosten für die Klärung sind viel geringer als die Kosten für eine falsch getimte Umstellung.

Lies das Migrations-Playbook: Wie man sich ohne Unterbrechungen aus der Lock-in-Situation befreit

Häufig gestellte Fragen (FAQ)

Was ist Migrationsdurchführbarkeit?

Die Migrationsmachbarkeit gibt an, ob eine geplante cloud-basierte Migration unter Berücksichtigung der Abhängigkeiten der Anwendung, der Fähigkeiten des Teams und der geschäftlichen Gründe für den Schritt derzeit realistisch umsetzbar ist. Sie erfolgt vor der Strategie- oder Architekturarbeit. Eine Machbarkeitsprüfung liefert ein klares „Jetzt handeln“, „Später handeln“ oder „Zuerst die Hindernisse beseitigen“.

Was löst eine Cloud-Migration aus?

Migrationen gelingen selten ohne einen konkreten Auslöser. Die häufigsten Auslöser sind eine Vertragsverlängerung, ein regulierter Kunde, der eine bestimmte Datenresidenz verlangt, eine regionale Expansion, ein größerer Ausfall oder ein explizites Kosten- oder Ausfallsicherheitsziel. Migrationen, die von dem allgemeinen Wunsch getrieben sind, die Bindung zu verringern, ohne dass ein konkretes Ereignis dahintersteht, rutschen meist im Zeitplan nach hinten.

Was blockiert die meisten Cloud-Migrationen?

Fünf Hindernisse sind für die meisten fehlgeschlagenen oder verzögerten Migrationen verantwortlich: ungelöste anbieterbezogene Abhängigkeiten, Betriebswerkzeuge, die eng an die aktuelle cloud gekoppelt sind, die Anforderung einer einzigen, unumkehrbaren Umstellung ohne Rollback-Möglichkeit, eine Kompetenzlücke im Team, das für den Zielzustand erforderlich ist, und ein unklarer geschäftlicher Auslöser. Wenn man diese im Voraus erfasst, lassen sich die meisten Hindernisse in geplante Arbeitsschritte umwandeln.

Solltest du schrittweise oder auf einen Schlag migrieren?

Eine schrittweise Migration ist mit deutlich geringerem Risiko machbar als eine einmalige Umstellung. Eine Arbeitslast, die in Teilabschnitten verschoben werden kann, wobei jeder Teilabschnitt unabhängig validiert wird, ermöglicht es dem Team, an jeder Grenze anzuhalten, ohne sich auf die nächste Phase festlegen zu müssen. Eine Migration im „Single-Window“-Verfahren ohne Rollback-Möglichkeit sollte als risikoreiches Vorgehen betrachtet werden, das einer ausdrücklichen Begründung bedarf.

Was ist der Unterschied zwischen Migrationsdurchführbarkeit und Migrationsstrategie?

Die Machbarkeit beantwortet die Frage, ob es sich lohnt, der Migration jetzt Priorität einzuräumen. Die Strategie beantwortet die Frage, wie die Migration durchgeführt werden soll, sobald du dich zum Handeln entschlossen hast. Die Machbarkeitsprüfung liefert an einem Nachmittag eine Ja/Nein/Warten-Entscheidung; die Strategie liefert eine Zielarchitektur, ein Runbook und einen Ablaufplan über mehrere Wochen hinweg. Die Strategie ist vergebener Aufwand, wenn die Machbarkeitsprüfung noch kein klares „Ja“ ergeben hat.