Power BI vs Microsoft Fabric: What Stays in PBIX and What Moves to Lakehouse in 2026

The Scenario: A Sales Analytics Team Drowning in PBIX Files

Imagine a mid-sized sales analytics team:

• 12 analysts building and maintaining reports
• 20+ PBIX files in a single workspace
• A shared SQL source plus a few Excel and CSV files
• One central “Sales Performance” report that everyone depends on

Pain points:

• Dataset refresh is slow and occasionally fails.
• Measures are duplicated across multiple PBIXs.
• Each analyst has their own version of customer and product tables.
• Nobody is sure which PBIX has the “official” logic.

The organization has started a Microsoft Fabric rollout. A Lakehouse is available, but only a few models use it. The big question: Power BI vs Microsoft Fabric – how do we decide what stays in PBIX and what moves to Lakehouse in 2026?

We’ll walk through this team’s transition and extract a decision framework you can apply to your own environment.

Step 1: Map Your Current PBIX Footprint

Before moving anything to Lakehouse, you need a clear picture of what’s inside your PBIXs.

For the sales team, the lead analyst does a quick inventory:

1. Data sources per PBIX

   • SQL database
   • Excel files (targets, budgets)
   • CSV exports from CRM

2. Transformations inside PBIX

   • Power Query for cleaning and merging
   • Calculated columns for business rules
   • Relationship tweaks and role-playing dimensions

3. Measures and business logic

   • Core measures (Sales, Margin, Units, Discounts)
   • Complex time intelligence
   • Row-level security (RLS) roles

4. Refresh and performance

   • Refresh duration and failures
   • Size of PBIX and dataset
   • Visuals that are consistently slow

You can automate some of this with the Power BI REST API or just document the top 5–10 critical PBIXs.

The key output of this step is a simple matrix for each PBIX:

• Data volume: small, medium, large
• Transformation complexity: low, medium, high
• Logic reuse need: low, medium, high
• Performance pain: low, medium, high

This matrix drives the next decisions.

Step 2: The Core Rule – Storage, Logic, and Presentation

In Fabric, you should separate three concerns:

• Storage & integration → Lakehouse / Warehouse
• Semantic logic (measures, relationships, RLS) → Semantic model (can be Lakehouse-based)
• Presentation (visuals, bookmarks, layout) → Power BI reports (PBIX, then PBIR / live in Service)

A practical rule of thumb for 2026:

1. Lakehouse holds:

   • Raw and curated tables
   • Heavy transformations
   • Slowly changing dimensions
   • Historical snapshots

2. Power BI semantic models hold:

   • Relationships
   • Measures
   • RLS
   • Light calculated columns (if truly report-specific)

3. PBIX files should focus on:

   • Report layout and visuals
   • Very report-specific measures or calc columns
   • Minimal data prep

For our sales team, this means:

• Move shared tables (Sales, Customers, Products, Regions, Calendar) into a Lakehouse.
• Build a central semantic model on top of the Lakehouse.
• Keep PBIXs as thin as possible: connect to the central model, avoid heavy Power Query.

Step 3: What Definitely Moves to Lakehouse

When deciding Power BI vs Microsoft Fabric, some patterns are clear candidates for Lakehouse.

1. High-volume fact tables

Move to Lakehouse when:

• Fact tables are tens of millions of rows or more.
• You have multiple PBIXs reading the same tables.
• Refreshes are slow or failing in Power BI.

Example in our scenario:

• FactSales (5 years of data)
• FactOrders
• FactDiscounts

These become Lakehouse tables, loaded via pipelines or notebooks.

-- Lakehouse SQL view for curated sales
CREATE VIEW vw_FactSales_Curated AS
SELECT 
    s.SalesID,
    s.OrderDate,
    s.CustomerID,
    s.ProductID,
    s.RegionID,
    s.Quantity,
    s.NetAmount,
    s.DiscountAmount
FROM 
    lh_raw.FactSales s
WHERE 
    s.OrderDate >= DATEADD(year, -5, GETDATE());

2. Shared dimensions and reference data

Move to Lakehouse when:

• Multiple PBIXs use the same dimension (Customer, Product, Calendar).
• You need one governed version of attributes and hierarchies.

For the sales team:

• DimCustomer with unified segments
• DimProduct with consistent product groups
• DimCalendar with fiscal periods

These sit in the Lakehouse and are surfaced through the central semantic model.

3. Heavy transformations and joins

Move to Lakehouse when:

• Power Query steps are complex (multiple merges, custom functions).
• You need reusable logic across reports.

Example: converting raw CRM exports into a clean customer dimension.

# Fabric notebook snippet for customer cleanup
from pyspark.sql.functions import trim, upper, col

raw = spark.read.table("lh_raw.crm_customers")

clean = (raw
    .withColumn("CustomerName", trim(col("CustomerName")))
    .withColumn("CustomerCode", upper(trim(col("CustomerCode"))))
    .dropDuplicates(["CustomerCode"]))

clean.write.mode("overwrite").saveAsTable("lh_curated.DimCustomer")

Once this runs in Fabric, PBIX just consumes DimCustomer from the semantic model.

Step 4: What Usually Stays in PBIX (At Least for Now)

Not everything needs to move. Some logic is easier and safer to keep in PBIX, especially while your Fabric rollout is still maturing.

1. Report-specific calculations

Keep in PBIX when:

• A measure only makes sense in one report.
• It’s tightly tied to specific visuals or storytelling.

Example: a custom KPI for one executive view.

Exec Focus Score = 
VAR MarginScore = DIVIDE([Total Margin], [Total Sales])
VAR GrowthScore = DIVIDE([Sales YoY], [Total Sales LY])
RETURN
    (MarginScore * 0.6) + (GrowthScore * 0.4)

If only the executive dashboard uses this, it can live in that PBIX.

2. Lightweight data shaping for visuals

Keep in PBIX when:

• You create small helper tables for slicers or groupings.
• The logic is purely visual and not a shared business rule.

Example: a custom ordering table for a slicer.

Slicer Order =
DATATABLE(
    "Label", STRING,
    "SortOrder", INTEGER,
    {
        {"Today", 1},
        {"Last 7 Days", 2},
        {"Last 30 Days", 3},
        {"FYTD", 4}
    }
)

This is harmless inside PBIX and doesn’t belong in Lakehouse.

3. Temporary experiments

Keep in PBIX when:

• You are prototyping new logic.
• It’s not yet approved as a standard metric.

Once the business signs off, move the logic into the central semantic model or Lakehouse transformations.

Step 5: Central Semantic Model – The Bridge Between Lakehouse and PBIX

For our sales team, the real change is not just Lakehouse storage, but a central semantic model that multiple reports share.

Design principles:

1. Single source of truth for measures

   • Core measures (Sales, Margin, Units, Discounts) defined once.
   • Time intelligence standardized.

2. Shared relationships and RLS

   • One place to maintain relationships between facts and dimensions.
   • RLS roles defined centrally.

3. Thin PBIX files

   • Each report connects to the central model.
   • Little or no data prep per report.

Example of core measures in the central model:

Total Sales = SUM(FactSales[NetAmount])

Total Margin = SUM(FactSales[NetAmount]) - SUM(FactSales[CostAmount])

Sales YoY = 
CALCULATE(
    [Total Sales],
    DATEADD(DimCalendar[Date], -1, YEAR)
)

Sales YoY % = 
DIVIDE([Total Sales] - [Sales YoY], [Sales YoY])

All downstream PBIX reports reuse these measures. No more copy-paste DAX between files.

Step 6: A Practical Decision Framework (2026 Edition)

Here’s a simple checklist you can apply to each component in your current PBIXs.

Move to Lakehouse when:

• Data volume is high and shared across multiple reports.
• Transformations are complex, reusable, or performance-critical.
• Governance is important (official dimensions, certified facts).
• Refresh is slow or unstable in Power BI.

Move to central semantic model when:

• Measures are used in more than one PBIX.
• RLS rules should be consistent across reports.
• Relationships are non-trivial and need central control.
• You want thin, maintainable PBIX files.

Keep in PBIX when:

• Logic is highly report-specific or experimental.
• Helper tables are purely visual and small.
• The report is a one-off with limited reuse needs.

For the sales team, applying this framework leads to:

• Lakehouse: all core facts and dimensions, heavy transformations, historical snapshots.
• Semantic model: shared measures, RLS, relationships.
• PBIX: visuals, layout, and a small set of report-specific measures.

Result: refresh times drop, duplication decreases, and onboarding new analysts becomes easier.

Step 7: Migration Tactics That Don’t Break Your Existing Reports

Moving from PBIX-centric to Lakehouse-centric can be done gradually.

For the sales team, they use a phased approach:

1. Clone, don’t overwrite (initially)

   • Create a new Lakehouse-based semantic model.
   • Connect a copy of the main PBIX to the new model.
   • Validate visuals and numbers before switching production.

2. Parallel refresh for a short period

   • Run old and new datasets side by side.
   • Compare key metrics daily or weekly.

3. Measure-by-measure migration

   • Move core measures into the central model first.
   • Replace local measures in PBIX gradually.

4. Freeze local transformations once migrated

   • Once a transformation is moved to Lakehouse, mark the PBIX version as deprecated.
   • Remove it after a stability period.

5. Document patterns and naming

   • Use consistent table and measure names across Lakehouse and semantic model.
   • Keep a simple catalog in OneNote, SharePoint, or a wiki.

This reduces risk and lets the team keep delivering reports while modernizing their stack.

One Concrete Takeaway: Start with One “Thin Report” Pilot

Don’t try to refactor every PBIX at once. Pick one high-impact report and turn it into a thin report that uses a Lakehouse-backed semantic model.

For that report:

1. Move shared tables to Lakehouse.
2. Build a central semantic model with core measures.
3. Strip Power Query and duplicated measures out of the PBIX.
4. Keep only layout and truly report-specific logic in the file.

Once that pilot works, you’ll have a clear, tested pattern for deciding what stays in PBIX and what moves to Lakehouse across the rest of your workspace in 2026.

Editor's Note

This article reflects how teams with growing Power BI estates are rebalancing logic between PBIX files, shared semantic models, and Fabric Lakehouses, especially in environments where performance, governance, and reuse across multiple reports are becoming critical.

Insights compiled through ongoing industry research, discussions within the Excelgoodies Analytics Community, and the hands-on project work in the Microsoft Fabric & Power BI (https://www.excelgoodies.ro/microsoft-fabric-power-bi-training-romania) programme.