Azure Data Factory vs Fabric Data Factory - What's Actually Different

If you've been running Azure Data Factory (ADF) for a few years - and plenty of Australian organisations have - you've probably been wondering about Data Factory in Microsoft Fabric. Is it a replacement? An upgrade? A completely different thing with a familiar name?

The short answer: it's the next generation of ADF, rebuilt as a SaaS service inside the Fabric platform. Microsoft's official comparison lays out the feature differences in detail, but reading through comparison tables doesn't tell you what it actually feels like to work with, or whether migrating makes sense for your situation.

I've been helping clients evaluate and migrate between these two services for the past year. Here's what I've found.

The Biggest Shift - PaaS to SaaS

The fundamental difference isn't any single feature. It's that ADF is a PaaS service you configure and manage in the Azure portal, while Fabric Data Factory is a SaaS service that lives inside a Fabric workspace alongside your lakehouses, warehouses, notebooks, and Power BI reports.

What does that mean in practice? A few things:

No more integration runtimes to manage. In ADF, you deal with Azure Integration Runtime, self-hosted IR, and Azure-SSIS IR. You configure them, monitor them, troubleshoot them when they go down. In Fabric, the cloud compute is handled for you. If you need on-premises access, you use an On-premises Data Gateway instead of a self-hosted IR - similar concept, different implementation.

No more publish step. In ADF, you author your pipeline, then hit Publish to deploy it. This is a source of constant confusion for people new to ADF ("Why isn't my change working? Oh, I forgot to publish."). Fabric just has Save and Run. Save your work, or run it immediately. It's a small thing that removes a real friction point.

Everything lives in a workspace. Your pipelines sit next to your data assets. You can wire a pipeline to load data into a lakehouse that feeds a Power BI report, all within the same workspace, without jumping between portals. The integration is genuinely tighter than what you get with ADF and separate Azure services.

What Stayed the Same

If you know ADF, you'll recognise most of what's in Fabric Data Factory. The pipeline authoring experience looks similar. Activities like Copy, ForEach, If Condition, Lookup, and Set Variable all work the way you'd expect. The expression language is nearly identical, so your existing knowledge of ADF expressions transfers directly.

About 90% of ADF activities are available in Fabric. The big ones are all there - Copy, Script, Stored Procedure, Web, ForEach, Switch, Until, Filter, and so on. If your ADF pipelines use standard activities, there's a good chance they'll map over without major rework.

What's New and Better

A few things in Fabric genuinely improve on the ADF experience:

Dataflow Gen2 replaces mapping data flows. If you've worked with mapping data flows in ADF, you know they're powerful but can be finicky - especially around debugging and performance tuning. Dataflow Gen2 in Fabric provides a simpler authoring experience built on Power Query. It's more intuitive, and Microsoft keeps adding features from mapping data flows into Gen2. The transition isn't complete yet, but the direction is clear.

The monitoring hub is a real upgrade. ADF's monitoring works fine for individual pipelines, but getting a cross-workspace view of what's running, what's failed, and what's slow requires extra work. Fabric's monitoring hub gives you a unified view across all your workspace items - pipelines, dataflows, notebooks, everything. The copy activity drill-down with duration breakdowns is particularly useful when you're troubleshooting slow data loads.

Datasets are gone. In ADF, you define datasets as separate objects that describe the shape and location of your data. They add a layer of indirection that many people find confusing. Fabric eliminates them entirely - you define data properties inline within activities and use connections to link to data sources. It's simpler and means fewer objects to manage.

Native lakehouse and warehouse integration. You can use Fabric lakehouses and warehouses as both sources and destinations directly in your pipelines. No connector configuration, no linked service setup. They're just there because they're in the same platform.

New activities you can't get in ADF. Fabric adds Office 365 Outlook (send email notifications from pipelines), Teams (orchestrate Teams activities), semantic model refresh (trigger Power BI refreshes), and Dataflow Gen2 as a pipeline activity.

What's Still Missing or Rough

It's not all sunshine. There are gaps you should know about before committing to a migration:

SSIS integration isn't available yet. If you're running SSIS packages through ADF's Azure-SSIS integration runtime, there's no equivalent in Fabric right now. Microsoft says they're working on it, but there's no timeline. For organisations with significant SSIS investments, this could be a blocker.

Managed virtual networks and private endpoints are still "to be determined." If your ADF pipelines use managed VNet for secure connectivity, Fabric doesn't have a direct equivalent yet. The Virtual Network Data Gateway is an option, but it works differently - you deploy it into your own Azure VNet and manage it yourself, whereas ADF's managed VNet is fully Microsoft-managed.

Tumbling window triggers work differently. In ADF, tumbling window triggers are a first-class concept for processing data in time-based intervals. In Fabric, the equivalent is interval scheduling, which covers the basic use case but doesn't have all the same features around dependency chaining and retry policies.

Pricing model is completely different. ADF charges per activity run and data movement. Fabric uses capacity-based pricing (F SKUs) where you pay for a chunk of compute and your pipeline runs consume from that pool. Pipeline and external activities don't incur extra charges - only activity runs and data movement count. Whether this works out cheaper depends entirely on your workload patterns. We've seen it go both ways.

The CI/CD Story

This is one area where Fabric has made genuine progress. In ADF, CI/CD means ARM templates and Git integration - it works, but it's not elegant. You publish your entire factory as a unit, and cherry-picking individual changes requires manual effort.

Fabric gives you two options. You can use external Git repos (Azure DevOps or GitHub), similar to ADF but with easier cherry-picking of individual items. Or you can use Fabric's built-in deployment pipelines, which let you promote workspace items through Dev, Test, and Production environments without managing Git repos at all.

The built-in deployment pipelines are particularly nice for smaller teams that don't want the overhead of managing a Git-based CI/CD workflow. You just promote items between environments through the Fabric UI.

Self-Hosted IR vs On-Premises Data Gateway

If you're connecting to on-premises data sources, the mechanism is different between the two platforms. ADF uses a self-hosted integration runtime. Fabric uses an On-premises Data Gateway (OPDG).

The key differences: OPDG supports more services (Power BI, Power Apps, Power Automate, and all Fabric workloads) and can be shared across your entire tenant, while SHIR is limited to ADF, Synapse, ML Studio, and Purview. OPDG supports recovery keys and up to 10 nodes for high availability, while SHIR supports up to 8 nodes and requires reinstallation for recovery.

One thing to watch: OPDG doesn't support auto-updates like SHIR does. You'll need to manage updates manually, which is easy to forget and can lead to compatibility issues.

Should You Migrate?

This is the question I get most often. My honest answer: it depends on where you are.

If you're starting a new project, build it in Fabric Data Factory. The experience is cleaner, the integration with the rest of the Fabric platform is a real advantage, and you'll be building on the platform Microsoft is actively investing in.

If you have existing ADF pipelines that work fine, don't rush to migrate. ADF isn't going away - Microsoft continues to support and update it. Migration has a cost, and if your current setup meets your needs, there's no urgency.

If you're already moving to Fabric for other reasons (lakehouse, warehouse, Power BI migration), bringing your data pipelines along makes sense. Having everything in one platform reduces the operational overhead of managing separate services.

If you depend on SSIS or managed VNets, wait. Those gaps are real, and working around them adds complexity that may negate the benefits of migration.

Microsoft has published a migration planning guide that's worth reading if you're seriously considering the move.

For organisations thinking through this transition, our Microsoft Data Factory consultants can help assess your current ADF estate and plan a sensible migration path. We also work across the broader Microsoft Fabric platform and can help you think about how Data Factory fits alongside lakehouse, warehouse, and Power BI in a unified architecture. If you're in the early stages of figuring out your data strategy, our business intelligence solutions practice is a good starting point.