What “Power BI + Fabric” Really Means For Your Existing Reports

The Scenario: A Finance BI Team Caught in the Middle

Imagine a small BI team inside a finance department:

• 3 analysts building Power BI reports
• 1 data engineer maintaining a SQL data warehouse
• A growing set of reports on sales, margin, and forecast accuracy

Their current setup:

• Data lives in:
  • On‑prem SQL Server (actuals)
  • A cloud data warehouse (budget & forecast)
  • A few Excel files in SharePoint (adjustments, mappings)
• Power BI connects to these sources via:
  • DirectQuery to the cloud data warehouse
  • Scheduled imports from SQL Server via the gateway
  • SharePoint folder connectors for Excel

Pain points:

• Refresh chains are fragile; one Excel file change breaks half the model.
• The data engineer is tired of being the bottleneck for every new data source.
• Management wants near real‑time margin reports, but the current architecture can’t keep up.

Now the licensing portal and documentation start talking about Power BI + Fabric, and everyone asks:

• Are we being forced into Fabric?
• Do we have to rebuild our models?
• Is there a cheaper or more expensive way to run what we already have?

Let’s unpack what’s actually changed.

What “Power BI + Fabric” Actually Is (And Isn’t)

Power BI is no longer positioned as a stand‑alone product. It’s now part of Microsoft Fabric, which is a broader analytics platform.

At a high level, Fabric bundles:

• Power BI (visualisation & semantic models)
• Data engineering (Spark notebooks, pipelines)
• Data science (ML workloads)
• Real‑time analytics (KQL‑style engines)
• Data warehouse & lakehouse (SQL & Delta tables)

Key clarifications for the finance BI team:

• Your existing Power BI workspaces, reports, and datasets still work.
• The Power BI you know is now the “Power BI experience” inside Fabric.
• Fabric adds new workload types and a new capacity model, but does not invalidate your .pbix files.

In other words, Fabric is a superset. Power BI is one part of it.

Licensing: How Power BI + Fabric Changes the Money Conversation

This is usually the first internal meeting: IT, finance, and BI trying to decode SKUs.

At a simplified level, you now think about:

1. Per‑user licenses

   • Power BI Pro / Premium Per User (PPU) still exist.
   • Users with these licenses can work with Fabric‑backed content, within limits.

2. Capacity licenses (Fabric capacities)

   • Instead of buying a “Power BI Premium capacity”, you buy a Fabric capacity.
   • That capacity is shared by all workloads: Power BI, Warehouse, Lakehouse, etc.

For our finance BI team, the key questions:

• Do we need Fabric capacity right now?
• Or can we stay on Pro / PPU and selectively use Fabric features?

A pragmatic approach:

• If you’re mostly:

  • Importing data into Power BI
  • Building semantic models
  • Publishing standard reports

  …you can usually stay on Pro / PPU in the short term.

• If you want to:

  • Consolidate data into a central lakehouse/warehouse
  • Run heavy data transformations at scale
  • Share one copy of data across multiple teams and tools

  …you’ll likely want Fabric capacity sooner.

The finance team’s decision pattern often looks like this:

1. Keep existing Power BI licensing.
2. Pilot a small Fabric capacity for one critical scenario (e.g., margin reporting) and measure:
   • Refresh reliability
   • Performance
   • Developer productivity
3. Only then consider migrating more workloads.

Architecture Shift: From Many Data Silos to One Lake

The biggest conceptual change with Power BI + Fabric is architectural.

Old pattern (our finance team today):

• Power BI models directly connect to:
  • On‑prem SQL
  • Cloud data warehouse
  • SharePoint Excel
• Each dataset has its own transformation logic in Power Query.
• The same logic is duplicated across multiple reports.

New pattern with Fabric available:

• Data is ingested into a Fabric Lakehouse / Warehouse.
• Transformations run in Fabric (Spark, Dataflows Gen2, pipelines).
• Power BI models connect to curated tables in the Lakehouse/Warehouse.

For the finance team’s margin report:

• Instead of each report pulling from multiple sources and doing its own joins, you create a single curated factMargin table in a Lakehouse/Warehouse.
• Power BI connects to that table, and multiple reports reuse it.

This shift matters because:

• You centralise business logic (no more 5 versions of the same transformation).
• You separate data engineering from reporting more cleanly.
• You can scale storage and compute independently from report rendering.

You are not forced into this model on day one, but Fabric makes it much more natural.

What Happens to Your Existing Power BI Models?

This is where most teams worry about rework.

The good news

• Your existing datasets and reports continue to run.
• You can still:
  • Use Power Query in Desktop
  • Publish to workspaces
  • Schedule refreshes

Where Fabric quietly shows up

Even if you haven’t asked for it, you’ll notice:

• New object types in workspaces (Lakehouse, Warehouse, Data Science, etc.).
• Options to create Direct Lake models (Power BI models directly on lakehouse data).
• Dataflows Gen2 (Fabric‑backed dataflows) alongside the old dataflows.

You can ignore these at first. But for the finance team’s margin scenario, two Fabric features are worth piloting:

1. Dataflows Gen2 to centralise transformations across reports.
2. A Warehouse or Lakehouse to host curated tables.

A Concrete Before/After: Margin Report Refreshes

Let’s make this very practical.

Before: Power BI‑only approach

For the margin report, the team currently:

1. Connects Power BI Desktop to:
   • On‑prem SQL: Sales, Costs
   • Cloud DW: Budget
   • SharePoint: Adjustments.xlsx
2. Builds a Power Query chain inside the .pbix:
   • Merge Sales and Costs into factMargin
   • Join Budget for variance
   • Append Adjustments
3. Publishes the dataset and report.
4. Sets up a scheduled refresh via gateway.

Typical issues:

• Refresh fails when Adjustments.xlsx structure changes.
• Every new report needing margin logic copies the same queries.
• The data engineer can’t see or version‑control the business logic easily.

After: Power BI + Fabric pattern

Step 1 – Ingest data into Fabric (once per source):

• Create a Lakehouse or Warehouse.
• Use Fabric pipelines or Dataflows Gen2 to ingest:
  • Sales from on‑prem SQL
  • Costs from on‑prem SQL
  • Budget from cloud DW
  • Adjustments from SharePoint

Step 2 – Build a central transformation (e.g., Dataflows Gen2):

let
    Sales     = Source{[Name="Sales"]}[Data],
    Costs     = Source{[Name="Costs"]}[Data],
    Budget    = Source{[Name="Budget"]}[Data],
    Adj       = Source{[Name="Adjustments"]}[Data],

    MarginBase = Table.NestedJoin(
        Sales,
        {"DocID"},
        Costs,
        {"DocID"},
        "CostsTable",
        JoinKind.LeftOuter
    ),
    ExpandedCosts = Table.ExpandTableColumn(
        MarginBase,
        "CostsTable",
        {"CostAmount"},
        {"CostAmount"}
    ),

    MarginWithBudget = Table.NestedJoin(
        ExpandedCosts,
        {"Month", "Product"},
        Budget,
        {"Month", "Product"},
        "BudgetTable",
        JoinKind.LeftOuter
    ),
    ExpandedBudget = Table.ExpandTableColumn(
        MarginWithBudget,
        "BudgetTable",
        {"BudgetMargin"},
        {"BudgetMargin"}
    ),

    MarginFinal = Table.Combine({ExpandedBudget, Adj})
in
    MarginFinal

This Dataflow writes a curated factMargin table into the Lakehouse/Warehouse.

Step 3 – Point Power BI to the curated table

• In Power BI Desktop, connect to the Warehouse or Lakehouse.
• Import or use Direct Lake (if available) for factMargin.
• Build your semantic model and measures on top:

Margin = SUM ( 'factMargin'[Revenue] ) - SUM ( 'factMargin'[CostAmount] )

Margin % = 
DIVIDE(
    [Margin],
    SUM ( 'factMargin'[Revenue] )
)

Margin vs Budget = [Margin] - SUM ( 'factMargin'[BudgetMargin] )

Step 4 – Reuse across reports

• Any new report that needs margin logic just connects to the same factMargin.
• The Dataflow/Data Engineering layer owns the joins and business rules.

Result for the finance team:

• Fewer refresh failures (one curated pipeline instead of many ad‑hoc ones).
• Easier governance (one place to review margin logic).
• Faster onboarding (new analysts hook into existing tables, not raw sources).

Governance and Workspaces in the Fabric Era

Workspaces now host more than just Power BI artifacts. They can contain:

• Reports, dashboards, semantic models
• Lakehouses, Warehouses
• Dataflows, Pipelines
• Notebooks

For our finance team, that means rethinking workspace design.

A workable pattern:

1. Data workspace (IT / data engineering owned)

   • Lakehouse/Warehouse
   • Dataflows Gen2
   • Pipelines

2. Semantic workspace (BI team owned)

   • Power BI datasets (semantic models)
   • Shared dimensions, measures

3. Report workspaces (per domain or department)

   • Thin reports that connect to shared semantic models

Benefits:

• Clear ownership: data engineers vs BI vs report authors.
• Fewer accidental changes to core data objects.
• Easier permission management.

You don’t have to reorganise everything immediately, but new Fabric objects are a good trigger to clean up workspace sprawl.

How to Decide What to Do This Quarter

When Power BI is sold as Power BI + Fabric, you don’t need a big‑bang migration. You do need a plan.

For a team like our finance BI group, a realistic 90‑day plan could be:

1. Inventory your current Power BI estate

   • List datasets that:
     • Have complex Power Query logic
     • Feed multiple reports
     • Frequently fail refresh

2. Pick one high‑pain dataset as your Fabric pilot

   • Margin, sales, or forecasting are typical candidates.
   • Criteria: business‑critical, messy sources, lots of reuse.

3. Stand up a small Fabric footprint

   • One Lakehouse or Warehouse.
   • One Dataflows Gen2 pipeline to produce a curated fact table.

4. Refactor that dataset only

   • Move transformations out of .pbix into Dataflows Gen2.
   • Point a new semantic model at the curated tables.

5. Measure tangible outcomes

   • Refresh success rate.
   • Time to onboard a new report.
   • Time to make a change to a core business rule.

6. Decide whether to expand

   • If the pilot shows clear operational benefits, move more datasets.
   • If not, pause; you can still run happily on classic Power BI.

One Practical Takeaway

Pick one fragile, high‑value Power BI dataset and rebuild it using Fabric building blocks (Lakehouse/Warehouse + Dataflows Gen2 + a clean semantic model); this small experiment will tell you more about whether Power BI + Fabric is worth adopting in your environment than any roadmap presentation or product announcement.