Mounting Azure Data Factory in Microsoft Fabric - A Low-Risk Way to Get Started

Microsoft has shipped something useful that I think a lot of Australian data teams will quietly appreciate. You can now mount an existing Azure Data Factory directly into a Fabric workspace, without migrating anything. Your pipelines keep running where they always ran, on the same compute, billed the same way. But you can see them, trigger them, and even edit them from inside Fabric.

This is not a migration tool. It is a connection. Think of it as opening a window into your existing ADF estate from inside your Fabric workspace. The factory itself stays exactly where it is. Nothing gets copied, converted, or moved.

I want to walk through why this matters, who it is actually useful for, and where the rough edges still are.

The Real Problem This Solves

Most Australian organisations we work with are not greenfield Fabric customers. They have an existing Azure data estate, often built up over years, with significant ADF pipelines doing the heavy lifting for their data warehousing and analytics. Sometimes it is hundreds of pipelines. Sometimes it is the same dozen pipelines that have been running quietly in production since 2021 and nobody wants to touch them.

When Fabric came along, these teams faced an awkward decision. The new world is Fabric. The new investment is in Fabric. But everything they actually run is in ADF. How do you start adopting Fabric without bet-the-farm migrations?

The standard answer was to build new things in Fabric while keeping existing things in ADF. Which is fine, except now you have two pipeline canvases, two monitoring experiences, two security models, and two places people have to log in to see what is running. The unified workspace promise of Fabric does not quite work because half your stuff is not actually in Fabric.

Mounting your ADF into Fabric fixes this. You get a single workspace view. You can see your ADF pipelines and your Fabric pipelines side by side. You can hand a dashboard to a stakeholder and have everything in one place. The pipelines themselves have not moved an inch.

What Actually Happens When You Mount

The mechanism is straightforward. You go to your Fabric workspace, create a new item, choose "Azure Data Factory", and pick the ADF instance you want to mount. There is also a path from inside the Azure portal, where you go to your ADF, find the "ADF in Microsoft Fabric" option, and mount it that way.

Once mounted, you see the ADF as an item inside your Fabric workspace. Clicking into it gives you a view that looks and feels like the ADF authoring experience, embedded inside Fabric. You can browse your pipelines, edit them, debug them, and trigger them. The interface is the ADF interface, just hosted inside Fabric.

What does not change:

• The pipelines still run on ADF infrastructure
• The same integration runtimes (including any self-hosted IRs you have) are still in use
• Billing still goes through Azure ADF, not Fabric capacity
• Your Git repo configuration (if you have ADF wired up to Azure DevOps or GitHub) keeps working
• Triggers, datasets, linked services, all unchanged

If you unmount, the mount goes away instantly. No data loss, no rollback procedure. The ADF was never really inside Fabric to begin with, it was just visible from there.

Where The Limits Are

Because this is a mount rather than a migration, there are things you can do in the native ADF portal that you cannot do (or cannot do well) from within Fabric.

Full monitoring is still in the ADF portal. The basic trigger-and-debug experience works in Fabric, but if you want to see historical runs, set up alerts, configure diagnostic logging, or do any of the operational monitoring that an actual data ops team needs, you go back to ADF. This is not a small thing. For production workloads, the ADF monitoring view is where you live, and Fabric does not replicate that experience.

Global parameters are not visible from Fabric. If your pipelines depend on these, you manage them in the ADF portal.

There are a handful of other smaller gaps around configuration screens and admin functions that have not been ported across. Nothing catastrophic but worth knowing.

In practice, what this means is that mounting your ADF gives developers and analysts a unified workspace view, but operations and platform teams still need to use the ADF portal for the operational side of things. That is fine as long as you are clear about it upfront.

Who This Is Actually For

I want to be specific here because I see this feature getting positioned as "the way" to bring ADF into Fabric, and that is not quite right.

This is useful if:

• You have an existing ADF investment that is running fine and you do not want to disturb it
• You are building new things in Fabric and you want a single workspace where the team can see everything
• You want to explore Fabric and get familiar with it without committing to a migration
• Your data team uses Fabric features (lakehouses, notebooks, Power BI) and they need to occasionally interact with ADF-driven outputs

This is not what you want if:

• You are committed to running everything in Fabric long-term and want to consolidate billing on Fabric capacity
• You want Copilot for pipeline authoring (that is a Fabric Data Factory feature, not an ADF feature)
• You want fast copy for dataflows, lakehouse destinations, or other Fabric-native pipeline capabilities
• You need the deeper Fabric integrations like pipeline triggers based on Fabric events

Think of mounting as a way station, not a destination. It is excellent for organisations that want to start using Fabric without disrupting their existing ADF setup. It is not a substitute for an actual migration if you decide you want to be all-in on Fabric.

The Tenant And Region Thing Trips People Up

A small but important note. Your ADF and your Fabric workspace need to be in the same Microsoft Entra ID tenant. This sounds obvious until you realise that some organisations have multiple tenants (acquisitions, subsidiaries, regulatory separation), and the ADF and Fabric you want to connect are in different ones. In that case, mounting does not work.

Same region is recommended but not required. We have seen acceptable performance with cross-region mounts, but for anything that involves real-time interaction (debugging a pipeline that is misbehaving), cross-region latency starts to feel sluggish. If you have a choice, keep them in the same region.

You also need contributor access on the ADF and member or admin on the Fabric workspace. The user doing the mount needs both. If you are in a security-conscious environment, this can require a small bit of coordination, but it is not particularly onerous.

How We Use This With Clients

When we are doing Fabric adoption work for clients with existing ADF estates, we typically use mounting as a first step. Here is the pattern that works.

First, mount the existing ADF into the Fabric workspace where the new Fabric work will live. This immediately gives the team a unified view. They can see existing pipelines and new Fabric items side by side. The cognitive load of switching between portals drops significantly.

Second, start building new things in Fabric (lakehouses, dataflows Gen2, notebooks, Fabric pipelines). The team gets familiar with Fabric-native tooling while their existing ADF stuff keeps humming along.

Third, identify which ADF pipelines are good migration candidates. The ones that are causing pain, the ones that would benefit from Fabric-native features, the ones where Copilot or fast copy would save real time. These get migrated using the dedicated ADF-to-Fabric migration tooling (which is a separate feature, also worth knowing about).

Fourth, the boring well-behaved ADF pipelines that have been running fine for years just stay where they are, mounted and visible inside Fabric, with no actual change. They might get migrated eventually. They might not. There is no urgency.

This staged approach is much more workable for most teams than trying to do a big-bang migration. It also lets you discover quickly which Fabric features actually matter for your workload, rather than committing to a full rebuild based on a slide deck.

If you want help thinking through how to phase a Fabric adoption alongside an existing ADF estate, that is exactly the kind of work our Microsoft Fabric consultants do. We can also help with the broader question of how Fabric fits into a Microsoft AI and data strategy through our Azure AI consulting practice.

Worth Trying

If you have an existing ADF and any kind of Fabric workspace, this feature is worth trying. The mount is non-destructive and reversible. You can have your ADF showing up in Fabric within five minutes, and unmount it within thirty seconds if you decide you do not like it.

The biggest value is not technical. It is organisational. A unified workspace where the team can see everything in one place removes a meaningful amount of friction. For teams trying to get traction on Fabric while keeping their existing stack running, that is a real win.

If you want to chat about how to approach this for your environment, get in touch.

Reference: Bring your Azure Data Factory to Fabric on Microsoft Learn