Migrate ADF to Microsoft Fabric.

ADF and Microsoft Fabric are close cousins, which is exactly the trap

On paper, moving Azure Data Factory to Microsoft Fabric looks like the easiest migration in the Microsoft estate. Data Factory in Microsoft Fabric is, in Microsoft’s own words, “the next generation of Azure Data Factory.” A Fabric Data pipeline has the same shape as an ADF pipeline: activities grouped into a workflow, a Copy activity that looks identical, the same family of control-flow activities, If Condition, Switch, For Each, Until. Microsoft states that roughly ninety percent of ADF activities are already available in Fabric. So the temptation is to treat this as a copy-paste exercise.

That closeness is the trap. The ten percent that does not map is concentrated in exactly the constructs that carry the most business logic and the most operational risk: Mapping Data Flows, self-hosted integration runtime dependencies, and the parameter sprawl of metadata-driven pipelines. A naive lift-and-shift sails through the easy ninety percent and then quietly breaks on the parts nobody can see from a single JSON file. That is why the agent fleet documents the logic, not just the labels, before it builds anything.

What actually breaks in a naive port

Mapping Data Flows have no runtime on Fabric. There is no “execute data flow” you can re-point. Microsoft maps Mapping Data Flow to Dataflow Gen2 (the Power Query experience) and Wrangling Data Flow alongside it. A flow’s real content - alter-row policies that drive SCD behavior, derived-column expressions, conditional splits, joins and aggregates - has to be re-expressed, either as Dataflow Gen2 steps, as set-based SQL, or as a PySpark notebook writing Delta. Copy the pipeline JSON and you copy a reference to a flow that simply will not execute.

Self-hosted IR dependencies do not travel. Any pipeline that reaches an on-premises or network-restricted store is implicitly bound to a self-hosted integration runtime - custom drivers, firewall rules, a particular network topology. On Fabric that role belongs to the On-premises Data Gateway, and Fabric’s managed compute removes the Azure/Auto-resolve IR entirely. None of that re-plumbs itself. If a migration assumes connectivity that no longer exists, the first real run fails at extract time.

Parameter sprawl hides the behavior. ADF rewards metadata-driven design: one generic pipeline, a control table, a ForEach loop, and dynamic-content expressions like @activity('Lookup').output threaded between activities. The consequence is that what actually runs is data-dependent and invisible in any single pipeline file. You cannot reconstruct the real workload by reading JSON; you have to resolve the parameter values and the control metadata.

Datasets, linked services and triggers all change shape. Fabric collapses datasets and linked services into Connections, with data properties defined inline in activities. ADF triggers split into Fabric schedules and event triggers - and tumbling-window triggers specifically map to interval-based schedules. Each of these is a small translation, but there are many of them, and the dependsOn dependency graph (with its Succeeded / Failed / Skipped / Completed conditions) has to be rebuilt faithfully as activity success and failure paths or the error-handling branches silently vanish.

How the fleet handles ADF → Fabric

The Documenter parses the Git-backed JSON artifacts (pipelines, activities, the dependsOn graph, datasets, linked services and triggers) and, crucially, resolves the parameterization rather than reading it literally. It follows a ForEach back to its control table and a dynamic-content expression back to the activity output that feeds it, so the knowledge base captures what the estate does, not just what it is named. Self-hosted IR usage is detected and raised at the assessment gate. That keeps the hard parts visible to a human before a single line is built.

From the knowledge base, the builders generate one of two flavors. In the dbt flavor, transformation logic from the data flows becomes Warehouse models; SCD Type 2 flows become dbt snapshots with dbt_valid_from / dbt_valid_to history; upserts become incremental models on the dbt-fabric default merge strategy keyed on a unique_key; and a thin Fabric Data pipeline still runs the Copy activity and then triggers the dbt run, because dbt transforms, it does not move bytes. In the your-framework flavor, the fleet rebuilds native Fabric Data pipelines with Copy activities and control-flow activities, rewrites each Mapping Data Flow as Dataflow Gen2 or a PySpark notebook, replaces linked services with Connections, and re-creates triggers as schedules and event triggers in your own orchestration conventions.

Then the build-test-run loop takes over. The test agent runs the rebuilt pipeline against real inputs and compares the output to the original ADF run: row counts, SCD history, schema. A failure is not added to a list; it goes back to the builders and the loop re-runs. The iteration log on this page is representative: a dropped alter-row policy, an unresolved pipeline parameter, a stale gateway schema, each caught and fixed, until the run comes back green with a row delta of zero. Autonomous in the loop. Accountable at the gates: assessment, design, and promotion are yours.

If Spark and Unity Catalog are a better fit for your estate, Migrate ADF to Databricks covers the same pair onto that platform.