Data lake export for Dynamics 365 Finance and Operations

For analytical workloads against Dynamics 365 Finance and Operations, the export-to-lake pattern has evolved through multiple iterations. Knowing which one is current — and which is deprecated — matters for new investments and existing migrations.

The progression.

• BYOD (Bring Your Own Database) — original pattern; F&O exports data entities to a customer-owned Azure SQL Database. Legacy; being phased out.
• Export to Data Lake — wave 2 2020; replaces BYOD for ADLS-based analytics. Currently in maintenance mode.
• Synapse Link for Dataverse with F&O integration — wave 2 2023+; surfaces F&O data through the Dataverse Synapse Link.
• Fabric Link for D365 — wave 2 2024+; the current strategic direction.

For new deployments, target Fabric Link. For existing BYOD/Export to Data Lake, plan migration.

BYOD (legacy)

F&O exports selected data entities to an Azure SQL Database the customer provides:

• Configurable per entity (full or incremental).
• Scheduled refresh.
• Customer's responsibility to manage the SQL Database.
• Power BI, Power Query, or other tools connect to the SQL.

Pros: SQL is familiar; customer controls. Cons: SQL cost; not modern lake-based; deprecation announced.

Export to Data Lake

F&O exports to Azure Data Lake Storage Gen2:

• CSV files per entity.
• Common Data Model (CDM) folder structure.
• Refresh on schedule or near-continuous.
• Synapse SQL serverless queries the files.

Pros: Lake-native; columnar potential. Cons: CSV is suboptimal; CDM folder format somewhat dated; in maintenance mode.

Fabric Link for D365

The current best-practice path. From the F&O side:

• Configure Fabric Link in F&O admin.
• Select entities to replicate.
• Data lands in OneLake as Delta Parquet.
• Available immediately in Fabric Lakehouse and Warehouse.

Pros: Modern format; OneLake-native; Direct Lake-ready; integrated with Fabric semantic models. Cons: Fabric capacity required; newer feature evolving.

Data scope

Both Export to Data Lake and Fabric Link surface:

• F&O data entities (the same ones used for integration).
• Selectable per entity.
• Both initial bulk and incremental updates.
• Field-level granularity.

The export catalog is large; choosing which entities to replicate is curation work.

Performance and latency.

• BYOD — refresh based on configured schedule, typically minutes to hours.
• Export to Data Lake — similar; minutes between batch flushes.
• Fabric Link — continuous delta; minutes from change to availability.

For most reporting workloads, any of these is fast enough. Real-time operations against F&O data require different approaches.

Schema considerations.

• F&O entities are denormalised views over underlying tables.
• Replication preserves the entity structure.
• Joins between entities happen at query time in the lake.
• Underlying F&O tables (e.g., CustTable, VendTable) are not directly replicated; only their entities.

For some advanced scenarios, table-level replication via direct database access is needed; this is unsupported and avoided.

Query patterns.

• Synapse SQL serverless — SELECT * FROM OPENROWSET(...).
• Fabric Warehouse — T-SQL over OneLake Delta tables.
• Fabric Lakehouse — SQL endpoint over Lakehouse.
• Spark notebooks — for advanced transformations.
• Power BI — semantic models in Direct Lake mode.

The unified Fabric experience makes the queries simpler than the older Synapse Link pattern.

Combining F&O and Dataverse data.

• Customer 360 reporting needs F&O sales + Dataverse CRM data.
• Both replicated to the same OneLake.
• Join at query time across the two.
• Single semantic model or warehouse model unifies them.

This unification is the strategic value of OneLake — heterogeneous data sources made queryable as one.

Security.

• Lake-side security is file/folder based.
• F&O row-level security doesn't carry over.
• Sensitive entities need separate restricted containers or column-level masking.
• Audit access to lake to ensure compliance.

Cost.

• BYOD — Azure SQL Database cost; meaningful.
• Export to Data Lake — ADLS storage; relatively cheap.
• Fabric Link — Fabric capacity consumption.

Per gigabyte, the modern lake-based options are cheaper than BYOD's SQL. Fabric Link bundles cost into Fabric capacity, which has its own economics.

Migration paths.

• BYOD to Fabric Link — re-implement reports against Fabric Lakehouse; gradual cutover.
• Export to Data Lake to Fabric Link — Microsoft provides guidance; migration tools emerging.
• Direct database access (unsupported) to Fabric Link — refactor to entity-based; significant work.

Common pitfalls.

• Sticking with BYOD past EOL. Eventually unsupported; migration becomes forced.
• All entities replicated. Storage and cost explode; query performance suffers from clutter.
• Schema changes in F&O broken downstream. Pipeline picks up new fields; reports fail unless monitored.
• Performance not tuned. Lake queries slow; complaints; investigation reveals partitioning or compression issues.
• No data lineage. Reports reference replicated data without traceability to F&O source; auditor questions impossible to answer.

Operational rhythm.

• Daily — verify replication freshness; check for failures.
• Monthly — review entity selection; retire unused replications.
• Quarterly — performance review; cost analysis.
• Annually — strategy review; align with Microsoft's direction.

Strategic positioning

F&O analytics has been a moving target across Microsoft's data strategy. The current direction is unambiguous: OneLake-based, Fabric-integrated. For organisations early in their F&O analytics journey, jump to Fabric Link directly. For organisations on BYOD or Export to Data Lake, plan migration on a 12–24 month horizon. The destination is clear; the path matters less than committing to start the journey.