Synapse Fabric Migrationsstrategie: Lift-Shift oder mehr

Constantin, Pexon Consulting | 9 Min. Lesezeit | 29.07.2026

TL;DR

Eine tragfähige Synapse Fabric Migrationsstrategie beginnt mit einer Entscheidung: Lift-and-Shift für Tempo oder Modernisierung für langfristigen Nutzen. Danach folgt ein phasenweiser Plan mit Runbook, Testlauf und klaren Rückfall-Optionen. Pexon plant und steuert diesen Weg mit 30 Azure-Spezialisten, ohne Big-Bang und ohne Datenverlust.

Warum die Strategie über den Erfolg entscheidet

Die meisten gescheiterten Migrationen scheitern nicht an der Technik, sondern an der fehlenden Strategie. Wer ohne Plan anfängt, zieht Altlasten mit um, unterschätzt Abhängigkeiten und merkt zu spät, dass halbe Migrationen doppelten Betrieb bedeuten. Eine gute Synapse Fabric Migrationsstrategie klärt vor der ersten umgezogenen Pipeline drei Dinge: was migriert wird, in welcher Reihenfolge, und was das Zielsystem am Ende können muss.

Der Ausgangspunkt ist immer eine Bestandsaufnahme: Welche SQL Pools, Pipelines und Spark-Workloads laufen, welche werden noch gebraucht, welche sind Karteileichen. Diese Inventur ist unspektakulär, aber sie entscheidet über den halben Projekterfolg. Warum sich der Umzug überhaupt lohnt, ist eine eigene Frage (siehe Verwandte Themen).

Lift-and-Shift gegen Modernisierung

Die zentrale Weichenstellung ist die Frage, wie viel Sie beim Umzug verändern.

Lift-and-Shift bedeutet, die bestehende Struktur möglichst unverändert nach Fabric zu übertragen. Das ist schnell und risikoarm, weil wenig neu gebaut wird. Der Preis: Sie nehmen bestehende Ineffizienzen mit und nutzen die Fabric-Stärken wie OneLake und Direct Lake noch nicht voll aus. Als erster Schritt ist das oft trotzdem richtig.

Modernisierung heißt, die Architektur beim Umzug auf Fabric hin zu optimieren: Datenmodelle bereinigen, auf OneLake als zentralen Speicher setzen, Pipelines neu schneiden. Das kostet mehr Aufwand, liefert aber das eigentliche Zielbild. Unsere klare Empfehlung: In der Praxis gewinnt meist ein zweistufiger Weg. Erst ein pragmatisches Lift-and-Shift, um vom feature-frozenen Synapse wegzukommen, dann eine schrittweise Modernisierung im Betrieb. So vermeiden Sie den riskanten Big-Bang.

Der phasenweise Migrationsplan

Ein bewährter Ablauf gliedert die Migration in klare Phasen, jede mit einem definierten Ergebnis:

1. Assessment und Inventur: Bestandsaufnahme aller Objekte, Abhängigkeiten und Datenmengen. Ergebnis ist eine priorisierte Migrationsliste.
2. Zielarchitektur und Runbook: Das Zielsystem in Fabric wird entworfen, das Runbook beschreibt jeden Schritt reproduzierbar. Microsofts Migrationsassistent und die Fabric-Werkzeuge unterstützen dabei.
3. Pilot mit echten Daten: Ein abgegrenzter Bereich wird migriert und validiert, inklusive Data-Factory-Pipelines und Reports.
4. Rollout in Wellen: Die restlichen Workloads folgen in kontrollierten Wellen, mit Rückfall-Option je Welle statt eines einzigen Stichtags.

Genau diesen Plan setzen wir im Rahmen unserer Cloud-Consulting-Leistung und Data-Analytics-Leistung auf. Die technische Umsetzung der einzelnen Bausteine, von OneLake bis zu den SQL Pools, steht in den Verwandten Themen.

Die häufigsten Fallstricke

Drei Fehler sehen wir immer wieder. Erstens der Big-Bang: alles auf einen Stichtag zu migrieren, ohne Rückfall-Option, ist unnötig riskant. Zweitens das Mitschleppen von Altlasten: Wer beim Lift-and-Shift nie modernisiert, hat in Fabric dieselben Probleme wie vorher. Drittens der unterschätzte Testaufwand: Ohne einen echten Pilot mit produktionsnahen Daten fliegen Datentyp- und Logikunterschiede erst im Rollout auf. Wer diese drei vermeidet, hat den Großteil des Risikos im Griff. Den breiteren Microsoft-Data-Kontext liefert der Azure AI Foundry Leitfaden.

Häufig gestellte Fragen

Lift-and-Shift oder Modernisierung, was ist besser?

Kommt auf Ihr Ziel an. Lift-and-Shift ist schnell und risikoarm, nutzt aber die Fabric-Stärken nicht voll aus. Modernisierung liefert das eigentliche Zielbild, kostet aber mehr. In der Praxis bewährt sich ein zweistufiger Weg: erst pragmatisch umziehen, dann im Betrieb modernisieren.

Wie lange dauert eine Synapse-zu-Fabric-Migration?

Das hängt von der Größe der Landschaft ab. Ein abgegrenzter Pilot lässt sich in wenigen Wochen umsetzen, der vollständige Rollout in Wellen zieht sich je nach Umfang über Monate. Wichtig ist nicht die Geschwindigkeit, sondern dass jede Welle kontrolliert und mit Rückfall-Option läuft.

Braucht man einen Migrationsassistenten?

Microsofts Migrationsassistent und die Fabric-Werkzeuge nehmen viel manuelle Arbeit ab, etwa bei der Übertragung von Strukturen. Sie ersetzen aber keine Strategie. Das Runbook, die Reihenfolge und die Zielarchitektur bleiben eine Planungsaufgabe, die vor dem Werkzeugeinsatz steht.

Was kostet die Planung einer Migrationsstrategie?

Die Strategie entsteht in einem Assessment, das Aufwand, Reihenfolge und Kostenbild der Migration konkret macht. Diese Vorarbeit ist der günstigste Teil des Projekts und spart im Rollout ein Vielfaches, weil sie Fehlwege und doppelten Betrieb vermeidet.

Kann man während der Migration produktiv weiterarbeiten?

Ja, genau dafür ist der phasenweise Ansatz da. Statt eines Stichtags migrieren Sie in Wellen, während der Rest weiterläuft. Jede Welle wird validiert, bevor die nächste startet. So bleibt der Betrieb stabil, und ein Problem betrifft nie die ganze Plattform auf einmal.

Nächster Schritt

Sie stehen vor einer Synapse-zu-Fabric-Migration und wollen sie sauber planen statt drauflos zu migrieren? Wir erstellen mit Ihnen die Strategie, das Runbook und den Wellenplan, abgestimmt auf Ihren laufenden Betrieb.

Verwandte Themen