top of page
Suche

Migration von Azure Data Factory zu Fabric Data Factory: Geht das – und wie aufwändig ist es wirklich?


Microsoft Fabric bringt mit Data Factory in Fabric eine neue, SaaS-orientierte Datenintegrationsschicht, die viele Konzepte aus Azure Data Factory (ADF) bewusst weiterführt – aber nicht 1:1 identisch ist.

Für viele Organisationen stellt sich deshalb die pragmatische Frage: Kann ich meine ADF-Landschaft nach Fabric Data Factory migrieren, wie komplex ist das, welche Vor- und Nachteile entstehen – und gibt es Tools, die helfen?


Dieser Artikel ordnet genau das ein, mit Fokus auf typische Enterprise-Realität: bestehende Pipelines, heterogene Quellen, Sicherheits- und Betriebsanforderungen, CI/CD, und die Frage nach „Lift & Shift“ vs. „Modernisieren“.



Migration von Azure Data Factory zu Microsoft Fabric Data Factory




1) Geht eine Migration überhaupt?

Ja – Migration ist möglich, aber in der Praxis meistens eine Mischung aus Konvertieren, Nachbauen und Modernisieren.


Microsoft beschreibt dafür explizit einen Migrationspfad inkl. Planungsschritten und Konvertierungs- bzw. Conversion-Tools. Dazu gehören u. a. eine Planungs-/Assessment-Phase, die Nutzung von ADF-Items in Fabric (für Kontinuität) sowie ein PowerShell Conversion Tool für Pipelines mit hoher Funktions-Parität.


Wichtig ist: Fabric Data Factory ist nicht nur „ADF unter neuem Namen“, sondern hat eigene Artefakte und Schwerpunkte (z. B. stärker vereinfachte Data Movement Patterns, Copy Job/Assistenten, engere Verzahnung mit OneLake/Fabric Workspaces).



2) Was ist Fabric Data Factory im Kern – und was ist anders als ADF?


Gemeinsamkeiten (konzeptionell):

Pipelines mit

  • Activities,

  • Parametern,

  • Triggering

  • Orchestrierung

sind weiterhin das Grundmodell.


Viele Copy- und Orchestrierungs-Patterns lassen sich übertragen (z. B. Copy, Lookup, Stored Procedure-orchestrierte Schritte).


Unterschiede (praktisch relevant):

Fabric Data Factory ist workspace- und Fabric-zentriert und spielt eng mit anderen Fabric-Workloads zusammen (Lakehouse/Warehouse/Notebooks/Dataflow Gen2 etc.).


Es gibt in Fabric mit Copy Job ein sehr „UI-first“ Data-Movement-Artefakt für viele Standardfälle – ohne dass zwingend eine Pipeline gebaut werden muss.

Bestimmte ADF-Funktionen/Patterns sind (noch) nicht verfügbar oder unterscheiden sich (siehe Limitations).



3) Wie komplex ist die Migration? Eine realistische Einordnung

Die Komplexität hängt weniger von der Anzahl Pipelines allein ab, sondern davon, welche Features Sie in ADF genutzt haben und wie „plattformnah“ die Implementierung ist. Wir nehmen nachstehend eine kleine Einordnung vor.


Kategorie A: „Hohe Parität“ – oft gut konvertierbar

Typische Beispiele hier können sein:

  • Standard Copy-Pipelines (SQL → Lake/Storage, File → Lake, etc.)

  • Einfache Orchestrierung: Lookup, If/ForEach, Execute Pipeline, Stored Procedure Calls

  • Parameterisierte, wiederkehrende Muster


Für solche Muster zielt Microsoft explizit auf automatisierte Migration per PowerShell Conversion Tool (Skalierung von Aktivitäten/Parametern).


Kategorie B: „Teils kompatibel“ – Migration möglich, aber mit Umbau

Typische Beispiele:

  • Komplexe Steuerlogik, verschachtelte Pipelines, umfangreiche dynamische Content-Ausdrücke

  • Custom/Edge-Connectoren oder spezielle Authentifizierungs-Flows

  • Starkes Zusammenspiel mit Azure Key Vault, OAuth-basierte Connector-Auth, Managed Identity über viele Quellen


Hier ist die Realität: Sie migrieren nicht nur „Code“, sondern Security-/Connectivity-Patterns.


Kategorie C: „Replatforming“ – eher neu denken als kopieren

Typische Beispiele hier sind:

  • ADF Mapping Data Flows als zentrales Transformations-Backbone

  • Heavy Data Engineering Workloads, die in Fabric besser als Notebook/Spark/SQL umgesetzt werden

  • Near-real-time Muster, die eher in Eventstream/Real-Time Analytics gehören


Microsoft liefert hierfür eine Entscheidungshilfe, wann Copy Activity/Copy Job/Dataflow/Spark/Eventstream sinnvoll ist.



4) Limitations & Gap-Analyse: Was bremst typische ADF-Migrationen?

Die wichtigste Gegenfrage vor jeder Migration lautet: Welche ADF-Funktionen nutze ich, die Fabric (noch) nicht kann oder anders löst?


Microsoft dokumentiert aktuelle Einschränkungen für Pipelines in Fabric Data Factory, u. a.:

  • Tumbling Window Trigger ist (noch) nicht verfügbar.

  • Bestimmte Connector-Features (z. B. OAuth, Azure Key Vault Integration) sind eingeschränkt.

  • Managed Identity ist aktuell nicht überall verfügbar (z. B. zunächst nur für bestimmte Stores).


Solche Punkte entscheiden, ob Sie:

  1. sofort migrieren können,

  2. ein Hybrid-Szenario fahren müssen (ADF weiterbetreiben, schrittweise verlagern), oder

warten/umdesignen sollten.



5) Vor- und Nachteile der Migration


Vorteile

(1) Vereinheitlichung in Fabric

Wenn Ihr Zielbild ohnehin Fabric ist (OneLake, Lakehouse/Warehouse, Power BI im selben Tenant-/Workspace-Kontext), reduziert Fabric die Tool-Fragmente und fördert End-to-End-Workflows.


(2) Schnellere Standard-Data-Movement-Umsetzung

Copy Job (inkl. inkrementellen Varianten und CDC-orientierten Ansätzen) ist als „go-to“ Bewegungskomponente gedacht – oft schneller als komplette Pipeline-Modellierung.


(3) Nahtlose Orchestrierung über mehrere Fabric-Artefakte

In Fabric-Pipelines können Sie Copy, Dataflow, Notebooks etc. in einem Orchestrierungsrahmen kombinieren.


Nachteile / Risiken

(1) Feature-Gaps gegenüber „reifem“ ADF

Gerade Trigger-/Auth-/Connector-Themen sind oft show-stopper. Das muss man früh prüfen (Gap-Analyse).


(2) Operative Reife, Governance & Migrationstiefe

Bei großen ADF-Landschaften ist die eigentliche Arbeit häufig nicht „Pipelines nachbauen“, sondern:

  • Monitoring/Alerting-Parität

  • Deployment- und Environment-Strategie

  • Naming/Foldering/Ownership

  • Berechtigungen und Secret-Handling


(3) „Lift & Shift“ ist selten optimal

Viele ADF-Lösungen enthalten technische Schulden (historische Patterns, Workarounds, überkomplexe Parameterlogik).


Eine Migration ist oft der beste Zeitpunkt für Vereinfachung – aber das erhöht kurzfristig den Projektumfang.



6) Gibt es Tools für die Migration?

Ja – und es gibt mehrere Ebenen von „Tools“:


(A) Microsoft-native Tools/Ansätze

1) ADF in Fabric „sichtbar machen“ (Kontinuität / schrittweise Migration)

Microsoft beschreibt einen Ansatz, bei dem bestehende ADF-Instanzen in Fabric „sichtbar“ sind, sodass Sie graduell migrieren und testen können.


2) PowerShell Conversion Tool

Für Pipelines mit hoher Parität (typisch: Copy/Lookup/Stored Procedure) wird ein PowerShell-Konvertierungstool genannt, das Migration in größerem Maßstab automatisieren soll.


3) Best-Practices & Migration Guidance

Microsoft dokumentiert Best Practices inkl. Hinweisen auf Partnerangebote und typische Enterprise-Szenarien (z. B. viele Pipelines, diverse Connectoren, Downtime-Anforderungen).


(B) Partner-Tools (Azure Marketplace / Migration Suites)

Microsoft verweist auf „Trusted migration partners“, die u. a. Scans, Zielartefakt-Generierung, Impact-Analyse/Lineage und Testpläne unterstützen.

Das ist besonders relevant, wenn Sie hunderte Pipelines und strikte Betriebsanforderungen haben.


(C) Praktische Hilfstools im Alltag

Auch ohne „großes Migrationstool“ sind diese Bausteine essenziell:

  • Inventory/Export Ihrer ADF-Pipelines (Definitionen, Parameter, Trigger, Datasets, Linked Services)

  • Automatisierte Tests (Datenstichproben, Row-Counts, Checksummen, SLA-Vergleiche)

  • Observability/Monitoring-Checks in Fabric (Pipeline Runs, Failure Patterns, Retry Semantik)



7) Ein bewährter Migrationsablauf

Schritt 1: Inventarisieren & klassifizieren

Listen Sie Pipelines nach Typ:

  • Data Movement (Copy)

  • Orchestrierung (ELT-Steuerung)

  • Transformation (Mapping Data Flows vs. SQL/Notebook)

  • Trigger-Typen (Schedule/Event/Tumbling Window)

  • Auth/Secrets (Key Vault, OAuth, MSI)


Schritt 2: Paritätscheck gegen Fabric-Limitations

Vergleichen Sie Ihre „Must-Haves“ mit den aktuellen Fabric-Einschränkungen.


Schritt 3: Zielmuster pro Pipeline festlegen

Nutzen Sie die Fabric-Entscheidungshilfe:

  • Copy Job vs. Copy Activity

  • Dataflow Gen2 vs. Notebook/Spark

  • Eventstream für Streaming-nahe Szenarien


Schritt 4: Pilot (10–20% der Pipelines)

Wählen Sie repräsentative Pipelines (nicht nur die einfachen) und messen:

  • Build-Time

  • Run-Time

  • Kosten-/Kapazitätsauswirkung

  • Betrieb (Monitoring, Fehlerbehandlung)


Schritt 5: Skalierung mit Conversion Tool + Standards

Wo möglich konvertieren, wo nötig redesignen. Für „High Parity“ Pipelines lohnt Automatisierung.


Schritt 6: Cutover & Parallelbetrieb

Fahren Sie zeitlich begrenzten Parallelbetrieb (ADF & Fabric) mit Vergleichsmetriken, bis Datenqualität/SLA stabil sind.




Fazit: Migration von Azure Data Factory zu Microsoft Fabric Data Factory

Die Migration von Azure Data Factory zu Microsoft Fabric Data Factory geht – aber selten als reines Copy/Paste. 


Für viele Standard-Pipelines ist die Migration gut machbar und lässt sich teilweise automatisieren (u. a. über Microsofts PowerShell-Konvertierungsansatz).

Gleichzeitig entscheiden Feature-Gaps (Trigger/Auth/Connectoren) und Ihr Transformationsansatz (Dataflow vs. Spark/SQL) über den tatsächlichen Aufwand.


Wer Fabric ohnehin als Zielplattform gewählt hat, kann durch die Migration langfristig profitieren: mehr Vereinheitlichung, klarere End-to-End-Flows und schnellere Standard-Data-Movement-Umsetzung via Copy Job.



Swiss Business Analytics als Partner für Migration und Umsetzung

Die Migration von Azure Data Factory zu Fabric Data Factory ist selten ein rein technisches Vorhaben. In der Praxis treffen bestehende ADF-Landschaften, gewachsene Betriebsmodelle, Sicherheitsanforderungen, Kostenüberlegungen und organisatorische Abhängigkeiten auf eine neue Plattformlogik in Microsoft Fabric. Genau hier entscheidet sich, ob eine Migration nachhaltig gelingt oder lediglich bestehende Komplexität verschoben wird.


Swiss Business Analytics begleitet Unternehmen gezielt in dieser Übergangsphase. Der Fokus liegt nicht auf schematischen Migrationspfaden, sondern auf einer realistischen Einordnung:

Welche ADF-Pipelines lassen sich sinnvoll migrieren, welche sollten neu gedacht werden und wo ist ein hybrider Betrieb temporär die bessere Lösung.


Entscheidungen werden dabei konsequent workload-getrieben getroffen – basierend auf Datenquellen, Orchestrierungslogik, Transformationsgrad, Betriebsanforderungen und Governance.


In der Umsetzung reicht die Erfahrung von strukturierten Migrationsanalysen über den Aufbau von Fabric-konformen Data-Integration-Patterns bis hin zur sauberen Einbettung von Fabric Data Factory in eine bestehende Fabric-Architektur.


Dazu zählen unter anderem die Integration mit OneLake, Lakehouse- und Warehouse-Workloads, der Einsatz von Dataflows Gen2, Notebooks und Pipelines sowie Themen wie Workspace-Design, Kapazitätsplanung, CI/CD und Betriebskonzepte.


Der Mehrwert liegt nicht in der reinen Tool-Migration, sondern in einer stabilen, wartbaren und zukunftsfähigen Datenplattform. Swiss Business Analytics unterstützt genau dort, wo aus einer technischen Migration eine tragfähige Fabric-Lösung werden muss.



Ihr Partner für moderne Datenplattformen


Swiss Business Analytics GmbH unterstützt Sie bei der Einführung von Microsoft Fabric, der Entwicklung einer nachhaltiger Datenarchitekturen, Trainings für IT und Fachbereiche und auch bei der Umsetzung von Datenprodukten und Self-Service-Konzepten.


👉 Kontaktieren Sie uns für ein unverbindliches Beratungsgespräch – wir helfen Ihnen, Hype in Realität zu verwandeln.



Swiss Business Analytics GmbH – Ihr Partner für datengetriebene Lösungen.


Wenn Sie erfahren möchten, wie Microsoft Fabric Ihre Datenstrategie transformieren kann, kontaktieren Sie Swiss Business Analytics. Wir helfen Ihnen dabei, die richtigen Lösungen für Ihr Unternehmen zu entwickeln.

bottom of page