Tableau to Microsoft Fabric: Migrate the Model, Not the Workbooks

A Tableau to Power BI migration plan built on workbook counts prices the wrong work. Here is what breaks in delivery and why the semantic model comes first.

Most Tableau to Power BI migration plans start the same way. Someone exports a list of workbooks, maps the calculated fields to DAX, puts a team on it and sets a date. The plan looks fine on paper, but it rests on a count that is wrong from the start.

The inventory is not the estate

A Tableau site that has run for years holds three kinds of content, and only one of them deserves a migration budget.

First are the dashboards the business actually runs on. Then there are the copies of those dashboards, made by an analyst who needed one filter changed and never merged the change back. Last come the workbooks nobody has opened in a year, which stay because nobody has the authority to delete them.

A plan built on the raw workbook count treats all three the same. It prices the dead content, converts it, tests it and trains people on it. Then usage after cutover shows that much of it was never opened again.

So the first job of discovery is not scoping the conversion. It is deciding what not to move. Tableau already records who opened what and when, through its admin views on Server and Admin Insights on Tableau Cloud. That history answers most of the question before anyone opens a single workbook. The rest is a conversation with named owners, and their sign-off on what gets retired goes into the plan.

What actually breaks in delivery

Converting the charts is the easy part. The trouble tends to come from four places that a workbook count never shows.

Logic hiding in extracts. Tableau data sources often carry joins, filters and aggregations defined inside the workbook, not in the warehouse. When the report is rebuilt on Fabric, that logic has to live somewhere. If nobody wrote it down, the rebuilt numbers quietly differ from the old ones, and nobody can explain why.

Calculations that translate but don't behave the same. Level-of-detail expressions and table calculations do have Power BI equivalents. They just don't respond to filters in quite the same way. A FIXED expression ignores most view filters. Its DAX version has to reproduce that on purpose. A literal translation can match on the default view and then drift the first time a user slices by region.

A data model in every workbook. In Tableau, each workbook often owns its own data source. Fifty workbooks can mean fifty slightly different definitions of revenue. A one-to-one migration carries all of that sprawl into Power BI, where it becomes fifty semantic models to maintain.

Security built into the report. Tableau row-level filtering often lives in user filters or calculated fields inside the workbook. In Power BI and Fabric it belongs in the semantic model's roles and in the workspace permissions around it. Teams that convert visuals first and security last find the gap in user acceptance testing, or later still.

The approach: model first, visuals last

The plan that holds up reverses the order most teams default to.

Rationalize before you estimate. Usage history sorts every workbook into retire, consolidate or migrate. Owners sign off on the retirements. The estimate is built on what is left.

Consolidate the semantics. Before any report gets rebuilt, the definitions scattered across workbook data sources are pulled into a small number of shared semantic models on Fabric. The extract logic moves upstream into the lakehouse or warehouse, where it can be tested and reused. Microsoft's own Analytics on Azure blog makes the same case in its piece on Tableau to Power BI migration, arguing for a semantic-layer-first approach over report-by-report conversion.

Translate with a test harness, not by eye. Our accelerators take care of the mechanical translation from Tableau's calculation language to DAX and Power Query M. Translation is necessary, but it isn't enough. Every migrated measure is checked against Tableau's output at several levels of detail and across several filter combinations, not just on the view someone happened to open.

Rebuild visuals and security together, then run in parallel. Reports are rebuilt on top of the shared models with row-level security in place from day one. Both platforms run side by side for a set period. Named business owners sign off on matching numbers before Tableau is switched off.

What it costs to get it wrong

The first cost is paying twice. You pay to migrate dead content, and then you pay again to clean it up in Power BI.

The second is time. If the business won't sign off on numbers that don't match, both platforms stay licensed for as long as the argument lasts. Tableau often ends up kept alive "just in case" long after the go-live date.

The third cost is trust. The first time an executive sees two versions of revenue, the new platform gets the blame, whatever the real cause. Adoption stalls, and people go back to exporting to Excel.

There is also a cost that didn't exist a few years ago. On Fabric, semantic models are what Copilot and data agents read when they answer a business question. We have written before about why the semantic layer matters for AI. If you carry fifty definitions of revenue into Fabric, every AI tool you build on top of it inherits the same ambiguity. A migration done workbook by workbook doesn't just copy the old estate. It becomes the base your AI program sits on.

That is why our migration assessment starts with one question: what should you not move? Answering it honestly is most of the work, and it is what makes the rest of the plan trustworthy.