# How to Migrate Tableau to Power BI: A Step-by-Step Guide for 2026

> How to migrate Tableau to Power BI in seven steps: what converts cleanly, what needs rework, what drives effort and cost, and how to validate the result.

- Canonical: https://getantares.io/tableau-to-power-bi-migration/
- Published: 2026-02-18
- Updated: 2026-09-30

---

A Tableau to Power BI migration runs in seven steps: inventory and prune the estate, score and sequence what remains, map the data sources into a shared model, convert the calculations, rebuild the report pages, reconcile the numbers, and cut over. On the reference figures this library uses, that is two to six weeks for ten dashboards and four to nine months for two hundred, and conversion is the shortest of the seven steps: the shared model and the validation take the calendar, and the first step sets the budget for the rest.

This guide is about moving dashboards, not about connecting Tableau to a Power BI dataset. It walks the seven steps in order: what each one produces, what converts cleanly, what has to be rebuilt, and where projects stall. Microsoft's [Power BI migration series](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-overview) covers the same ground from the tenant side in five stages (gather requirements, plan deployment, proof of concept, create and validate, deploy); the steps below are that sequence as it looks from a Tableau estate.

## The seven steps of a Tableau to Power BI migration

| Step | What it produces | Where it usually goes wrong |
| --- | --- | --- |
| 1. Inventory and prune | Every dashboard with its usage and owner, and the shorter list that will move | Counting workbooks instead of dashboards; migrating what nobody opens |
| 2. Score and sequence | A complexity score per dashboard, waves, a change‑freeze policy | Estimating from the dashboards the team knows best |
| 3. Map sources, build the model | Shared semantic models with relationships in place of blends | One private data set per report |
| 4. Convert calculations | DAX measures, with the ambiguous ones flagged for a decision | Translating syntax word for word and trusting the total |
| 5. Rebuild report pages | One report page per dashboard, interactions rebuilt from Power BI parts | Redesigning while converting |
| 6. Validate the numbers | Agreed measures reconciled at an agreed grain, differences explained | Eyeballing layouts instead of reconciling totals |
| 7. Cut over | A parallel window, endorsed reports, a read‑only date for Tableau | Publishing without a named owner per report |

## Step 1: Inventory the Tableau estate and prune it

Count dashboards, not workbooks. The dashboard is the thing a person opens and the thing a conversion produces; a workbook holding six of them is six units of work. Tableau's [administrative views](https://help.tableau.com/current/server/en-us/adminview.htm) on Server and Cloud report traffic to views, stale content and actions by user, and the [Metadata API](https://help.tableau.com/current/api/metadata_api/en-us/index.html) adds workbooks, data sources and lineage. Cross the two and every row carries three facts: how often it is opened, what it depends on, and who owns it.

The list is always longer than anyone expected, and not because teams are careless: estates grow for years. Declining to migrate a dashboard nobody has opened in two quarters is the only saving in the project that costs no engineering (two quarters, not one, so that quarter‑end packs survive the cut), and Microsoft's requirements stage makes the same point from the other side: a direct one‑to‑one migration without any refactoring or enhancement is rare. The output is a shortlist with an owner's name on each row. The task‑by‑task version is the [migration checklist](/tableau-migration-checklist/), and the [Tableau Server](/tableau-server-to-power-bi-migration/) and [Tableau Cloud](/tableau-online-to-power-bi-migration/) pages cover what differs by source.

## Step 2: Score what remains and sequence it into waves

Two dashboards with identical charts can be several times apart in effort. The difference is the feature mix: [LOD expressions](https://help.tableau.com/current/pro/desktop/en-us/calculations_calculatedfields_lod.htm), table calculations, sets, custom SQL, blends and extensions. Score on those rather than on visual count and the estimate holds up once the work starts; the scoring model, and why the old finance dashboards tend to score highest, is on [dashboard complexity analysis](/tableau-dashboard-complexity-analysis/).

Sequence so the team learns before it commits: a first wave of simple dashboards that settles workspace layout, naming and refresh; a second wave of the high‑visibility ones once the pattern is proven; the complex remainder last. Microsoft's [proof of concept stage](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-proof-of-concept) belongs between the first two waves, on the ugliest common pattern rather than the prettiest dashboard. Announce a short change freeze on the Tableau side for each wave, and stand up workspaces and [deployment pipelines](https://learn.microsoft.com/en-us/fabric/cicd/deployment-pipelines/intro-to-deployment-pipelines) before wave one. The decisions a plan has to lock at this point are on the [migration planning guide](/tableau-migration-planning-guide/), and the calendar by estate size is on [how long a migration takes](/how-long-does-tableau-to-power-bi-migration-take/).

## Step 3: Map the data sources and build the shared model first

The table maps each Tableau concept to where it lands in Power BI. Two rows change numbers rather than just locations: blends and custom SQL. Three rows are easy to forget on a Tableau Server estate: the gateway, the groups and the Prep flows.

| Tableau | Power BI | Note |
| --- | --- | --- |
| [Published data source](https://help.tableau.com/current/pro/desktop/en-us/publish_datasources.htm) | Shared semantic model | One model, many reports ([data sources](/tableau-data-sources-to-power-bi-datasets/)) |
| [Extract (.hyper)](https://help.tableau.com/current/pro/desktop/en-us/extracting_data.htm) | Import mode with scheduled refresh | Large extracts want incremental refresh ([extracts](/convert-tableau-extracts-to-power-bi-dataflows/), [Hyper files](/convert-hyper-files-to-power-bi/)) |
| Live connection | [DirectQuery](https://learn.microsoft.com/en-us/power-bi/connect-data/desktop-directquery-about), or Import if latency allows | DirectQuery constrains DAX and slows visuals; decide per source |
| [Data blending](https://help.tableau.com/current/pro/desktop/en-us/multiple_connections.htm) | Model [relationships](https://learn.microsoft.com/en-us/power-bi/transform-model/desktop-relationships-understand) | Cardinality and cross‑filter direction are decisions ([blending](/tableau-blending-to-power-bi-relationships/)) |
| [Custom SQL](https://help.tableau.com/current/pro/desktop/en-us/customsql.htm) | A view in the source, Power Query, or a native query | Placement decides whether query folding survives ([custom SQL](/tableau-custom-sql-to-power-bi/)) |
| Joins inside a data source | Relationships in a [star schema](https://learn.microsoft.com/en-us/power-bi/guidance/star-schema) | Flattened sources unflatten into a fact table and dimensions |
| User filters | [Row‑level security](https://learn.microsoft.com/en-us/fabric/security/service-admin-row-level-security) roles | Checked in step 6 with "view as" |
| Workbook, dashboard, worksheet | PBIX or PBIP file, report page, visual | Worksheets ride along with their dashboards ([workbook to PBIX](/tableau-workbook-to-pbix-conversion/)) |
| Site, project | Workspace, app | Permissions are rebuilt, not copied |
| Server or Cloud groups | Microsoft Entra groups on workspace roles and RLS | Membership is recreated; nothing syncs across |
| On‑premises sources (Bridge on Cloud) | [On‑premises data gateway](https://learn.microsoft.com/en-us/power-bi/connect-data/service-gateway-onprem) | Stand it up before wave one; every refresh schedule rides on it |
| Prep flows | Dataflows, or logic moved into the warehouse | Outside dashboard conversion; sized as data‑platform work |

Build the model before the report pages. Microsoft recommends [separating the semantic model from reports](https://learn.microsoft.com/en-us/power-bi/guidance/report-separate-from-model), and a migration is where the advice pays: a shared star schema is slower for the first dashboard and faster for every one after it, and it prevents an estate of private data sets that refresh on their own schedules and quietly disagree. Blends are where the numbers move. Tableau aggregates each source at the linking fields and then combines them; a Power BI relationship filters rows first and aggregates after, so a many‑to‑many blend can yield a defensible total that is not Tableau's total. Note those cases now so that step 6 expects them.

## Step 4: Convert the calculations

Three buckets describe conversion coverage better than one percentage: what converts cleanly, what converts but needs a reviewer's decision, and what has to be designed again.

| Tableau feature | Power BI counterpart | Fate |
| --- | --- | --- |
| Row‑level calculated fields (`IF`, `CASE`, `DATEDIFF`, string functions) | DAX calculated columns and measures | Converts cleanly ([function mapping](/tableau-calculated-fields-to-dax/)) |
| Aggregations (`SUM`, `AVG`, `COUNTD`) | Measures | Converts cleanly |
| Groups, hierarchies, folders, aliases | Groups, hierarchies, display folders | Converts cleanly ([groups and hierarchies](/tableau-groups-to-power-bi/)) |
| Parameters | What‑if parameters or field parameters | Converts with review ([parameters](/tableau-parameters-to-power-bi-parameters/)) |
| LOD expressions (`FIXED`, `INCLUDE`, `EXCLUDE`) | `CALCULATE` with filter modifiers, `SUMMARIZE` | Converts with review ([LOD to DAX](/tableau-lod-expressions-to-dax/)) |
| [Table calculations](https://help.tableau.com/current/pro/desktop/en-us/functions_functions_tablecalculation.htm) (running total, percent of total, rank) | `WINDOW`, `OFFSET`, `RANKX` with explicit partitions | Converts with review ([table calculations](/tableau-table-calculations-to-dax/)) |
| Filter and highlight [actions](https://help.tableau.com/current/pro/desktop/en-us/actions.htm) | [Visual interactions](https://learn.microsoft.com/en-us/power-bi/create-reports/service-reports-visual-interactions), drillthrough | Converts with review ([actions](/tableau-actions-to-power-bi-drillthrough/)) |
| Sets | Measures with `TOPN`, or a flag column | Rebuilt ([sets](/tableau-sets-to-dax-measures/)) |
| [Set actions](https://help.tableau.com/current/pro/desktop/en-us/actions_sets.htm), parameter actions | Bookmarks, field parameters; no stored set a click can write into | Redesign |
| Dashboard extensions, custom visuals | AppSource visuals, separate APIs | Redesign |

"With review" means the syntax converts but a decision does not. Tableau resolves a `FIXED` expression by its [order of operations](https://help.tableau.com/current/pro/desktop/en-us/order_of_operations.htm), ignoring dimension filters and respecting context filters, while DAX resolves everything against filter context. The converted measure has to state whether it respects slicers or ignores them, and only the worksheet's filter list says which. Table calculations pose the same kind of question: the addressing and partitioning Tableau infers from the view become explicit arguments in DAX. Translate the intent of a calculation rather than its text; a literal translation compiles, renders and returns the wrong number.

One example carries the whole class. A worksheet shows `{FIXED [Customer] : SUM([Sales])}` with Region on the filter shelf. In Tableau the per‑customer figure is the customer's sales across all regions, because a quick filter is applied after the FIXED expression. The DAX equivalent that keeps that behavior is `CALCULATE(SUM(Sales[Amount]), ALLEXCEPT(Sales, Sales[Customer]))`, which ignores a Region slicer. If the workbook had Region as a context filter instead, the Tableau figure was per customer within the selected region, and `Sales[Region]` has to be added to the `ALLEXCEPT` list so the slicer keeps filtering. Same expression, two correct answers, and only the workbook's filter setup says which one you owe. The [LOD to DAX page](/tableau-lod-expressions-to-dax/) works through INCLUDE and EXCLUDE the same way.

Give the third bucket its own estimate: a page of standard charts can still owe most of its remaining hours to one set action and an extension, which is why a coverage figure without a feature breakdown says little about the schedule. [What automation converts and what it breaks](/tableau-to-power-bi-automated-migration/) goes through the buckets one by one.

## Step 5: Rebuild the report pages

One Tableau dashboard becomes one Power BI report page. The vocabulary matters because Microsoft uses [dashboard](https://learn.microsoft.com/en-us/power-bi/create-reports/service-dashboards) for a canvas of pinned tiles that cannot be filtered; the report page is where filtering and drilling live. A page has a [page size](https://learn.microsoft.com/en-us/power-bi/create-reports/power-bi-report-display-settings), 16:9 by default with custom height and width allowed, so a tall Tableau dashboard either gets a custom height that scrolls or is split across two pages. Tableau's device layouts become a separate [mobile layout](https://learn.microsoft.com/en-us/power-bi/create-reports/power-bi-create-mobile-optimized-report-about), and formatting that lived in each worksheet moves into a [report theme](https://learn.microsoft.com/en-us/power-bi/create-reports/desktop-report-themes); on a like‑to‑like rebuild that formatting pass is where a surprising share of the hours go. Interactions are assembled from different parts: Tableau builds them from actions, Power BI from visual interactions, drillthrough, bookmarks and report page tooltips, and the person who used the original is the only reliable judge of whether the result still feels right. The [dashboard‑level process](/migrate-tableau-dashboards-to-power-bi/) takes the rebuild step by step.

Convert like‑to‑like. Migration and redesign have different acceptance criteria: a migrated report can be checked against a known original, a redesigned one has nothing to check against, so scope grows by opinion. Ship the like‑to‑like version, let it settle, then run redesign as new development on the reports that turn out to be used. The one exception is the third bucket above, where a feature has no counterpart and design work is unavoidable.

## Step 6: Validate the numbers, then the behavior

Microsoft's [create and validate stage](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-create-validate-content) names four aspects: data accuracy, security, functionality and performance. Numbers come first, and the agreement about them comes before conversion starts: which measures reconcile, at which grain, within what tolerance. State the tolerance explicitly, including zero for figures that are reported outside the company. Everything outside that agreement is cosmetic. Check each report page twice, with no filters and with the common slicer combinations applied, since context‑dependent measures tend to match at the grand total and part ways below it.

Where totals disagree, the cause is usually semantic rather than arithmetic: the blend that became a relationship, the `FIXED` expression that now respects a slicer, a many‑to‑many join resolved differently. Record and explain those rather than adjusting figures until the two platforms agree, and expect a few to be defects in the Tableau original that the migration made visible; Microsoft's guidance puts it as more common than you might think to find an error in the legacy solution. Security means row‑level security roles viewed as a test user. Functionality means the click that filtered three charts and the tooltip that carried a worksheet. Performance has a plain threshold in the same guidance: most reports should present their visuals in under ten seconds, and many that do not trace to DAX, model or report design before they trace to capacity. Validate with the people who built the originals; a dashboard's author finds in minutes what a reviewer misses in a day, and their sign‑off is what step 7 needs. The register of what goes wrong is on [migration risk assessment](/tableau-migration-risk-assessment/).

## Step 7: Cut over, enable users and retire Tableau

Keep both platforms live for an agreed window, publish the Power BI content through an app (Microsoft's [deploy stage](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-deploy-support-monitor) covers the mechanics), and fix the date on which Tableau turns read‑only. Put that date ahead of the Tableau renewal rather than on it, so the license overlap is a decision instead of an accident. [Endorsement](https://learn.microsoft.com/en-us/power-bi/collaborate-share/service-endorse-content) on the Power BI side tells consumers which version is authoritative while both exist, and every report has a named owner before it is published.

Dashboards are not the only thing running on a Tableau Server. Subscriptions and data‑driven alerts need Power BI [subscriptions](https://learn.microsoft.com/en-us/power-bi/consumer/end-user-subscribe) and [alerts](https://learn.microsoft.com/en-us/power-bi/create-reports/service-set-data-alerts); views embedded in portals need new embed URLs; scheduled tabcmd and REST jobs and Prep flows need a counterpart or an explicit retirement; and the workbook files themselves go into an archive for audit before the server is switched off.

Content is half the cutover. Microsoft's [migration overview](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-overview) and its [notes from customer migrations](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-learn-from-customers) both put training, support and a communication plan among the things that separate migrations that stick from migrations that get quietly bypassed; authors and consumers need different training. In regulated settings the parallel window also carries the audit trail and the formal sign‑off, which the [financial services](/tableau-to-power-bi-migration-financial-services/) and [healthcare](/tableau-to-power-bi-migration-healthcare/) pages take further. Then watch usage in the new tenant: it shows which content earned its migration and which redesigns deserve funding.

## What drives the effort and cost of a Tableau to Power BI migration

Six things set the effort, and dashboard count is the weakest of them: how many dashboards survive pruning; how heavily they lean on LOD expressions, table calculations and sets; how many distinct sources and blends they sit on; how much interaction is built from actions; how strict the validation policy is; and how long the two platforms run in parallel, which is also how long two license bills overlap. The first three are measurable before any money is spent, which is the case for doing steps 1 and 2 properly.

For a hand rebuild, the arithmetic the ROI model on this site uses is dashboards times hours times rate: 100 dashboards at 80 hours and $85 an hour is $680,000, with hours per dashboard ranging from a handful to well over a hundred depending on the feature mix. A conversion tool replaces most of those hours with a per‑dashboard fee plus a review share, and both figures move with complexity. The budget lines are on [cost estimation](/tableau-migration-cost-estimation/), the business case on the [migration cost calculator](/tableau-to-power-bi-migration-cost-calculator/), and the crossover between rebuild and automation on [automated versus manual migration](/automated-vs-manual-tableau-migration/).

The license delta is the driver nobody prices early. Power BI Pro licenses every author and every viewer per user; Premium Per User adds larger models and more refreshes, still per user; a Fabric capacity of F64 or larger lets viewers with a free license read content, which changes the arithmetic for a large viewer population, while smaller F SKUs still need Pro or PPU for every viewer ([Microsoft's licensing reference](https://learn.microsoft.com/en-us/fabric/enterprise/licenses), as of September 2026, which also notes that the older Premium P SKUs are being retired in favor of F SKUs). Price the viewer population under each model before the parallel window opens, because the two bills overlap for as long as it runs; list prices are on [cost estimation](/tableau-migration-cost-estimation/).

## Tableau to Power BI migration challenges: what to do and what to avoid

Three practices carry most of the outcome: analyze the estate before committing to dates, keep the conversion like‑to‑like with redesign as a separate project, and validate numbers rather than appearance. The table pairs those and six more with the mistake each one prevents.

| Do | Avoid | Why it matters |
| --- | --- | --- |
| Score the estate before promising dates | Converting first and discovering complexity later | Effort follows calculations and data sources, not dashboard count |
| Retire dead content before migrating it | Moving everything because moving is easier than deciding | Each retired dashboard removes conversion, validation and license cost |
| Sequence simple content first | Opening with the flagship dashboard | Early waves expose model problems while they are still cheap to fix |
| Convert like‑to‑like | Redesigning during conversion | A redesigned report cannot be reconciled against the original |
| Freeze Tableau edits during a wave | Letting authors keep changing the source | Two versions drift apart and the comparison never settles |
| Reconcile agreed measures at an agreed grain | Comparing screenshots side by side | Layout differences are expected; a wrong total is not |
| Build the shared model before the report pages | Giving every report its own private data set | Duplicated models multiply refresh cost and then disagree |
| Size unconvertible features as their own workstream | Hiding them inside a coverage percentage | Sets, set actions and extensions are design work with a separate estimate |
| Name an owner per report before cutover | Publishing and hoping adoption follows | Unowned reports fail sign‑off first and adoption second |

## Which migration approach: conversion tool, consultant, or in‑house rebuild

The approach question is really a question about steps 4 and 5. A conversion tool compresses them, narrows step 6 to the flagged items and, if it ships an analyzer, produces the step 1 and 2 inventory; the pruning decisions, the owners, the model design and the cutover stay with your team whatever you buy. A consultancy carries the judgment in steps 1 through 3 and the change management in step 7, at consulting rates per dashboard. An in‑house rebuild teaches the team Power BI thoroughly and is the slowest of the three. Estate size, feature mix and the renewal date decide between them, and mixed models are common: a tool for conversion, internal owners for validation, outside help for the model and the cutover. [What a conversion tool actually converts](/tableau-to-power-bi-conversion-tool/), [consultant versus tool](/tableau-migration-consultant-vs-tool/) and [how to compare migration tools](/tableau-vs-power-bi-migration-tools/) cover the trade‑offs.

## What Antares does

Antares is a BI migration tool, and Tableau to Power BI is one of the [migration routes it supports](/#capabilities); each route has its own guide, such as [Tableau to Databricks AI/BI](/tableau-to-databricks-ai-bi-migration/). The Analyzer does the work of steps 1 and 2: it reads metadata only from the source environment and returns the inventory, usage where the source exposes it, and complexity scoring. It is deterministic and free, so pruning and scoring happen before any commitment. The Converter covers steps 4 and 5: one source Tableau dashboard becomes one Power BI report page, deployed into your Fabric workspace in the Power BI service, for a flat 200 USD (or 200 EUR) per source dashboard. There is no per‑user licensing and nothing expires; LLM usage is billed by your own provider, typically under 20 USD (or 20 EUR) per dashboard, and private endpoints are supported. On the ROI arithmetic above, Antares' internal estimate, the one the ROI calculator on this site uses, is that roughly a tenth of the manual effort remains as review; for the 100‑dashboard example that is $88,000 against $680,000, and the share in your estate depends on the feature mix.

The pipeline is deterministic‑first with guardrailed, validated AI steps. Where a mapping is ambiguous, the kind of LOD or blend question described in step 4, it is flagged for review rather than silently guessed, and any assumption the pipeline does make is recorded, so step 6 starts with the items that need judgment. Conversion is like‑to‑like by design, and Antares is not a data migration tool: it converts dashboards and the semantic logic inside them rather than rebuilding the warehouse underneath. [Run the free Analyzer](https://try.getantares.io) on your estate to get the step 1 and 2 output before deciding anything else.

## Go deeper

**Technical conversion:** [LOD expressions to DAX](/tableau-lod-expressions-to-dax/), [calculated fields to DAX](/tableau-calculated-fields-to-dax/), [table calculations to DAX](/tableau-table-calculations-to-dax/), [sets to DAX measures](/tableau-sets-to-dax-measures/), [parameters](/tableau-parameters-to-power-bi-parameters/), [actions to drillthrough](/tableau-actions-to-power-bi-drillthrough/), [extracts to dataflows](/convert-tableau-extracts-to-power-bi-dataflows/), [data sources to semantic models](/tableau-data-sources-to-power-bi-datasets/), [custom SQL](/tableau-custom-sql-to-power-bi/), [blending to relationships](/tableau-blending-to-power-bi-relationships/), [Hyper files](/convert-hyper-files-to-power-bi/), [groups and hierarchies](/tableau-groups-to-power-bi/), [workbook to PBIX](/tableau-workbook-to-pbix-conversion/).

**Planning:** [planning guide](/tableau-migration-planning-guide/), [checklist](/tableau-migration-checklist/), [complexity analysis](/tableau-dashboard-complexity-analysis/), [timeline](/how-long-does-tableau-to-power-bi-migration-take/), [cost estimation](/tableau-migration-cost-estimation/), [migration cost calculator](/tableau-to-power-bi-migration-cost-calculator/), [risk assessment](/tableau-migration-risk-assessment/), [enterprise strategy](/enterprise-tableau-migration-strategy/).

**Approaches:** [conversion tools](/tableau-to-power-bi-conversion-tool/), [automated migration](/tableau-to-power-bi-automated-migration/), [dashboard migration process](/migrate-tableau-dashboards-to-power-bi/), [automated versus manual](/automated-vs-manual-tableau-migration/), [consultant versus tool](/tableau-migration-consultant-vs-tool/), [tool comparison](/tableau-vs-power-bi-migration-tools/), [choosing a migration tool](/best-tableau-to-power-bi-migration-tool/), [BiChart alternatives](/bichart-alternative-tableau-migration/).

**Platform and industry:** [Tableau Server](/tableau-server-to-power-bi-migration/), [Tableau Cloud](/tableau-online-to-power-bi-migration/), [Microsoft Fabric](/tableau-to-microsoft-fabric-migration/); [financial services](/tableau-to-power-bi-migration-financial-services/), [healthcare](/tableau-to-power-bi-migration-healthcare/), [retail](/tableau-to-power-bi-migration-retail/), [manufacturing](/tableau-to-power-bi-migration-manufacturing/). Other routes: [Tableau to Databricks AI/BI](/tableau-to-databricks-ai-bi-migration/).

Primary sources: Microsoft's [requirements](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-requirements), [deployment planning](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-planning) and [change management](https://learn.microsoft.com/en-us/power-bi/guidance/fabric-adoption-roadmap-change-management) guidance; Tableau's documentation on [dashboards](https://help.tableau.com/current/pro/desktop/en-us/dashboards_create.htm) and the features linked above.

## Related resources

- [Tableau Migration Planning Guide](/tableau-migration-planning-guide/)
- [Tableau Migration Checklist](/tableau-migration-checklist/)
- [Automated Tableau Migration: What Converts, What Breaks](/tableau-to-power-bi-automated-migration/)
- [Tableau to Databricks AI/BI Migration Guide](/tableau-to-databricks-ai-bi-migration/)
- [Power BI to Tableau Migration Guide](/power-bi-to-tableau-migration/)

## FAQ

### Can a Tableau workbook be exported directly into Power BI?

No. A workbook is Tableau's own XML (.twb) or packaged (.twbx) format, and Power BI Desktop does not open either. What moves is the metadata: data source definitions, calculated fields, dashboard layout and actions, which a converter reads and rebuilds as a semantic model and a report page. Pointing Power BI at the same database is a different task from migrating the dashboards.

### What converts cleanly from Tableau to Power BI, and what has to be rebuilt?

Standard visuals, fields, groups, hierarchies and row-level calculated fields usually convert without intervention. LOD expressions, table calculations, parameters, blends, actions and custom SQL convert but need a reviewer's decision about filter context or model placement. Sets, set actions, extensions and custom visuals have no counterpart to convert into and are designed again in Power BI parts.

### Do we have to migrate every Tableau dashboard?

No, and most estates should not. Usage data from Tableau's administrative views shows which dashboards nobody has opened in months; those are retired rather than converted, which removes their conversion, validation and license cost at once. Migrate what the business uses and keep the rest as an archive with a named owner.

### Do we need Microsoft Fabric to migrate from Tableau to Power BI?

No. Power BI Pro or Premium Per User licenses are enough to publish and share migrated reports. A Fabric capacity matters when the viewer population is large, because on F64 and larger SKUs viewers need only a free license, and when the reports are meant to sit next to lakehouses and warehouses. The dashboards land in the Power BI workload either way.

### What is the most common mistake in a Tableau to Power BI migration?

Starting conversion before the estate has been counted, scored and pruned. Every later number becomes a guess, the features that need a redesign stay hidden inside a coverage percentage, and the team pays to convert and validate dashboards nobody opens. The second most common is redesigning during conversion, which removes the original the new report was going to be checked against.