From Power BI to Microsoft Fabric: A Practitioner's Migration Guide
How to migrate from Power BI to Microsoft Fabric in stages. Workspace conversion, semantic-model placement, Direct Lake mode, governance changes, and what NOT to migrate.
Microsoft Fabric is a superset of Power BI, not a replacement. Every Power BI workspace, semantic model, and report continues to work with no migration. So why migrate at all? Because the parts of Fabric that Power BI never had — OneLake, Direct Lake mode, Real-Time Intelligence, integrated notebooks — only deliver value once you actually use them. Sitting on a Power BI workspace inside a Fabric capacity gives you the bill without the upgrade.
This guide walks the migration in the order that actually works in practice, based on the cohort projects we've shepherded through this transition.
Phase 1 — Capacity and licensing
Before any technical migration, get the capacity model right.
Power BI Premium per Capacity (P-SKUs) is being phased out in favour of Fabric capacities (F-SKUs). The new F-SKUs unlock every Fabric workload, not just Power BI. If you're currently on a P-SKU, Microsoft offers an in-place transition to the equivalent F-SKU (e.g., P1 → F64) with no data movement — the workspace lifts and the new workloads simply become available.
Decision points at this stage:
- Do you keep autoscale enabled? Different default in Fabric than P-SKUs.
- Which workloads do you actually want enabled on the capacity? Each Fabric workload (Lakehouse, Warehouse, Real-Time, ML) can be toggled per capacity.
- Who admins the capacity? In Fabric, capacity admin is more powerful than it was — they control which workloads are on or off.
If you're not on Premium today, you can start on F2 (the smallest capacity) for evaluation. Real production workloads typically start at F8 or F16.
Phase 2 — Workspaces and OneLake
The biggest mental shift is OneLake. In pure Power BI, your data lives wherever you imported it from. In Fabric, every workspace gets a OneLake folder, and every Lakehouse, Warehouse, KQL Database, etc. inside that workspace stores its data in OneLake.
Practically this means:
- Pick one workspace to be a "data source" workspace — this is where Lakehouses live.
- Keep your existing report/model workspaces separate.
- Use shortcuts to surface OneLake data to other workspaces without copying it.
The shortcut model is what makes a clean architecture possible: data physically lives once, but logically appears wherever it's needed.
Phase 3 — Semantic models and Direct Lake
This is where most teams find unexpected value.
In Power BI you have two models for connecting to data:
- Import — data is loaded into VertiPaq, fast, but constrained by refresh windows
- DirectQuery — queries pass through to the source on every interaction, slower
Fabric introduces a third: Direct Lake. The semantic model reads Delta tables in OneLake directly, without an Import-style refresh. Queries are nearly Import-fast, but the data is always current (within the source's freshness). For tables in the gigabyte-to-terabyte range that you currently Import on a nightly schedule, Direct Lake is often a better fit.
The migration steps:
- Land your source data into a Lakehouse in OneLake (the Phase 4 work below).
- Create a new semantic model with Direct Lake against the Lakehouse.
- Rebuild relationships and measures (these don't carry over from Import models — they're new objects in a new model).
- Validate report performance against a known-good Import model before cutover.
What does NOT migrate well to Direct Lake:
- Models with heavy calculated columns — Direct Lake doesn't support them; you'll need to materialize as columns in the Delta table upstream
- Models that depend on incremental refresh policies
- Models with complex dataflow lineages where the dataflows do most of the transformation
For those, an Import model in Fabric (which works exactly as it did in Power BI Premium) is fine.
Phase 4 — Data ingestion
If you currently use Power BI dataflows (Gen1), they continue to work. Dataflows Gen2 are the upgraded path and write to Lakehouses or Warehouses. For complex transformations the better target is a Pipeline with notebook activities — but this requires Spark fluency that pure Power BI teams may not have.
Sequencing recommendation:
- Move dataflow Gen1 → Gen2 if you want a Lakehouse target without learning Spark.
- Move complex SSIS / ADF pipelines → Fabric Data Pipelines + notebooks if you need orchestration.
- Keep simple direct-from-source connections in Import semantic models if they work — there's no obligation to over-engineer.
Phase 5 — Governance and CI/CD
Fabric's deployment pipelines (separate from data pipelines, despite the unfortunate naming) handle dev/test/prod promotion of artifacts. They work on every Fabric item type, not just Power BI.
Git integration binds a workspace to an Azure DevOps or GitHub repo. Source-controlled artifacts now include semantic models, reports, notebooks, pipelines, and Lakehouse schemas. This is the biggest governance upgrade over Power BI Premium and the one most teams under-use.
Set both up early — the discipline they enforce is much harder to retrofit later than to start with.
What NOT to migrate
A few things that don't need migrating, because they're already fine:
- Reports — they sit on top of semantic models. If the semantic model is unchanged, the report is unchanged.
- App Workspaces and Apps — these continue to work as before.
- Row-level security rules in Import models — these carry over with the model.
- Sharing permissions — these carry over with the workspace.
A few things you should explicitly NOT migrate:
- Datasets you don't actually use. The capacity bill is the same; the maintenance bill isn't. A migration is a free chance to retire dead datasets.
- Reports that haven't been opened in 90 days. Same logic.
A typical migration timeline
For a mid-sized BI team (5–15 active developers, 50–200 datasets):
- Weeks 1–2 — Capacity transition, OneLake architecture decision
- Weeks 3–4 — First Lakehouse, first Direct Lake model, validation against a known-good Import model
- Weeks 5–8 — Roll the Direct Lake pattern across the top 10 datasets by usage
- Weeks 9–12 — Pipeline migration for the most painful refresh paths
- Weeks 13–16 — Governance: Git integration, deployment pipelines, sensitivity labels at scale
A team that tries to do everything in a single big-bang migration usually stalls in week 4. Phased rollout works.
Where this lands
Fabric is the path forward for Power BI. The migration isn't optional in the long run; the question is just whether you do it deliberately or get pushed by feature deprecation. Doing it deliberately, in order, with clear before/after measurements at each phase, is what separates the teams that complain about Fabric from the ones that quietly start shipping more.
Frequently asked questions
Do I have to migrate from Power BI to Microsoft Fabric?
No — every Power BI workspace, semantic model, and report continues to work in Fabric with no migration. The reason to migrate specific assets is to access capabilities Power BI doesn't have: OneLake (single logical data lake), Direct Lake mode (Import-fast queries against always-current data), Real-Time Intelligence, integrated notebooks, and Spark. If your existing Power BI setup serves your needs, there's no forced migration timeline.
What is Direct Lake mode in Microsoft Fabric?
Direct Lake is a third semantic-model storage mode (alongside Import and DirectQuery) that reads Delta tables directly from OneLake. Queries are nearly as fast as Import, but the data is always current — there's no refresh schedule. It's designed for tables in the gigabyte-to-terabyte range. It does not support all DAX features (calculated columns, for example) so an Import model is sometimes still the right choice.
Will my Power BI Premium P-SKU still work in Fabric?
Yes — Microsoft offers an in-place transition from Power BI Premium P-SKUs to the equivalent Fabric F-SKUs (e.g., P1 → F64). Workspaces lift over with no data movement. The new F-SKU unlocks every Fabric workload, not just Power BI; you choose which workloads to enable per capacity.
Should I move my Power BI dataflows to Dataflows Gen2?
If you want a Lakehouse target without learning Spark, yes — Dataflows Gen2 are the natural upgrade path and they write to Lakehouses or Warehouses. If your current Gen1 dataflow already does what you need and you're not feeding a Lakehouse downstream, there's no urgency. For complex orchestration the better target is a Fabric Data Pipeline with notebook activities, but that requires Spark fluency.
