Dataflow Gen1 zu Gen2 Migration: Legacy verstehen, sauber migrieren

Definition

Eine Dataflow Gen1 zu Gen2 Migration überführt bestehende Power-BI-Dataflows (Gen1) in Dataflow Gen2 innerhalb von Microsoft Fabric. Es ist keine „In-Place“-Aktualisierung, sondern ein Neuaufbau auf einer neuen Laufzeit mit eigenen Artefakt-IDs und teils abweichenden Funktionen.

Einleitung

Wenn dein Setup auf Gen1-Dataflows basiert, ist das jetzt ein echtes Legacy-Thema: nicht, weil morgen alles ausfällt, sondern weil Weiterentwicklung und Zukunftssicherheit woanders stattfinden. Die Dataflow Gen1 zu Gen2 Migration ist damit ein Planungs- und Risikothema für IT und Fachbereich: Was muss umziehen, wie testest du sauber, und wie vermeidest du Report-Brüche?

Warum Gen1 „Legacy“ praktisch relevant ist

„Legacy“ heißt im Microsoft-Kontext typischerweise: keine neuen Features, Fokus auf Bugfixing und ein absehbarer Retirement-Pfad. Bestehende Gen1-Dataflows können zunächst weiterlaufen, aber du musst mit zunehmenden Einschränkungen rechnen: weniger Support für neue Quellen, steigende Reibung bei Governance und ein höheres Betriebsrisiko, wenn sich die Umgebung (Gateways, Credentials, Tenants) ändert. Entscheidungsrelevant ist: Je näher du an kritischen Prozessen bist (Standard-KPIs, Finance, tägliche Refreshes), desto weniger willst du dich auf eine auslaufende Technologie verlassen.

Gen2 in Microsoft Fabric: Nutzen, der im Alltag zählt

Dataflow Gen2 ist stärker auf Datenprodukte und Wiederverwendung ausgelegt: Du landest nicht mehr „nur“ für ein Dataset, sondern kannst Daten in Fabric-Zielen wie Lakehouse oder Warehouse bereitstellen. Der Nutzen für Anwender ist konkret: saubere, kuratierte Tabellen (Gold-Daten) stehen zentral bereit, sodass Teams in Power BI oder Excel schneller losbauen können, ohne jedes Mal Power Query neu zu erfinden.

• Bessere Skalierung und Performance für größere Datenmengen (relevant bei vielen Tabellen oder langen Refresh-Zeiten).
• Saubere Einbindung in Orchestrierung (Pipelines) statt „Refresh als schwarzer Kasten“.
• Mehr Klarheit bei Datenzielen: Daten können für mehrere Reports und Teams wiederverwendet werden, nicht nur für ein einzelnes Modell.

Gen1 vs. Gen2: Kompatibilität, die du vorab klären musst

Der wichtigste Vergleich ist nicht „Feature-Liste“, sondern „Was bricht bei uns?“ Gen2 nutzt weiterhin Power Query und M Language (Power Query M), aber nicht jede Gen1-Logik ist 1:1 übertragbar. Typische Prüfpunkte sind: verwendete Connectoren, Parameter/Functions, Abhängigkeiten über Linked/Computed Entities sowie Authentifizierung (Cloud vs. On-premises data gateway).

Faustregel: Je „cleaner“ dein Gen1-Dataflow ist (klare Query-Schritte, wenig Spezial-Workarounds, saubere Credentials), desto schneller kommst du rüber. Je mehr historisch gewachsene M-Skripte, Gateway-Sonderfälle und manuelle Refresh-Fixes existieren, desto wichtiger wird ein POC mit echter Test-/Validierungsphase.

Migration-Optionen im Überblick (ohne Wunschdenken)

Es gibt mehrere Wege, Gen1-Logik nach Gen2 zu bekommen. Wichtig: Du bekommst neue Artefakte, oft mit neuer ID. Plane also immer auch das Update von Abhängigkeiten (z. B. wer nutzt die Ausgaben, welche Reports/Modelle hängen dran).

• Export Template: Gen1 als Power-Query-Template exportieren und in Gen2 übernehmen. Gut für strukturierte, wiederholbare Migrationen.
• Copy & Paste: M-Queries kopieren und in Gen2 einfügen. Schnell für kleine Dataflows oder einzelne Queries.
• Save As / CI/CD: „Save As“ in Richtung Gen2 und anschließend über Deployment/CI/CD kontrolliert ausrollen. Gut, wenn du Dev/Test/Prod ernst nimmst.

Voraussetzungen: Fabric Capacity, Berechtigungen, Umgebung

Dataflow Gen2 ist an Microsoft Fabric gekoppelt. Entscheidend ist daher die Fabric Capacity: ohne passende Capacity wird es entweder gar nicht gehen oder nicht stabil betrieben werden können. Zusätzlich brauchst du klare Workspace-Regeln und Rollen: Wer darf erstellen, wer darf Credentials verwalten, wer darf veröffentlichen?

Typische Mindestanforderungen für einen sauberen Start: Fabric Capacity aktiv im Ziel-Workspace, Contributor-/Member-Rechte für Entwickler, geregelte Zugriffspfade auf Quellen (Cloud-Connectoren oder On-premises data gateway), sowie ein festgelegtes Ziel (Lakehouse oder Warehouse), damit die Daten nicht wieder im nächsten „Datensilo“ enden.

POC-Plan und schrittweises Vorgehen inkl. Test/Validierung

Wenn du Kosten, Zeitaufwand und Risiko ernsthaft steuern willst, mach keinen Big Bang. Starte mit einem POC, der technisch und fachlich repräsentativ ist: 1–2 Dataflows, die typischen Transformationsaufwand und echte Nutzeranforderungen abdecken.

Pragmatischer Ablauf

• Inventar: Welche Gen1-Dataflows gibt es, welche Quellen (SQL, Dateien), welche Refresh-Fenster, welche Abhängigkeiten?
• Migration: Eine Option wählen (Template/Copy/Save As) und im Test-Workspace umsetzen.
• Validierung: Side-by-Side-Vergleich gegen „existing“ Gen1-Ergebnisse (Row-Counts, Summen, Stichproben), Refresh-Dauer, Fehlermeldungen, Berechtigungen.

Erfolgs-Messbarkeit: Definiere vorab 3 Kennzahlen, z. B. Refresh-Zeit, Fehlerquote/Retry-Aufwand und Anzahl manueller Eingriffe pro Monat. Damit kannst du nach dem Go-live objektiv sagen, ob die Migration ihr Ziel erreicht.

Risiken, typische Hindernisse und wie du sie entschärfst

Die häufigsten Stolpersteine sind nicht „M funktioniert nicht“, sondern Betrieb und Abhängigkeiten: fehlende Credentials, unstimmige Gateway-Konfiguration, andere Datenziele (Lakehouse/Warehouse) und daraus folgende Anpassungen in nachgelagerten Modellen. Dazu kommt: Neue IDs bedeuten, dass Verknüpfungen nicht automatisch „magisch“ mitwandern.

Was hilft: klare Cutover-Planung (Parallelbetrieb), saubere Dokumentation pro Dataflow (Quelle, Transformation, Ziel), und Monitoring der Refreshes nach dem Go-live. Wenn du viele Dataflows hast, lohnt sich zusätzlich ein Standard für Namenskonventionen und Workspaces, damit nicht wieder Wildwuchs entsteht.

Zeitplan, Retirement-Info und Kommunikation

Kommunikation ist Teil der Technik: Stakeholder müssen verstehen, dass „Legacy“ nicht Panik bedeutet, aber Priorisierung. Plane intern mit einem klaren Fenster: POC (kurz, fokussiert), dann Wellenmigration nach Kritikalität. Kommuniziere einen Freeze-/Cutover-Termin pro Welle, plus einen Zeitraum für Parallelbetrieb, in dem Gen1 und Gen2 bewusst gegengeprüft werden. So minimierst du Risiko und vermeidest, dass Fachbereiche plötzlich anderen Zahlen „nicht mehr trauen“.

Wann externe Unterstützung sinnvoll wird

Externe Hilfe lohnt sich, wenn mindestens eines davon zutrifft: viele Dataflows und unklare Abhängigkeiten, kritische Refresh-Fenster (z. B. morgens vor 8 Uhr), oder kein Team, das Fabric Capacity, Workspaces und Pipelines sauber betreiben kann. Dann geht es weniger um „Implementierung“, sondern um einen robusten Migrationspfad inkl. Testlogik und Betriebssetup.