The bottom line
Fabric Data Factory shares ADF's pipeline heritage but differs in the places that matter for a migration. Triggers: ADF's schedule, tumbling-window and event triggers map onto Fabric's scheduling and the event-driven Data Activator, but not one-for-one, so trigger logic is re-created, not copied. Linked services become connections managed at the tenant/workspace level, with on-premises access through the on-premises data gateway rather than a self-hosted integration runtime. Dataflows Gen2 replace mapping/wrangling data flows with a different authoring surface. And the cost model changes fundamentally — from ADF's per-activity-run and IR-hours billing to Fabric capacity (CU) consumption, which can be cheaper or dearer depending on workload shape. Where it breaks: there is no true one-click migration, heavy custom ADF patterns need rebuilding, and capacity contention is a new failure mode.
In This Article
It shares DNA with ADF — and that is the trap
Fabric Data Factory is built on the same pipeline engine as Azure Data Factory, so the authoring experience is familiar and much of the activity library looks identical. That familiarity is useful and also the source of the trap: teams assume parity and plan a mechanical migration, then hit the areas where Fabric deliberately does things differently because it lives inside a unified SaaS platform rather than as a standalone Azure service.
The differences cluster in four places — triggers, connections and gateways, data flows, and the cost model — and each one touches production operation. A migration that respects those differences is straightforward; one that assumes a rename discovers them during the first failed overnight load. Plan it as a migration with a parallel-run period, not a cutover.
Triggers and scheduling are not one-for-one
ADF has three trigger types — schedule, tumbling window, and storage/event — and production pipelines often lean on their specific behaviours, particularly tumbling window's dependency and backfill semantics. Fabric handles scheduling natively on pipelines and brings event-driven execution through Data Activator (Reflex) and event streams, but the mapping is not literal: tumbling-window dependencies and backfill in particular need re-expressing rather than copying, and event triggers are wired through Fabric's eventing rather than an ADF event trigger.
The practical implication is that trigger logic is re-created and re-tested, not exported. For most schedule-based pipelines this is quick; for pipelines that depend on tumbling-window chaining or precise event semantics it is design work. Catalogue every trigger and its dependency behaviour before migrating, because a trigger that silently fires differently is a data-timing bug that surfaces as a late or doubled load.
Linked services, connections and the gateway
ADF's linked services become Fabric connections, managed centrally and reusable across items rather than defined per factory, which is cleaner but means credentials and connection objects are re-established in Fabric rather than imported wholesale. The bigger shift is the runtime for reaching data: ADF's self-hosted integration runtime, which many on-premises SAP and SQL Server loads depend on, is replaced in the Fabric world by the on-premises data gateway.
That gateway change matters for anyone pulling from on-premises sources — the connectivity is re-provisioned and re-tested, and the operational ownership of the gateway (who patches it, who monitors it) is re-established. For a cloud-only estate this is minor; for a manufacturer pulling from an on-premises SAP S/4HANA or a plant SQL Server, the gateway migration is one of the more careful parts of the exercise and should be rehearsed against a non-production source first.
The two migration areas that most often bite: tumbling-window trigger semantics, and on-premises connectivity moving from a self-hosted integration runtime to the on-premises data gateway. Rehearse both before touching a production load.
Data flows and pipelines: what maps and what rebuilds
Pipelines and their activities migrate relatively well — the orchestration concepts are shared, and copy activities and control flow look familiar. Data transformation is where the authoring surface changes: ADF's mapping data flows and wrangling data flows give way to Dataflows Gen2 in Fabric, built on the Power Query engine, which is a different authoring model rather than a direct import. Transformation logic is rebuilt on the new surface, not lifted across.
For estates that kept transformation in SQL or notebooks and used ADF mainly for orchestration, the migration is lighter — the heavy logic was never in ADF data flows. For estates that invested in complex mapping data flows, that logic is re-authored in Dataflows Gen2 or moved to Fabric notebooks/Spark, which is an opportunity to simplify but also real work. Inventory where your transformation logic actually lives before estimating the migration.
The cost model changes fundamentally
This is the difference finance will notice. Azure Data Factory bills per activity run, per data-movement volume, and per integration-runtime hour — a granular, usage-based model. Fabric Data Factory consumes Fabric capacity units (CU) from the same shared capacity as every other Fabric workload, so pipeline cost becomes part of the capacity planning rather than a separate per-run line.
Whether that is cheaper depends entirely on workload shape. A heavy, bursty ADF workload may be more economical on dedicated Fabric capacity; a light, intermittent one may be cheaper on ADF's pay-per-run. The real risk is not the headline cost but contention: pipeline runs now compete for the same CUs as Power BI queries and lakehouse jobs, so a heavy overnight load can throttle capacity that interactive reporting needs in the morning. Model the capacity consumption and the timing, not just the sticker price.
Where this breaks
There is no reliable one-click migration. Microsoft provides tooling and guidance, but tumbling-window triggers, complex mapping data flows, self-hosted IR dependencies and custom activities need deliberate rebuilding and testing. Treating the migration as automatic is the single most common way it goes wrong — budget for a proper migration project with a parallel-run period, not a weekend.
Capacity contention is a genuinely new failure mode: in ADF a runaway pipeline cost money; in Fabric it can starve your reporting layer of capacity, so workload scheduling and capacity sizing become operational concerns they were not before. And some ADF capabilities and third-party connectors may not have exact Fabric equivalents yet — check the specific activities and connectors your pipelines use against current Fabric support before committing a date, because a missing connector is a blocker discovered too late.
What to do first
Inventory before you migrate — the estimate lives in the detail, not the headline.
- Catalogue every pipeline, trigger (and its dependency/backfill behaviour), linked service and data flow, and where transformation logic actually lives
- Flag the hard parts: tumbling-window triggers, mapping data flows, self-hosted IR / on-premises sources, custom activities
- Confirm every connector and activity you use has current Fabric support before committing a timeline
- Model Fabric capacity consumption and run timing, including contention with Power BI and lakehouse workloads
- Migrate in waves with a parallel-run period and reconciliation, rehearsing the on-premises gateway cutover against a non-production source first
If you are planning an Azure Data Factory to Fabric move, the risk is in the triggers, gateways and capacity model — not the pipelines you can see. Book 30 minutes with Amit for an honest migration assessment of your ADF estate. No slides, no pitch deck, no obligation to proceed.
Free Assessment
Where does your operation sit on the data maturity curve?
8 questions. 3 minutes. You get a scored breakdown across data infrastructure, analytics readiness, and automation potential — with a specific next step for your industry.