The bottom line
Delta Lake on Fabric works well but has specific migration traps: ADLS shortcuts need explicit Delta log paths, schema evolution settings differ from Databricks defaults, and the Lakehouse SQL endpoint needs table registration before Power BI can read via Direct Lake.
In This Article
Why Migrate Delta Lake to Fabric
Most organisations arriving at Microsoft Fabric already have Delta Lake data somewhere — usually Azure Data Lake Storage Gen2 (ADLS), sometimes Databricks, occasionally Azure Synapse Analytics. The migration to Fabric is attractive because Fabric unifies the analytical layer: one platform for data engineering, BI, and AI instead of three. The OneLake storage model means a single Delta table is queryable by Spark notebooks, the SQL analytics endpoint, Power BI via Direct Lake, and the Fabric Data Agent without copying data. That is the architectural win.
What the documentation does not adequately cover is the specific ways the migration fails in practice. We have run this migration for clients in manufacturing, FMCG, and logistics where the source data lives in ADLS Gen2 with existing Delta tables, and the same set of issues appears every time.
OneLake Shortcuts: The First Trap
OneLake Shortcuts let you point a Fabric Lakehouse at external data in ADLS, S3, or GCS without copying it. The trap is that when you create a Shortcut to an ADLS container that holds a Delta table, Fabric does not automatically recognise it as a Delta table. The Shortcut creates a file path reference — not a managed Delta table. If you navigate to the Lakehouse Files explorer, the folder appears, but it does not show up in the Tables section, and the SQL analytics endpoint cannot query it.
The fix is explicit Delta table registration. After creating the Shortcut, you need to run a notebook command to register the table against the SQL endpoint. Only after this step does the table appear in the SQL endpoint and become queryable by Power BI Direct Lake.
OneLake Shortcuts are a pointer to data, not a Delta table registration. You always need the explicit CREATE TABLE step to make the table visible to the SQL endpoint.
Table Registration and the SQL Endpoint
The Fabric Lakehouse SQL analytics endpoint is an auto-generated, read-only SQL endpoint that exposes all managed Delta tables in the Lakehouse. "Managed" here means tables created via spark.sql CREATE TABLE or tables written using DeltaTable.createOrReplace() in PySpark — not just files that happen to be in Delta format sitting in the Files section. This catches every team migrating from Databricks who expects the table catalog to auto-populate.
Another gap: if you are migrating from Azure Synapse Analytics, Synapse external tables defined over ADLS do not migrate to Fabric automatically. You need to re-create the table definitions in the Fabric Lakehouse using the CREATE TABLE syntax. The column definitions, partition columns, and Delta properties all need to be explicitly set if they differ from defaults.
Schema Evolution Differences
Databricks enables schema evolution on Delta tables by default in many notebook contexts. Fabric does not. If your existing Delta pipelines use mergeSchema=True in the DataFrameWriter or autoMerge=True in Delta table properties, you need to set these explicitly in Fabric. The Databricks default session variable for auto-merge does not exist in Fabric Spark — set mergeSchema on write operations explicitly.
Column mapping mode is another schema evolution gotcha. Databricks columns with spaces or special characters are handled by column mapping. If your source tables use column mapping and you migrate the Parquet files to Fabric without explicitly setting this Delta table property, column reads will fail with cryptic errors. Always check the source Delta table properties before migration using DESCRIBE EXTENDED in Databricks and recreate any non-default properties in Fabric.
Direct Lake Mode Gotchas
Direct Lake mode in Power BI reads Delta tables from OneLake directly without import, giving import-speed query performance on live data. The limitations are: maximum 1 billion rows per table in the semantic model (at F64 capacity), no support for calculated columns that reference DirectQuery sources, and the requirement that all tables in the semantic model use Direct Lake — you cannot mix Direct Lake and import mode tables in the same model as of May 2026.
The framing fallback to DirectQuery is the most common surprise. When a Direct Lake model hits a query it cannot serve from the in-memory column store — usually a complex DAX measure or a query that exceeds the row limit — it falls back to DirectQuery against the SQL endpoint. The performance difference shows up in Power BI Performance Analyzer as queries taking 3-5 seconds instead of under 200ms. The fix is to optimise the Delta table: run OPTIMIZE with ZORDER on the columns most commonly filtered, and check that the Lakehouse table statistics are up to date by running ANALYZE TABLE.
Delta Lake migrations to Fabric are worth doing — the architecture simplification is genuine and the Direct Lake mode for Power BI is a real performance improvement over DirectQuery. The gotchas are specific and avoidable if you know they are coming. If you are planning a migration from Databricks, ADLS, or Synapse to Fabric and want a technical review of your specific setup, I am happy to work through it.
Free Assessment
Where does your operation sit on the data maturity curve?
8 questions. 3 minutes. You get a scored breakdown across data infrastructure, analytics readiness, and automation potential — with a specific next step for your industry.