Moving Dynamics 365 to Microsoft Fabric is now the standard path for organisations that want to unify CRM and ERP data with their broader analytics estate - without building and maintaining custom ETL pipelines between systems that should never have been separated. The mechanism that makes this possible, Dataverse Link to Fabric, is in general availability and received a significant upgrade in June 2026: low-latency sync now reduces data freshness from up to two hours down to under 15 minutes for most environments.

This guide covers every available migration path - Dataverse Link to Fabric, Azure Synapse Link for Dataverse, and what to do if your organisation is still running the now-decommissioned Export to Data Lake or BYOD - with precise steps, genuine trade-offs, and the architectural decisions that determine whether your Dynamics 365 data arrives in Fabric clean and usable or becomes a long-term maintenance liability.

Why Organisations Are Moving Dynamics 365 to Microsoft Fabric

Dynamics 365 generates some of the most operationally significant data in any organisation - sales opportunities, customer service cases, finance transactions, inventory movements, purchase orders, and HR records. The problem has always been that this data lived in an operational system designed for transactional throughput, not analytical depth. Getting it out for reporting meant either tolerating Power BI's DirectQuery latency against live Dataverse, running scheduled exports that were often hours stale, or building custom pipelines that had to be maintained every time a Dynamics schema changed.

Microsoft Fabric changes the equation structurally. By linking Dynamics 365 directly into OneLake - Fabric's unified data lake - organisations can run Power BI semantic models, Fabric notebooks, Spark-based transformations, and AI agents against live operational data without any custom pipeline between Dynamics and the analytics layer. The data stays in Dataverse under Dataverse governance; Fabric reads it through shortcuts rather than copies. This is not a migration in the traditional sense - it is an integration that removes the gap between the operational and analytical estates.

"The fastest way to lose analytical trust in a Dynamics 365 deployment is to let the reporting layer fall hours behind the operational system. Fabric Link closes that gap structurally rather than by tuning a pipeline."

Three specific pressures are driving adoption in 2026. First, the decommissioning of Export to Data Lake in March 2025 forced every organisation still on that path to move - and most chose Fabric Link over rebuilding on Azure Synapse Link from scratch. Second, the June 2026 low-latency sync GA brought Fabric data freshness to under 15 minutes, making it viable for near-real-time operational dashboards that Export to Data Lake never supported at reasonable cost. Third, Microsoft's Copilot investments in both Dynamics 365 and Fabric are substantially more powerful when both systems share a data layer - an agent that can read and write Dataverse, and analyse that data through Fabric's compute layer, operates without the context loss that happens when operational and analytical systems are separate.

Understanding the Dynamics 365 to Microsoft Fabric Architecture

Before choosing a migration path, it helps to understand what Dynamics 365 actually consists of from a data perspective, because the architecture differs between product families and determines which integration approach applies.

Dynamics 365 Customer Engagement (CE) applications - Sales, Customer Service, Field Service, Marketing, Customer Insights - store data natively in Microsoft Dataverse. Dataverse is the platform layer, and CE apps are essentially structured tables and business logic on top of it. Because CE data is already in Dataverse, it is directly accessible via Dataverse Link to Fabric with no additional configuration beyond enabling the link.

Dynamics 365 Finance and Operations (F&O) - Finance, Supply Chain Management, Commerce, Human Resources - uses a separate data architecture. F&O does not store data natively in Dataverse; it has its own database. However, it is integrated with Dataverse via the Dual-write and Virtual Entities features. To include F&O tables in a Fabric link, you must explicitly add them through the "add tables" option after creating the initial link - they are not auto-selected the way CE tables are.

Dynamics 365 Business Central is a separate product with its own architecture and does not use Dataverse natively. Business Central data requires a different integration approach - typically through Business Central APIs, OData feeds, or a Data Factory pipeline - and is outside the scope of Dataverse Link to Fabric.

Dataverse Link to Fabric: The No-ETL Migration Path

Dataverse Link to Fabric is Microsoft's preferred integration method for moving Dynamics 365 data into Microsoft Fabric. It requires no ETL pipeline, no data duplication into external storage, and no custom transformation code. When you create a Fabric link from Power Apps, Dataverse creates shortcuts from the Dataverse data lake directly into OneLake - meaning the data stays inside the Dataverse governance boundary, and Fabric reads it via those shortcuts rather than maintaining its own copy.

One limitation specific to CE environments: when linking a Dynamics 365 CE environment, all Dataverse tables are included in the link - there is no table-level selection for the CE portion. You can subsequently stop syncing specific tables to reduce storage costs via the Manage tables option, but the initial setup is all-or-nothing for CE. Finance and Operations tables, by contrast, are not auto-selected and must be added manually - giving F&O more granular control from the start.

Azure Synapse Link for Dataverse: When You Need More Control

Azure Synapse Link for Dataverse is the older integration path and remains fully supported. Where Dataverse Link to Fabric keeps data inside the Dataverse governance boundary, Azure Synapse Link exports data to your own Azure Data Lake Storage Gen2 account, giving your team full control over the storage infrastructure, retention policies, and data lake organisation.

Synapse Link supports two storage modes. The first exports data in CSV format with no transformation - the lowest-cost option with the least transformation effort to read raw, but requiring your own pipeline to make it analytics-ready. The second enables the Delta Lake option, which runs Microsoft-managed notebooks to create Delta tables in Synapse or a Fabric Lakehouse, producing the same Delta Parquet format as Fabric Link but with the data residing in your own ADLS Gen2 account rather than Dataverse-managed storage.

Synapse Link is the right choice in three specific scenarios: when your organisation requires data to reside in storage you own and control for compliance or audit reasons; when you need to integrate Dynamics data with non-Microsoft data sources in the same pipeline before it reaches Fabric; or when your Fabric capacity is constrained and you want to manage Lakehouse storage costs independently of Dataverse storage billing.

Fabric Link vs Azure Synapse Link: How to Choose

For most organisations evaluating how to migrate Dynamics 365 to Fabric in 2026, Dataverse Link to Fabric is the correct choice. It requires less infrastructure, produces analytics-ready data faster, and sits on Microsoft's primary investment path. Azure Synapse Link remains valid when regulatory or compliance requirements mandate that data reside in storage your organisation owns and controls.

Migrating Dynamics 365 Finance and Operations to Microsoft Fabric

Finance and Operations data integration with Fabric is the most technically involved path because F&O does not store data natively in Dataverse. The integration relies on the Dual-write feature, which synchronises F&O entities into Dataverse tables in near-real time, making those tables visible to the Fabric link.

Alternatively - and this is the more commonly used path for analytics - F&O tables can be added directly to an existing Dataverse Fabric link via the "add tables" option in Power Apps. This requires that the Dataverse environment is linked to the F&O environment, which is a prerequisite typically established during the Dynamics 365 setup rather than during the Fabric migration. When you add F&O tables, change tracking must be enabled for each table in F&O before synchronisation will work.

Key F&O tables commonly linked to Fabric

The most analytically useful F&O tables for Fabric integration include General Ledger journals and postings (GeneralJournalEntry, LedgerJournalTrans), sales and purchase order headers and lines, inventory tables (InventTable, InventSum), vendor and customer master data (VendTable, CustTable), and budget and forecast entities. Each must have change tracking enabled before being added to the link - enabling change tracking on a large table can take time on initial sync and should be planned for, not done immediately before a go-live.

Migrating Dynamics 365 Customer Engagement to Microsoft Fabric

Dynamics 365 Customer Engagement migration to Fabric is the simpler path because CE data is native Dataverse. Sales opportunities, accounts, contacts, leads, service cases, activities, and all custom entities created in your CE environment are already Dataverse tables and are immediately available to the Fabric link without any additional integration step.

The significant architectural decision for CE environments is the all-or-nothing table selection at link creation. When you create a Fabric link from a CE-heavy Dataverse environment, all tables - including system tables, audit tables, and metadata tables - are included by default. This can generate substantial Dataverse storage consumption, particularly in large environments with many custom entities and extensive audit logging. The post-link step of reviewing and stopping sync on high-volume, low-analytical-value tables is not optional for cost management - it is a required part of the implementation.

For organisations running Dynamics 365 Customer Insights (the CDP product), the tables required for Customer Insights are automatically included in the Fabric link if Customer Insights is installed in the same environment. This makes the unified customer profile available in Fabric for cross-source customer analytics without any additional configuration.

Legacy Migration: Export to Data Lake, BYOD, and Data Export Service

Three legacy integration services have been deprecated and require migration if still in use. Each has a different target path:

For any of these legacy paths, the migration is not just a technical switch - it typically requires rebuilding downstream Power BI semantic models or pipelines that were reading from the old export destination, because the data format, table names, and schema conventions differ between the legacy exports and the Delta Parquet tables produced by Fabric Link. Budget time for semantic model updates alongside the technical migration.

Step-by-Step: How to Migrate Dynamics 365 to Fabric via Dataverse Link

The following steps cover creating a new Dataverse Link to Fabric from a Power Apps environment that includes CE data, with F&O tables added separately.

Power BI and AI on Dynamics 365 Data in Fabric

The strategic value of connecting Dynamics 365 to Microsoft Fabric extends well beyond replacing a data export job. Once Dynamics data is in OneLake, it becomes part of the shared analytical estate that all Fabric workloads - Power BI, Spark notebooks, Data Warehouse, Real-Time Intelligence, and AI agents - can access without duplication.

For Power BI, the immediate benefit is DirectLake semantic models. Rather than importing Dynamics data into a Power BI dataset on a refresh schedule, a DirectLake model reads directly from the Delta Parquet files in the Fabric Lakehouse. Combined with the low-latency sync introduced in June 2026, this means a Power BI report on sales pipeline, service case volume, or inventory levels can reflect Dynamics transactions from within the last 15 minutes - at no additional compute cost beyond the Fabric capacity already consumed by the Lakehouse.

For AI and Copilot, the integration is more architecturally significant. Microsoft's Copilot in Dynamics 365 and Copilot in Fabric are more capable when they share a data layer. An AI agent that needs to read a customer's open service cases, analyse historical purchase patterns, and trigger a Dynamics workflow based on the analysis can do all three within a single governed boundary - reading from OneLake, computing in Fabric, and writing back through Dataverse - rather than crossing three separate API boundaries with separate authentication and rate limits.

Governance, Security, and Compliance After Migration

The no-copy architecture of Dataverse Link to Fabric means that Dataverse's own security model governs access to the data. Row-level security defined in Dataverse does not automatically propagate to Fabric - users accessing the Fabric Lakehouse directly can read all rows in the linked tables regardless of their Dynamics 365 role assignments. This is a critical governance point that often surprises teams migrating from Export to Data Lake, which had the same limitation.

The practical implication: access to the Fabric Lakehouse containing Dynamics shortcuts should be governed through Fabric workspace permissions, not assumed to inherit Dataverse row-level security. Sensitive Dynamics entities - employee records, financial postings, customer PII - should have their Fabric workspace access restricted to the same population that would have access in Dynamics, and any Power BI reports exposing this data should implement their own row-level security at the semantic model level.

For organisations in regulated industries - healthcare, financial services, government - confirm that your Fabric capacity region matches the data residency requirements for the Dynamics data you are linking. Dataverse and Fabric capacity must be in the same tenant, but need not be in the same region; cross-region data access should be reviewed against any data sovereignty obligations before enabling the link in production.

Common Mistakes When Connecting Dynamics 365 to Microsoft Fabric

Conclusion: Choosing the Right Path to Migrate Dynamics 365 to Fabric

The decision to migrate Dynamics 365 to Fabric is now less a question of whether and more a question of which path and when. Export to Data Lake is gone. BYOD is deprecated and unfit for modern analytics or AI workloads. The two viable paths - Dataverse Link to Fabric and Azure Synapse Link - are both in active development, but their roadmap priority differs markedly: Microsoft's primary investment is in Fabric Link, and the June 2026 low-latency sync update is the most tangible evidence of that.

For most organisations, Dataverse Link to Fabric is the correct starting point. It requires the least infrastructure, produces analytics-ready data the fastest, and creates the shortest path between a Dynamics transaction and a Power BI report or a Copilot agent response. Azure Synapse Link remains valuable when data residency requirements mandate storage ownership, but that is a compliance-driven exception rather than the general case.

Numlytics specialises in Microsoft Fabric migration and has worked with enterprise teams across the US, UK, Australia, and UAE to connect Dynamics 365 estates to Fabric - from initial architecture decisions through to production go-live, semantic model build, and ongoing data quality monitoring. If your team is evaluating the migration or has already started and hit an obstacle, speak with a certified Fabric consultant and receive a scoped proposal within 24 hours.