Microsoft Fabric vs Azure Data Factory: What's New
Microsoft calls Fabric Data Factory the next generation of Azure Data Factory. This guide maps each Data Factory concept to its Fabric counterpart, lists what Fabric adds and what its documentation says is still missing, explains the move from pay-as-you-go to capacity billing, and sets out the three upgrade paths.
GloryTecks Team
Training & Placement Faculty
Last updated: 2 October 2026
Open almost any Azure Data Factory documentation page today and the first thing on it is a notice: Data Factory in Microsoft Fabric is the next generation of Azure Data Factory, and if you are new to data integration, start there. For anyone who has spent years learning linked services and integration runtimes, that sentence raises obvious questions. Microsoft Fabric vs Azure Data Factory: what actually changes, what does not, and is it time to move?
Everything below is taken from Microsoft's comparison and upgrade documentation as it stood when this was written. Fabric changes quickly; check the linked pages for the current state.
Two different kinds of service
Azure Data Factory is a platform service in Azure. You create a factory in a subscription, manage its integration runtimes and network, and pay for what each run consumes.
Microsoft Fabric is an analytics platform delivered as software as a service. Data Factory is one workload in it, beside data engineering, a data warehouse and Power BI, all working over OneLake, a single logical data lake built on Azure Data Lake Storage (Microsoft Learn: what is Microsoft Fabric).
Microsoft's own comparison puts it in two words: Azure Data Factory is a data integration PaaS service, and Fabric pipelines are a data integration SaaS service (Microsoft Learn: differences between Data Factory in Fabric and Azure). Most of the differences below follow from that. A SaaS service hides infrastructure, and with it some control.
What maps to what
| Azure Data Factory | Fabric Data Factory | What changes |
|---|---|---|
| Pipeline | Pipeline | Same model; the JSON definitions differ |
| Linked service | Connection | Simpler to set up |
| Dataset | None | Data properties are defined inline in each activity |
| Mapping data flow | Dataflow Gen2 | A Power Query experience |
| Azure integration runtime | Not needed | Fabric manages the compute |
| Self-hosted integration runtime | On-premises data gateway | The gateway used by Power BI |
| Triggers | Schedules and event triggers | No standalone, shared trigger objects |
| Publish | Save, or Run | No publishing step |
| Debug mode | Always interactive | No separate debug |
| Execute Pipeline activity | Invoke Pipeline activity | Can call across platforms |
| Global parameters | Variable library | A different implementation |
| Managed identity | Workspace identity | A different identity model |
| ARM templates for CI/CD | Deployment pipelines | Built in; individual items can be promoted |
| Expression language | Expression language | Nearly identical |
The last row matters most for anyone worried about their skills. Microsoft's wording is that your existing expression knowledge transfers directly. So does the orchestration model: activities, dependencies, parameters, loops and conditions.
What disappears
Three things that every Data Factory developer manages are gone.
Datasets. In Fabric a Copy activity carries its own file path, format and compression. There is no separate object to create and reuse. For simple pipelines this is less work. For metadata-driven designs built around parameterized datasets, it is a change in pattern: the upgrade guide says to parameterize the connection object instead.
The publish step. There is no gap between saved and live. That removes a common source of confusion, and it removes a checkpoint.
Integration runtimes. Cloud compute is managed for you. For on-premises sources the self-hosted runtime is replaced by the on-premises data gateway, which is a different product with different properties: Microsoft's comparison lists, for example, that the gateway stores credentials centrally in the gateway cloud service with no Key Vault integration, where the self-hosted runtime stores them locally and supports Key Vault.
What is new
- Activities for Microsoft 365: Outlook email and Teams messages as pipeline steps, where Data Factory needs a Logic App.
- Semantic model refresh as an activity, for Power BI.
- Native lakehouse and warehouse destinations, and OneLake shortcuts that let a pipeline work on external data without copying it.
- Built-in deployment pipelines, with the ability to promote individual items. Azure Data Factory deploys everything in the collaboration branch or nothing; see CI/CD for Azure Data Factory.
- Copilot for creating and editing pipelines.
- A monitoring hub that spans workspaces and item types.
What is not there yet
Microsoft's documentation is candid about the gaps, and they are the part to read before planning anything.
- Activity coverage is about 90%. The comparison says approximately 90% of Data Factory activities are available. The Validation activity has to be rebuilt from Get Metadata and If Condition, and the Synapse notebook activities have no counterpart.
- SSIS. The feature table marks the Azure-SSIS integration runtime as to be determined, with the design still being worked on. The upgrade guide's advice for now is to run SSIS packages with Data Factory pipelines and call them from Fabric. The Fabric pricing page does list a meter for SQL Server Integration Services, so this is an area in motion.
- Managed virtual networks and private endpoints are also marked to be determined in the feature table, with a virtual network data gateway described as the Fabric approach.
- Scheduling. Data Factory has triggers as shared objects: one trigger for many pipelines, managed centrally. The upgrade guide says Fabric currently requires per-pipeline schedule management, with no schedule reuse or central hub.
- Key Vault. Described as mature in Data Factory and as limited integration in Fabric. If your security design rests on Key Vault references, compare what is supported.
- Dynamic connections. Connection properties do not support dynamic values the way parameterized linked services do.
- Data flows. The standard dataflow in Fabric is Power Query based, and four mapping data flow transformations, Assert, Alter Row, Stringify and Window, are not supported in it. Running mapping data flow transforms in Fabric is a preview feature (Microsoft Learn: Fabric guide for mapping data flow users). Wrangling vs mapping data flows covers the two styles.
None of these is a verdict. Each is a line to check against your own factory.
How you pay
This is the largest practical difference, and it is a difference in kind.
Azure Data Factory is pay-as-you-go. Each activity run, each DIU-hour of copying, each vCore-hour of data flow is metered and billed. A factory that runs nothing costs close to nothing.
Fabric is capacity-based. You buy a capacity, an F SKU, and workloads draw on it in Capacity Units. For pipelines Microsoft publishes the rates: 1.5 CU hours for data movement, and 0.0056 CU hours for each non-copy activity run (Microsoft Learn: pricing for pipelines). Other items a pipeline starts, a notebook or a dataflow, consume capacity of their own.
Neither model is cheaper in general. A capacity is paid for while it runs, however much of it is used, and is shared by everything in it: pipelines, warehouses, notebooks and Power BI. An organisation already running Fabric capacity may find pipelines nearly free at the margin. One with a handful of nightly copies may find a capacity costs more than its entire Data Factory bill. The comparison needs your own numbers.
Three ways to move
Microsoft describes three upgrade paths (Microsoft Learn: upgrade planning).
1. Mount the factory in Fabric. An Azure Data Factory item in a Fabric workspace gives a live view of an existing factory. Nothing is converted. Pipelines keep running on Azure Data Factory's infrastructure, with the same integration runtimes and Azure billing, and the factory can be unmounted at any time (Microsoft Learn: Azure Data Factory item in Fabric). It is a way to look, not a migration.
2. The built-in upgrade experience. An assessment classifies every pipeline and activity as Ready, Needs review, Coming soon or Not compatible, and supported pipelines can be upgraded into a workspace one at a time.
3. Manual rebuilding, for pipelines with low parity. The guide's own steps begin with an inventory and with removing unused items before converting anything, which is good advice whatever the destination.
What a conversion involves, from the same guide: linked services recreated as connections, global parameters as variable libraries, dataset properties moved inline, self-hosted runtimes replaced with gateways, and unsupported activities rebuilt.
Should you move?
| Situation | Reasonable position |
|---|---|
| Starting a new data platform, no existing factory | Follow Microsoft's advice and evaluate Fabric first |
| The organisation already has Fabric capacity | New pipelines in Fabric; migrate old ones as they need change |
| A stable factory that works, no Fabric elsewhere | No urgency; run the assessment to know where you stand |
| Dependence on SSIS, private endpoints or shared triggers | Stay, and watch those items in the documentation |
| Heavy use of mapping data flows | Check each flow against the supported transformations |
| Learning data engineering now | Learn pipelines and orchestration; the concepts apply in both |
Two points keep this in proportion. Azure Data Factory is still a documented, supported service, and Microsoft's mount option exists precisely so that existing factories can keep running. And "next generation" describes a direction. The honest state, on Microsoft's own pages, is a product with about 90% of the activities and several infrastructure features still to come.
For learners
Little is wasted. Pipelines, activities, parameters, expressions, the Copy activity, incremental loading, error handling, idempotent design: all of it carries over. What is specific to Azure Data Factory is the infrastructure layer, integration runtimes, linked services and datasets, ARM deployment, and that is the layer Fabric removes or replaces. The Azure Data Factory roadmap notes which topics are which. For how Fabric relates to the analytics side, see Azure Synapse vs Azure Data Factory.
Is Azure Data Factory being replaced by Microsoft Fabric?
Are Fabric pipelines the same as ADF pipelines?
Can I run my existing ADF pipelines in Fabric without changes?
Is Fabric cheaper than Azure Data Factory?
Azure Data Factory and cloud data integration are covered in the Data Engineering course.
Sources
- Differences between Data Factory in Fabric and Azure (Microsoft Learn) — Microsoft Learn
- Upgrade planning for Azure Data Factory to Fabric Data Factory (Microsoft Learn) — Microsoft Learn
- How to use Azure Data Factory item (Mount) in Microsoft Fabric (Microsoft Learn) — Microsoft Learn
- What is Microsoft Fabric (Microsoft Learn) — Microsoft Learn
- Pricing for pipelines in Microsoft Fabric (Microsoft Learn) — Microsoft Learn
- A guide to Fabric Dataflows for Azure Data Factory Mapping Data Flow users (Microsoft Learn) — Microsoft Learn
GloryTecks Team
Training & Placement Faculty
The GloryTecks faculty team mentors learners across Data Science, AI and Data Engineering, with a focus on real-time projects and placement readiness in Hyderabad.
Want to master Azure Data Factory?
Join GloryTecks’ expert-led Data Engineering training in Hyderabad with real-time projects and 100% placement support.
Related articles
Azure Data Factory Roadmap 2026: A Complete Guide
A staged roadmap for learning Azure Data Factory in 2026: the six building blocks and how they relate, five stages from a first copy pipeline to deployed and monitored pipelines, a checkpoint for each stage, how Microsoft Fabric changes the picture, the state of the certifications, and the skills ADF does not replace.
Linked Services in Azure Data Factory Explained
A linked service is how Azure Data Factory connects to a data store or a compute service. This guide covers the two kinds, the anatomy of the JSON, authentication from keys to managed identities, keeping secrets in Key Vault, parameterising one linked service for many databases, and handling development and production.
Copy Activity in Azure Data Factory: A Practical Guide
The Copy activity is the workhorse of Azure Data Factory. This guide explains what it does in three steps, the formats and stores it handles, column mapping, the sink write behaviours, insert, pre-copy script and upsert, compared on a real table across three runs, fault tolerance, staging, and reading the output.