Migrating Power BI Workloads to Fabric Without Breaking Reports

Almost every Fabric migration I am asked to review starts the same way: someone in the room believes this is a lift and shift. Move the workspaces, flip on a Fabric capacity, done by Friday. It is not. Power BI reports sit on top of gateways, personal OneDrive files, refresh schedules, and security rules that nobody has stress-tested in years. Move those foundations carelessly and the reports do not just look different, they return wrong numbers or stop refreshing entirely. This guide walks through the exact sequence I follow, what breaks and why, how to triage what is worth moving, an honest read on Direct Lake, and a parallel-run protocol that lets you cut over with evidence instead of hope.

Before anything else, one caveat that governs the whole article. Microsoft ships Fabric changes on a near-continuous cadence, and licensing, SKU behaviour and Direct Lake fallback rules change more often than any static guide can keep pace with. Treat the specifics here as a snapshot, not a contract. For the mechanics of capacity sizing and licence tiers I keep a separate, regularly updated piece: Power BI licensing and capacity planning. And if you have not yet framed the wider adoption story, start with the Microsoft Fabric adoption roadmap before you touch a single workspace.

What actually breaks

I want to name the failure modes early, because they shape every decision that follows. When a Power BI estate moves to Fabric and reports go wrong, it is almost never the visuals. It is what sits underneath. Four things break far more often than anything else.

1. Gateway-dependent refreshes.

Any dataset that pulls from an on-premises source through an enterprise data gateway carries a hidden dependency. When you rehome the semantic model into a Fabric capacity, the gateway binding, the stored credentials, and the privacy levels do not always follow cleanly. A refresh that ran for years silently fails the first morning after cutover, and the report shows yesterday's data with no error on the page. You find out when a user does.

2. Excel-sourced models on someone's OneDrive.

There is always at least one. A business-critical model whose source is a spreadsheet living in an individual's personal OneDrive, refreshed under their account. When that person is on leave, or leaves the company, or the file path changes, the model dies. Migration is the moment these land mines surface, because the refresh context changes and the personal credential no longer resolves. Inventory has to hunt these down deliberately.

3. Row-level security never tested at capacity.

RLS that behaved fine for a handful of pilot users can degrade badly under real concurrency on a shared capacity, and worse, misconfigured roles can leak rows across regions or business units. Very few teams have actually tested their RLS filters at production concurrency. A migration forces the question, and it is better to answer it in a pilot than in a board pack.

4. Dataflows Gen1 that need rebuilding as Gen2.

Gen1 dataflows do not simply upgrade in place. The Gen2 model in Fabric has a different architecture, different output destinations, and different compute behaviour. Anything of substance built in Gen1 has to be rebuilt and re-tested as Gen2, not migrated. Budget real effort for this; it is one of the most consistently underestimated line items in these programmes.

The five-stage migration

I run these programmes in five stages, in order, and I resist every pressure to skip or overlap them. The discipline is the point.

Stage 1: Inventory.

Catalogue every workspace, report, semantic model, dataflow and its refresh dependencies. Capture usage metrics from the admin and usage-metrics reports: who opens what, how often, and when it last refreshed. You cannot triage what you have not counted, and the number of reports is always higher than anyone guessed. Flag every gateway source, every personal OneDrive source, and every Gen1 dataflow here, at the start.

Stage 2: Triage.

Score everything (the matrix below does this) and decide, per report, whether it migrates as-is, gets refactored, or retires. Most estates carry a long tail of reports nobody opens. Retiring them is the single fastest way to shrink the programme.

Stage 3: Capacity pilot.

Stand up a Fabric capacity and migrate a representative slice: one gateway-dependent model, one heavy DirectQuery report, one RLS-secured model, one candidate for Direct Lake. Load it, test refresh, test RLS at realistic concurrency, and watch the capacity metrics app for throttling and smoothing behaviour. This is where you learn what your specific SKU can actually carry before you commit the estate to it.

Stage 4: Wave migration.

Move the estate in waves grouped by business domain, not alphabetically and not all at once. Each wave gets its own parallel-run window (covered below) before its reports are cut over. Keep the finance domain out of the early waves deliberately; more on why at the end.

Stage 5: Decommission.

Only after a wave has run in parallel, reconciled, and cut over cleanly do you retire the old artefacts. Decommission is a stage, not an afterthought: revoke old refresh schedules, archive the retired reports, and remove the now-orphaned gateway data sources so nobody accidentally reconnects to them.

The triage matrix

Triage is where the money is saved. Score every existing report on three axes: monthly usage, business criticality, and estimated refactor cost. The scoring does not need to be precise, it needs to be consistent, so that ranking the estate produces sensible decisions. Here is the matrix I hand to clients as a starting frame.

The blunt recommendation that saves the most effort: the bottom 40 percent of reports by usage should be retired, not migrated. In almost every estate I have inventoried, roughly two in five reports are opened by nobody, or by one person who has moved on, or are stale duplicates of a report that already migrated. Migrating them costs real money and buys nothing. Publish the retirement list, give people a two-week window to object, and delete what nobody defends. A smaller estate is a faster, cheaper, safer migration, and the discipline of retiring dead content is worth doing even if you were not moving to Fabric at all.

Direct Lake, honestly

Direct Lake is the headline reason many teams move to Fabric, so it deserves a straight answer. It is genuinely fast. It reads Delta tables in OneLake directly into the engine without importing and without the per-query round trip of DirectQuery, so on well-modelled data it delivers import-like speed on data volumes that would make an import model painful. When it works, it is very good, and it is the single most compelling technical reason to be on Fabric rather than plain Power BI Premium.

The honesty comes next. Direct Lake does not always stay in Direct Lake mode. Under conditions people do not anticipate, it falls back to DirectQuery, and when it does your fast report quietly becomes a slow one that hammers the source. The fallback is triggered by things that are easy to introduce without realising: certain model features, some measure and relationship patterns, exceeding capacity guardrails on row or memory limits for the SKU, and in particular calculated columns and calculated tables, which are not supported in Direct Lake and force the model down to DirectQuery. Teams migrating import models that lean on calculated columns get caught by this constantly, because the report still works, it just no longer performs.

For the authoritative and current list, read the Direct Lake overview and the broader Microsoft Fabric documentation . I deliberately do not restate the fallback rules in full here, because a printed list goes stale faster than I can update it.

Rollback and the two-week parallel run

No wave cuts over without a rollback plan and a parallel run. This is the part that lets you migrate a finance-grade estate and keep your credibility.

The rollback plan.

Keep the old workspace intact and refreshing throughout each wave's parallel window. Do not repoint the source systems, do not revoke the old gateway data source, and do not delete anything until after cutover is confirmed. Rollback then means one thing: send users back to the old report link and turn the new one off. Because the old estate never stopped refreshing, rollback is instant and lossless. The moment you decommission early to "tidy up", you lose that safety net, which is exactly why decommission is a separate final stage.

The two-week parallel run.

Run old and new side by side for two full weeks per wave, long enough to cover a month-end boundary if the wave includes period-sensitive reports. During the window, reconcile the new model against the old one on a fixed schedule: row counts on the key fact tables and the headline measures that the business quotes. Do not eyeball the charts; compare numbers in a table and require them to match within a defined tolerance before you sign off. Here is the reconciliation frame I use.

Any non-zero variance on a financial measure blocks cutover until it is explained. Sometimes the new number is the correct one and the old report had a latent bug, that is a fine outcome, but it has to be understood and documented, never waved through. The Business Central and Power BI reporting patterns are a good example of where these variances tend to hide, because ledger-sourced measures are unforgiving of a mis-joined dimension.

Migrate the finance pack last

This is the political advice, and it is the most important sentence in the article. Migrate the finance pack last. Always.

The finance audience is the one group with both the authority and the inclination to kill your programme, and they will do it over a rounding difference. Not a wrong number, a rounding difference: a figure that is off by a currency unit because of a different aggregation order or a floating-point quirk, on a report that reconciled perfectly everywhere else. To a finance director that single cell is proof the whole platform cannot be trusted, and the migration budget evaporates in the next steering meeting. It does not matter that the operational estate moved flawlessly; nobody remembers the ninety reports that were fine, they remember the one that was a dollar out.

So you migrate finance last, deliberately, after you have proven the method on lower-stakes domains, built a track record of clean reconciliations, and tuned the parallel-run process until variances are near zero and fully explained. By the time you reach the finance pack you are not asking them to trust a new platform, you are showing them a programme that has already reconciled a dozen waves to the penny. Sequence is politics. Put the most dangerous audience at the end, when your evidence is strongest.

Conclusion

Fabric is a good destination and Direct Lake is a genuine advance, but the move rewards patience and punishes shortcuts. Inventory honestly, triage ruthlessly and retire the dead 40 percent, pilot on a real capacity, migrate in waves with a rollback net and a two-week reconciled parallel run, decommission only when a wave is proven, and keep finance for last. Do that and your reports keep telling the truth through the transition, which is the only measure of a migration that actually matters.