Migrating Power BI Datasets to Microsoft Fabric: A Step‑by‑Step Playbook for Existing Workspaces

1. Decide What to Migrate (and What to Leave Alone)

Before touching Fabric switches, you need a migration inventory. Not every dataset should move on day one.

1.1 Classify your existing workspaces

For each existing Power BI workspace, classify it:

• Tier 1 – Critical production
  • Executive reports
  • Dashboards with SLAs / tight refresh windows
• Tier 2 – Important but flexible
  • Departmental reporting
  • Self‑service models with regular use
• Tier 3 – Low impact / legacy
  • Old POCs
  • One‑off analyses

Start with Tier 2 workspaces for your first migrations. They’re important enough to matter, but not so critical that a minor issue becomes a crisis.

1.2 Categorize datasets by complexity

For each dataset in scope, note:

• Data source types
  • Cloud DB (Azure SQL, Synapse, Fabric Warehouse)
  • On‑prem SQL / Oracle via gateway
  • Files (SharePoint, OneDrive, Data Lake)
• Refresh mode
  • Import
  • DirectQuery
  • Composite
• Dependencies
  • Shared datasets used across multiple reports
  • Dataflows feeding the dataset
  • RLS and security groups

This shapes your migration order. For example:

1. Import models using cloud sources
2. Composite models
3. On‑prem sources via gateway

2. Understand What “Fabric‑Enabled” Actually Changes

If you already know Fabric basics, focus on what changes specifically for Power BI datasets when a workspace becomes Fabric‑enabled.

2.1 Workspace modes and Fabric

Your existing workspace can be in:

• Pro / Shared capacity – limited Fabric capabilities
• Premium Per User (PPU) – more features, but per‑user
• Premium capacity / Fabric capacity – full Fabric experience

For dataset migration, what matters is:

• Whether the workspace is backed by a Fabric capacity
• Whether you can create Fabric items (Lakehouse, Warehouse, Notebooks) in that workspace

If you’re planning to land data into a Lakehouse or Warehouse and then model it, you want:

• A Fabric capacity‑backed workspace for end‑state
• Clear naming convention, e.g.:
  FIN-Prod-Fabric, Sales-Analytics-Fabric

2.2 Dataset behavior in Fabric workspaces

Once in a Fabric workspace, your Power BI datasets:

• Can use Fabric Lakehouse/Warehouse as sources
• Can be part of end‑to‑end Fabric pipelines
• Still behave as regular semantic models for Power BI reports

The semantic layer doesn’t disappear; it just sits in a richer environment.

3. Prepare: Clean, Document, and Freeze

Migration is the best time to clean up and document what you actually have.

3.1 Clean up unused datasets and reports

In each workspace:

• Identify datasets with:
  • No refresh in months
  • No report usage in months (from usage metrics)
• Archive or delete them before migration

Fewer objects = fewer surprises.

3.2 Document current state

For each dataset in scope, capture:

• Dataset name and workspace
• Data sources (server, DB, file locations)
• Refresh schedule and window
• RLS roles and group mappings
• Downstream reports / apps

A simple table in Excel or a OneNote page is enough. This becomes your migration checklist.

3.3 Freeze changes

Agree with stakeholders on a change freeze window:

• No new measures added during migration
• No structural changes to tables/relationships
• Only urgent hotfixes allowed

This avoids chasing a moving target while you test in Fabric.

4. Choose a Migration Path: Lift‑and‑Shift vs Re‑platform

You have two main strategies for each dataset.

4.1 Lift‑and‑shift semantic model only

You keep the data sources as they are (e.g. Azure SQL, on‑prem SQL via gateway) and move the dataset into a Fabric workspace.

Use this when:

• Data source is stable and performant
• You mainly want Fabric for governance, centralization, or future integration

High‑level steps:

1. Create or select a Fabric‑enabled workspace
2. Re‑publish the PBIX to the new workspace
3. Re‑wire refresh, RLS, and apps

4.2 Re‑platform data + model into Fabric

You move both the data pipelines and the semantic layer into Fabric (e.g. Lakehouse + Warehouse + dataset).

Use this when:

• You want to consolidate ETL into Fabric
• You’re moving from scattered imports/files to Lakehouse/Warehouse

High‑level steps:

1. Land data into a Lakehouse or Warehouse
2. Build a Fabric semantic model on top
3. Migrate measures/relationships from the old dataset
4. Swap reports to the new model

5. Step‑by‑Step: Lift‑and‑Shift a Power BI Dataset to Fabric

This is the quickest path for existing workspaces.

5.1 Create the target Fabric workspace

In the Power BI Service:

1. Create a new workspace (or pick an existing one) that is backed by Fabric capacity
2. Apply naming conventions and assign:
   • Admins
   • Members
   • Viewers
3. Align workspace roles with your existing security model

5.2 Extract the current semantic model

From Power BI Desktop:

1. Download the PBIX from the existing workspace
2. Open it and:
   • Check Model view for tables and relationships
   • Review Manage roles for RLS definitions

Optionally, export measures using Tabular Editor if you want an external backup.

5.3 Validate data sources in Desktop

In Power BI Desktop:

1. Go to Transform data → Data source settings
2. Note each source and authentication method
3. For on‑prem sources, confirm the gateway is still valid

Sample SQL query used by a dataset:

SELECT 
    o.OrderID,
    o.OrderDate,
    c.CustomerName,
    o.TotalAmount
FROM dbo.Orders o
INNER JOIN dbo.Customers c
    ON o.CustomerID = c.CustomerID
WHERE o.OrderDate >= DATEADD(DAY, -365, CAST(GETDATE() AS date));

Keep queries like this unchanged during initial migration unless you’re also re‑platforming.

5.4 Publish to the Fabric workspace

From Power BI Desktop:

1. File → Publish → Select the new Fabric workspace
2. Wait for the dataset and reports to appear in the Service

In the Service:

• Confirm the dataset appears under Datasets + dataflows (or Semantic models)
• Confirm reports are linked to the new dataset

5.5 Reconfigure refresh and gateway

In the Fabric workspace:

1. Open the dataset → Settings
2. Reconfigure:
   • Data source credentials
   • Gateway mappings (for on‑prem)
   • Scheduled refresh (match or improve previous schedule)

Test a manual refresh. Only move on when it passes.

5.6 Recreate RLS and validate

In the Service or Desktop:

1. Ensure Manage roles definitions are present
2. Map AAD security groups to roles

Example DAX filter for a Sales Manager role:

[RegionCode] IN VALUES(Users[RegionCode])

Where Users is a table mapping user principal names to region codes.

Use View as in Power BI Desktop or the Service to validate:

• One user per region
• A manager seeing multiple regions

5.7 Swap reports and apps

If reports were previously bound to the old dataset:

1. Re‑publish reports pointing to the new dataset
2. Or use Power BI Desktop to rebind the report to the new model, then publish

Finally, update:

• Apps to use reports from the Fabric workspace
• Bookmarks or links (e.g. intranet pages) if URLs changed

6. Step‑by‑Step: Re‑platform to Fabric Lakehouse/Warehouse

When you want to modernize the data layer as well, follow this path.

6.1 Land data into a Lakehouse or Warehouse

Use Fabric Data Pipelines or Dataflows Gen2 to load data.

Example: simple SQL source into a Fabric Warehouse using a Data Pipeline:

1. Create a Data Pipeline in Fabric
2. Add a Copy data activity from Azure SQL to Fabric Warehouse
3. Map tables 1:1 initially (optimize later)

If you prefer Lakehouse, you might use a Notebook to transform data:

from pyspark.sql.functions import col, to_date

orders = spark.read.table("source_db.dbo_Orders")

orders_clean = (
    orders
    .withColumn("OrderDate", to_date(col("OrderDate")))
    .filter(col("OrderDate") >= "2023-01-01")
)

orders_clean.write.mode("overwrite").saveAsTable("lakehouse_gold.Orders")

6.2 Build the Fabric semantic model

In the Lakehouse or Warehouse:

1. Select New semantic model from the table list
2. Choose the tables that match your existing dataset
3. Open in Power BI Desktop to:
   • Recreate relationships
   • Recreate measures

Example measure migration:

Old measure in the Power BI dataset:

Total Sales := 
SUM ( Sales[SalesAmount] )

You can copy this directly into the new semantic model.

6.3 Align dimensions and keys

Ensure dimension keys and surrogate keys are consistent:

• Same grain (e.g. CustomerID, ProductID)
• Same or mapped data types

If you change keys (e.g. introduce surrogate keys), document mapping logic and validate row counts.

6.4 Rebind reports to the new model

Once the Fabric semantic model is ready:

1. Open existing PBIX reports in Desktop
2. Use Transform data → Data source settings or Model → Switch semantic model (depending on features available) to point to the new model
3. Validate visuals, especially those using:
   • Time intelligence
   • RLS‑sensitive data

7. Testing: Don’t Skip the Boring Parts

Testing is where migrations succeed or fail.

7.1 Data validation

For each key table/measure:

• Compare row counts between old and new datasets
• Compare totals for important measures (e.g. Total Sales, Total Orders) for:
  • Last full year
  • Last full month
  • Last full day

You can use a simple validation query in the Warehouse:

SELECT 
    CAST(OrderDate AS date) AS OrderDate,
    SUM(TotalAmount) AS TotalAmount
FROM dbo.FactSales
GROUP BY CAST(OrderDate AS date)
ORDER BY OrderDate DESC;

Export both old and new results to Excel and compare.

7.2 Performance checks

Focus on:

• Initial report load time
• Slicer responsiveness
• Heavy visuals (many points, complex measures)

If performance regresses:

• Check relationships and cardinality
• Consider aggregations or summary tables in Fabric
• Review DAX for expensive patterns (e.g. nested CALCULATE with wide filters)

7.3 Security and RLS

Test RLS with real users or test accounts:

• One user per role
• Users belonging to multiple roles
• Users with no role (should see nothing)

Document results and sign‑off from data owners.

8. Cutover and Decommissioning

Once testing is done, plan the switch.

8.1 Plan the cutover window

Pick a low‑usage window and define:

• Exact time when reports will switch to Fabric
• Who is on call (BI team, DBA if needed)
• Rollback plan (revert app to old workspace if needed)

8.2 Communicate with stakeholders

Send a short, focused update:

• What is changing (e.g. new backend, same report URLs)
• When the change happens
• Expected impact (e.g. brief outage during cutover)

8.3 Monitor after go‑live

For the first days:

• Monitor refresh failures
• Monitor capacity metrics (if you manage Fabric capacity)
• Track user tickets and feedback

Only after stability is proven:

• Decommission old datasets
• Remove old workspace access

9. One Practical Takeaway

Don’t migrate workspaces ad‑hoc. Create a repeatable migration checklist (inventory → classify → choose path → lift‑and‑shift or re‑platform → test → cutover) and apply it workspace by workspace. The discipline of running the same steps every time will save you far more hours than any single Fabric feature.