For teams running ADF today, that shift creates real pressure. Fragmented tooling across Synapse, ADF, and Power BI. PaaS management overhead that eats engineering hours. And a growing gap between where Microsoft is investing (Copilot, AI, unified governance) and where your pipelines currently live.
This guide walks through the architecture shift, the three migration paths Microsoft offers, a step-by-step process, and the pitfalls that trip up most teams during cutover.
Key Takeaways
- Fabric Data Factory keeps ADF pipeline concepts but shifts PaaS to SaaS, changing Integration Runtime, connections, and parameters
- Microsoft offers three paths: Mount-First, Built-in Migration Assistant, and PowerShell bulk migration
- Mapping Data Flows, SSIS packages, and custom activities do not migrate automatically and need redesign
- An assessment-first, phased approach reduces production risk
Why Migrate from Azure Data Factory to Microsoft Fabric
Microsoft positions Fabric as its unified analytics platform, integrating OneLake, Lakehouse, Warehouse, and Copilot-driven AI under one workspace model. Microsoft has not announced ADF's retirement. Fabric is a strategic replatforming option data teams should evaluate now.
Operational and cost benefits:
- Fabric consolidates billing into Capacity Units across Data Orchestration and Data Movement meters, versus ADF's per-run and per-IR-hour pricing
- Capacities can scale or pause on demand, unlike fixed infrastructure management under ADF's PaaS model
- Governance moves into a single workspace instead of spanning multiple Azure resource groups
Microsoft has reported that 67% of the Fortune 500 use Microsoft Fabric. That figure shows how quickly enterprise adoption moved even in Fabric's early stages.
Before you weigh those gains against a full move, it helps to clear up what Fabric actually replaces.
Does Fabric Include ADF?
Not exactly. Fabric Data Factory is an evolved version of ADF's pipeline engine, embedded and running natively inside the Fabric workspace rather than as a separate product beside ADF. Same DNA, different chassis.
That overlap is useful on day one. It also makes the cost of waiting clearer.
The risk of staying on ADF long-term:
- Slower feature releases as Microsoft's engineering investment shifts to Fabric
- No native Copilot or AI-assisted pipeline authoring
- Governance stays disconnected from your Lakehouse and Warehouse assets
Teams that delay migration keep working pipelines, but they fall behind on platform features, AI-assisted authoring, and unified governance.
Understanding the Architectural Shift: ADF vs. Fabric Data Factory
The PaaS-to-SaaS move changes more than terminology:
- Resource boundaries shift from individual Azure services to a shared Fabric capacity
- IAM consolidates around Entra identity at the workspace level
- Cost attribution moves from per-service billing to capacity consumption you track through Fabric Metrics
Integration Runtime Changes
Azure IR, Self-Hosted IR (SHIR), and Azure-SSIS IR don't carry over as-is. Fabric replaces explicit IR management for cloud work, but on-premises access now runs through the On-premises Data Gateway (OPDG), which is not a direct SHIR equivalent.
Fabric pipeline support requires gateway version 3000.214.2 or later.
Key Terminology Changes
Three concepts change shape entirely:
- Linked Services → Connections: Tighter identity integration through Entra, but connections don't support parameter expressions the same way linked services did
- Global Parameters → Variable Libraries: A structured key-value store, but conversion is manual. Expressions like
@globalParameters()won't rewrite themselves - Datasets: Eliminated in favor of inline activity properties
| ADF Concept | Fabric Equivalent |
|---|---|
| Integration Runtime (Cloud/SHIR) | No explicit IR / On-premises Data Gateway |
| Linked Service | Connection |
| Global Parameter | Variable Library |
| Datasets | Inline activity properties |
| Mapping Data Flow | Dataflow Gen2 |
Migration Paths and Step-by-Step Process
Microsoft offers three migration paths, each with a different risk profile. Choose based on how much you need to inspect before you move production workloads.
Path 1: Mount-First
Bring your existing ADF factory into a Fabric workspace as a mounted item. You get read-only visibility and planning capability without touching production; execution stays in Azure.
Use this path for inventory and governance review before you commit to cutover.
Path 2: Built-in Migration Assistant (Preview)
Run the assistant from the ADF authoring canvas. It assesses each pipeline and assigns a readiness status:
- Ready — migrate as-is
- Needs review — fix issues before moving
- Coming soon — Fabric support still in progress
- Not compatible — no Fabric equivalent; plan a refactor
Export results to CSV for a shareable inventory you can use in planning reviews.
Path 3: PowerShell (Microsoft.FabricPipelineUpgrade)
Use this path for large-scale, scriptable, CI/CD-integrated migrations. You need the same Entra tenant, Contributor access on the target Fabric workspace, and PowerShell 7.4.2 or later.
Core Migration Steps
After you pick a path, run the migration in this sequence:
- Assess pipelines with the Migration Assistant or PowerShell What-If validation
- Mount the factory in a Fabric workspace for visibility
- Select pipelines, starting with Ready-status items
- Map linked services to connections, reviewing each one individually
- Validate expressions, authentication, and outputs before cutover
Prioritization Strategy
Order the work to keep early risk low:
- High-parity, low-risk pipelines first (Copy, Lookup, standard control flow)
- Business-critical pipelines next, once patterns are proven
- Data Flow and SSIS-dependent pipelines last, because they need full redesign
Copy and orchestration activities usually carry over cleanly. These patterns need rework:
- Mapping Data Flows → Dataflow Gen2
- CDC patterns → Copy job items
- Custom activities → Azure Batch
- SSIS packages → full redesign
Post-Migration Validation and Common Pitfalls
Migrating pipelines is step one. Making sure they behave the same way in production is the part teams underestimate.
Critical validation checklist:
- Re-enable triggers manually — schedule triggers migrate but are disabled by default
- Verify every connection and authentication method works as expected
- Recreate global parameters as variable libraries (this step is manual, not automatic)
- Test tumbling-window backfill behavior, since backfill isn't supported in Fabric
The biggest pitfall is assuming full automation. It doesn't exist yet. Several components still need manual work:
- SAP ECC, SAP BW, MDX, and SAP CDS connectors have no Fabric equivalent
- Custom event triggers can't migrate
- CMK, dual-token, and federated identity credential flows need manual redesign
Run parallel execution before cutting over completely. Compare ADF and Fabric outputs side by side and reconcile any discrepancies. Only decommission ADF pipelines once you've validated consistent results across a full production cycle.
Why Partner with an Experienced Data Engineering Team for Your Migration
Migrations that touch dozens of pipelines, custom activities, and regulated data don't forgive shortcuts. Fintech and healthcare organizations in particular carry compliance obligations that make a botched cutover expensive — not just in engineering time, but in audit exposure.
Hexaview has spent over a decade building data engineering and Microsoft Fabric solutions for capital markets and wealth management clients, including firms like LPL Financial and Addepar. That work has translated into measurable outcomes on comparable data platform engagements:
- 97% rise in data accuracy reported across data engineering implementations
- 20,000+ hours saved through automated analysis workflows
- Lower manual effort and faster data access on lake and pipeline projects
Hexaview holds SOC 2 Type 2 certification and is an AWS Select Tier Service Partner, credentials that matter when regulated enterprises evaluate who touches their production data pipelines. For organizations weighing an ADF to Fabric migration alongside compliance requirements, that combination of domain expertise and verified security controls reduces the risk of a mid-migration surprise.
Frequently Asked Questions
Does Microsoft Fabric include Azure Data Factory?
Not as a separate bundled product. Fabric Data Factory is a SaaS-native evolution of ADF's pipeline engine, embedded directly inside Fabric workspaces.
What is the difference between Azure Data Factory and Microsoft Fabric?
ADF is a PaaS data-integration service billed per run and IR hour. Fabric Data Factory is SaaS and billed through shared capacity. It sits inside a broader analytics platform with Lakehouse, Warehouse, and AI tools built in.
How long does an ADF to Fabric migration typically take?
Timeline hinges on pipeline count and complexity, especially Mapping Data Flows and custom activities. A phased migration that starts with high-parity pipelines keeps risk manageable at any scale.
Will my ADF triggers migrate automatically to Fabric?
Schedule triggers migrate but stay disabled by default until you manually re-enable them. Other trigger types, including custom event triggers, need manual recreation entirely.
Can I migrate Mapping Data Flows to Fabric directly?
No. Mapping Data Flows require conversion to Dataflow Gen2, Warehouse SQL, or Spark notebooks depending on your target architecture. There's no automatic lift-and-shift.
Is the ADF to Fabric migration tool free to use?
Yes. Microsoft's built-in Migration Assistant is free and runs directly inside the ADF authoring canvas. Fabric Data Factory execution itself remains consumption- and capacity-billed.
