Power BI to Microsoft Fabric migration services
Microsoft is retiring the Power BI Premium per-capacity SKUs, which turns a licensing change into a dated project. Senior US-based engineers baseline what your current capacity actually consumes, size and provision the right Fabric F SKU in Azure, reassign every workspace, validate reports, refreshes and gateways against the old environment, and hand back a written decommission checklist. One written price, typical delivery in 2–4 weeks, 30 days of hypercare included.
Representative dashboard — sample data
What you get
Reassigning workspaces is the easy hour. Sizing the capacity, proving the reports still reconcile, and actually closing the old subscription are the parts that decide whether this lands.
We install the capacity metrics app, take a fourteen-day baseline of capacity-unit consumption across your workspaces, and choose the SKU from that evidence instead of matching whatever you bought years ago.
The Fabric capacity is created under your own tenant and billing account, in the region you choose, with resource tags applied so the spend lands in the right cost center from day one.
A pilot workspace moves first and gets checked properly. The rest follow in waves scheduled around refresh windows, so an overnight load is never interrupted mid-run by a reassignment.
Every scheduled refresh, gateway connection, deployment pipeline, and workspace app is exercised on the new capacity and compared against the old one before anybody signs anything off.
Budgets and alerts on the capacity resource, pause and resume schedules where a capacity is genuinely idle, and the surge and overage protections that keep one runaway workload from swallowing the whole pool.
A written record of what moved, what still points at the old capacity, which settings had to be reapplied, and the manual steps needed to cancel the retiring subscription on a date you choose.
How it works
A free consultation, a workspace inventory, and a fourteen-day consumption baseline tell us which SKU you need and whether the region stays the same. You get a written scope, one fixed price, and a delivery date.
Capacity is created in your Azure subscription, a pilot workspace moves and is validated, then the remaining workspaces follow in waves scheduled around your refresh windows and month-end.
We watch consumption on the new capacity through a stabilization window, tune governance settings, then hand over the decommission checklist and 30 days of hypercare.
This is not an optional modernization. Microsoft's own Power BI Premium to Microsoft Fabric migration overview (opens in new tab) states that the Premium per-capacity P SKUs are being retired, that new P SKUs are no longer sold, and that each subscription ends at the end of its current agreement term. It also spells out what happens if you miss the date: the capacity enters a 30-day grace period, interactive operations are throttled from day 31, and from day 91 all operations are rejected — your data is retained but unreachable until the workspaces are moved to a Fabric capacity or the capacity is deleted. Customers with an active Enterprise Agreement can generally keep renewing existing P capacity until the EA term ends, which is worth confirming with your Microsoft account contact before you pick a date.
Two things are explicitly out of scope of the retirement, and both save a lot of unnecessary worry: per-user Power BI Pro and Premium Per User licenses continue unchanged, and the EM and A embedded SKUs are not part of it. If your question is which per-user licenses to buy rather than which capacity to move to, our guide to Power BI licensing for small business is the page you want — it compares Pro, Premium Per User, and capacity for a team that is choosing. This page is for an estate that already exists and has to move.
The most expensive mistake here is guessing the SKU. Fabric capacity is measured in capacity units, and the SKU table maps them onto the Premium sizes you already know — F64 carries the same compute as P1, F128 as P2, F256 as P3 — but a like-for-like swap is a starting hypothesis, not an answer. The Microsoft Fabric Capacity Metrics app (opens in new tab) gives a fourteen-day view of what your workspaces genuinely consume, including the throttling events nobody reported, and Microsoft's capacity planning guidance (opens in new tab) sets out how to read that baseline against a SKU. Where the picture is unclear, a 60-day trial capacity lets us run the workloads that worry you before any money is committed.
One threshold drives most of the decision. On F64 or larger, users holding only a Fabric free license and a Viewer role can read Power BI content, exactly as they could on Premium. On the smaller SKUs — F2 through F32 — every person viewing that content needs a Pro or Premium Per User license, so a capacity that looks cheaper can quietly cost more once you count the viewers. The Fabric licensing documentation (opens in new tab) holds the current rules, and Microsoft publishes the rates on its Fabric pricing page (opens in new tab); we do not quote capacity prices, because they are regional and Microsoft's to set. What we quote is the fixed fee for the migration work itself. If you are still building the budget case rather than the project, our article on Microsoft Fabric licensing cost works through the published CU-hour rate, reserved against pay-as-you-go, and what the F64 viewer rule is actually worth against Pro seats.
Most of the estate carries across untouched. The table below separates the parts that genuinely change from the parts that only feel risky, and it is the checklist we validate against during cutover.
| Area | Changes? | What it means on the new capacity |
|---|---|---|
| Reports, semantic models, dashboards | No | Continue working as they are; nothing is rebuilt, re-authored, or re-pointed as part of the licensing move |
| Pro, Premium Per User, and free licenses | No | Unchanged. On F64 and above, free-license viewers still read content; on F2–F32 each viewer needs Pro or PPU |
| Workspaces, apps, pipelines, Git integration | No | Workspaces are reassigned to the new capacity; deployment pipelines, workspace apps, and Git connections keep working |
| Scheduled refreshes and data pipelines | No | They run on the new capacity on the same schedule; a refresh in flight during reassignment can be interrupted, so waves are timed around them |
| Purchasing and billing | Yes | Moves from a Microsoft 365 commitment to Azure billing — pay-as-you-go by default, with yearly or multiyear reservations available |
| Capacity administration | Yes | Workspace assignment and capacity settings stay in the Fabric portal; pause, resume, and resize move to the Azure portal under Azure role-based access control |
| Autoscale | Yes | Premium-style autoscale does not exist on F SKUs. You resize on demand instead, which is why the baseline and the alerting matter |
| Cost governance | New | Workspace-level surge protection and capacity overage protection become available, along with Azure budgets, tags, and cost reporting |
Complexity is decided almost entirely by two questions: does the tenant change, and does the Azure region change. Everything else is scheduling. We establish which row you are in during scoping, because the difference between the first row and the last is the difference between a fortnight and a rebuild.
| Scenario | Complexity | What it adds to the work |
|---|---|---|
| Same tenant, same region | Low | The recommended default. Workspaces are reassigned to the new capacity with no expected downtime beyond refreshes running at that moment |
| Same tenant, different region | Moderate to high | Large-storage-format semantic models must be backed up and restored or converted first; Fabric items such as lakehouses, warehouses, and notebooks have to be captured and recreated, and reports rebound to the new model IDs |
| Multiple regions, one tenant | Moderate | A capacity is purchased per target region and content governance is planned per region, but each individual move follows the standard steps |
| Across tenants | High | Not a reassignment at all. Workspaces, gateways, semantic models, reports, apps, and dashboards are recreated by hand; we scope this separately and say so plainly |
Cross-region moves are chosen, not stumbled into — data residency is usually the only reason worth the extra work. If yours is driven by where the underlying data platform lives rather than by the reporting layer, that conversation belongs with our Azure migration and cost optimization consulting, since the capacity, the region, and the bill all sit in the same Azure subscription.
Fabric capacity is an Azure resource billed per second, which changes how you manage it. Microsoft's guidance is candid that pay-as-you-go rates typically run higher than the equivalent Premium SKU if you simply leave a capacity running around the clock, so the savings come from the levers Premium never had. Reservations discount steady, predictable workloads. Pause and resume (opens in new tab) stops billing on a capacity that is genuinely idle overnight or at weekends — with the important caveat that content on a paused capacity is unavailable, so we only schedule it where nobody is looking. Budgets, alerts, and tags on the capacity resource make the spend visible to whoever owns it.
We track daily spend with you through the first weeks and compare consumption against the baseline captured before the move. Where a capacity looks overloaded afterwards, the usual cause is a change in workload — a new refresh schedule, a batch of new content — rather than the migration itself, and that is worth establishing before anyone scales up and pays for it.
Landing on Fabric opens doors that were previously shut: mirroring and shortcuts to bring existing data into OneLake, unified OneLake security, and Direct Lake storage mode (opens in new tab), which queries Delta tables in OneLake with import-mode performance and a refresh that updates metadata rather than copying data. All of it is genuinely useful. None of it belongs inside a migration with a subscription deadline attached, and Microsoft's own guidance treats these as optional follow-ups that should not extend the timeline.
So we keep them separate on purpose. The migration gets your estate onto supported capacity by a date. Anything you then want built on top — a Direct Lake model, a lakehouse layer, new reporting for a team that has been waiting — is scoped afterwards as its own fixed-fee piece of work, which is what our fixed-fee Power BI dashboard development service exists for. If you are also carrying an older reporting estate alongside Power BI, our SSRS to Power BI migration service handles that consolidation on the same terms, and if a QlikView estate is still reloading alongside your Power BI content, our QlikView to Power BI migration service brings those documents onto the same semantic model before capacity has to carry both. And if what feeds those reports is a set of Alteryx Designer workflows running on somebody's desktop, that is a conversion project rather than a capacity move: our Alteryx to Microsoft Fabric migration services rebuild those workflows as Fabric dataflows and pipelines and reconcile the output against the originals.
It fits organizations already running Power BI at capacity scale who have received a renewal notice, an end-of-term date, or an internal question nobody can answer about what happens next. It also fits teams on per-user licensing who have decided capacity is now the right shape and want it provisioned and governed properly rather than clicked into existence. It is sized as a single fixed-fee project with a stated end date, not a rolling program.
Everything produced is yours from the first day. The capacity lives in your Azure subscription, the workspaces in your tenant, the documentation in your hands. If you want the reasoning behind the fixed-fee model before you talk to anyone, how our process works covers scoping, delivery, and what happens after handover.
The table shows scope and typical timeline rather than prices, because an honest number needs your workspace inventory and consumption baseline first. Fabric capacity itself is billed to you by Microsoft through Azure and never through us.
| Phase | Scope | Typical timeline | Fee |
|---|---|---|---|
| Phase 1 — baseline and decision | Workspace and item inventory, capacity metrics app installed, fourteen-day consumption baseline, SKU and region decision, licensing implications documented, and the Azure resource provider registered | About the first week | Fixed fee — scoped after your free consultation |
| Phase 2 — provision, move, validate | Capacity provisioned in your Azure subscription with tags and role assignments, pilot workspace moved and checked, remaining workspaces reassigned in waves, then refreshes, gateways, pipelines, and apps validated against the old capacity | Weeks 2–3 | Fixed fee — scoped after your free consultation |
| Phase 3 — stabilize and decommission | Consumption monitored against the baseline, capacity workload settings and surge protection reapplied, budgets and alerts configured, pause schedules set where useful, and the written decommission checklist handed over for the retiring subscription | Week 4 and close-out | Fixed fee — scoped after your free consultation |
Related services
Fixed-fee development for the reporting you want built once your estate has landed on Fabric capacity.
Migration and cost optimization for the Azure subscription your Fabric capacity and data platform now sit in.
Retire a report server alongside the capacity move, with paginated reports and subscriptions rebuilt properly.
Pro vs Premium Per User vs Fabric capacity, explained for a team that is still choosing.
How scope drives the number, so a written fixed fee is something you can sanity-check.
What to ask, what to check, and the answers that should make you walk away.
FAQ
Microsoft is retiring the Power BI Premium per-capacity P SKUs and no longer sells new ones, so each subscription ends with its agreement term. Enterprise Agreement customers can usually renew existing capacity until the EA ends. Per-user Pro and Premium Per User licenses are not affected by the retirement.
No. Reports, semantic models, dashboards, workspace apps, deployment pipelines, and Git integration all keep working after workspaces are reassigned. A same-region, same-tenant move has no expected downtime beyond refreshes that happen to be running at the moment of reassignment, which we schedule around.
We size it from evidence, not guesswork. The Microsoft Fabric Capacity Metrics app gives a fourteen-day baseline of your current capacity-unit consumption, and a trial capacity lets us test the workloads that worry you. F64 matches P1 on compute and is the point where free-licensed viewers can read Power BI content.
That depends on capacity size. On F64 or larger, users with a Fabric free license and the Viewer role read content exactly as they did on Premium. On F2 through F32, every viewer needs Pro or Premium Per User, which is why the SKU decision and the licensing decision have to be made together.
It does not. Cancelling a P SKU is a manual step in the Microsoft 365 admin center, and nothing in Fabric does it for you. We keep both running through a stabilization window, validate refreshes and reports on the new capacity, then hand you a written decommission checklist.
Typical delivery is two to four weeks from kickoff, with dates in your written scope. The fee is fixed and reflects how many workspaces move, whether the target region changes, and how much cost governance you want configured afterwards. Fabric capacity itself is billed by Microsoft through Azure, not by us.
Book a free consultation
Tell us what you’re trying to fix — a report, an approval process, an intranet, a Copilot rollout. We scope it as a fixed-fee project, you approve, and a senior engineer delivers in 2–4 weeks.
The fastest way to reach us is the form — tell us the task and we’ll reply within one business day.