Azure Data Factory vs Fabric Data Factory - Which to Choose Now
Every second client we talk to has the same question right now. They've been running Azure Data Factory (ADF) for years, the licence renewal is coming up, and Microsoft keeps nudging them toward Fabric. Should they migrate? Should they stay? Should they run both?
The short answer is that it depends on what you've already built, what you're trying to do next, and whether you have a Power BI shop or a data engineering shop. The longer answer is what this article is for.
I'll be upfront. We're a Microsoft partner and we work across both products. Some of our clients should absolutely stay on ADF for the next three years. Others should move to Fabric this quarter. A few should run both for different workloads. There's no universal answer, and anyone telling you there is either has Microsoft sales targets or doesn't know what they're talking about.
The simple version of what these two products actually are
Azure Data Factory is the data integration service that Microsoft has been building since 2015. It's a standalone Azure resource. You provision it, you pay for what runs through it, you connect it to your storage and your databases, and you build pipelines. It's mature, well-documented, and used by tens of thousands of organisations.
Fabric Data Factory is the same engine, more or less, rebuilt inside Microsoft Fabric. Fabric is the all-in-one SaaS analytics platform Microsoft launched in 2023. Fabric Data Factory sits alongside the lakehouse, the warehouse, Power BI, the notebooks, and the real-time analytics features. You don't provision it separately. It's just there when you turn on a Fabric capacity.
If you've used ADF, the Fabric version will feel familiar. Same pipeline canvas, similar activities, similar Dataflow Gen2 experience (which replaced the old Dataflow Gen1). What's different is the surrounding context. ADF is a piece in a larger Azure data architecture you assemble. Fabric Data Factory is a piece of a pre-assembled platform.
The licensing model is where this decision actually lives
Here's where most people get confused. ADF and Fabric Data Factory are priced completely differently, and the comparison isn't obvious.
Azure Data Factory charges per pipeline activity run, per data movement DIU-hour, and per integration runtime hour. A typical mid-sized Australian organisation with 50-150 pipelines running daily might spend AUD $1,500-$6,000 per month. Heavy users with complex Mapping Data Flows on Spark clusters can hit AUD $15,000+ per month. We wrote a detailed data factory cost guide covering the per-activity pricing if you want the numbers.
Fabric Data Factory is paid for through Fabric capacity. You buy an F SKU (F2, F4, F8, F16, F32, F64, F128, F256, F512, F1024, F2048) and your data factory workloads consume Capacity Units alongside everything else in Fabric. An F2 is around AUD $400/month if billed monthly through Azure. An F64 (the smallest SKU that includes Power BI Pro for free for users) is around AUD $13,000/month.
This is the trap. A Fabric capacity sounds like a great deal because you get warehouse, lakehouse, notebooks, Power BI, KQL, ML, and data factory all bundled. But if your data factory workload is heavy and your other Fabric usage is light, you're paying for capacity you don't need. Conversely, if you already have an F64 for Power BI, adding data factory workloads costs you nothing extra until you saturate the capacity.
The breakeven calculation we run for clients usually comes down to this question: are you already paying for a Fabric capacity for some other reason? If yes, push more workloads into it. If no, ADF is probably cheaper for a pure data integration workload until you hit serious scale.
A practical comparison for the things that actually matter
| Capability | Azure Data Factory | Fabric Data Factory |
|---|---|---|
| Pricing model | Per-activity, per-DIU, per-IR hour | Capacity Units within Fabric SKU |
| Pipeline activities | 90+ built-in activities | Similar set, some still rolling out |
| Source connectors | 100+ connectors, very mature | Most ADF connectors plus Fabric-native ones |
| Mapping Data Flows | Yes, runs on Spark | Replaced by Dataflow Gen2 (Power Query at scale) |
| CI/CD | ADF git integration, ARM templates, Azure DevOps | Fabric git integration (improving but newer) |
| On-premises data gateway | Self-hosted Integration Runtime | On-premises Data Gateway (same product Power BI uses) |
| Managed Virtual Network | Yes (separate cost) | Coming, varies by region |
| Customer-managed keys | Yes | Yes, via Fabric capacity |
| Private endpoints | Full support | Full support |
| Managed identity for sources | Yes, widely supported | Yes, parity is mostly there |
| Output destination | Anywhere you connect | OneLake first, anywhere else also supported |
| Multi-region failover | Build it yourself | Capacity-level, simpler |
| Best for | Pure integration into existing Azure architecture | Integration when destination is Fabric lakehouse/warehouse |
When Azure Data Factory is still the right choice in 2026
We tell clients to stay on ADF when these things are true:
You're moving data between systems that have nothing to do with Power BI or Fabric. If your job is pulling from Salesforce, transforming, and loading into Snowflake or a SQL Managed Instance, ADF is the cleaner tool. You're not paying for capacity you won't use.
You have existing investment in ADF you don't want to throw away. We had one client with 400+ pipelines across three ADF instances, all source-controlled in Azure DevOps with full CI/CD. Migrating to Fabric would have cost AUD $200,000+ and given them very little. We told them to stay put.
You need fine-grained cost attribution. ADF gives you per-pipeline, per-activity cost data through Azure Cost Management. Fabric capacity is a shared resource. If your finance team needs to charge back data integration costs to specific business units, ADF is easier to defend.
You're heavily invested in Synapse pipelines. Synapse pipelines are essentially ADF inside Synapse. If you've built your analytics in Synapse and aren't ready for the phased Synapse to Fabric migration, staying on the ADF/Synapse stack for another 12-18 months is reasonable.
Your data integration team is mature and prefers code-first development. ADF supports JSON-based pipeline definitions, ARM templates, and Bicep deployments. Fabric's deployment story is improving but it's not at parity yet for power users.
When Fabric Data Factory is the better choice now
You should move to Fabric Data Factory when:
You're loading data into a Fabric lakehouse or warehouse. The OneLake integration is genuinely better than what you can build by hand with ADF and ADLS Gen2. Shortcuts, direct lakehouse writes from pipelines, and the metadata that flows through to Power BI semantic models all work better when the source is Fabric Data Factory. We have a separate piece on moving data from Azure Data Factory to Fabric that covers the patterns.
You already have a Fabric capacity for Power BI. If you've upgraded from Power BI Premium per user to a Fabric F-SKU for one Power BI workspace, you're already paying for capacity. Use it. Pushing your data factory workloads into the same capacity is basically free until you saturate it.
Your team is more Power BI than data engineering. Dataflow Gen2 (the Fabric version of the old Power Query dataflows) is genuinely good for analyst-led transformation work. If your team is comfortable with Power Query M and not comfortable with Mapping Data Flows on Spark, Fabric is friendlier. We covered the Dataflow Gen2 migration scenarios and the Gen1 to Gen2 migration path in more detail.
You want fewer Azure resources to manage. Fabric is SaaS. You don't provision integration runtimes, you don't manage Managed VNets, you don't think about ADF region failover. For smaller teams without dedicated platform engineers, this matters.
The hybrid pattern that actually works in production
About a third of our clients end up running both, on purpose, for the next year or two.
The pattern is: keep ADF for the heavy data movement work that lands data in raw zones (ADLS Gen2, on-premises SQL, etc.), and use Fabric Data Factory for the curated layer that feeds Power BI and the warehouse. ADF does the deep plumbing. Fabric Data Factory does the last mile into OneLake.
This pattern works because it lets you keep your existing ADF investment while progressively moving the user-facing parts of the analytics estate into Fabric. It's also easier to defend at the budget level because you can show clear ownership of each tool.
The risk is operational complexity. Now your team needs to know both products, and your monitoring needs to cover both. We typically recommend this pattern for organisations with 5+ data engineers. Smaller teams should pick one.
Common objections we hear from clients
"Microsoft is going to deprecate ADF anyway, so we may as well move now."
Microsoft has been very clear that ADF is not going anywhere. The ADF team is still shipping new connectors and features. Treating ADF as legacy is a mistake. That said, the strategic direction of investment is clearly Fabric, and over a 3-5 year horizon, more capability will land in Fabric first.
"Fabric is cheaper because everything is included."
This is only true if you'd actually use everything that's included. Fabric capacity pricing makes sense when you're using lakehouse, warehouse, data factory, Power BI, and notebooks all together. If you're just doing data integration, ADF on consumption pricing is usually cheaper.
"We can't run both because of cost."
Running both isn't expensive if you size things correctly. ADF is consumption-based, so an idle ADF instance costs nothing. The question is whether your team can support both, not whether you can afford both.
"Fabric isn't enterprise-ready."
This was true 18 months ago. It's not true now. We have clients running mission-critical workloads on Fabric. The Fabric security governance checklist we maintain covers what you need to put in place, and it's basically achievable for any organisation that has done the same for Azure.
A decision framework you can actually use
Run through these questions in order:
- Are you loading data into a Fabric lakehouse, warehouse, or Power BI semantic model as the primary destination? If yes, lean Fabric Data Factory.
- Do you already have a Fabric capacity (F-SKU) running for Power BI or analytics? If yes, lean Fabric Data Factory.
- Is your destination a non-Microsoft analytics platform (Snowflake, Databricks, BigQuery, on-prem warehouse)? If yes, ADF is probably cleaner.
- Do you have more than 100 existing ADF pipelines with full CI/CD? If yes, the migration cost is real - stay on ADF for now unless you have a strategic reason to move.
- Is your team analyst-heavy with Power Query skills, or engineer-heavy with Spark/SQL skills? Analysts lean Fabric. Engineers can use either, but ADF has more depth.
- Do you need per-pipeline cost attribution to business units? ADF is easier.
- Do you need a Managed VNet with private endpoints today, in a region where Fabric doesn't yet offer it? ADF.
Most of our clients land on one of three answers. Either they stay on ADF for the next 2-3 years, they go all-in on Fabric, or they run both with a clear demarcation of which tool owns which layer.
What the migration actually looks like if you decide to move
Migrating ADF to Fabric Data Factory is not a one-click experience, despite what the marketing implies. Microsoft has tooling that imports ADF pipeline JSON into Fabric, but the result usually needs hand-tuning. Mapping Data Flows in particular don't translate directly - they need to be rebuilt as Dataflow Gen2 or as Spark notebooks.
A typical migration for an Australian mid-market client (50-100 pipelines, mixed connectors, on-premises gateway, Azure DevOps integration) takes 8-16 weeks of consulting effort. Budget is usually AUD $80,000 to $200,000 depending on complexity. The biggest risk areas are: custom activities, third-party connectors that don't yet exist in Fabric, and CI/CD reconfiguration.
We always recommend running both in parallel for at least one full month-end cycle before decommissioning the ADF instance. The cost of running both for a month is much smaller than the cost of breaking a finance close.
When to bring in a consultant
If you have a working ADF setup and you're happy with it, you probably don't need help to keep running it. Where consulting actually pays for itself is in two situations.
The first is the architectural decision itself. Whether to stay, move, or run both is the kind of question that's hard to answer from inside your own organisation. We do a lot of these reviews and the pattern is always the same - the right answer is rarely obvious and the wrong answer costs serious money.
The second is the actual migration if you decide to move. Doing this with internal staff who haven't done it before is usually slower and riskier than bringing in people who have done it five or ten times. Our Microsoft Data Factory consultants and Microsoft Fabric consultants teams in Australia do this work week in week out. We can help with the assessment, the migration plan, or the build itself.
If you want a second opinion on whether to move from ADF to Fabric Data Factory, or you've already decided to move and want help doing it properly, get in touch. We do an initial review at no cost and you'll get a real answer, not a sales pitch. You can reach us through the contact page or read more about how we work on the about page.