Moving to Microsoft Fabric Is Not Lift-and-Shift: 6 Things That Break During Migration

The Scenario: A Power BI Shop “Just Turning On Fabric”

Picture a typical analytics setup:

• One Premium capacity hosting:
  • 15–20 Power BI semantic models (import + DirectQuery)
  • Several large dataflows (Gen1) feeding those models
  • A couple of paginated reports
• Data sources:
  • Azure SQL Database and Synapse dedicated SQL pools
  • A data lake in Azure Data Lake Storage Gen2
• Governance:
  • Separate workspaces for Finance, Sales, Operations
  • Deployed through deployment pipelines

Management agrees to move to Microsoft Fabric to consolidate data engineering and BI. The initial decision: upgrade the existing Premium capacity to Fabric and leave most content as‑is, then “gradually modernize”.

On day one, nothing looks broken. But over the next few weeks, six issues show up. None are bugs; all are design mismatches between “old Premium” assumptions and how Fabric actually works.

1. Dataflows Gen1 vs Dataflows Gen2: The Hidden Re‑Architecture

The first surprise: the team assumed they could keep dataflows Gen1 untouched and “just” start using Fabric items alongside them.

What actually happens:

• In a Fabric capacity, you can still create and run dataflows Gen1.
• Fabric also introduces dataflows Gen2, which:
  • Store data in OneLake by default.
  • Use a different runtime and item type.
  • Integrate more directly with Fabric pipelines and Lakehouses.

The break point in our scenario:

• Finance has a Gen1 dataflow writing dimension tables to Azure SQL.
• A new Fabric Lakehouse is created for Finance.
• Someone assumes they can simply “point the dataflow at the Lakehouse tables” and keep the rest identical.

That doesn’t hold:

• Gen1 dataflows don’t write directly into Lakehouse tables.
• Gen2 dataflows are designed for OneLake destinations and have different configuration.

Symptoms

• Confusion in the workspace: both Dataflow and Dataflow (Gen2) items exist.
• Some refreshes start failing when engineers try to redirect outputs to Lakehouse without redesigning the flow.

What Actually Works

For a Fabric‑native setup you need to:

1. Decide per domain whether you’ll keep Gen1 or move to Gen2.
2. For Gen2:
   • Create a Lakehouse (or Warehouse) as the storage target.
   • Rebuild the dataflow using dataflows Gen2, pointing outputs to Lakehouse tables.

Example: re‑implement a simple dimension load into a Lakehouse using dataflows Gen2 and Power Query.

let
    Source = Sql.Database("myserver.database.windows.net", "FinanceDW", [Query="SELECT DimCustomerID, Name, Country FROM dbo.DimCustomer"]),
    RenamedColumns = Table.RenameColumns(Source, {{"DimCustomerID", "CustomerKey"}}),
    Cleaned = Table.TransformColumns(RenamedColumns, {{"Name", Text.Trim, type text}})
in
    Cleaned

In the dataflow Gen2 designer, you then map the Cleaned query to a Lakehouse table.

Lesson: moving to Fabric is your moment to pick a lane. Running Gen1 and Gen2 side‑by‑side is possible, but every hybrid dependency you keep will slow down later modernization.

2. Import Models vs Direct Lake: Performance Assumptions Break

The team is excited about Direct Lake and assumes they can switch their largest import models over and “get the same performance without refresh”.

Key reality points:

• Direct Lake works only when:
  • The semantic model is built on a Fabric Lakehouse or Warehouse.
  • The data is stored in Delta tables in OneLake.
• When conditions aren’t met, Fabric falls back to DirectQuery for those tables.

In the scenario:

• Sales builds a Lakehouse over existing parquet files in OneLake.
• They create a semantic model on top and expect Direct Lake.
• Some tables are Delta, some are not.

Symptoms

• Some visuals are fast, others are noticeably slower.
• Performance Analyzer shows DirectQuery for certain tables.
• Modelling team is confused: “We thought this was Direct Lake everywhere.”

What Actually Works

Direct Lake is table‑level, not “model‑wide magic”. You need:

1. Delta format for tables you want in Direct Lake.
2. A semantic model created from the Lakehouse or Warehouse item.

If you’re using Fabric notebooks or pipelines, you can materialize Delta tables explicitly. For example, in a notebook using PySpark:

from pyspark.sql import SparkSession

spark = SparkSession.builder.getOrCreate()

df = spark.read.parquet("Tables/raw/sales/")

# Simple transformation
clean_df = df.dropna(subset=["OrderId"]).withColumnRenamed("OrderDate", "OrderDateUtc")

# Write as Delta into the Lakehouse
clean_df.write.format("delta").mode("overwrite").save("Tables/curated/sales_delta/")

Then, in Power BI Desktop connected to the Fabric workspace, you:

• Create a new semantic model from the Lakehouse.
• Use the curated/sales_delta table.

Lesson: switching an import model to Direct Lake is a data engineering change, not just a connection string tweak. You must control table formats and sources, or you’ll end up in mixed Direct Lake/DirectQuery mode with unpredictable performance.

3. Gateway and Connectivity: Not Everything Becomes “Cloud‑Native” Overnight

The team assumes that once they’re in Fabric, on‑premises gateways will become less important because “Fabric is more cloud‑native”.

Reality:

• Fabric still uses Power BI gateways for on‑premises and some private network sources.
• Lakehouses and Warehouses can connect to external data sources, but those sources still need network reach.

In our scenario:

• Operations has a semantic model in DirectQuery against an on‑prem SQL Server via gateway.
• They create a Fabric Warehouse and try to offload some queries there.
• They expect Fabric pipelines to pull data directly from on‑prem SQL “because Fabric is the new engine”.

Symptoms

• Pipelines fail with connectivity errors when run from Fabric.
• Semantic model refresh works (through gateway), but Warehouse load does not.

What Actually Works

You still need to:

1. Configure data sources in the gateway for Fabric items that connect to on‑prem.
2. Use supported connectors in Fabric pipelines and dataflows.

For example, a Fabric dataflow Gen2 connecting to on‑prem SQL Server via gateway uses the same underlying gateway configuration as Power BI.

Checklist for migration:

• Inventory all data sources currently using gateway.
• Confirm each is supported by Fabric dataflows/pipelines.
• Validate that the gateway cluster is sized and stable enough to handle both Power BI and Fabric workloads.

Lesson: Fabric doesn’t remove gateway; it broadens where gateway is required. Migration plans that ignore gateway configuration will hit connectivity issues as soon as data engineering moves into Fabric.

4. Workspace Layout and Item Types: Governance Patterns Don’t Map 1:1

Before Fabric, the team had a simple pattern:

• One workspace per domain.
• Inside each workspace: datasets, reports, dataflows, and a few paginated reports.

Fabric introduces:

• Lakehouses
• Warehouses
• Notebooks
• Data pipelines
• Dataflows Gen2
• Mirrored databases

The team initially drops all new items into the same existing workspaces.

Symptoms

• Hard to tell which Lakehouse feeds which semantic model.
• Notebook authors accidentally modify tables used by production reports.
• Deployment pipelines become messy because pipelines were designed around “report + dataset + dataflow” only.

What Actually Works

You need a Fabric‑aware workspace strategy. A pragmatic pattern:

1. Separate engineering and consumption:
   • One workspace for data engineering items (Lakehouse, Warehouse, pipelines, notebooks, dataflows Gen2).
   • One or more workspaces for BI consumption (semantic models, reports, dashboards, paginated reports).
2. Use deployment pipelines where the separation is clear:
   • Development workspace (engineering + test models).
   • Test workspace (mirrored structure, test data).
   • Production workspace (consumption only, linked to production Lakehouse/Warehouse).

In our scenario, Finance ends up with:

• Finance-Data workspace: Lakehouse, pipelines, dataflows Gen2.
• Finance-Reports workspace: semantic models and reports.

Lesson: Fabric adds new item types that behave differently. If you drop them into old workspaces without revisiting governance, you’ll end up with tangled dependencies and fragile deployment pipelines.

5. Refresh, Scheduling, and Orchestration: Old Timers Don’t Fit New Runtimes

The team originally relied on:

• Dataset scheduled refreshes.
• Dataflow refresh schedules.

After moving to Fabric, they start using:

• Pipelines for data ingestion.
• Lakehouses with notebooks for transformations.

They assume they can keep the old refresh schedules and “slot Fabric tasks around them”.

Symptoms

• Dataset refreshes start before Lakehouse loads have finished.
• Some semantic models are now effectively querying stale data.
• Overlapping workloads lead to capacity peaks and throttling.

What Actually Works

Fabric gives you more orchestration options, but you need to align them deliberately:

1. Use pipelines or notebooks to load and transform data into Lakehouse/Warehouse.
2. Trigger semantic model refreshes after data engineering completes.

Options include:

• Using Fabric pipelines to call a Power BI REST API to trigger dataset refresh when a data load activity succeeds.
• Moving from scheduled refresh to event‑driven refresh where practical.

An example pattern (described, not full code):

• Pipeline Activity 1: Copy data from source to Lakehouse.
• Activity 2: Notebook transformation.
• Activity 3: Web activity calling Power BI REST API to refresh a semantic model.

Lesson: Fabric adds orchestration; it doesn’t magically align existing refresh schedules. Migrating without rethinking the end‑to‑end timing will surface race conditions and capacity spikes.

6. Cost and Capacity Behaviour: Fabric Workloads Share the Same Pool

The team is used to thinking in terms of Power BI Premium capacity utilization for:

• Dataset refresh
• Query load
• Paginated reports

Once Fabric is enabled, the same capacity now runs:

• Lakehouse queries
• Warehouse queries
• Pipelines and dataflows Gen2
• Notebooks

The migration plan did not include any capacity modelling for these new workloads.

Symptoms

• Semantic model refreshes that were previously stable start to throttle or slow down.
• Notebook authors see intermittent performance degradation.
• Capacity metrics show new types of workload, but nobody is watching them.

What Actually Works

You need to:

1. Use the Fabric capacity metrics app to monitor:
   • CPU usage
   • Memory
   • Query wait times
   • Different workload contributions (BI, Data Engineering, etc.).
2. Plan when heavy data engineering jobs run relative to BI usage.
3. Consider separate capacities for heavy engineering vs. critical BI if workloads conflict.

In our scenario, the fix is:

• Move the nightly heavy Lakehouse loads to a different window than Finance’s early‑morning report refreshes.
• Monitor and adjust pipeline concurrency.

Lesson: Fabric workloads are not free. Migration that ignores capacity behaviour will look fine during testing and then degrade once real data engineering jobs start sharing the same pool as BI queries.

Practical Takeaway: Treat Fabric Migration as a New Architecture, Not a Switch

The pattern across all six breakpoints is simple: moving to Microsoft Fabric is not lift‑and‑shift. Turning on Fabric capacity keeps old content running, but every Fabric feature you adopt (Lakehouse, Warehouse, Direct Lake, pipelines, notebooks, dataflows Gen2) comes with architectural decisions.

If you’re about to migrate:

• Pick one domain (Finance, Sales, Operations) and fully modernize it end‑to‑end:
  • Dataflows Gen2 into Lakehouse/Warehouse
  • Delta tables for Direct Lake where appropriate
  • Fabric‑aware workspace split
  • Orchestrated refresh
  • Capacity monitoring
• Use that domain as your template before touching the rest.

That way, the first time something breaks, it’s in a controlled slice of your environment—and the fix becomes part of your standard pattern instead of a late‑night firefight.