Move Power BI to Fabric. Keep everything that works.
A structured, governance-led migration for UK organisations that have outgrown a Power BI-only analytics setup. We land your data in a Fabric lakehouse, rebuild the semantic model once, rebind your reports and prove the numbers match before anything goes live.
- Power BI estate audit, dependency map and transition plan
- Transformation logic built once in Fabric, shared by every model
- Reports reconciled against today's numbers before cutover
- Workspaces, governance and capacity designed to grow with you
Built for organisations already running Power BI
This migration is one of four Microsoft Fabric services we offer. It is the right starting point when there is a real Power BI estate to protect. If that is not you yet, one of the other two routes below will fit better.
This page is for you if
Your reports, dashboards and semantic models already live in Power BI and people rely on them- Data comes from SQL Server, Synapse, source APIs, spreadsheets or files through Import models and a gateway
- The same transformation logic is repeated across models and the copies no longer agree
- Refresh times, model sizes or an unmanageable estate are becoming the problem
- You want one governed data layer under Power BI, not another reporting tool
Starting Fabric from scratch?
No Power BI estate to move yet, or a green-field platform to stand up? The Fabric Accelerator sets up a governed platform and gets a first use case live.
Not sure Fabric is the right move?
Test one real reporting or data use case on your own data, and get a clear recommendation and roadmap before you commit to a migration.
The signs it is time to move the data layer out of Power BI
Power BI is excellent at reporting. It was never designed to be the place where an organisation's data preparation lives. These are the reasons clients come to us for this migration.
Duplicated transformation logic
Every team rebuilds the same data preparation inside its own model, and the copies drift apart.
Data volumes outgrowing Power BI
Refreshes take hours, models hit size limits, and scalability becomes a daily workaround.
No shared data layer
Prepared data lives only inside individual reports, so nothing can be reused safely.
A licensing renewal forcing the decision
Premium capacity SKUs stopped being sold in 2025, so the renewal conversation becomes a capacity and platform conversation.
The estate is unmanageable
No lineage, no documentation, and one source change breaks reports nobody knew depended on it.
Tool sprawl
Separate warehouse, ETL and BI tools, each with its own cost, skills and security model, and nothing to unify them.
AI ambitions
Copilot and AI agents need one governed data foundation, not a dozen semantic models that disagree.
A warehouse that reports can't keep up with
A SQL Server or Synapse warehouse feeds Power BI, but the modelling and logic still happen downstream in every report.
One team, one model, a few reports and not much complexity? Power BI works. Fabric is for when it grows.
From Power BI only, to Power BI on Fabric
This is not a lift and shift, and it is not a licensing exercise. The reports stay. The semantic model is rebuilt properly. Power BI stays as the reporting workload. The data preparation moves out of individual models and into a Fabric lakehouse, one governed data platform where it is built once.
Reports and dashboards bound to one or more Import models, each with its own logic.
Reconnected to the rebuilt model and checked against today's numbers. Published through your existing App, so users keep the same front door.
Carries the data preparation and the business logic, so every change means touching the model.
A documented star schema sitting on lakehouse tables, reproducing today's agreed numbers. Import, Direct Lake or DirectQuery chosen per model.
Repeated in Power Query across models. Copies drift apart.
Built once in the lakehouse and reused by every model and report downstream.
Each model pulls and stores its own copy of the source data.
Every source, from SQL Server to Azure data services, lands in OneLake on schedule, validated, and resilient to source API changes.
Feeds Power BI directly; the modelling and business logic still live inside each report.
Continues to feed the lakehouse for as long as you need it. Retirement is a separate decision, on your timeline.
Scheduled Import refreshes that fail quietly, with nobody alerted.
Every load logged with time, rows and pass or fail, and failures alerted before users notice.
Workspace and access model built for Power BI alone.
Your governance model extended to Fabric workspaces, domains and OneLake, with Dev, Test and Prod environments and deployment pipelines.
Premium capacity sized when the estate was smaller, or Pro with no capacity at all.
Fabric capacity planned from measured usage, with headroom for the next use case, whether that is a new domain or real-time analytics, rather than guesswork.
Four phases, one parallel run, no surprise cutover
Each phase ends with something you can review and sign off. Nothing is built until the scope and the target design are agreed, and nothing goes live until it has been reconciled.
Assess
- Inventory of workspaces, semantic models, reports, gateways and data sources
- Dependency and lineage map: what feeds what, and who uses it
- What to migrate, merge or retire
- Agree the numbers that must reconcile
Design
- Target architecture on OneLake: lakehouse, warehouse where needed, Fabric Data Factory and data engineering workloads
- How the lakehouse integrates with your warehouse and sources
- Workspace and domain design, governance model adapted for Fabric
- Storage mode decided per semantic model
- Capacity planning, Dev, Test and Prod environments
Migrate
- Sources ingested into the lakehouse on schedule, with validation
- Transformation logic built once
- Semantic model rebuilt, reports rebound
- Parallel run and reconciliation against today's figures
Hand over
- Plain-English documentation and runbook
- Load logging, failure alerts and monitoring in the Fabric portal
- Training for the people who will run it
- Roadmap for what comes next
- Your existing estate stays live throughout. Users are not moved until their reports are reconciled.
- Sequenced, not big bang. Report groups move in an order driven by dependency and business priority.
- Governance is designed first, so workspaces, access and domains are in place before content arrives.
The deliverables of a migration, in plain terms
These are the things running in your environment when we hand over. Not a roadmap to follow on your own.
All your data on Fabric
Every source feeding today's model ingested into the lakehouse: landing on schedule, validated, and resilient to source API changes.
A rebuilt semantic model
A lean, documented star schema replacing the inherited model, carrying all of today's data and reproducing today's agreed numbers, and documented so Copilot can use it.
Your reports, live
Reports rebound to the new model and reconciled, published through your existing App so users keep the same front door.
A secured platform
Credentials in Azure Key Vault, no personal logins, Dev, Test and Prod environments with proven deployment pipelines.
Failures caught early
Every load logged (time, rows, pass or fail) with automatic failure alerts, so problems reach your team before they reach your users.
Operable without us
Plain-English documentation and runbook, handed over live, so a capable Power BI professional can run the platform day to day.
Where Power BI to Fabric migrations go wrong
Most failed migrations are not technical failures. They are planning failures that only show up after cutover. We have seen each of these, and the approach above exists to prevent them.
Lifting and shifting a tangled model
Numbers that quietly change
Workspace sprawl on day one
Treating Direct Lake as mandatory
Rebuilding transformations per model, again
Personal logins in connections
Capacity sized by guesswork
Cutover with no way back
Power BI expertise that extends into Fabric
Governance first, on both sides of the move
The semantic model is the migration
Built to be run without us
Lazaros Viastikopoulos
Founder & Principal Consultant
Laz previously ran the Power BI practice at Telefónica Tech Data & AI (formerly Adatis). The consultant who scopes your migration is the one who delivers it, with a small team of Power BI developers, data engineers and governance specialists, all working on Microsoft data analytics as their primary discipline.
Migration is one of four ways we help with Fabric
Most migrations lead somewhere. Governance keeps the new platform tidy, and the Accelerator is how the next use case gets built on it. Not sure where you sit? Book a conversation and we will tell you honestly.
Microsoft Fabric Governance
The foundation every Fabric platform needs, and the piece most often left until too late. Our governance-first methodology applied to Fabric's shared data and workspace model.
- Workspace governance framework and domain structure
- OneLake access model, classification and data protection
- Purview integration, sensitivity labels and lineage visibility
- Capacity governance, admin controls and operating policies
Microsoft Fabric Accelerator
From Fabric capacity to a governed, production-ready platform in weeks, not months. Built for organisations ready to implement Fabric properly from the start.
- Tenant setup, workspace governance and capacity configuration
- OneLake structure, access model and governance from day one
- First production-ready use case live on the right Fabric architecture
- Handover, enablement and roadmap for what comes next
Microsoft Fabric Proof of Concept
Not sure if Fabric is right for you? Our PoC helps you test a real use case on your data, ending with a clear recommendation, handover, and roadmap.
- Built around a real reporting, data, or platform use case
- Discovery, design, build, review, and roadmap
- Architecture, governance, and current-state assessment included
- Working PoC, handover, and a clear next-step recommendation
Power BI to Fabric migration FAQs
The questions we are asked most often before a migration starts. If yours is not here, ask it on a call.
No. Your reports are kept and rebound to the rebuilt semantic model. What changes is the model and the data layer underneath it. Where a report depends on a measure or field that is being renamed or merged, we update it and reconcile the output before it goes live.
They should not, and we prove it. We agree which numbers count before any build, run the old and new models side by side, and reconcile the rebuilt model against today's figures. Differences are investigated and explained, not waved through.
No. Migration is sequenced by dependency and business priority. Your existing Power BI estate stays live during the parallel run, and cutover happens group by group once each set of reports is reconciled.
Not necessarily. Direct Lake suits some semantic models well and others less so. Fabric offers Import, Direct Lake and DirectQuery, and storage mode is a design decision made per model during the Design phase, based on data volume, refresh needs and query patterns.
It stays as a source for as long as you need it. Fabric lands the data you report on into a lakehouse so that transformation logic lives in one place. Retiring an existing warehouse is a separate decision we help you plan, not something the migration forces.
On-premises sources continue to connect through a gateway. What changes is that the gateway feeds the lakehouse once, on a schedule, rather than feeding every semantic model separately.
You need a Fabric capacity to build on. It can be reserved or pay-as-you-go, and sizing it is part of the Design phase. If you are already on a Fabric capacity, or a Premium renewal is forcing the decision, we factor that timing into the plan. Where appropriate, the early phases can run on a trial capacity.
Your team. Every migration is handed over with plain-English documentation, a runbook, monitoring and training, so a capable Power BI professional can operate the platform day to day. We can stay on in a support role if you want one, but you will not depend on it.
It depends on the size and state of the estate: how many semantic models, reports and sources there are, and how tangled the existing model is. The Assess phase gives you a scoped plan with sequencing and effort before any build starts, so you commit with the facts in front of you.
We work to transparent day-rate pricing with a clearly defined scope and milestones. The Assess phase is scoped first, and the migration proposal that follows sets out scope and investment before any build starts.
Tell us what your Power BI estate looks like today
A short conversation with Laz about your models, sources and what is pushing you towards Fabric. You will leave with a view on whether a migration is the right next step, and what the Assess phase would cover.