Legacy Power BI vs Fabric Power BI: What Changed, What Stayed, Semantic Models, Direct Lake, P SKU to F SKU, OneLake, Composite Models, Git Integration, Web Modeling, and the Complete Migration Path

Table of Contents

• What Actually Changed — And What Did Not
• Datasets Are Now Semantic Models — More Than a Rename
• Workspaces in Fabric — Same Name, Bigger Scope
• OneLake — The Storage Revolution
• P SKUs to F SKUs — The Licensing Shift
• Direct Lake — Why It Changes Everything
• Import vs DirectQuery vs Direct Lake — The Deep Comparison
• Default Semantic Models — The Decoupling
• Composite Models — Mixing Storage Modes
• Web Modeling vs Desktop — Building Models in the Browser
• Git Integration for Power BI — Version Control at Last
• What Stays Exactly the Same
• Migration Path — Legacy to Fabric
• When to Convert to Direct Lake — And When Not To
• Common Mistakes
• Interview Questions
• Wrapping Up

Our Power BI Architecture post introduced the three storage modes and Fabric Power BI Direct Lake covered Direct Lake in detail. This post is the complete before and after — what changed between legacy Power BI (standalone service, Premium P SKUs) and Fabric Power BI (unified platform, F SKUs), what stayed the same, and the migration path between them.

Analogy — Moving from an apartment to a house. Legacy Power BI is like living in an apartment. Your unit (workspace) contains your furniture (reports, datasets). The building manager handles electricity and plumbing (capacity, refresh). You share hallways with neighbors but never enter their apartments. Moving to Fabric is like moving to a house with the same furniture. Your couch (reports), dining table (semantic models), and kitchen (DAX) all work the same way. But now you have a garage (Lakehouse), a workshop (Spark notebooks), a garden (Data Factory), and a shared neighborhood storage facility (OneLake). The furniture is identical — the house just has more rooms.

What Actually Changed — And What Did Not

CHANGED (Fabric adds new capabilities):
  ✓ Licensing: P SKUs → F SKUs (capacity units shared across workloads)
  ✓ Storage: separate storage per tool → OneLake (unified Delta Lake)
  ✓ Storage mode: Import/DirectQuery only → Direct Lake added
  ✓ Workspace scope: Power BI items only → all Fabric items
  ✓ Terminology: "dataset" → "semantic model"
  ✓ Default semantic models: auto-created with Lakehouse → decoupled (Oct 2025)
  ✓ Version control: none → Git integration (Azure DevOps, GitHub)
  ✓ Modeling: Desktop only → web modeling in browser
  ✓ Composite models: Import + DirectQuery → Import + DirectQuery + Direct Lake
  ✓ Maps: Bing Maps → Azure Maps (paginated reports)

NOT CHANGED (your existing work survives):
  ✗ Reports: same visuals, same interactions, same look and feel
  ✗ DAX: all measures, calculated columns, and functions work identically
  ✗ Relationships: same cardinality, same cross-filter, same model view
  ✗ Power Query (M): same transformations, same editor
  ✗ RLS (Row-Level Security): same rules, same enforcement
  ✗ Scheduled refresh: still works for Import mode
  ✗ Gateways: still needed for on-premises sources
  ✗ Power BI Desktop: still the primary development tool
  ✗ Pro and PPU licenses: still available and functional

Datasets Are Now Semantic Models — More Than a Rename

In 2023, Microsoft renamed “datasets” to “semantic models.” This is not just terminology — it reflects a shift in how Power BI fits into the broader data platform.

What changed with the rename:

  Before (legacy):
    "Dataset" implied a copy of data -- something you import and refresh.
    Tightly coupled to the report (one dataset per report was the norm).
    Managed as a byproduct of publishing a .pbix file.

  After (Fabric):
    "Semantic model" implies a BUSINESS LAYER -- a governed, shared definition
    of how data should be interpreted (relationships, measures, security).
    Can be INDEPENDENT of reports (multiple reports share one model).
    First-class item in Fabric with its own lifecycle and permissions.
    Can be managed via REST APIs, version-controlled in Git.

  What this means for data engineers:
    - Build ONE semantic model per business domain (sales, finance, HR)
    - Multiple BI developers create different reports on the same model
    - The model is the "contract" between DE (who builds it) and BI (who consumes it)
    - Treat semantic models like APIs -- versioned, documented, governed

Workspaces in Fabric — Same Name, Bigger Scope

Legacy Power BI workspace:
  Contains: semantic models, reports, dashboards, dataflows, paginated reports
  Nothing else -- it is a Power BI-only container

Fabric workspace:
  Contains: everything from legacy PLUS
    Lakehouses, Warehouses, Notebooks, Pipelines, Spark Job Definitions,
    SQL Databases, KQL Databases, Eventstreams, ML Models, Environments,
    Data Factory pipelines, Dataflow Gen2, and more

  Impact for data engineers:
    Your Power BI semantic model lives NEXT TO the Lakehouse it reads from
    Both are in the same workspace
    Both share the same permissions model
    Both are deployed together via deployment pipelines
    This eliminates the disconnect between "data platform" and "BI platform"

Workspace governance:
  Legacy: workspace-level permissions (Admin/Member/Contributor/Viewer)
  Fabric: same roles, but now they apply to ALL Fabric items in the workspace
  A workspace Viewer can see Lakehouse files AND reports
  Consider this when designing workspace access for sensitive data

OneLake — The Storage Revolution

Legacy Power BI data flow:
  Source Database → ADF pipeline → Data Lake (ADLS Gen2) → Power BI Import
    Three copies of data:
    1. Source database (original)
    2. Data Lake (transformed copy)
    3. Power BI model (VertiPaq compressed copy)

Fabric with Direct Lake:
  Source Database → Pipeline → Lakehouse (OneLake, Delta tables) → Direct Lake
    Two copies of data:
    1. Source database (original)
    2. OneLake Lakehouse (transformed, Delta format)
    Power BI reads DIRECTLY from OneLake -- no third copy

  This eliminates:
    - The import refresh step (no data copying into Power BI)
    - The scheduled refresh window (data is near-real-time)
    - The duplicate storage cost (no VertiPaq copy)
    - The "data is stale between refreshes" problem

For data engineers:
  In legacy: you build the pipeline AND configure the refresh schedule
  In Fabric: you build the pipeline, and Direct Lake handles the rest
  Your gold layer IS the BI layer -- no separate ETL into Power BI

P SKUs to F SKUs — The Licensing Shift

The transition timeline:
  Jan 31, 2025: last day to purchase or renew P SKUs
  Feb 1, 2025: new purchases must use F SKUs
  Jan 1, 2026: end-of-life for non-EA customers
  Jan 1, 2028: end-of-life for EA customers

P SKU to F SKU mapping:
  P1 → F64
  P2 → F128
  P3 → F256
  P4 → F512
  P5 → F1024

Key difference:
  P SKU: dedicated capacity for Power BI ONLY
    Your Power BI had the entire compute pool to itself

  F SKU: shared capacity for ALL Fabric workloads
    Power BI, Spark, Data Factory, Warehouse, Real-Time Analytics
    ALL share the same pool of Capacity Units (CUs)
    A heavy Spark notebook competes with Power BI refreshes
    Workload scheduling becomes important

  Impact for data engineers:
    - Monitor CU consumption across workloads (Capacity Metrics App)
    - Schedule Spark jobs and Power BI refreshes to avoid overlap
    - Size capacity based on TOTAL workload, not just Power BI
    - Use the Fabric Capacity Metrics App to identify throttling

Direct Lake — Why It Changes Everything

The three eras of Power BI data access:

  Era 1 -- Import Mode (2015-present):
    Copy data into Power BI → fast queries → stale between refreshes
    Data engineer: builds pipeline + configures scheduled refresh
    Problem: refresh takes time, data is hours old, storage is duplicated

  Era 2 -- DirectQuery (2016-present):
    Query source at report time → always fresh → slow queries
    Data engineer: optimizes source database for BI query patterns
    Problem: source gets hammered, queries are slow, limited DAX

  Era 3 -- Direct Lake (2023-present, Fabric only):
    Read Delta files from OneLake directly into VertiPaq → fast + fresh
    Data engineer: builds pipeline to gold layer in Lakehouse → done
    No scheduled refresh, no data duplication, near-real-time
    The gold layer IS the BI layer

Why Direct Lake matters for data engineers:
  Before: DE builds pipeline → writes to Lakehouse → then ALSO configures
          Power BI Import refresh to copy data from Lakehouse into Power BI
  After:  DE builds pipeline → writes to Lakehouse → Direct Lake reads it
          No additional step. Pipeline output = BI-ready data.

What Direct Lake needs from data engineers:
  - Well-optimized Delta tables (run OPTIMIZE, VACUUM)
  - V-Order applied to Parquet files (Fabric does this by default)
  - Not too many small files (compact with OPTIMIZE)
  - Stay within SKU guardrails (row and column limits per table)
  - Proper star schema (same as Import mode)

Import vs DirectQuery vs Direct Lake — The Deep Comparison

Default Semantic Models — The Decoupling

Before (pre-October 2025):
  Creating a Lakehouse or Warehouse automatically created a "default semantic model"
  This model was tightly coupled -- changes to the Lakehouse schema changed the model
  Could not be managed independently
  Caused confusion: "which model should I use?"

After (October 2025):
  Default semantic models are now INDEPENDENT items
  New Lakehouses/Warehouses no longer auto-create default models
  You explicitly create semantic models and choose which tables to include
  Full control over model schema, relationships, and measures

  Impact for data engineers:
    - You decide which gold layer tables go into the semantic model
    - Not every Lakehouse table needs to be in the model
    - Create focused models: "Sales Model" with only sales-related tables
    - Avoid the "one model with 50 tables" anti-pattern

Composite Models — Mixing Storage Modes

Fabric introduced composite models that mix Direct Lake tables with Import tables in the same semantic model.

What composite models enable:

  Direct Lake tables (from OneLake):
    FactSales (10M rows) → Direct Lake (fast, no import needed)
    DimCustomer (50K rows) → Direct Lake

  Import tables (from any source):
    BudgetTargets (100 rows from Excel) → Import (not in OneLake)
    ExchangeRates (365 rows from API) → Import (not in OneLake)

  All four tables in ONE semantic model
  Direct Lake for the big tables, Import for small reference tables
  Best of both worlds

  Use cases:
    - Large fact tables in Lakehouse + small reference tables from external sources
    - Mixing Fabric data with non-Fabric data in one model
    - Adding Excel budget/target data alongside Lakehouse actuals

Web Modeling vs Desktop — Building Models in the Browser

Legacy: Power BI Desktop is the ONLY way to build models
  Download .pbix → connect → model → publish → iterate

Fabric: web modeling in the browser
  Open semantic model in Fabric portal → edit directly in browser
  Add tables, create relationships, write measures -- no Desktop needed
  Useful for: quick changes, adding a measure, fixing a relationship

Limitations of web modeling:
  - Cannot use Power Query (M) transformations
  - Cannot create calculated tables
  - Cannot connect to new data sources (for Import)
  - No "What-If" parameters

When to use which:
  Web modeling: Direct Lake models (selecting Lakehouse tables, adding measures)
  Desktop: Import models, complex Power Query, full development experience
  Both: mature organizations use Desktop for initial build, web for quick edits

Git Integration for Power BI — Version Control at Last

Legacy Power BI:
  No version control
  .pbix file shared via email or SharePoint
  "Who changed what?" is impossible to answer
  Rolling back = finding an old .pbix file (if it exists)

Fabric Power BI:
  Workspace connects to Azure DevOps or GitHub
  Semantic model definitions stored as JSON/PBIR files in Git
  Full version history, diffs, branching, pull requests
  Multiple developers can work on the same model

What gets version-controlled:
  ✓ Semantic model definition (tables, relationships, measures)
  ✓ Report layout (pages, visuals, bookmarks)
  ✓ Power BI pipeline configurations
  ✗ Actual data (never stored in Git)
  ✗ Scheduled refresh settings (workspace-level config)

Impact for data engineers:
  - Model changes go through PRs (reviewed before deployment)
  - Deployment pipelines promote from dev → test → prod
  - Model definition + report layout = version-controlled as code
  - Same Git workflow as Databricks, ADF, and Terraform

What Stays Exactly the Same

For reports:
  - All visuals work identically
  - Slicers, drill-through, bookmarks, conditional formatting -- unchanged
  - Report navigation and user experience -- identical
  - Users see no difference when viewing reports

For DAX:
  - All functions work identically (CALCULATE, ALL, SUMX, etc.)
  - Measures, calculated columns -- same behavior
  - Time intelligence -- same functions, same results
  - The VertiPaq engine is the same engine

For modeling:
  - Relationships, cardinality, cross-filter -- identical
  - Star schema patterns -- same best practices
  - RLS (Row-Level Security) -- same rules, same enforcement

For administration:
  - Workspace roles (Admin/Member/Contributor/Viewer) -- same
  - Power BI Pro and PPU licenses -- still work
  - Gateways -- still needed for on-premises sources
  - Power BI Desktop -- still the primary development tool

For data refresh:
  - Scheduled refresh -- still works for Import models
  - Incremental refresh -- still works
  - On-demand refresh via REST API -- still works
  - Existing Import models do NOT need to convert to Direct Lake

Migration Path — Legacy to Fabric

Migration is ADDITIVE -- nothing breaks:

  Step 1: CAPACITY MIGRATION (licensing)
    P1 → F64, P2 → F128, etc.
    All existing workspaces move to the new capacity
    Reports, models, refreshes continue working unchanged
    This is a billing switch, not a technical migration

  Step 2: WORKSPACE AWARENESS
    Workspaces now show Fabric items (Lakehouses, Notebooks)
    Existing Power BI items remain unchanged
    No action needed unless you want to add Fabric workloads

  Step 3: OPTIONAL -- Convert Import models to Direct Lake
    This is OPTIONAL and should only be done when beneficial
    Requires: data already in a Fabric Lakehouse (Delta format)
    Requires: Power Query transformations moved to the pipeline layer
    Requires: calculated columns replaced with measures or pipeline logic
    Benefits: no scheduled refresh, no data duplication, near-real-time

  Step 4: OPTIONAL -- Enable Git integration
    Connect workspace to Azure DevOps or GitHub
    Version-control semantic models and reports
    Set up deployment pipelines for dev → test → prod

  Timeline:
    Step 1: do now (licensing deadline approaching for EA: Jan 2028)
    Step 2: automatic (nothing to do)
    Step 3: do when building new models or when refresh issues justify it
    Step 4: do when team is ready for proper CI/CD

When to Convert to Direct Lake — And When Not To

CONVERT to Direct Lake when:
  - Data already lives in a Fabric Lakehouse (Delta tables)
  - Scheduled refresh is a bottleneck (takes too long, too infrequent)
  - Dataset is large (Import approaching size limits)
  - Near-real-time freshness is needed
  - You want to eliminate data duplication (source + PBI copy)

DO NOT convert when:
  - Model uses extensive Power Query transformations (must move to pipeline)
  - Model uses calculated columns and calculated tables (not supported in DL)
  - Data is small and refresh is fast (Import works fine)
  - Data comes from non-Fabric sources (Excel, on-prem SQL, APIs)
  - Team does not have a Lakehouse with gold layer tables ready

The conversion process (non-trivial):
  1. Move all Power Query (M) transformations to the pipeline layer
     (ADF, Databricks, Spark notebooks -- ETL before Power BI)
  2. Replace calculated columns with measures or pipeline-computed columns
  3. Build gold layer tables in Lakehouse (star schema, Delta format)
  4. Run OPTIMIZE and VACUUM on Delta tables
  5. Create a new semantic model in Direct Lake mode
  6. Recreate relationships and measures (DAX measures transfer)
  7. Rebuild reports on the new model (or use XMLA rebinding)
  8. Validate results match the Import model
  9. Decommission the old Import model

This is an engineering project, not a toggle switch.

Common Mistakes

1. Assuming migration to Fabric breaks existing reports. Moving from P SKU to F SKU is a capacity reassignment. All reports, DAX, relationships, and refresh schedules continue working unchanged. No reports need to be rebuilt. Migration is additive — Fabric adds capabilities, it does not remove existing ones.

2. Converting every Import model to Direct Lake immediately. Direct Lake requires data in a Fabric Lakehouse with proper Delta table optimization. Converting an Import model that uses Power Query transformations and calculated columns requires significant engineering effort. Only convert when there is a clear benefit (large dataset, refresh bottleneck, near-real-time need).

3. Not understanding that F SKU capacity is shared across workloads. Unlike P SKU (dedicated to Power BI), F SKU capacity is shared by all Fabric workloads. A heavy Spark job running during peak Power BI usage causes throttling. Schedule data engineering jobs and BI refresh during off-peak hours, and monitor with the Capacity Metrics App.

4. Treating semantic models as dataset byproducts instead of first-class assets. In Fabric, semantic models are independent, governed items — not just something a .pbix file produces. Build semantic models deliberately, version-control them in Git, and treat them as the API contract between data engineering and BI teams.

5. Not enabling Git integration for semantic models. Without Git, model changes are untracked, unreviewable, and irreversible. Enable Git integration on workspaces and commit model changes through pull requests. This is the single most impactful governance improvement for Power BI in Fabric.

6. Ignoring Direct Lake guardrails and fallback behavior. Each F SKU has limits on rows and columns per Direct Lake table. Exceeding these causes silent fallback to DirectQuery, which is dramatically slower. Set the DirectLakeBehavior property to fail instead of fallback if you need to detect when guardrails are hit. Size your SKU based on your largest table.

7. Expecting Direct Lake to work without Delta table maintenance. Direct Lake reads Delta Parquet files directly. If your Lakehouse has thousands of small files from streaming inserts, Direct Lake performance degrades and may fall back to DirectQuery. Run OPTIMIZE regularly (Fabric auto-optimizes in many cases), ensure V-Order is applied, and run VACUUM to remove old files.

8. Not planning workspace design for mixed Fabric workloads. In legacy Power BI, a workspace contained only BI items. In Fabric, the same workspace may contain Lakehouses, notebooks, pipelines, and Power BI items. A workspace Viewer can see all items. Design workspace boundaries considering security — sensitive Lakehouse data and executive reports may need separate workspaces.

Interview Questions

Q: What are the key differences between legacy Power BI and Fabric Power BI? A: Fabric adds three major changes: Direct Lake storage mode (reads Delta files from OneLake without import), unified workspaces (contain Lakehouses, notebooks, and pipelines alongside reports), and Git integration (version-control semantic models). Licensing shifted from P SKUs (Power BI-only capacity) to F SKUs (shared Fabric capacity). “Datasets” were renamed to “semantic models” to reflect their role as governed business layers. However, existing reports, DAX, relationships, RLS, and refresh schedules all continue working unchanged.

Q: What is the difference between Import mode and Direct Lake mode? A: Import mode copies data from sources into Power BI’s VertiPaq engine during a scheduled refresh. Data is fast to query but stale between refreshes and duplicates storage. Direct Lake reads Delta Parquet files directly from OneLake into VertiPaq on-demand, without a refresh process. Data is near-real-time fresh with no duplication. Direct Lake requires Fabric (F SKU), data in Delta format in a Lakehouse, and does not support calculated columns or calculated tables. Import works with any license and any data source.

Q: Do existing Power BI reports need to be rebuilt when migrating to Fabric? A: No. Moving from P SKU to F SKU is a capacity reassignment. All existing reports, semantic models, DAX measures, relationships, scheduled refreshes, and RLS rules continue working unchanged. The migration is additive. Converting Import models to Direct Lake is optional and should only be done when there is a clear benefit. Existing Import and DirectQuery models work identically on Fabric capacity.

Q: What happens to Power Query transformations when converting to Direct Lake? A: Direct Lake does not support Power Query (M) transformations because it reads pre-computed Delta tables directly. All transformations must be moved to the upstream data pipeline — ADF, Databricks notebooks, Fabric pipelines, or SQL views in a Fabric Warehouse. This is typically the biggest effort in converting from Import to Direct Lake. The semantic model in Direct Lake mode connects directly to the gold layer tables, which must already be clean and modeled.

Q: How does F SKU capacity differ from P SKU capacity? A: P SKUs allocated dedicated compute exclusively for Power BI workloads. F SKUs use a shared pool of Capacity Units consumed by ALL Fabric workloads: Power BI, Spark, Data Factory, Warehouse, Real-Time Analytics, and more. This means a heavy Spark notebook running in the same capacity competes with Power BI report queries. Organizations must monitor CU consumption across workloads, schedule jobs to avoid contention, and size capacity based on total workload — not just Power BI. P1 maps to F64, P2 to F128, and so on.

Q: What are composite models and how do they work with Direct Lake? A: Composite models allow mixing storage modes within one semantic model. In Fabric, you can combine Direct Lake tables (large fact tables from OneLake) with Import tables (small reference tables from Excel or APIs) in the same model. This is useful when most data lives in a Lakehouse (Direct Lake) but some reference data (budget targets, exchange rates) comes from external sources that are not in OneLake. Each table independently uses its optimal storage mode.

Q: When should a data engineer recommend converting an Import model to Direct Lake? A: Recommend Direct Lake when data already lives in a Fabric Lakehouse, scheduled refresh is a bottleneck (long refresh times or insufficient frequency), the dataset is large (approaching Import size limits), or near-real-time freshness is needed. Do not recommend it when the model uses extensive Power Query transformations, relies on calculated columns or tables, is small with fast refresh, or when source data is not in Fabric. The conversion requires moving transformations to the pipeline layer, replacing calculated columns with measures, and building gold layer Delta tables.

Wrapping Up

The move from legacy Power BI to Fabric Power BI is evolutionary, not revolutionary. Your reports, DAX, relationships, and RLS all survive unchanged. What Fabric adds is a unified platform where the data pipeline, the Lakehouse, the semantic model, and the reports all live together — governed by the same permissions, version-controlled in the same Git repo, and promoted through the same deployment pipeline.

Direct Lake is the headline feature: it eliminates the import refresh process by reading directly from your gold layer Delta tables. But it is optional. Import mode still works, DirectQuery still works, and Fabric adds the choice of Direct Lake for workloads where near-real-time freshness and zero data duplication matter.

In the next post, we will cover the final piece: Power BI deployment and sharing — deployment pipelines, what happens to reports and semantic models after promotion, lakehouse rebinding across environments, sharing methods, row-level security, and the complete end-to-end deployment workflow.

Related posts: – Power BI Architecture – Power BI Direct Lake in Fabric – Microsoft Fabric Overview – Fabric Capacity Metrics App – Fabric Git Integration