Tableau Migration Risk Assessment: Risks, Early Signals and Mitigations
August 11, 2026
Ten risks account for most Tableau to Power BI migration trouble: shifted totals, features with no Power BI counterpart, calculations restated plausibly but wrongly, unreachable data sources, custom SQL that slows everything downstream, redesign scope creep, parallel-run drift, ownerless content, security differences at cutover, and flat adoption afterwards. Migrations seldom break during conversion; they break on things found late, when a fix costs a schedule instead of a review cycle. The register below pairs each risk with the signal it gives before it becomes expensive.
Risk here means something checkable rather than a colored heat map. Every row names what you would already see in an inventory or a first conversion, and what removes the risk instead of documenting it. How much of the estate each risk touches is what complexity scoring measures, and this page assumes that scoring has been done.
The Tableau migration risk register
| Risk | Early signal | Mitigation |
|---|---|---|
| Totals change after conversion | Blended data sources in the inventory, or many-to-many and cross-source-group relationships in the draft model | Power BI joins limited relationships with INNER JOIN semantics, so unmatched rows drop out instead of landing in a blank row. Model the join explicitly and reconcile at a grain that exposes it. See blending to relationships |
| A feature with no counterpart surfaces late | Sets and set actions present in the feature inventory | Size the manual rebuild backlog on its own at analysis time, because this is design work rather than translation. See sets to DAX measures |
| A calculation is restated plausibly but wrongly | Nested LOD expressions, or table calculations with unusual addressing and partitioning | Review each flagged calculation with the Tableau original open, and accept on reconciled figures rather than on how the visual looks. See LOD expressions to DAX |
| A data source is unreachable from the target tenant | File-based connections, desktop-local paths and per-analyst credentials appearing in the source map | Prove one connection end to end through a data gateway with a scheduled refresh before dates are promised |
| Custom SQL slows everything downstream | Hand-written SQL connections counted in the inventory | A native query stops later Power Query steps from folding back to the source. Move the logic into a view or the model. See custom SQL to Power BI |
| Scope creep arrives as redesign requests | Owner review comments asking for new metrics, new filters or a different layout | Keep conversion like-to-like and collect every request in a backlog that opens after cutover |
| Parallel-run drift | Tableau edit timestamps later than the agreed freeze date, visible in the administrative views | Freeze per wave instead of across the whole program, and keep each parallel window short enough that the freeze holds |
| Acceptance stalls on ownerless content | Inventory rows with no named owner, or an owner who has changed role or left | Assign an owner or retire the content before conversion. Nothing can be signed off when no one holds the definition of correct |
| Security behaves differently after migration | User filters, row-level rules and data-source permissions carried inside Tableau workbooks | Map roles to row-level security during modeling and test one user per role before cutover |
| Adoption stays flat after a correct migration | Usage in the new workspaces not rising 30 days after users were moved | Staff change management and enablement as scheduled work with named owners, separately for consumers and authors |
Which risks an upfront analysis removes
Six of those ten are properties of the estate as it stands today, readable from workbook metadata before anyone opens Power BI. Blended sources, sets and set actions, nested calculation logic, custom SQL connections, unreachable data sources and content without an owner can all be counted from workbook metadata and priced into the plan, rather than arriving later as change requests against a signed budget.
That is the case for analyzing the estate before converting a pilot and extrapolating from it. A pilot tells you what one dashboard cost. An inventory tells you how many dashboards carry the features that made it cost that.
The risks analysis cannot remove
The other four are organizational and get settled by policy. Scope creep is contained by writing down that conversion is like-to-like and redesign is a separate project. Parallel-run drift is contained by a dated change freeze that dashboard owners agreed to in advance. Ownerless content is contained by declining to migrate it. Adoption is contained by staffing enablement rather than announcing it.
None of these cost anything to decide and all of them cost a great deal to retrofit, which is why they belong in the plan document rather than the risk log. The planning guide treats them as decisions to lock before conversion starts. Across several business units and hundreds of report consumers they change shape again, and enterprise migration strategy covers what scale does to them.
How to keep the register useful
Keep it short and dated. Forty rows produce a document nobody reads, while ten rows with a named owner and a review date stay a working artifact. Revisit it at the end of every wave, because a risk that failed to materialize in the simple wave may still be waiting inside the complex one.
Tie closure to evidence. Row one closes when the agreed measures reconcile at the agreed grain and somebody signs, not when a report page looks right, which is the same standard behind Microsoft treating creating and validating content as one stage. The migration checklist holds the task-level form of that discipline, with an exit criterion on every line.
What Antares does about migration risk
The first two columns of this register are what the Analyzer produces against a real estate. It is free, behaves deterministically and reads metadata alone, so the feature and source inventory behind every early signal comes back without data leaving your environment. Mappings that cannot be resolved with confidence are flagged rather than guessed, which is the behavior a register needs: a known unknown sitting in a backlog is cheaper than a silent substitution found during validation.
Antares is a BI migration tool. Each source Tableau dashboard converts into a Power BI report page for a flat $200, with nothing billed per user and no expiry, and the LLM work goes to whichever provider you already use at typically under $20 per converted dashboard, private endpoints supported. Conversion runs deterministic-first with guardrailed, validated AI steps and stays like-to-like, so the redesign row above is handled by scope discipline rather than by software. Run the free Analyzer to fill in the signal column for your own workbooks.
Related reading: the Tableau to Power BI migration guide, dashboard complexity scoring, table calculations to DAX and the Analyzer. Primary sources: Microsoft on many-to-many relationships, plus Tableau's table calculation reference.
← Back to Complete Migration Guide
Related Migration Resources
Frequently asked questions
What are the main risks in a Tableau to Power BI migration?
Ten recur: totals shifting after conversion, features with no Power BI counterpart found late, a calculation restated plausibly but wrongly, unreachable data sources, custom SQL slowing refreshes, redesign requests expanding scope, parallel-run drift, ownerless content blocking sign-off, security differences at cutover, and flat adoption afterwards.
Why do numbers change after a Tableau dashboard is converted?
Usually because a blend became a relationship. Power BI resolves limited relationships with INNER JOIN semantics, so rows without a match on both sides drop out rather than showing as blanks. Reconcile the affected measures at a grain that makes the missing rows visible.
Which migration risks can be identified before conversion starts?
The ones that are properties of the workbooks themselves: blended sources, sets and set actions, nested calculation logic, custom SQL connections, sources unreachable from the target tenant, and content with no named owner. All are readable from metadata and can be priced into the plan.
How do you stop scope creep during a migration?
Write the rule down before review starts: conversion is like-to-like, and any redesign is a separate project with its own budget. Requests raised during owner review go into a backlog that opens after cutover. Without that rule, every review cycle reopens the specification.