From Power BI to Microsoft Fabric: A Skills Ladder for Working Analysts

Scenario: The Analytics Team That Outgrew Power BI Alone

Imagine a central analytics team:

• 20–30 Power BI reports
• A handful of certified semantic models in a shared workspace
• Data sources: a cloud data warehouse, a couple of APIs, and some large CSV/Parquet files in cloud storage
• A small dev/test/prod pattern using deployment pipelines

Pain points:

• Data prep logic split between Power Query in desktop, SQL views in the warehouse, and ad‑hoc scripts
• Slow refreshes and occasional gateway issues
• Data scientists asking for the “same data as the reports, but in notebooks”
• Leadership pushing to “move analytics into Fabric” without a clear roadmap

We’ll use this team as the running example and climb the skills ladder step by step.

Step 1 – From Power BI Workspaces to Fabric Domains and Workspaces

You already know X:

• Power BI workspaces for organizing reports and datasets
• Roles like Admin, Member, Contributor, Viewer
• Deployment pipelines for dev/test/prod

Next step in Fabric (Y): understand domains, Fabric workspaces, and how they relate to Power BI artifacts.

Key points:

• A Fabric workspace is still the container for Power BI items (reports, semantic models, paginated reports), but also for new Fabric items: Lakehouses, Warehouses, Dataflows Gen2, notebooks, pipelines, etc.
• Domains are a governance and organization layer across workspaces, typically aligned to business areas (Finance, Sales, HR). They help with discovery, access patterns, and policy application.
• Power BI workspaces created in Fabric capacities are effectively Fabric workspaces; you can add Fabric items alongside your existing Power BI content.

For our scenario team:

• Keep the dev/test/prod pattern, but make sure the workspaces are Fabric-enabled (on Fabric or Premium capacity).
• Align workspaces to domains so that Lakehouses, Warehouses, and semantic models for a business area live together.

Skill ladder takeaway:

• If you can design sensible Power BI workspace structures, the next skill is designing Fabric workspace + domain structures that keep data engineering and reporting in the same place.

Step 2 – From Power Query to Dataflows Gen2 and Lakehouse Tables

You already know X:

• Power Query in Power BI Desktop for data prep
• Basic M: Table.TransformColumns, Merge, Group By
• Incremental refresh configured on tables in semantic models

Next step in Fabric (Y): use Dataflows Gen2 feeding Lakehouses, instead of doing all prep inside the semantic model.

What changes:

1. Dataflows Gen2

   • Still Power Query, still M.
   • Runs as a Fabric item in a workspace.
   • Can write output to a Lakehouse (Delta tables) or other Fabric storage.

2. Lakehouse

   • Stores data in OneLake as Delta tables.
   • Exposes tables to Power BI via the Lakehouse’s default semantic model or via new models you build.

Minimal pattern for the scenario team:

• Move heavy data prep from desktop Power Query into Dataflows Gen2.
• Land curated tables in a Lakehouse.
• Build semantic models on top of those Lakehouse tables.

Example: simple Dataflows Gen2 transformation that lands into a Lakehouse table:

let
    Source = Sql.Database("your-server", "SalesDW"),
    SalesRaw = Source{[Schema="dbo", Item="FactSales"]}[Data],
    FilteredRows = Table.SelectRows(
        SalesRaw,
        each [OrderDate] >= Date.AddDays(Date.From(DateTime.LocalNow()), -365)
    ),
    RemovedColumns = Table.RemoveColumns(FilteredRows, {"InternalNote"})
in
    RemovedColumns

In Dataflows Gen2, you configure the output of this query to a Lakehouse table (e.g. Sales_Fact_Curated).

Skill ladder takeaway:

• If you can model transformations in desktop Power Query, the next skill is designing Dataflows Gen2 → Lakehouse pipelines so that prep is reusable across reports and notebooks.

Step 3 – From Shared Datasets to Fabric Semantic Models and Direct Lake

You already know X:

• Shared datasets (semantic models) in Power BI workspaces
• Import vs DirectQuery, and basic performance tuning
• Row-level security (RLS) in Power BI

Next step in Fabric (Y): understand semantic models in Fabric and when Direct Lake is worth using.

Key points:

• The semantic model concept is the same: tables, relationships, measures, RLS.
• In Fabric, semantic models can be:
  • Created from Lakehouse/Warehouse tables
  • Auto‑generated (e.g. default Lakehouse models) or custom
• Direct Lake is a storage mode where the semantic model reads directly from Delta tables in OneLake (no import, no DirectQuery), with in‑memory caching managed by the engine.

Important behaviours (high‑level, capacity‑dependent):

• Direct Lake works when the data is in OneLake Delta tables and the semantic model is eligible (size, configuration, capacity).
• If conditions are not met, the model can fall back to Import or DirectQuery, depending on setup.
• You still design the model: relationships, measures, RLS behave as they do in Power BI semantic models.

For the scenario team:

• Move curated tables into a Lakehouse.
• Build a semantic model on those tables; consider Direct Lake when:
  • The data is refreshed frequently.
  • You want near‑import performance without scheduled imports.

Simple DAX measure (same in Fabric semantic models):

Total Sales := SUM ( 'Sales_Fact_Curated'[SalesAmount] )

Sales Last 30 Days :=
CALCULATE (
    [Total Sales],
    DATESINPERIOD (
        'Date'[Date],
        MAX ( 'Date'[Date] ),
        -30,
        DAY
    )
)

Skill ladder takeaway:

• If you can design robust shared datasets, the next skill is choosing Lakehouse vs Warehouse as sources and understanding Direct Lake as a storage option, not a different modeling language.

Step 4 – From Scheduled Refresh to Fabric Pipelines and Orchestration

You already know X:

• Scheduled refresh in Power BI
• Incremental refresh policies on tables
• Basic deployment pipelines for reports and semantic models

Next step in Fabric (Y): orchestrate data movement with Fabric Data Pipelines and align refresh across Lakehouse, Dataflows, and semantic models.

Why it matters:

• In Power BI‑only setups, it’s common for the semantic model refresh to be the first time data prep runs.
• In Fabric, you often want:
  • Dataflows Gen2 to land data in Lakehouses/Warehouses
  • Pipelines to orchestrate order (e.g. raw → curated → semantic model refresh)

Typical pipeline for our scenario team:

1. Ingest raw data into a Lakehouse (files, database copy, etc.).
2. Run Dataflows Gen2 to transform raw into curated tables.
3. Trigger semantic model refresh once curated tables are updated.

Skill ladder takeaway:

• If you understand scheduled refresh and incremental refresh, the next skill is orchestrating those refreshes with pipelines so downstream models see consistent data.

Step 5 – From “Ad‑Hoc Data” to Lakehouse for Analysts and Notebooks

You already know X:

• Pulling CSV/Excel files directly into Power BI
• Occasional use of R or Python in Power BI for niche calculations

Next step in Fabric (Y): treat the Lakehouse as the shared analytical data layer and learn just enough notebooks to be useful.

Lakehouse for analysts:

• Store “one‑off” but important files (CSV, Parquet) as tables in the Lakehouse instead of embedding them in a single Power BI file.
• Let data scientists and engineers access the same tables via notebooks.

Example: simple notebook cell to read a Lakehouse table in PySpark (where supported):

from pyspark.sql import SparkSession
from pyspark.sql.functions import col, current_date, date_sub

spark = SparkSession.builder.getOrCreate()

sales_df = spark.read.table("Sales_Fact_Curated")

sales_df.createOrReplaceTempView("Sales_Fact_Curated_View")

recent_sales_df = (
    sales_df
    .filter(col("OrderDate") >= date_sub(current_date(), 90))
    .groupBy("CustomerId")
    .sum("SalesAmount")
    .withColumnRenamed("sum(SalesAmount)", "TotalSales")
)

display(recent_sales_df)

Behaviour notes:

• The exact notebook APIs and SQL functions available depend on the runtime and engine configured for the notebook; the example above illustrates the pattern of reading a Lakehouse table and querying it via Spark.
• The key skill for an analyst is less about mastering PySpark and more about understanding that the same curated tables are usable by both reports and notebooks.

Skill ladder takeaway:

• If you’re used to pulling files straight into Power BI, the next skill is landing them in a Lakehouse so that analysts, data scientists, and engineers all work from the same curated tables.

Step 6 – From Tenant‑Level Governance to Fabric‑Aware Governance

You already know X:

• Power BI tenant settings
• Workspace roles and app permissions
• Basic RLS and object‑level security (OLS) in semantic models

Next step in Fabric (Y): apply those governance instincts to Fabric domains, workspaces, and item types.

Practical focus for analysts (not admins):

• Understand which domain your workspace belongs to and the implied data ownership.
• Keep sensitive data transformations in governed workspaces; avoid personal workspaces for shared logic.
• Continue to use RLS/OLS in semantic models; Fabric doesn’t change the core security model for those.

For the scenario team:

• Make sure Lakehouses and Warehouses that feed production reports live in governed, domain‑aligned workspaces.
• Keep experimental notebooks and ad‑hoc dataflows in clearly marked dev workspaces.

Skill ladder takeaway:

• If you already design secure Power BI models, the next skill is placing Fabric items in the right domain/workspace structure so that governance policies actually apply.

What You Can Safely Ignore (For Now)

Fabric is broad. As an analyst, you don’t need to learn everything immediately.

You can usually defer:

• Deep Spark tuning or custom runtimes
• Complex data engineering patterns (medallion architectures in detail, advanced CDC)
• Real‑time streaming pipelines beyond basic use cases
• Advanced CI/CD with external tools

Focus on the ladder:

1. Workspaces + domains
2. Dataflows Gen2 → Lakehouse
3. Semantic models on Lakehouse/Warehouse, including Direct Lake where it fits
4. Pipelines to orchestrate refresh
5. Lakehouse as shared layer for reports and notebooks
6. Governance aligned to domains and Fabric items

Practical Takeaway

Pick one existing Power BI report that’s painful to refresh and rebuild its data path using Dataflows Gen2 → Lakehouse → semantic model in a Fabric workspace. That single end‑to‑end path will force you up each rung of the skills ladder once, and you can reuse the pattern for the rest of your portfolio.