Why Tableau Migrations Fail (And It's Not the Tools)

Here's how most Tableau-to-Power BI migrations start: someone pulls a list of workbooks from Tableau Server, estimates three months, and kicks off a project.

Here's how most of them end: six months later, half the dashboards are rebuilt, the other half are "in progress," and someone is explaining to leadership why the budget doubled.

The problem isn't the tools. It's that nobody mapped the minefield before walking into it.

"We have 47 workbooks to migrate"

This sentence has killed more migration timelines than anything else. Counting workbooks tells you nothing about what's inside them.

One "simple" workbook might have:

• LOD expressions that don't have a clean DAX equivalent
• Custom SQL baked into the data connection with business logic that nobody documented
• Data blending across three sources with join conditions that one person understood (and they left last year)
• Table calcs doing time-series math that breaks if you rearrange the sort order
• Dashboard actions chaining five views together into a workflow users depend on daily

You don't know this from a workbook list. You find out three weeks into conversion, when everything breaks.

The "one dashboard" that's actually five projects

Picture a typical exec dashboard. Regional sales, YoY comparison, interactive date filter, LOD calc for customer acquisition by territory, custom SQL for pipeline data, drill-through to detailed reports.

Looks like one dashboard. It's actually:

• A data model redesign (Power BI's relationship engine works differently than Tableau's)
• DAX development to replicate the LOD logic (and no, CALCULATE + REMOVEFILTERS isn't always enough)
• Parameter rework using slicers or what-if params instead of Tableau parameters
• SQL tuning for DirectQuery performance (Tableau extracts hide a lot of query sins)
• Interaction rebuild using Power BI drillthrough instead of Tableau actions

Each layer multiplies the effort. A workbook with all five? That's not a conversion task. That's a rebuild.

The dependencies nobody sees

The ugliest migration risks aren't in individual workbooks. They're in the connections between them.

Calc chains. A calculated field references three other calcs, each built on logic someone developed over two years. Touch one, and you're validating the entire chain.

Shared data sources. Workbooks that look independent share extract schedules, prep logic, or assumptions about data quality. Migrate them one at a time and those shared assumptions break silently.

User workflows. Dashboard A's output feeds into Dashboard B through exported data or saved filters. Your users have built their Monday morning routine around this. They won't tell you — they'll just complain when it stops working.

Timing assumptions. Calcs that depend on specific refresh timing, fiscal calendars, or timezone handling. These work by accident in Tableau and fail by default in Power BI.

"While we're at it, let's redesign the dashboards"

Don't.

Seriously. This is the sentence that turns a six-month migration into a twelve-month one.

Yes, you'll see things worth improving. Note them down, file them for later. But mixing migration with redesign means:

• You can't validate accuracy (did the number change because of migration or your "improvement"?)
• Testing scope explodes
• Users can't tell if problems are bugs or features
• Nobody knows what "done" looks like anymore

Migrate first. Improve later. Boring advice. Also correct.

What actually works

The teams that pull off migrations without a crisis share one habit: they spend real time understanding what they have before they touch anything.

That means:

1. Inventory at the feature level — not "47 workbooks" but "12 with complex LODs, 8 with custom SQL, 23 that are basically flat tables"
2. Score complexity honestly — a workbook with 3 LODs and data blending is a different conversation than one with a bar chart on a simple extract
3. Map dependencies — which workbooks share data sources? Which feed into each other?
4. Check usage — how many of those 47 workbooks did someone actually open in the last 90 days? (Spoiler: fewer than you think. We consistently see 30-40% of Tableau estates are ghost dashboards nobody uses.)
5. Phase it — start with simple stuff to build team muscle, then tackle the complex workbooks with proven processes

Tools are the easy part

There are plenty of migration tools out there. Some are decent at converting standard visualizations and basic calcs. None of them handle complex LOD-to-DAX conversion well, because that's fundamentally a semantic problem — you need to understand the intent behind the calculation, not just the syntax.

Tools work best when you know what to point them at. Which means the real work happens before you open any migration tool at all.

The five questions

Before your next migration planning meeting, make sure you can answer these:

1. What's the actual complexity of your Tableau environment — not workbook count, but feature-level difficulty?
2. Which workbooks need full rebuilds vs. straight conversion?
3. How will you verify the numbers match after conversion?
4. How many of your workbooks are even worth migrating?
5. What breaks if you migrate workbooks out of order?

If you can't answer those confidently, you're not ready to start converting. You're ready to start analyzing.

Want to answer those questions with data instead of guesswork? Run a free Antares analysis on your Tableau environment — you'll see complexity scores, usage data, and a prioritized migration plan before you commit to anything.