Migrate to Fabric on your terms, not in a scramble

There is no market-wide deadline, and anyone selling you one is selling you a scare. Microsoft's own position is that no immediate action is required and that you convert your Power BI Premium capacity at your next renewal. Two things are true regardless: the legacy Export to Data Lake pipe for finance and operations apps has been retired, and P SKUs can no longer be bought, only renewed. So the forcing function is your renewal date, not an industry cliff.

Most of what has been written about a Fabric deadline does not survive contact with Microsoft's documentation. We are not going to build a case on a date that is not there. The case is better than that, and it holds up in front of a technical buyer.

The pipe has gone. Export to Data Lake for finance and operations apps was deprecated and its decommissioning has been under way for some time. It is not coming back. Its supported successors are Azure Synapse Link for Dataverse and Link to Microsoft Fabric. If anything in your estate still depends on that legacy export, it is running on borrowed time, and every report standing on it is exposed.

The licence has changed shape. P SKUs are no longer available for purchase. They can only be renewed, and the Power BI Premium SKUs are being retired. To keep the Premium capabilities you rely on, you move to an F SKU. Microsoft is explicit that you can carry on using your existing Premium capacity until your next renewal. That is the moment the decision becomes real for you, and it will be a different moment for you than for anyone else.

The consequence of drifting into it. If a Premium subscription simply lapses, there is a grace window of full access to get the move done, after which content reverts to shared capacity. Large semantic models and Premium-rendered reports stop working. That is not a cliff imposed on the market. It is a self-inflicted one, and it is entirely avoidable with a plan.

Because the levers that control Fabric cost only exist on F SKUs. Pause and resume, on-demand resizing and Spark autoscale billing are F-only capabilities and are not available on P. Until you are on an F SKU, you are paying for capacity you cannot switch off overnight, cannot resize on the day you need to, and cannot bill elastically when a workload spikes.

This is the part the Finance Director should read. Fabric is sold as software but it bills like infrastructure. Capacity is a unit of compute you rent, and everything on the tenant draws from it. One badly written Direct Lake query, or one oversized Spark cluster someone spun up on a Friday, can throttle the whole tenant and eat a month of budget over a weekend. The organisations that get burned are not the ones who chose wrong. They are the ones who left the capacity unpoliced.

Which is why the SKU matters more than it looks. The cost-control features are not evenly distributed.

• Pause and resume. Available on F SKUs, not on P. Batch and development capacity can be switched off when nobody is using it, instead of billing around the clock.
• On-demand resizing. F only. Size the capacity to the workload as it changes, rather than buying for the annual peak and paying for it every day of the year.
• Spark autoscale billing. F only. Spark workloads bill for what they consume rather than drawing against a fixed reservation, so a heavy engineering job stops competing with reporting for the same headroom.
• The F64 threshold. At F64 and above, users can consume Power BI content on a free licence. Below it, every viewer needs a Pro licence. That single line moves the sizing decision from a technical question to a licence-count question, and it changes the answer for most organisations.
• Network and key controls. Trusted workspace access, managed private endpoints, customer-managed keys and workspace-level private links are F-only. If your security posture needs them, the SKU decision is already made for you.
• Guardrails, not hope. None of the above helps if nobody is watching the burn. Capacity alerts, throttling thresholds and a pause schedule are configuration, and they have to be somebody's job.

We do not publish capacity prices, because a number on a web page is worth nothing to you. What we do is model your burn against your own workloads and your own user count, and show you the running cost before you commit to anything. You are not paying us to build pipelines. You are paying us to police the capacity.

Both are supported, and neither is going away. Link to Fabric is no-copy and no-ETL, and your data stays inside the Dataverse governance boundary, but every non-system table with Track changes enabled is selected automatically, you cannot cherry-pick, and it consumes additional Dataverse storage. Azure Synapse Link exports continuously to your own storage account, where you choose the tables and you own the pipeline. The right answer depends on who you want to own the plumbing, and on where you want the data to live.

This is the decision that gets made badly, usually because someone assumed there was only one option left.

The correction, stated plainly. Azure Synapse Link is not being retired. Microsoft has been explicit that customers who want to keep exporting data and building their own integration pipelines will be able to do so well into the future, and the two paths are presented as complementary rather than as a succession. Anyone telling you Synapse is dead is either out of date or selling something. What has been retired is Export to Data Lake, and that distinction is the difference between a migration you plan and a migration you panic through.

Where a pre-built, pre-reconciled extraction foundation fits the job better than a bespoke pipeline, Reveal is our productised option, which reduces implementation time and risk.

A migration runs as a phased delivery anchored on your renewal date: capacity and licence assessment, the data-path decision, an estate and dependency map, the migration build, a reconciled parallel run, then cutover with the cost guardrails switched on. Nothing legacy is switched off until the new numbers have been reconciled against the old ones, figure by figure.

The shape below is deliberately unglamorous. A migration is a risk-management exercise dressed as a technology project, and the sequence is what keeps it that way.

1. Capacity and licence assessment

   We start from your renewal date and your current capacity, size the F SKU against what your workloads actually consume rather than against the badge you happen to hold, and settle the F64 question against your real viewer count. This is where the economics are decided, and it is done before anything is built.

2. The data-path decision

   Link to Fabric or Azure Synapse Link, decided on governance posture, storage ownership and who is going to run the pipeline once we have gone. Written down with the reasons, so it survives an audit and a change of personnel.

3. Estate and dependency map

   What still runs on the legacy pipe, which reports and semantic models depend on it, what breaks on the day it goes, and in what order things have to move. Most of the risk in a migration lives in this document, not in the build.

4. The migration build

   We land the data on the chosen path, build the transformation layer the link does not give you, and handle the Finance and Operations schema realities, so the raw layer ingests clean rather than merely looking clean.

5. Parallel run and reconciliation

   Old and new run side by side and we reconcile to the finance source, figure by figure, until the new estate produces the same numbers as the estate you already trust. Only then does anything get decommissioned.

6. Cutover and cost guardrails

   The legacy pipe is retired, and the capacity goes live with alerts, throttling thresholds, pause and resume schedules and workspace guardrails already configured, so the first invoice contains no surprises.

Where speed matters and the scope is tight, a fixed-scope migration pack sits beside the full programme. Either way, the cost is scoped and shown to you before you commit to it.

A Fabric migration delivers an F SKU sized to your real workload, a supported Dynamics data path chosen and documented, the transformation layer that the link does not provide, a parallel run reconciled to your finance source, the legacy pipe decommissioned, and cost guardrails live from day one.

Here is the whole of it, so there is no question about what lands and what does not.

• An F SKU sized to your workload. Sized against what your workloads actually consume and against your viewer count, with the F64 licence threshold weighed openly rather than assumed either way.
• A supported Dynamics data path, chosen and documented. Link to Fabric or Azure Synapse Link, selected on your governance posture and pipeline ownership, with the reasoning written down.
• The transformation layer the link does not give you. Financial dimensions, RecId relationships, enum decoding and the soft-delete filter, built once, so the numbers above them hold.
• A parallel run, reconciled figure by figure. The new estate proves it agrees with the old one before the old one is switched off. No leap of faith, and no month-end spent finding out.
• The legacy pipe decommissioned. Export to Data Lake dependencies identified, migrated and retired, so nothing in your estate is standing on a pipe that has already gone.
• Cost guardrails from day one. Capacity alerts, throttling thresholds, pause and resume schedules and workspace guardrails configured before go-live, not after the first surprising invoice.

The migration is the door. The readiness assessment can come before it, so you decide on evidence rather than pressure. The implementation build comes after it, once you are on the platform. The managed platform runs it, and governance sits across all of it. You take each rung on the evidence, with no obligation to take the next.

1. Diagnose first.

   If you do not yet know what your estate would cost to run on Fabric, or what still depends on the legacy pipe, start with the Fabric readiness assessment, which produces the evidence this migration is scoped from.

2. Migrate.

   This page. Off the retired pipe, onto a supported data path, onto capacity you can control, with the numbers reconciled before anything is switched off.

3. Then build.

   With the platform in place, Fabric architecture and implementation extends it into the workloads you actually wanted, rather than a lift-and-shift of what you already had.

4. Then run it.

   If you would rather not police the capacity yourself, the managed Fabric platform takes the run-state, the FinOps and the guardrails. It is a choice, never a dependency we design in.

Governance runs across all four rungs, not after them. Fabric governance and security is where OneLake permissions, row-level and column-level security and the access model are done properly, and it is where a naive rollout quietly fails.

The boundary. Fabric is the platform. The data warehouse is the reconciled model layer that sits on it, where the financial-dimension, elimination and multi-entity logic is encoded once. Power BI is the reporting on top of that layer. Three cleanly separated things, one team, and this page is responsible only for the platform underneath them both.