Synapse Link to Fabric: Dynamics 365 Migration Guide [2026]

Microsoft has deprecated the Delta Lake/Parquet export path in Azure Synapse Link for Dataverse, making migration to Link to Microsoft Fabric mandatory for every enterprise running Dynamics 365 analytics. While existing Synapse profiles remain functional through December 2027, all active development, Direct Lake optimization, and unified OneLake mirroring have shifted exclusively to Fabric.

1. The Deprecation Mandate: Why Synapse Link Must Move

For five years, Azure Synapse Link for Dataverse (formerly Export to Data Lake) served as the standard highway for enterprise Microsoft Dynamics 365 reporting. Organizations pointed Dataverse and Dynamics 365 Finance & Operations (F&O) entities to an Azure Data Lake Storage (ADLS) Gen2 account, converted CSVs to Parquet, and ran Synapse Serverless SQL pools to feed Power BI Import datasets.

This architecture accumulated significant engineering debt: double-storage costs (Dataverse storage plus ADLS Gen2), scheduled data refresh latency (often 2–4 hours behind production transactions), and recurring Synapse pipeline failures when schema drift occurred in upstream ERP tables.

Under Microsoft's unified data strategy, the feature set is consolidated under the "Link data" interface in Power Apps, with Link to Microsoft Fabric established as the sole strategic destination. New customer access to the standalone Synapse Delta/Parquet export was terminated on October 15, 2026. Transitioning before the December 2027 deadline is an operational necessity.

2. Architecture: Synapse Serverless vs. Fabric OneLake

The fundamental shift between Synapse Link and Microsoft Fabric is the elimination of the relational query translation tax. In the legacy Synapse topology, an ERP business event in Dynamics 365 was exported to ADLS Gen2 as CSV or append-only Parquet logs. To read that data, Power BI had to generate T-SQL queries executed by a Synapse Serverless SQL pool, which translated the SQL into storage calls, marshaled the result sets over the network, and cached them in a Power BI Analysis Services tabular model.

In Microsoft Fabric, the architecture collapses into three zero-copy layers:

1. Dataverse & F&O Mirroring: Dataverse synchronizes table changes directly into OneLake in standard Delta Lake format (open-source Parquet files accompanied by a _delta_log transaction ledger).
2. OneLake Shortcuts & Fabric Lakehouse: The synchronized tables appear instantly as shortcuts inside your designated Fabric Lakehouse. No data copying, cross-tenant egress, or compute clusters are involved.
3. Direct Lake Query Execution: When a user opens an executive Power BI report, the VertiPaq engine does not execute T-SQL through a gateway. It loads the columnar Parquet files straight from OneLake storage into memory on demand.

3. Six-Step Production Migration Protocol

Migrating an enterprise ERP estate carrying 100+ entities without reporting interruption requires a disciplined staging protocol. Never sever Synapse Link until Fabric semantic models have passed financial validation.

Phase 1: Workspace & Capacity Assignment

In the Microsoft Fabric Admin Portal, create a dedicated workspace (e.g., ws-enterprise-erp-analytics-prod) and assign it to an active Fabric capacity (minimum F64 for enterprise production with Direct Lake, or trial F2/F4 for non-production validation). Ensure the Power Platform tenant and Fabric workspace reside in the same geographic Azure region to avoid cross-region latency.

Phase 2: Enable Link to Microsoft Fabric in Power Apps

Log in to the Power Apps maker portal (make.powerapps.com) with System Administrator privileges. Navigate to Tables → Analyze → Link to Microsoft Fabric. Select your target Fabric workspace. The service automatically creates a Dataverse-managed lakehouse named Dataverse_orgname_environment.

Phase 3: Entity Selection & Initial Sync

Select the business tables required for reporting. For commercial operations, prioritize core ledgers and masters: account, contact, systemuser, salesorder, salesorderdetail, invoice, and invoicedetail. If Dynamics 365 Finance & Operations is linked, select your financial entities (e.g., GeneralLedgerActivities, CustomerPaymentJournalLines).

// Monitor Dataverse to Fabric synchronization status via Power Apps CLI pac fabric status --environment-url https://orgname.crm.dynamics.com/ \ --workspace-name "ws-enterprise-erp-analytics-prod" \ --table-name "salesorder"

Phase 4: Establish the Curated Analytics Lakehouse

Do not build reporting semantic models directly on the raw Dataverse system lakehouse. Create a curated business Lakehouse (e.g., lh_finance_gold). In this gold lakehouse, create OneLake Shortcuts pointing to the raw Delta tables in the Dataverse lakehouse. This insulates your downstream reports from structural Dataverse system updates.

Phase 5: Parallel Financial Reconciliation

Run parallel financial reconciliations for two consecutive financial closes. Compare the general ledger trial balance, aging receivables, and sales order backlog generated by the legacy Synapse-backed model against the new Fabric model. The variance must be exactly $0.00.

Phase 6: Decommission Legacy Synapse Link

Once sign-off is achieved from the Financial Controller, navigate to Azure Synapse Link in Power Apps, select the legacy profile, and click Unlink. Archive the historical ADLS Gen2 storage container in accordance with your corporate data retention policy, then delete the Synapse Serverless workspace.

4. Direct Lake Mode & Semantic Model Re-Platforming

The primary technical challenge in this migration is re-platforming existing Power BI semantic models from Import Mode to Direct Lake without losing hundreds of complex DAX business measures, calculation groups, and row-level security (RLS) rules.

Rebuilding models from scratch in the web browser is error-prone. Instead, enterprise teams use the open-source Semantic Link Labs (sempy_labs) Python package within a Fabric Notebook to automate model conversion:

import sempy_labs as labs from sempy_labs import directlake # 1. Connect to existing Import model in staging workspace = "ws-enterprise-erp-analytics-prod" legacy_model = "Finance_Corporate_Reporting_Legacy" target_lakehouse = "lh_finance_gold" # 2. Inspect table schema and delta compatibility directlake.check_direct_lake_readiness( dataset=legacy_model, workspace=workspace, lakehouse=target_lakehouse ) # 3. Generate the Direct Lake semantic model repointing partitions to OneLake Delta tables directlake.migrate_import_to_direct_lake( dataset=legacy_model, new_dataset_name="Finance_Corporate_Reporting_DirectLake", workspace=workspace, lakehouse=target_lakehouse, overwrite=False ) print("Semantic model successfully migrated to Direct Lake mode.")

Direct Lake Fallback Safeguard: Direct Lake models require capacity memory. If a query requests data exceeding your Fabric capacity's Direct Lake memory limits, the query silently falls back to DirectQuery mode, inducing query latency. Monitor this metric in the Fabric Capacity Metrics app: ensure Direct Lake Fallback to DirectQuery Ratio remains at 0.00%.

5. FinOps: Sizing Fabric F-SKUs vs. Synapse Serverless

Budgeting for Microsoft Fabric requires transitioning from serverless variable metering to reserved capacity units. Azure Synapse Serverless billed $5.00 per TB scanned. For an organization whose analysts and scheduled refreshes scan 50 TB monthly, Synapse costs averaged ~$250/month in compute plus ADLS storage charges.

In Fabric, all workloads (Dataverse ingestion, Lakehouse shortcuts, OneLake storage, Notebooks, and Direct Lake Power BI queries) draw from a shared pool of Capacity Units (CUs):

The F64 Inflection Point: For organizations with over 400 report consumers, an F64 capacity is almost universally more cost-effective than licensing individual Power BI Pro ($10/user/month) or Power BI Premium Per User ($20/user/month) seats. Users with free Microsoft 365 licenses can consume reports hosted in an F64 workspace without per-user licensing add-ons.

6. Production Pitfalls & Cutover Checklist

Before decommissioning your Azure Synapse Link pipeline, verify these critical enterprise governance controls:

• Cross-Region Egress Avoidance: Verify that your Power Platform Environment, Azure subscription, and Fabric Capacity are deployed in the identical Azure geography (e.g., East US or West Europe). Cross-region capacity links trigger unthrottled network egress billing.
• Schema Drift Traps: When an administrator adds a custom custom field (e.g., cf_cost_allocation) in Dynamics 365, Fabric automatically mirrors the column into the Delta log. However, downstream Direct Lake models will not expose the new field until the semantic model metadata is synchronized via REST API or refreshed in Tabular Editor.
• Row-Level Security (RLS) Enforcement: In legacy Synapse, RLS was often implemented via SQL views. In Direct Lake, RLS rules must be declared inside the Fabric semantic model DAX definitions or configured at the OneLake storage layer.
• OneLake Storage Retention: Configure Delta Lake table maintenance routines (VACUUM and OPTIMIZE) in a weekly Fabric notebook to prune historical delta versions and compact small Parquet files, preventing storage bloat.