# Antares

> Antares is a BI migration analyzer and conversion accelerator for enterprise BI teams. The Analyzer assesses connected Tableau environments and uploaded Power BI reports (PBIX or PBIP) to surface migration risk and score how hard each workbook or report is to move before a rebuild begins; the homepage keeps the current list of supported migration routes (https://getantares.io/#capabilities). The Converter automates dashboard conversion at a flat fee of 200 USD, or 200 EUR, per dashboard, with validated, ready-to-use outputs. Operated by Dark Lake, LLC.

## Core pages
- [Homepage](https://getantares.io/): product overview, analyzer-first migration narrative, flat per-dashboard pricing and ROI calculator
- [Analyzer](https://getantares.io/analyzer/): free risk and effort analysis. Tableau: readiness score, feature-level detection of LOD, custom SQL, parameters, actions; flags orphaned and low-usage dashboards to de-scope. Power BI (upload a .pbix file or a zipped PBIP project): complexity score, migration difficulty for the chosen target, ranked migration considerations and a component inventory
- [Converter](https://getantares.io/converter/): automated dashboard conversion with validated, ready-to-use outputs — flat fee of 200 USD (or 200 EUR) per dashboard
- [Partners](https://getantares.io/partners/): official SI partners for end-to-end migration delivery; partner program for systems integrators
- [Migration Library](https://getantares.io/migration-library/): migration guides, conversion patterns, and insights
- [Pricing](https://getantares.io/pricing/): flat per-dashboard pricing — what the fee covers, what is billed separately, and how the unit is defined; machine-readable twin at https://getantares.io/pricing.md
- [App](https://try.getantares.io): sign up and run a free Analyzer scan

## Pillar guides
- [BI Migration: Approaches, Phases and the Hard Parts](https://getantares.io/bi-migration/): vendor-neutral overview — what a BI migration is, rebuild vs lift-and-shift vs rationalize-and-convert vs automated conversion, the phases, what stays hard whichever platforms are involved
- [Tableau to Power BI Migration — The Definitive Guide](https://getantares.io/tableau-to-power-bi-migration/): central hub linking five clusters of in-depth resources
- [Tableau to Databricks AI/BI Migration](https://getantares.io/tableau-to-databricks-ai-bi-migration/): what a Tableau dashboard becomes in Databricks AI/BI, what does not migrate as-is, sequencing, cost shape, Databricks' own import
- [Power BI to Tableau Migration](https://getantares.io/power-bi-to-tableau-migration/): what a Power BI report becomes in Tableau, the semantic model, DAX measures, RLS roles, bookmarks and drillthrough mapped, phases and validation; Analyzer available, conversion in private beta
- [Power BI to Databricks AI/BI Migration](https://getantares.io/power-bi-to-databricks-ai-bi-migration/): the model to metric views, DAX to SQL, RLS to Unity Catalog, Databricks' own .pbit import, phases and validation; Analyzer available, conversion in private beta

## Tableau to Databricks AI/BI (cluster)
Mapping Tableau constructs to Databricks AI/BI dashboards, Databricks SQL and Unity Catalog:
- [LOD expressions to Databricks SQL](https://getantares.io/tableau-lod-expressions-to-databricks-sql/)
- [Calculated fields to Databricks SQL](https://getantares.io/tableau-calculated-fields-to-databricks-sql/)
- [Table calculations to Databricks AI/BI](https://getantares.io/tableau-table-calculations-to-databricks/)
- [Parameters, filters and actions to Databricks AI/BI](https://getantares.io/tableau-parameters-to-databricks-ai-bi-parameters/)
- [Row-level security to Unity Catalog](https://getantares.io/tableau-row-level-security-to-unity-catalog/)
- [Databricks AI/BI vs Tableau: what changes for dashboard owners](https://getantares.io/databricks-ai-bi-vs-tableau/)

## Technical conversion (cluster)
Translating Tableau-specific features into Power BI equivalents:
- [LOD expressions to DAX](https://getantares.io/tableau-lod-expressions-to-dax/)
- [Calculated fields to DAX](https://getantares.io/tableau-calculated-fields-to-dax/)
- [Table calculations to DAX](https://getantares.io/tableau-table-calculations-to-dax/)
- [Sets to DAX measures](https://getantares.io/tableau-sets-to-dax-measures/)
- [Parameters to Power BI parameters](https://getantares.io/tableau-parameters-to-power-bi-parameters/)
- [Actions to Power BI drillthrough](https://getantares.io/tableau-actions-to-power-bi-drillthrough/)
- [Extracts to Power BI dataflows](https://getantares.io/convert-tableau-extracts-to-power-bi-dataflows/)
- [Data sources to Power BI datasets](https://getantares.io/tableau-data-sources-to-power-bi-datasets/)
- [Custom SQL to Power BI](https://getantares.io/tableau-custom-sql-to-power-bi/)
- [Data blending to Power BI relationships](https://getantares.io/tableau-blending-to-power-bi-relationships/)
- [Hyper files to Power BI](https://getantares.io/convert-hyper-files-to-power-bi/)
- [Groups and hierarchies to Power BI](https://getantares.io/tableau-groups-to-power-bi/)
- [Workbook (.twbx) to PBIX](https://getantares.io/tableau-workbook-to-pbix-conversion/)
- [Export or connect Tableau to Power BI](https://getantares.io/export-tableau-to-power-bi/): there is no export button and no Tableau connector; the routes that work for data, dashboards and side-by-side use

## Migration planning (cluster)
Process, scoping, and risk management:
- [Migration planning guide](https://getantares.io/tableau-migration-planning-guide/)
- [Cost estimation](https://getantares.io/tableau-migration-cost-estimation/)
- [Risk assessment](https://getantares.io/tableau-migration-risk-assessment/)
- [Dashboard complexity analysis](https://getantares.io/tableau-dashboard-complexity-analysis/)
- [Migration timeline](https://getantares.io/how-long-does-tableau-to-power-bi-migration-take/)
- [Migration checklist](https://getantares.io/tableau-migration-checklist/)
- [Migration cost calculator](https://getantares.io/tableau-to-power-bi-migration-cost-calculator/): interactive, no sign-up — manual rebuild vs Antares by complexity band, every assumption editable, formula on the page
- [Enterprise migration strategy](https://getantares.io/enterprise-tableau-migration-strategy/)

## Migration approaches (cluster)
Tools, methods, and comparisons:
- [Conversion tools overview](https://getantares.io/tableau-to-power-bi-conversion-tool/)
- [Automated migration](https://getantares.io/tableau-to-power-bi-automated-migration/)
- [Dashboard migration process](https://getantares.io/migrate-tableau-dashboards-to-power-bi/)
- [Tableau vs Power BI migration tools](https://getantares.io/tableau-vs-power-bi-migration-tools/)
- [Best migration tool](https://getantares.io/best-tableau-to-power-bi-migration-tool/)
- [Automated vs manual migration](https://getantares.io/automated-vs-manual-tableau-migration/)
- [Consultant vs tool](https://getantares.io/tableau-migration-consultant-vs-tool/)
- [BiChart alternatives](https://getantares.io/bichart-alternative-tableau-migration/)

## Platform-specific migration (cluster)
Source-platform-specific guidance:
- [Tableau Server to Power BI](https://getantares.io/tableau-server-to-power-bi-migration/)
- [Tableau Online to Power BI](https://getantares.io/tableau-online-to-power-bi-migration/)
- [Tableau to Microsoft Fabric](https://getantares.io/tableau-to-microsoft-fabric-migration/)

## Industry-specific migration (cluster)
Verticals with unique compliance and data requirements:
- [Financial services](https://getantares.io/tableau-to-power-bi-migration-financial-services/)
- [Healthcare](https://getantares.io/tableau-to-power-bi-migration-healthcare/)
- [Retail](https://getantares.io/tableau-to-power-bi-migration-retail/)
- [Manufacturing](https://getantares.io/tableau-to-power-bi-migration-manufacturing/)

## Migration Library
- [Why Tableau Migrations Fail (And It's Not the Tools)](https://getantares.io/migration-library/why-tableau-migrations-fail/) — published February 9, 2026

## Third-party listings
Antares is available on these enterprise marketplaces:
- [Databricks Marketplace](https://marketplace.databricks.com/details/90d24b77-11c2-4a72-be14-0a1b3026fae9/Tier-One-Analytics_Antares-BI-Migration-Automation): Tier One Analytics — Antares BI Migration Automation
- [Microsoft Marketplace](https://marketplace.microsoft.com/en-us/product/saas/tieroneanalyticsinc1760439825228.antares): Tier One Analytics Inc — Antares

## Machine-readable resources
- [llms-full.txt](https://getantares.io/llms-full.txt): this index plus the full text of every Migration Library page and blog post, in one file
- [pricing.md](https://getantares.io/pricing.md): structured pricing data
- [/mcp](https://getantares.io/mcp): agent index — what Antares is, the key facts, and every machine-readable resource in one short document. A static markdown file, not an MCP protocol endpoint; Antares ships no public MCP server.
- Markdown twins: any Migration Library page or blog post can be fetched as markdown — drop the trailing slash from its URL and append `.md`, e.g. [tableau-to-power-bi-migration.md](https://getantares.io/tableau-to-power-bi-migration.md)

## Legal
- [Privacy Policy](https://getantares.io/privacy/)
- [Terms of Service](https://getantares.io/terms/)

## Contact
- General: hello@getantares.io
- Privacy: privacy@getantares.io
- Security: security@getantares.io
- Legal: legal@getantares.io

---

# Full content

The index above lists every page; below is the complete text of each one, first
the Migration Library, then the blog. Any single page can also be fetched on its
own: take its URL, drop the trailing slash and append `.md` — for example
https://getantares.io/tableau-to-power-bi-migration.md

---

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

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](https://getantares.io/tableau-migration-checklist/), and the [Tableau Server](https://getantares.io/tableau-server-to-power-bi-migration/) and [Tableau Cloud](https://getantares.io/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](https://getantares.io/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](https://getantares.io/tableau-migration-planning-guide/), and the calendar by estate size is on [how long a migration takes](https://getantares.io/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](https://getantares.io/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](https://getantares.io/convert-tableau-extracts-to-power-bi-dataflows/), [Hyper files](https://getantares.io/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](https://getantares.io/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](https://getantares.io/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](https://getantares.io/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](https://getantares.io/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](https://getantares.io/tableau-groups-to-power-bi/)) |
| Parameters | What‑if parameters or field parameters | Converts with review ([parameters](https://getantares.io/tableau-parameters-to-power-bi-parameters/)) |
| LOD expressions (`FIXED`, `INCLUDE`, `EXCLUDE`) | `CALCULATE` with filter modifiers, `SUMMARIZE` | Converts with review ([LOD to DAX](https://getantares.io/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](https://getantares.io/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](https://getantares.io/tableau-actions-to-power-bi-drillthrough/)) |
| Sets | Measures with `TOPN`, or a flag column | Rebuilt ([sets](https://getantares.io/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](https://getantares.io/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](https://getantares.io/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](https://getantares.io/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](https://getantares.io/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](https://getantares.io/tableau-to-power-bi-migration-financial-services/) and [healthcare](https://getantares.io/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](https://getantares.io/tableau-migration-cost-estimation/), the business case on the [migration cost calculator](https://getantares.io/tableau-to-power-bi-migration-cost-calculator/), and the crossover between rebuild and automation on [automated versus manual migration](https://getantares.io/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](https://getantares.io/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](https://getantares.io/tableau-to-power-bi-conversion-tool/), [consultant versus tool](https://getantares.io/tableau-migration-consultant-vs-tool/) and [how to compare migration tools](https://getantares.io/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](https://getantares.io/#capabilities); each route has its own guide, such as [Tableau to Databricks AI/BI](https://getantares.io/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](https://getantares.io/tableau-lod-expressions-to-dax/), [calculated fields to DAX](https://getantares.io/tableau-calculated-fields-to-dax/), [table calculations to DAX](https://getantares.io/tableau-table-calculations-to-dax/), [sets to DAX measures](https://getantares.io/tableau-sets-to-dax-measures/), [parameters](https://getantares.io/tableau-parameters-to-power-bi-parameters/), [actions to drillthrough](https://getantares.io/tableau-actions-to-power-bi-drillthrough/), [extracts to dataflows](https://getantares.io/convert-tableau-extracts-to-power-bi-dataflows/), [data sources to semantic models](https://getantares.io/tableau-data-sources-to-power-bi-datasets/), [custom SQL](https://getantares.io/tableau-custom-sql-to-power-bi/), [blending to relationships](https://getantares.io/tableau-blending-to-power-bi-relationships/), [Hyper files](https://getantares.io/convert-hyper-files-to-power-bi/), [groups and hierarchies](https://getantares.io/tableau-groups-to-power-bi/), [workbook to PBIX](https://getantares.io/tableau-workbook-to-pbix-conversion/).

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

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

**Platform and industry:** [Tableau Server](https://getantares.io/tableau-server-to-power-bi-migration/), [Tableau Cloud](https://getantares.io/tableau-online-to-power-bi-migration/), [Microsoft Fabric](https://getantares.io/tableau-to-microsoft-fabric-migration/); [financial services](https://getantares.io/tableau-to-power-bi-migration-financial-services/), [healthcare](https://getantares.io/tableau-to-power-bi-migration-healthcare/), [retail](https://getantares.io/tableau-to-power-bi-migration-retail/), [manufacturing](https://getantares.io/tableau-to-power-bi-migration-manufacturing/). Other routes: [Tableau to Databricks AI/BI](https://getantares.io/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](https://getantares.io/tableau-migration-planning-guide/)
- [Tableau Migration Checklist](https://getantares.io/tableau-migration-checklist/)
- [Automated Tableau Migration: What Converts, What Breaks](https://getantares.io/tableau-to-power-bi-automated-migration/)
- [Tableau to Databricks AI/BI Migration Guide](https://getantares.io/tableau-to-databricks-ai-bi-migration/)
- [Power BI to Tableau Migration Guide](https://getantares.io/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.

---

## Tableau to Databricks AI/BI Migration: The Practical Guide for 2026

Canonical: https://getantares.io/tableau-to-databricks-ai-bi-migration/
Published: 2026-09-07
Updated: 2026-10-02

A Tableau to Databricks AI/BI migration is three layers of work: data logic into SQL datasets and Unity Catalog metric views, dashboards rebuilt on the AI/BI canvas, and access rebuilt in Unity Catalog. Automation covers the first two; the third is a design decision. This is not about [connecting Tableau to Databricks](https://docs.databricks.com/aws/en/partners/bi/tableau) as a data source, which Databricks documents separately.

Names first: search results still carry the old ones. AI/BI dashboards were Lakeview dashboards until Databricks [renamed them Dashboards](https://docs.databricks.com/aws/en/sql/release-notes/2024) on April 18, 2024. The older Databricks SQL dashboards, now called legacy dashboards, [reached end of life](https://docs.databricks.com/aws/en/ai-bi/release-notes/2026) on March 5, 2026, and Genie Spaces became Genie Agents on July 9, 2026 (release notes, as of September 2026).

## What a Tableau dashboard becomes in Databricks AI/BI

One line per concept; rows with real conversion work link to their owner page. Two Databricks words show up before their section: a **dataset** is the query a dashboard reads, and a **metric view** is a measure definition kept in Unity Catalog rather than inside any one dashboard.

| Tableau | Databricks AI/BI | Note |
| --- | --- | --- |
| Workbook (`.twb`, `.twbx`) | Not a unit in AI/BI | Converts one at a time; worksheets ride along |
| Dashboard | AI/BI dashboard | The unit of work and pricing |
| Published data source | Metric view in Unity Catalog | Shared across dashboards |
| Custom SQL | Dataset SQL | Read-only: no `CREATE` or `INSERT` |
| Extract (`.hyper`) | Result cache plus a schedule, or a materialized view | No file exists |
| Live connection | Dataset SQL on a SQL warehouse | Serverless, pro or classic |
| Calculated field | Dataset SQL column, custom calculation, or metric-view measure | [Calculated fields](https://getantares.io/tableau-calculated-fields-to-databricks-sql/) |
| LOD expression | Fixed or Coarser LOD, or dataset SQL | INCLUDE takes modeling: [LOD expressions](https://getantares.io/tableau-lod-expressions-to-databricks-sql/) |
| Table calculation | `AGGREGATE OVER`, or a SQL window function | Where it runs changes the total: [table calcs](https://getantares.io/tableau-table-calculations-to-databricks/) |
| Quick filter, parameter, filter action | Field filter, dashboard parameter, cross-filtering | [Parameters and actions](https://getantares.io/tableau-parameters-to-databricks-ai-bi-parameters/) |
| User filter | Unity Catalog row filter, plus the publish mode | The mode decides if it applies: [RLS](https://getantares.io/tableau-row-level-security-to-unity-catalog/) |
| Story | No documented equivalent | Dashboards have pages; the docs describe no story-style sequence |

## Why the logic moves before the pictures

Tableau lets a workbook carry its own semantics: an LOD expression can live inside the dashboard that needs it, which is sensible when the dashboard is the product. Databricks AI/BI assumes the opposite. A dashboard reads [datasets](https://docs.databricks.com/aws/en/dashboards/manage/data-modeling/datasets), dataset queries are read-only SQL, and the arithmetic exists before the chart does.

We recommend three layers: base views in Unity Catalog that clean and join source tables, [metric views](https://docs.databricks.com/aws/en/uc-semantics/metric-views/) holding the measures and their dimensions, and dashboard datasets on top. The payoff is that a disputed number has one definition, in SQL, that the whole team can read.

## What happens to extracts and live connections

There is no extract file in Databricks. A Tableau [extract](https://help.tableau.com/current/pro/desktop/en-us/extracting_data.htm) is a subset saved separately in `.hyper` format on its own refresh schedule. That job splits in two here, neither half an extract.

The first half is the dashboard [result cache](https://docs.databricks.com/aws/en/dashboards/caching): 24 hours, best effort, and new data does not invalidate it, so only a schedule refreshes it reliably, the nearest relative of your extract refresh. The second half is [materialized views](https://docs.databricks.com/aws/en/ldp/concepts/materialized-views), precomputed results held in Unity Catalog and refreshed on an interval. Nothing is downloaded, so neither is an extract.

A live connection becomes dataset SQL on a [SQL warehouse](https://docs.databricks.com/aws/en/compute/sql-warehouse/warehouse-types), serverless, pro or classic. Two rendering limits belong in the plan: most charts render up to 15,000 rows and tables up to 100,000 ([dashboard limits](https://docs.databricks.com/aws/en/dashboards/limits), as of September 2026).

## Should you migrate one to one first, or rationalize first

Inventory first: which dashboards were opened last quarter, who owns them, which three are one dashboard with different filters. Then convert like to like whatever survives, keeping redesign separate, per dashboard, after the numbers tie out.

The reason is arithmetic. A dashboard whose total no longer matches has one suspect if you only converted it, two if you redesigned it the same week. The structural budget belongs here too, at 15 pages, 100 datasets and 100 widgets per page as of September 2026, where a workbook of forty worksheets becomes a question about how many dashboards it should be.

## What the cost shape looks like

Tableau bills per seat. Databricks bills the compute under the dashboard, and words it plainly on its [business intelligence page](https://www.databricks.com/product/business-intelligence): "There are no additional license fees to use AI/BI. Standard Databricks Lakehouse $DBU rates apply." Genie is the exception: Databricks paused billing for Genie One and Genie Agents on July 15, 2026 and usage by users is free through January 31, 2027, while Genie Code, which runs `/importBI`, stays pay-as-you-go ([release notes](https://docs.databricks.com/aws/en/ai-bi/release-notes/2026)). The current terms, with the allowances, are on [the comparison page](https://getantares.io/databricks-ai-bi-vs-tableau/).

Viewer count therefore stops being a line item and becomes a capacity question. Every dataset query runs on the SQL warehouse, but results served from the 24-hour [dashboard cache](https://docs.databricks.com/aws/en/dashboards/caching) do not start it, and a schedule warms that cache so the first viewer of the day does not pay for it. Publish mode decides how far one query stretches: Share data permissions gives every viewer a shared cache, while Individual data permissions gives each their own, so each person's first load runs a query. Serverless [SQL warehouses](https://docs.databricks.com/aws/en/compute/sql-warehouse/warehouse-types) start in seconds and autoscale with the queue.

## Databricks' own import, and where a migration tool fits

Databricks ships an importer. Genie Code's `/importBI` command [accepts](https://docs.databricks.com/aws/en/dashboards/manage/import-bi) a `.twb`, `.twbx`, `.tds`, `.tdsx` or `.pbit` file and builds an AI/BI dashboard connected to local metric views, generally available since August 20, 2026. Genie Code is metered: excluded from the Genie free promotion, it keeps a pay-as-you-go allowance of 150 free DBUs per user a month ([release notes](https://docs.databricks.com/aws/en/ai-bi/release-notes/2026), as of September 2026). The docs carry no limitations section and no list of which Tableau constructs convert, so a person checking finds whatever a workbook lost, which is the work a tool built for estates is shaped around.

## What Antares does on this route

Everything above holds whichever tool you use. This section does not. Antares is a BI migration tool, [listed on the Databricks Marketplace](https://marketplace.databricks.com/details/90d24b77-11c2-4a72-be14-0a1b3026fae9/Tier-One-Analytics_Antares-BI-Migration-Automation), and Tableau to Databricks AI/BI is shipped. The [**Analyzer**](https://getantares.io/analyzer/) is free, deterministic and metadata-only: it reads the Tableau environment, not the business data in it, and returns the inventory sequencing depends on.

The **Converter** is deterministic-first with guardrailed, validated AI steps, at a flat $200 per source dashboard. LLM costs sit on top, typically under $20 per dashboard, billed by your own provider, private endpoints included. No per-user licensing, no time limits, and it runs as SaaS or inside your environment.

One Tableau dashboard becomes one Databricks AI/BI dashboard, worksheets riding along. It takes calculated fields to SQL and metric-view measures, LOD expressions to windowed aggregates, custom SQL to native Databricks SQL, and row-level security to Unity Catalog row filters. It is not a data migration tool: it converts dashboards and the semantic logic inside them, not data into Delta tables, the lakehouse, or Unity Catalog itself. [Run the free Analyzer](https://try.getantares.io) to see what the estate holds.

## If your source is Power BI

The shape is the same, the vocabulary shifts. A report page becomes an AI/BI dashboard, DAX measures become SQL and metric-view measures, RLS roles become Unity Catalog rules read through the publish mode, and Databricks' importer takes `.pbit` files. The free [Analyzer](https://getantares.io/analyzer/) already takes a Power BI report, a `.pbix` file or a zipped PBIP project, and scores how hard it is to move to AI/BI. Conversion on this route is in private beta; the [Converter page](https://getantares.io/converter/) takes requests for beta access.

The rest of the cluster: [LOD expressions](https://getantares.io/tableau-lod-expressions-to-databricks-sql/), [calculated fields](https://getantares.io/tableau-calculated-fields-to-databricks-sql/), [table calculations](https://getantares.io/tableau-table-calculations-to-databricks/), [parameters and actions](https://getantares.io/tableau-parameters-to-databricks-ai-bi-parameters/), [row-level security](https://getantares.io/tableau-row-level-security-to-unity-catalog/), and [AI/BI next to Tableau](https://getantares.io/databricks-ai-bi-vs-tableau/).

Primary sources for this page: Databricks on [datasets](https://docs.databricks.com/aws/en/dashboards/manage/data-modeling/datasets), [metric views](https://docs.databricks.com/aws/en/uc-semantics/metric-views/), [caching](https://docs.databricks.com/aws/en/dashboards/caching), [limits](https://docs.databricks.com/aws/en/dashboards/limits) and [importing BI files](https://docs.databricks.com/aws/en/dashboards/manage/import-bi), plus Tableau on [extracts](https://help.tableau.com/current/pro/desktop/en-us/extracting_data.htm).

## Related resources

- [Databricks AI/BI vs Tableau](https://getantares.io/databricks-ai-bi-vs-tableau/)
- [Tableau LOD Expressions in Databricks SQL](https://getantares.io/tableau-lod-expressions-to-databricks-sql/)
- [Tableau Calculated Fields to Databricks SQL](https://getantares.io/tableau-calculated-fields-to-databricks-sql/)
- [Tableau Table Calculations in Databricks AI/BI](https://getantares.io/tableau-table-calculations-to-databricks/)
- [Tableau Parameters in Databricks AI/BI](https://getantares.io/tableau-parameters-to-databricks-ai-bi-parameters/)
- [Tableau Row-Level Security to Unity Catalog](https://getantares.io/tableau-row-level-security-to-unity-catalog/)
- [Power BI to Databricks AI/BI Migration](https://getantares.io/power-bi-to-databricks-ai-bi-migration/)

## FAQ

### How long does a Tableau to Databricks AI/BI migration take?

No per-estate number would survive contact with your estate, so here is the shape instead. Inventory takes days once you can read usage and ownership. Conversion is per dashboard and predictable. Validation dominates the calendar, because every converted number has to tie out at two grains and two filter states before anyone signs it off.

### Should we migrate one to one first or rationalize first?

Inventory first: which dashboards were opened last quarter, who owns them, which three are the same dashboard with different filters. Convert like to like whatever survives that cut, then redesign separately, per dashboard, once the numbers tie out. A total that stops matching then has one suspect instead of two.

### Do we have to move our data into Databricks first?

The tables the dashboards read have to be in Databricks and registered in Unity Catalog, because AI/BI datasets query them there. That is a data platform project and it comes first. Antares converts dashboards and their semantic logic; it does not move data into Delta tables or build the lakehouse.

### Does Databricks AI/BI require Unity Catalog?

Databricks states on its business intelligence page, as of September 2026, that AI/BI "requires your data to be managed in Unity Catalog." Unity Catalog is also where row filters and column masks live, so the access rules that used to be Tableau user filters get rebuilt there rather than inside the dashboard.

### What happens to Tableau extracts?

Nothing is downloaded. The extract's job splits between the dashboard result cache, which holds results up to 24 hours on a best-effort basis and is refreshed reliably only by a schedule, and materialized views in Unity Catalog for aggregations that are expensive to recompute. Materialized views are server side, so calling them extracts misleads people.

### Is Power BI to Databricks AI/BI available from Antares?

Analysis is available; conversion is in private beta. The free Analyzer takes a Power BI report, a .pbix file or a zipped PBIP project, and scores how hard it is to move to Databricks AI/BI. Tableau to Databricks AI/BI conversion is shipped; the Power BI route is in private beta, and the Converter page takes requests for beta access. Databricks' own Genie Code importer already accepts Power BI template files, which is the native option outside the beta.

---

## Power BI to Tableau Migration: What Moves, What Is Rebuilt

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

A Power BI to Tableau migration moves three things: the report pages people open, the semantic model and the DAX measures behind them, and the row‑level security roles that decide who sees which rows. None of it moves as a file. Tableau Desktop does not open a `.pbix`, Power BI has no export to Tableau, and as of October 2026 neither vendor ships an importer for the other's format, so every report is regenerated from what its definition describes. This guide covers that direction; the opposite move, Tableau to Power BI, has [its own guide](https://getantares.io/tableau-to-power-bi-migration/).

## Why teams move from Power BI to Tableau

Rarely for price: Power BI Pro is usually the cheaper seat and is included in some Microsoft 365 plans. The usual reason is a consolidation after a merger in which the larger business already runs Tableau. Behind it come a Salesforce‑centered organization that wants analytics next to its CRM, a data platform that is not on Azure, where Entra groups, gateways and Fabric capacity stop being conveniences, and an analyst culture that prefers Tableau's worksheet model. Two scope facts belong in the first conversation: Tableau has no native counterpart to paginated reports, so pixel‑exact printouts stay in Power BI Report Builder, and most estates hold reports nobody has opened in months, which the inventory removes before anything is converted.

## What a Power BI report becomes in Tableau

The unit changes first: a report holds pages, a workbook holds dashboards, and every visual on a page becomes a worksheet of its own. "Converts" means the construct exists on both sides, "with review" means a person decides something, and "redesign" means Tableau has no object to convert into. Power BI's own dashboards, the canvas of pinned tiles, have no counterpart; the report page is what a Tableau dashboard corresponds to.

| Power BI | Tableau | Fate |
| --- | --- | --- |
| Report (`.pbix`, PBIP) with pages | Workbook (`.twb`, `.twbx`) with dashboards | **Converts**; one page becomes one dashboard |
| Visual | Worksheet placed on the dashboard | **Converts**; a twelve‑visual page is twelve worksheets |
| Semantic model: tables and relationships | Data source with relationships or joins; published if shared | **With review**: cardinality and filter direction |
| Import mode, DirectQuery | Extract (`.hyper`) on a refresh schedule, live connection | **Converts** |
| Calculated column (DAX, row level) | Row‑level calculated field | **Converts**; `RELATED` becomes the related field |
| Composite model, calculated table | No equivalent; a view in the source | **Redesign** |
| Power Query (M) | Tableau Prep flow, custom SQL, or logic moved into the warehouse | **With review** |
| Measure (DAX) | Aggregate calculated field, LOD expression or table calculation | **With review**, per measure |
| Calculation group, field parameter | Parameter plus a `CASE` calculation; dynamic zone visibility for sheet swapping | **Redesign** |
| RLS role | User filter on a published data source, or an entitlement table | **Redesign** (below) |
| Slicer, synced slicers | Quick filter applied to all sheets using the data source | **Converts** |
| Cross‑highlight, drillthrough page | Highlight action; filter action to a target dashboard | **With review** |
| Bookmark | Parameter action plus dynamic zone visibility; Show/Hide buttons | **Redesign** |
| Report page tooltip | Viz in Tooltip | **Converts** |
| Custom visual (AppSource) | Viz Extension from Tableau Exchange, or native marks | **Redesign** |
| Workspace, app, Entra groups | Project, site, Tableau groups | **Rebuilt, not copied** |

## Where the model lands

Power BI assumes a star schema with explicit relationships and one shared model. Tableau's [relationships](https://help.tableau.com/current/pro/desktop/en-us/datasource_relationships_learnmorepage.htm) are the counterpart: tables keep their own level of detail and Tableau picks join types at query time from the fields in the view, which is what a Power BI model does implicitly. Two things do not carry over. Circular relationships are not supported and relationships cannot be defined between published data sources, so two paths to a date table, or an inactive relationship switched on by `USERELATIONSHIP`, become a role‑playing copy of the dimension or a second data source. Several fact tables map to a [multi‑fact relationship](https://help.tableau.com/current/pro/desktop/en-us/datasource_mfr_multiple_base_tables.htm) data source (Tableau 2024.2 and later). Publish the data source first and build workbooks on it; it is also where the user filters have to live.

## Converting DAX measures: the part that sets the budget

Measures, not visuals, set the hours. A DAX measure is evaluated in a filter context assembled from the visual, the slicers and the model; a Tableau calculation is evaluated at the level of detail of the view, and LOD expressions and table calculations exist to step outside it.

| DAX pattern | Tableau shape | Fate |
| --- | --- | --- |
| Plain aggregate: `SUM`, `DISTINCTCOUNT`, `DIVIDE` | Aggregate calculated field: `SUM([Amount]) / COUNTD([Customer])` | **Converts** |
| `CALCULATE([Sales], 'Product'[Color] = "Blue")` | `SUM(IF [Color] = "Blue" THEN [Amount] END)` | **With review**: `CALCULATE` replaces an existing Color filter, `IF` intersects with it |
| `CALCULATE` with `ALL` or `REMOVEFILTERS` (share of total) | `{EXCLUDE [Region] : SUM([Amount])}` or a `TOTAL()` table calculation | **With review**: which filters it ignores |
| `CALCULATE` with `ALLEXCEPT` (per‑entity total) | `{FIXED [Customer] : SUM([Amount])}` | **With review**: which slicers survive differs |
| Context transition: `CALCULATE` inside `SUMX` over `VALUES` | Nested LOD: `AVG({INCLUDE [Customer] : SUM([Amount])})` | **With review**: INCLUDE keeps the view's filters |
| Time intelligence: `DATESYTD`, `SAMEPERIODLASTYEAR` | `RUNNING_SUM` or `LOOKUP` table calculations, or a date‑range LOD | **With review**: needs the dates in the view |
| Calculation group item: `CALCULATE(SELECTEDMEASURE(), DATESYTD(...))` | A parameter and a `CASE` calculation, repeated per base measure | **Redesign** |
| `WINDOW`, `OFFSET`, `RANKX`, visual calculations | Table calculations with explicit partitioning and addressing | **With review** |

The review rows share one cause, Tableau's [order of operations](https://help.tableau.com/current/pro/desktop/en-us/order_of_operations.htm). A FIXED expression ignores every filter in the view except context, data source and extract filters, while `ALL` and `ALLEXCEPT` clear only the filters on the table or columns you name and leave every other slicer in force. The same measure therefore keeps different slicers alive on each platform, and which ones it should keep is a decision per measure, not a translation; the [LOD to DAX page](https://getantares.io/tableau-lod-expressions-to-dax/) works through FIXED, INCLUDE and EXCLUDE from the other side. Time intelligence is the second trap: a DAX year‑to‑date works on a card with no dates on it because [CALCULATE](https://learn.microsoft.com/en-us/dax/calculate-function-dax) rewrites the filter context, while a table calculation computes on the marks in the view and needs the months present. [Calculation groups](https://learn.microsoft.com/en-us/analysis-services/tabular-models/calculation-groups) get their own line in the estimate: 8 time‑intelligence items over 20 measures are 160 effective measures, and as many calculations, or one parameter‑driven `CASE` per base measure, in Tableau.

## Row‑level security: roles become user filters

Power BI [row‑level security](https://learn.microsoft.com/en-us/fabric/security/service-admin-row-level-security) is a DAX filter per role, with members assigned in the service, usually through Entra groups, and it applies only to viewers. Tableau has no role object. The same outcome is a [user filter](https://help.tableau.com/current/server/en-us/rls_bestpractices.htm): a calculation such as `[Region Owner] = USERNAME()` or `ISMEMBEROF('EMEA')`, or an entitlement table joined to the data, set as a data source filter on a published data source. Placement matters: Tableau's guidance says that if the data source is embedded and a user can web edit or download the workbook, the row‑level security is nonexistent, because the filter can be removed. With the Data Management add‑on, a virtual connection with a data policy centralizes the filter across every workbook, the closest thing to roles managed in the service. Dynamic rules on `USERPRINCIPALNAME()` map well on Tableau Cloud, where usernames are email addresses; Tableau Server usernames can differ, and static roles with hard‑coded values map to Tableau groups. Test every role before cutover, because the row count per role is the first thing an auditor asks for.

## Interactions: drillthrough, bookmarks and field parameters

A [drillthrough page](https://learn.microsoft.com/en-us/power-bi/create-reports/desktop-drillthrough) becomes a filter action aimed at a detail dashboard and set to exclude all values when cleared, so the target stays empty until something is clicked. [Bookmarks](https://learn.microsoft.com/en-us/power-bi/create-reports/desktop-bookmarks) have no object to convert into: a bookmark captures filters, slicer state, sort order, drill location and the visibility of objects, and Tableau rebuilds that with a parameter action driving [dynamic zone visibility](https://help.tableau.com/current/online/en-us/dynamic_zone_visibility.htm), where a boolean, single‑value, view‑independent field shows or hides a zone. [Field parameters](https://learn.microsoft.com/en-us/power-bi/create-reports/power-bi-field-parameters) become a parameter with a `CASE` calculation for measure swapping, or a dynamic‑zone sheet swap for dimensions. Custom visuals from AppSource do not run in Tableau; the nearest thing is a [Viz Extension](https://help.tableau.com/current/pro/desktop/en-us/viz_extensions.htm), and most are redrawn with native marks. Count these per report: a page of standard charts can still owe most of its hours to two bookmarks and a custom visual.

## Phases, and how to validate the result

| Phase | What it produces | Where it goes wrong |
| --- | --- | --- |
| Inventory | Every report with its pages, measures, sources and viewers | Counting workspaces instead of the pages people open |
| Prune and score | The shorter list that moves, scored on measures, model shape and interactions | Scoring on visual count |
| Publish the data sources | Published data sources with relationships and user filters in place | Embedding a data source in every workbook |
| Convert the calculations | Calculated fields, with the review items flagged for a decision | Translating text and trusting the total |
| Rebuild the dashboards | One dashboard per report page, interactions built from actions | **Redesign**ing while converting |
| Validate and cut over | Numbers tied out under filters and per role; Power BI set read‑only | Checking totals only |

Once an admin enables them, Microsoft's [scanner APIs](https://learn.microsoft.com/en-us/fabric/governance/metadata-scanning-overview) return the measures with their DAX and the queries of every semantic model, enough to score an estate before anyone opens a report, and a report saved as a [Power BI project](https://learn.microsoft.com/en-us/power-bi/developer/projects/projects-overview) (PBIP) holds the same definitions as plain‑text files. Validation is the longest step. Reconcile agreed measures at the grand total and then under the slicer combinations users actually apply, because the "with review" patterns agree at the top and part ways below it; check year‑to‑date figures at a period boundary; open each dashboard as a user in each role. Explain every difference rather than adjusting until the platforms agree, and expect a few to be defects in the Power BI original that the move made visible.

## What Antares does on this route

Everything above holds whichever tool you use; this section is about Antares. The [Analyzer](https://getantares.io/analyzer/) is free, and its Power BI side is generally available: upload a `.pbix` file or a zipped PBIP project, one report per analysis, pick Tableau as the target, and it returns a complexity score, a migration difficulty score for Tableau, the main considerations for the move and a component inventory. A `.pbix` can carry imported data; the Analyzer works from the report and model structure and does not copy data rows into its results. Its DAX rating follows this page: measures built on context transition, measure switching or windowed ranking are rated hardest, iterators, table expressions and relationship functions sit in the middle, plain filters and time intelligence are light, and an expression the parser cannot read is left unclassified rather than scored.

Conversion from Power BI to Tableau is in private beta and is not self‑serve: the [Converter page](https://getantares.io/converter/) takes requests for beta access, and the home page keeps the [current list of routes](https://getantares.io/#capabilities) and their status. Antares converts dashboards and the semantic logic inside them, not data; the tables Power BI read stay where they are and Tableau connects to them. [Run the free Analyzer](https://try.getantares.io) on a report to see where its hours are before committing to a date.

Related reading: the [vendor‑neutral BI migration guide](https://getantares.io/bi-migration/), [LOD expressions and DAX](https://getantares.io/tableau-lod-expressions-to-dax/), [table calculations and DAX](https://getantares.io/tableau-table-calculations-to-dax/); for a Databricks target, [Power BI to Databricks AI/BI](https://getantares.io/power-bi-to-databricks-ai-bi-migration/). Primary sources: Microsoft on [CALCULATE](https://learn.microsoft.com/en-us/dax/calculate-function-dax), [calculation groups](https://learn.microsoft.com/en-us/analysis-services/tabular-models/calculation-groups), [field parameters](https://learn.microsoft.com/en-us/power-bi/create-reports/power-bi-field-parameters) and [row‑level security](https://learn.microsoft.com/en-us/fabric/security/service-admin-row-level-security); Tableau on [relationships](https://help.tableau.com/current/pro/desktop/en-us/datasource_relationships_learnmorepage.htm), [row‑level security](https://help.tableau.com/current/server/en-us/rls_bestpractices.htm), [LOD expressions](https://help.tableau.com/current/pro/desktop/en-us/calculations_calculatedfields_lod.htm) and [dynamic zone visibility](https://help.tableau.com/current/online/en-us/dynamic_zone_visibility.htm).

## Related resources

- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [Power BI to Databricks AI/BI Migration](https://getantares.io/power-bi-to-databricks-ai-bi-migration/)
- [BI Migration: Approaches, Phases and the Hard Parts](https://getantares.io/bi-migration/)
- [Tableau LOD Expressions to DAX](https://getantares.io/tableau-lod-expressions-to-dax/)
- [Tableau Actions to Power BI Drillthrough](https://getantares.io/tableau-actions-to-power-bi-drillthrough/)

## FAQ

### Can a Power BI report be converted directly into a Tableau workbook?

No. Tableau Desktop does not open .pbix or PBIP files, and Power BI has no export to Tableau. What moves is the definition: the semantic model, the DAX measures, the page layouts and the RLS roles, which a person or a conversion tool reads and rebuilds as a Tableau data source and workbook. Pointing Tableau at the same database is a separate task from migrating the reports.

### Is there a Power BI to Tableau migration tool?

Neither Microsoft nor Tableau ships one. Third‑party conversion tools regenerate workbooks from the report definition and leave review to people; Antares offers a free Analyzer for Power BI reports and has conversion to Tableau in private beta. Whatever tool is used, DAX measures with context transition, calculation groups, bookmarks and custom visuals still need a decision per item.

### How do DAX measures translate to Tableau calculations?

Plain aggregates become aggregate calculated fields. CALCULATE with ALL or ALLEXCEPT becomes an EXCLUDE or FIXED level-of-detail expression, and because the two platforms keep different filters alive, each one is checked under the slicers users actually set. Time intelligence becomes table calculations or date‑range LODs, and calculation groups have no equivalent, so each item is rebuilt as a parameter‑driven calculation.

### How does Power BI row-level security map to Tableau?

A Power BI role is a DAX filter with members assigned in the service. Tableau builds the same result from a user filter, a calculation using USERNAME() or ISMEMBEROF(), or an entitlement table, applied as a data source filter on a published data source. The published data source matters: a filter inside an embedded workbook can be removed by anyone allowed to edit or download it.

### What replaces bookmarks and drillthrough in Tableau?

Drillthrough becomes a filter action aimed at a detail dashboard, set to exclude all values when cleared so the target starts empty. Bookmarks have no direct counterpart; the saved state of filters, sort and object visibility is rebuilt with parameter actions and dynamic zone visibility, plus Show/Hide buttons on layout containers. Both count as design work in the estimate.

### Can Antares convert Power BI reports to Tableau today?

Analysis is available now and free: upload a .pbix file or a zipped PBIP project and get a complexity score and a migration difficulty score for Tableau. Conversion from Power BI to Tableau is in private beta rather than self‑serve; the Converter page takes requests for access, and the home page lists the current status of every route.

---

## Power BI to Databricks AI/BI Migration: The Practical Guide for 2026

Canonical: https://getantares.io/power-bi-to-databricks-ai-bi-migration/
Published: 2026-10-02
Updated: 2026-10-02

Moving a Power BI report to Databricks AI/BI means taking its semantic model and DAX measures into Unity Catalog tables and metric views, rebuilding its pages as AI/BI dashboards over SQL datasets, and turning its RLS roles into Unity Catalog row filters that only bite under the right publish mode. It is a different job from [connecting Power BI to Databricks](https://docs.databricks.com/aws/en/partners/bi/power-bi) as a data source, which many teams keep doing for the reports they do not move. Three names to have straight: AI/BI dashboards were renamed from Lakeview dashboards in April 2024 and took the AI/BI name that June, while the API still says Lakeview; the older Databricks SQL dashboards, called legacy dashboards at the end, [reached end of life](https://docs.databricks.com/aws/en/ai-bi/release-notes/2026) in March 2026; and Genie Code is the agent that, among other things, imports BI files.

## Why teams move from Power BI to Databricks AI/BI

The data is already there. When the tables Power BI imports every night are Delta tables in Unity Catalog, the import model is a second copy with its own refresh schedule, gateway and capacity, and the measure definitions live in a `.pbix` rather than next to the data they describe. Databricks bills the compute under a dashboard rather than a seat; its [business intelligence page](https://www.databricks.com/product/business-intelligence) says there are no additional license fees for AI/BI and standard DBU rates apply. Governance consolidates, with row filters, column masks, lineage and audit once in the catalog instead of once per semantic model, and viewer count becomes a capacity question rather than a license line (the [comparison page](https://getantares.io/databricks-ai-bi-vs-tableau/) has the current terms). The counterweight is real. Power BI remains stronger at pixel‑level formatting, paginated reports (pixel‑exact printable output) and the Excel workflow around them. A Power BI report on DirectQuery with single sign‑on already respects Unity Catalog permissions, and Databricks can [publish Unity Catalog tables as a Power BI semantic model](https://docs.databricks.com/aws/en/partners/bi/power-bi/service). Many estates end with both; this page is about the dashboards you decide to move.

## What a Power BI report becomes in Databricks AI/BI

Two Databricks words first: a **dataset** is the SQL query a dashboard reads, and a **metric view** is a measure definition kept in Unity Catalog, or locally inside a dashboard, instead of inside a report. Three [limits](https://docs.databricks.com/aws/en/dashboards/limits) shape how a report is split, as of September 2026: 15 pages per dashboard, 100 datasets per dashboard and 100 widgets per page. In the tables, "converts" means the construct exists on both sides, "with review" means a person decides something, and "redesign" means there is no object to convert into.

| Power BI | Databricks AI/BI | Note |
| --- | --- | --- |
| Report (`.pbix`, PBIP) with pages | One or more dashboards with pages | A sprawling report becomes several dashboards |
| Visual | Visualization widget | Charts, counters, tables, pivots, maps; a gauge becomes a counter |
| Semantic model: tables and relationships | Unity Catalog tables or views, with the joins in a local or Unity Catalog metric view | Measures defined once |
| Measure (DAX) | Metric‑view measure, calculated measure, or a dataset SQL column | Per measure (next section) |
| Calculated column, calculated table | Dataset SQL column or calculated dimension; a Unity Catalog view | Row‑level logic in SQL |
| Calculation group, field parameter (Power BI's measure and field switchers) | Dashboard parameter plus `CASE` in dataset SQL | No switching object; redesign |
| Import mode, DirectQuery | Dataset SQL on a SQL warehouse; a schedule warming the 24‑hour cache, materialized views | No model copy exists |
| Power Query (M) | Upstream views or pipelines in Unity Catalog; light transforms in dataset SQL | Outside the dashboard |
| Slicer, synced slicers | Field filter: single or multiple values, date range, text, slider; global or page‑level | Filters span datasets by field |
| Cross‑highlight, drillthrough page | Cross‑filtering between widgets on one dataset; drill‑through to a target page | Listed chart types only |
| Bookmark | Filter state carried in the URL; no saved‑state object | **Redesign** |
| Custom visual (AppSource) | Vega‑Lite custom visualization (Public Preview), or a native widget | **Redesign** |
| RLS role | Unity Catalog row filter, column mask or dynamic view, with Individual data permissions | Section below |
| Subscription | Schedule and subscription: PDF with CSV or Excel by email, PNG to Slack or Teams | The schedule also re‑runs the datasets |
| Paginated report, report page tooltip | No documented equivalent | Stays in Power BI or is redesigned |

## Why the measures move before the pictures

A Power BI report carries its own semantics: the measures live in the model that ships inside the `.pbix`. Databricks AI/BI assumes the opposite. A dashboard reads [datasets](https://docs.databricks.com/aws/en/dashboards/manage/data-modeling/datasets), dataset queries are read‑only SQL, and the arithmetic exists before the chart does. Build three layers: base views in Unity Catalog that join and clean the source tables, [metric views](https://docs.databricks.com/aws/en/uc-semantics/metric-views/) holding the measures and the fields they can be grouped by, and dashboard datasets on top that query them with `MEASURE(total_sales)` grouped by whatever fields a widget needs. [Local metric views](https://docs.databricks.com/aws/en/dashboards/manage/data-modeling/local-metric-views) inside a dashboard let you define measures and join relationships visually and export them to Unity Catalog later, the natural landing place for a small report's model. There is no model copy to refresh: an Import‑mode model's job splits between the dashboard [result cache](https://docs.databricks.com/aws/en/dashboards/caching), 24 hours, best effort, warmed reliably only by a schedule, and [materialized views](https://docs.databricks.com/aws/en/ldp/concepts/materialized-views) for aggregations that are expensive to recompute.

## Converting DAX to SQL and metric‑view measures

Rows run from the patterns that translate directly to the ones that are rebuilt. A DAX measure is evaluated in a filter context the visual assembles at query time; a metric‑view measure is evaluated against the fields in the widget plus whatever the dashboard filters pass down.

| DAX pattern | Databricks shape | Fate |
| --- | --- | --- |
| Plain aggregate, `DIVIDE` | Metric‑view measure: `SUM(amount)`, `TRY_DIVIDE(SUM(a), SUM(b))` | **Converts** |
| `CALCULATE` with a column filter | `SUM(amount) FILTER (WHERE color = 'Blue')` | **With review**: `CALCULATE` replaces an existing filter, `FILTER` intersects with it |
| `CALCULATE` with `ALL` or `REMOVEFILTERS` (share of total) | `SUM(amount) AGGREGATE OVER (PARTITION BY * EXCEPT (region))` | **With review**: which filters it ignores |
| `CALCULATE` with `ALLEXCEPT` (per‑entity total) | `SUM(amount) OVER (PARTITION BY customer_id)` on rows pre‑aggregated in a CTE | **With review**: on fact rows it repeats the total and widgets double‑count |
| Context transition (a row‑by‑row evaluation turned into a filter), iterators over `VALUES` | Aggregate at one grain in a CTE, then aggregate again | **With review**: double counting in pivots |
| Time intelligence: `DATESYTD`, `SAMEPERIODLASTYEAR` | `AGGREGATE OVER (PARTITION BY * ORDER BY month CUMULATIVE)` with the year in the widget's grouping, or a window partitioned by year in dataset SQL; `TRAILING 12 MONTH` for rolling periods | **With review**: needs a date dimension |
| Calculation group | One measure per item, or a parameter and `CASE` | **Redesign** |
| `RANKX`, `WINDOW`, `OFFSET` | `RANK() OVER`, `LAG`, `QUALIFY` in dataset SQL | **With review** |

Behind the review rows: [custom calculations](https://docs.databricks.com/aws/en/dashboards/manage/data-modeling/custom-calculations/level-of-detail) give you the two LOD shapes that matter, Fixed (`OVER (PARTITION BY dims)`) and Coarser (`AGGREGATE OVER (PARTITION BY * EXCEPT (field))`); there is no named form for adding dimensions the way an iterator does in DAX, so those are modeled in dataset SQL. Custom calculations are scoped to one dataset, capped at 200 per dataset, and table visualizations do not render calculated measures, so a measure that feeds a table goes into the dataset SQL or the metric view. The [LOD expressions to Databricks SQL](https://getantares.io/tableau-lod-expressions-to-databricks-sql/) page works the same window‑function mechanics from the Tableau side.

## Row‑level security becomes Unity Catalog

A Power BI RLS role is a DAX filter with members assigned in the service. In Databricks the rule moves to the data: a [row filter](https://docs.databricks.com/aws/en/data-governance/unity-catalog/filters-and-masks) is a SQL function attached to the table that evaluates each row at query time, usually with `is_account_group_member()` against the account groups your Entra groups sync into, and a column mask covers what object‑level security did. Whether a viewer feels it depends on how the dashboard is [published](https://docs.databricks.com/aws/en/dashboards/share/share). Under Individual data permissions, viewers run queries with their own credentials and the filters apply per person; under Share data permissions, the default, every viewer sees the publisher's view. A dashboard that carried RLS in Power BI has to be published in the individual mode. The Genie companion reads the dashboard's datasets under the same publish mode: with shared permissions it sees the publisher's rows, including ones no widget shows, so restricted datasets need the individual mode for that reason too. [Row‑level security to Unity Catalog](https://getantares.io/tableau-row-level-security-to-unity-catalog/) goes through the publish modes in detail.

## Databricks' own import, and where a migration tool fits

Databricks ships an importer. Genie Code's `/importBI` command [accepts](https://docs.databricks.com/aws/en/dashboards/manage/import-bi) a Power BI template, a `.pbit` file, alongside Tableau workbook and data source files, and builds an AI/BI dashboard connected to local metric views, creating dashboard relationships where it finds them in the source. A [template](https://learn.microsoft.com/en-us/power-bi/create-reports/desktop-templates) is exported from Power BI Desktop and holds the model definition, the queries and the pages without any data, which is why it is the accepted format and a `.pbix` is not. Direct uploads are capped at 100 MB, the agent works conversationally and asks for a screenshot for layout fidelity, and the documentation carries no list of which DAX constructs convert, so checking what each report lost stays with you.

## Phases and validation

| Phase | What it produces | Where it goes wrong |
| --- | --- | --- |
| Inventory | Every report with its pages, measures, sources and viewers | Counting reports instead of the pages people open |
| Land the data | The tables each report needs, reachable through Unity Catalog as Delta tables or federated foreign tables | Treating this as dashboard work; it is a data platform project and comes first |
| Model | Base views and metric views with the DAX translated | Translating into each dashboard's SQL instead of once |
| Build the dashboards | One dashboard per report or per page, filters and drill‑through rebuilt | **Redesign**ing while converting |
| Validate | Measures tied out under filters and per viewer, in the publish mode you will ship | Testing the draft, where the viewer's own permissions always apply |
| Cut over | Viewers moved, schedules set, the Power BI workspace read‑only | Both platforms live indefinitely |

Validate in the published dashboard, not the draft: for a draft the viewer's own data permissions always apply, so a security check that passes there can fail in a dashboard published with shared permissions. Reconcile at the grand total, then under the filter combinations users actually apply, then per role; year‑to‑date and share‑of‑total measures are where the two platforms part ways. Microsoft's [scanner APIs](https://learn.microsoft.com/en-us/fabric/governance/metadata-scanning-overview), once an admin enables them, supply the inventory, measures and their DAX included, and a report saved as a Power BI project holds the same definitions as plain‑text files.

## What Antares does on this route

Everything above holds whichever tool you use; this section is about Antares, a BI migration tool [listed on the Databricks Marketplace](https://marketplace.databricks.com/details/90d24b77-11c2-4a72-be14-0a1b3026fae9/Tier-One-Analytics_Antares-BI-Migration-Automation). The [Analyzer](https://getantares.io/analyzer/) is free, and its Power BI side is generally available: upload a `.pbix` file or a zipped PBIP project, one report per analysis, choose Databricks AI/BI as the target, and it returns a complexity score, a migration difficulty score for AI/BI, the main considerations and a component inventory. A `.pbix` can carry imported data; the Analyzer works from the report and model structure and does not copy data rows into its results. Measures are rated on what makes them hard to move, with context transition, measure switching and windowed ranking at the top, and an expression the parser cannot read is left unclassified rather than scored.

Conversion from Power BI to Databricks AI/BI is in private beta and is not self‑serve; the [Converter page](https://getantares.io/converter/) takes requests for beta access, and the home page keeps the [current list of routes](https://getantares.io/#capabilities). Antares is not a data migration tool: it does not move data into Delta tables or build the lakehouse, and the tables have to be reachable through Unity Catalog first. [Run the free Analyzer](https://try.getantares.io) on a report to see what moves.

Related reading: [Tableau to Databricks AI/BI](https://getantares.io/tableau-to-databricks-ai-bi-migration/), [Power BI to Tableau](https://getantares.io/power-bi-to-tableau-migration/), [AI/BI next to Tableau](https://getantares.io/databricks-ai-bi-vs-tableau/) and [BI migration approaches](https://getantares.io/bi-migration/). Primary sources: Databricks on [datasets](https://docs.databricks.com/aws/en/dashboards/manage/data-modeling/datasets), [metric views](https://docs.databricks.com/aws/en/uc-semantics/metric-views/), [custom calculations](https://docs.databricks.com/aws/en/dashboards/manage/data-modeling/custom-calculations/), [row filters and column masks](https://docs.databricks.com/aws/en/data-governance/unity-catalog/filters-and-masks), [publishing and sharing](https://docs.databricks.com/aws/en/dashboards/share/share) and [importing BI files](https://docs.databricks.com/aws/en/dashboards/manage/import-bi); Microsoft on [CALCULATE](https://learn.microsoft.com/en-us/dax/calculate-function-dax), [templates](https://learn.microsoft.com/en-us/power-bi/create-reports/desktop-templates) and [row‑level security](https://learn.microsoft.com/en-us/fabric/security/service-admin-row-level-security).

## Related resources

- [Tableau to Databricks AI/BI Migration](https://getantares.io/tableau-to-databricks-ai-bi-migration/)
- [Power BI to Tableau Migration](https://getantares.io/power-bi-to-tableau-migration/)
- [Databricks AI/BI vs Tableau](https://getantares.io/databricks-ai-bi-vs-tableau/)
- [Tableau Row-Level Security to Unity Catalog](https://getantares.io/tableau-row-level-security-to-unity-catalog/)
- [Tableau LOD Expressions in Databricks SQL](https://getantares.io/tableau-lod-expressions-to-databricks-sql/)

## FAQ

### What has to be in Unity Catalog before a Power BI report can move to Databricks AI/BI?

Every table the report's semantic model reads has to be reachable through Unity Catalog, as a Delta table or a federated foreign table, because dashboard datasets are SQL run on a SQL warehouse against the catalog. Getting them there is a data platform project that runs ahead of the dashboard work; a migration tool converts the report and its measures, it does not load tables or build the lakehouse.

### Does Databricks import .pbix files?

Not as of October 2026. Genie Code's import command lists .pbit, the Power BI template format, which holds the model, queries and pages without data. Export one from Power BI Desktop and the importer builds a dashboard with local metric views. The documentation does not say which DAX constructs survive, so the result is checked report by report.

### What happens to DAX measures in Databricks AI/BI?

They become SQL: measures in a metric view, calculated measures on a dataset, or columns in dataset SQL. Plain aggregates translate directly. Share‑of‑total and per‑entity patterns become window functions or AGGREGATE OVER expressions, time intelligence needs a date dimension and a cumulative window partitioned by year, and calculation groups are rebuilt one item at a time.

### Does Power BI row-level security carry over to Databricks dashboards?

The rules are rebuilt as Unity Catalog row filters and column masks, so they apply to every tool that reads the table, not only the dashboard. They take effect for viewers only when the dashboard is published with Individual data permissions; under the default Share data permissions everyone sees the publisher's view.

### Can we keep Power BI and point it at Databricks instead of migrating?

Yes, and many teams do for part of the estate. Power BI connects to a SQL warehouse through Partner Connect or the connector, DirectQuery respects Unity Catalog permissions, and Databricks can publish tables as a Power BI semantic model. Migration makes sense for dashboards whose measures should live in the catalog or whose viewer population makes per‑seat licensing the larger cost.

### Can Antares convert Power BI reports to Databricks AI/BI today?

Analysis is available and free: upload a .pbix or a zipped PBIP project and get a complexity score and a migration difficulty score for Databricks AI/BI. Conversion on this route is in private beta rather than self‑serve; the Converter page takes requests, and the home page shows the current status of every route.

---

## BI Migration: What It Is, How Teams Approach It, and What Stays Hard

Canonical: https://getantares.io/bi-migration/
Published: 2026-09-30
Updated: 2026-10-02

A BI migration moves the reporting layer of an organization from one business intelligence platform to another: the dashboards people open, the calculations and models behind them, and the rules about who sees what. The data itself usually stays where it is. That distinction matters, because a BI migration is often confused with two things that share its vocabulary: a data migration, which moves rows between systems, and a move inside one vendor, such as Tableau Server to Tableau Cloud, where the artifacts keep their format and the vendor ships the tooling.

## Why do teams migrate BI tools?

Four reasons come up most often. A licensing renewal makes the cost of the incumbent visible on one line, next to a cheaper or already‑owned platform. A consolidation decision, often after an acquisition, leaves the company running two or three BI tools and wanting one. The data platform pulls the reporting layer toward it, which is why Databricks and Microsoft each publish guidance for arriving from other tools. And sometimes the team that knew how to run the incumbent has left. Microsoft's [migration guidance](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-overview) names the same drivers: standardizing away from several tools, lowering cost of ownership, doing more with fewer people. None of them settles the shape of the project.

## What are the approaches to a BI migration?

| Approach | What it means | Fits when | What it costs you |
| --- | --- | --- | --- |
| Rebuild | Treat each old dashboard as a requirements document and author the new one from scratch | Small estate, or a redesign was overdue anyway | The most hours per dashboard; each one becomes a small project |
| Lift‑and‑shift | Reproduce each dashboard as faithfully as the target allows, no redesign | Regulated reporting, or users who need the same screen on Monday | Inherits every flaw, and some things cannot be reproduced at all |
| Rationalize, then convert | Retire what nobody opens, merge duplicates, then move what remains | Large estates that grew for years without pruning | An inventory and usage study before any dashboard moves |
| Automated conversion with review | A tool regenerates the model and report from the source definition; people review what it flags | Hundreds of dashboards with repeating patterns | Review capacity; output reproduces function, not pixel layout |

These are not exclusive. In practice a project mixes them: rationalize first, convert the bulk, rebuild the most‑viewed few, lift‑and‑shift what regulation freezes ([automated versus manual](https://getantares.io/automated-vs-manual-tableau-migration/) works through the economics of that mix). Microsoft's guidance says *it's rare that a direct one‑to‑one migration occurs without any refactoring or enhancement*, and its customer write‑ups note that not every report could be faithfully replicated. The mix is decided dashboard by dashboard.

## What are the phases of a BI migration?

Microsoft frames a migration as pre‑migration steps plus five stages: gather requirements and prioritize, plan deployment, conduct a proof of concept, create and validate content, then deploy, support and monitor. Whichever vendor is on the receiving end, the work falls into six phases.

| Phase | Output | The mistake to avoid |
| --- | --- | --- |
| Inventory and usage | Every dashboard, its sources, its viewers, its last open date | Counting workbooks instead of what people actually open |
| Scope and prioritize | A ranked list: what moves first, what moves later, what retires | Migrating everything because nobody will sign off on retiring anything |
| Proof of concept | A few representative dashboards, end to end, numbers reconciled | Picking the easy ones, which proves nothing about the estate |
| Convert or build | Models, measures and report pages on the target | Starting the bulk before modeling and naming conventions on the target are fixed |
| Validate | Old and new agree under filters, dates and security roles | Checking totals only; the discrepancies live in the details |
| Cut over and decommission | Users moved, the old platform read‑only, then off | Leaving both platforms live indefinitely, which doubles the cost the migration was meant to remove |

The last phase is the one the business cares about, because the decommission date is when the old license stops; sequence everything earlier backward from it.

## What makes BI migration hard, whatever the platforms?

Five problems recur whatever the source and target pair, and they are the ones estimates get wrong.

| Problem | Why it is hard | What decides it |
| --- | --- | --- |
| Where the logic lives | Every platform puts calculations somewhere different: a worksheet, a measure on a shared model, a SQL dataset, a metric view | A per‑calculation decision about its home on the target, made before the bulk conversion starts |
| Calculations with no equivalent | Level of detail expressions, table calculations, set actions and time intelligence each exist on some platforms and not others | An inventory that names them before anyone commits to a date; they are redesigned, not translated |
| Security | Row‑level rules are rebuilt against a different identity model every time | Testing per role before cutover; it is the first thing an auditor asks for afterwards |
| Validation | Two dashboards with the same total can still disagree under a filter, on a fiscal calendar, or for a user in a restricted role | Reconciliation under filters and roles, not totals; this is where projects that looked finished find out they were not |
| Adoption | Microsoft's customer notes say the challenges left after migration were skills, time and funding rather than the platform; its migration overview warns that experts in the old tool may feel displaced | Training, a support path and a communication plan, budgeted like the conversion itself |

The pair‑specific pages go into each of these for one source and target: [LOD expressions to DAX](https://getantares.io/tableau-lod-expressions-to-dax/), [row‑level security to Unity Catalog](https://getantares.io/tableau-row-level-security-to-unity-catalog/), [table calculations in Databricks AI/BI](https://getantares.io/tableau-table-calculations-to-databricks/).

## How do you choose a BI migration approach?

Measure the estate before choosing. Three measurements decide most of it. **The share of dashboards anyone opens.** In one migration Microsoft documents, about half of thousands of published reports had been accessed in the previous year, and the set that delivered significant value was half of that again; an estate with that profile is a rationalization project first. **The spread of complexity.** If most dashboards are a few standard charts on one source, automated conversion pays off and rebuild effort concentrates on the few that are not; if every dashboard is a bespoke analytical application, the plan is closer to a rebuild. **The reliability of per‑dashboard estimates**, which is low. The same write-up records a report estimated at 50 days that took about 50 hours, and concludes that estimates are *most valuable in the aggregate*. So measure the whole estate and size the project from the distribution, not from individual estimates. Cost and duration for the Tableau to Power BI case are worked through on their own pages: [cost estimation](https://getantares.io/tableau-migration-cost-estimation/) and [how long a migration takes](https://getantares.io/how-long-does-tableau-to-power-bi-migration-take/), and the [migration cost calculator](https://getantares.io/tableau-to-power-bi-migration-cost-calculator/) prices a manual rebuild against conversion from your own dashboard count and complexity mix.

## BI migration services, tools or both: which do you need?

BI migration solutions on the market fall into four kinds, and as of September 2026 they are not interchangeable. Vendor‑native importers move content toward the vendor who wrote them: Databricks' [Genie Code importer](https://docs.databricks.com/aws/en/dashboards/manage/import-bi) accepts Tableau workbook and data source files and Power BI template (`.pbit`) files and builds AI/BI dashboards, while Tableau's [Content Migration Tool](https://help.tableau.com/current/server/en-us/cmt-intro.htm) moves content between Tableau sites. Conversion tools read the source definition and generate the target artifacts across vendors. Services firms and systems integrators run the project, usually with an accelerator of their own inside. In‑house teams do the work by hand, the right answer for a small estate with the target skills present. [Consultant versus tool](https://getantares.io/tableau-migration-consultant-vs-tool/) works through the choice, and [the partner program](https://getantares.io/partners/) is where tool and integrator meet.

## What Antares does

This is the product‑dependent section; everything above holds whichever tool you use. Antares is the [BI migration tool](https://getantares.io/) behind this library, and it automates the convert phase with two modules. The **Analyzer** works from metadata, whether it connects read‑only to the source environment or takes an uploaded report file, and does not copy business data into its results. It returns the inventory the phases above depend on: usage where the source exposes it, complexity, data sources, and which dashboards carry constructs that will not translate mechanically. It is free and fully deterministic. The **Converter** is deterministic‑first with guardrailed, validated AI steps, and converts and deploys dashboards at a flat 200 USD (or 200 EUR) per source dashboard, LLM costs on top, typically under 20 USD (or 20 EUR).

Each supported source and target pair has its own guide, such as [Tableau to Power BI](https://getantares.io/tableau-to-power-bi-migration/) and [Tableau to Databricks AI/BI](https://getantares.io/tableau-to-databricks-ai-bi-migration/), and the home page keeps [the current list of routes](https://getantares.io/#capabilities). It is not a data migration tool and it does not redesign dashboards: the output is like for like, one source dashboard becoming one Power BI report page or one AI/BI dashboard. See the [Analyzer](https://getantares.io/analyzer/) and [Converter](https://getantares.io/converter/) pages, or [run the free Analyzer](https://try.getantares.io) on your own estate.

Primary sources: Microsoft's [Power BI migration overview](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-overview), [requirements stage](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-requirements) and [customer lessons](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-learn-from-customers); Databricks on [importing Tableau and Power BI files](https://docs.databricks.com/aws/en/dashboards/manage/import-bi); Tableau on the [Content Migration Tool](https://help.tableau.com/current/server/en-us/cmt-intro.htm).

## Related resources

- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [Tableau to Databricks AI/BI Migration](https://getantares.io/tableau-to-databricks-ai-bi-migration/)
- [Automated vs Manual Migration](https://getantares.io/automated-vs-manual-tableau-migration/)
- [Consultant vs Tool](https://getantares.io/tableau-migration-consultant-vs-tool/)
- [Power BI to Tableau Migration](https://getantares.io/power-bi-to-tableau-migration/)
- [Power BI to Databricks AI/BI Migration](https://getantares.io/power-bi-to-databricks-ai-bi-migration/)

## FAQ

### What is BI migration?

Moving an organization's reporting layer from one business intelligence platform to another: dashboards, the calculations and semantic models behind them, and access rules. The underlying data normally stays put, which separates it from a data migration, and it crosses vendors, which separates it from moving between sites of the same product.

### Is BI migration the same as data migration?

No. A data migration moves rows between storage systems; a BI migration moves what is built on top of them. The two are often scheduled together, but running them at once means every mismatched number has two possible causes. Sequencing the BI layer against the existing data, then moving data later, is usually cheaper to validate.

### Which BI migration approach is cheapest?

For a small estate, an in-house rebuild. Above a few dozen dashboards, rationalizing first is the biggest saving available, because a large share of most estates is never opened; automated conversion with review then handles the bulk, and rebuild effort is spent only on the dashboards that carry the most viewers.

### Can BI migration be automated?

Partly. The model, standard visuals, filters and most calculations can be generated from the source definition, and that is the bulk of the hours. Constructs with no equivalent on the target, security rules and the validation that old and new agree still need people. Vendor-native importers exist too, but each moves content toward its own vendor.

### Do we need a BI migration service, or can we do it in-house?

In-house is realistic when the estate is under a few dozen dashboards and the target platform's skills already exist. A services firm is the answer when nobody internal can run a multi-month program, or when change management for hundreds of viewers is the real work. Ask any firm which accelerator it uses and what its output needs reviewed.

---

## Tableau LOD Expressions in Databricks SQL, AI/BI Dashboards and Metric Views

Canonical: https://getantares.io/tableau-lod-expressions-to-databricks-sql/
Published: 2026-09-07
Updated: 2026-09-07

Databricks AI/BI dashboards have level of detail expressions of their own, and two of Tableau's three keywords land on them directly. `FIXED` becomes a scalar window function: `SUM(Sales) OVER (PARTITION BY Region)`. `EXCLUDE` becomes the coarser form: `SUM(Sales) AGGREGATE OVER (PARTITION BY * EXCEPT (Region))`. `INCLUDE` has no named keyword in a dashboard calculation, so it gets modeled in the dataset query instead.

Where the calculation ends up decides more than the syntax: a custom calculation, a dataset-SQL window and a metric view can return the same number and meet a dashboard filter at different moments. Databricks added [level of detail expressions for custom calculations](https://docs.databricks.com/aws/en/dashboards/manage/data-modeling/custom-calculations/level-of-detail) on [January 19, 2026](https://docs.databricks.com/aws/en/ai-bi/release-notes/2026); limits and dates here are as of September 2026.

## Where a Tableau LOD lands in Databricks AI/BI

Databricks names two kinds: **fixed**, on scalar window functions, and **coarser**, on aggregate window functions. Tableau names three. Two terms in the third column: a calculated dimension is a row-level column added to a dataset, and a calculated measure re-aggregates with whatever the chart groups by.

| Tableau LOD | Databricks AI/BI form | Where it lives, and how filters reach it |
| --- | --- | --- |
| `{FIXED [Region] : SUM([Sales])}` | `SUM(Sales) OVER (PARTITION BY Region)` | Calculated dimension, computed before visualization groupings and filters |
| `{FIXED : SUM([Sales])}` | `SUM(Sales) OVER ()`, wrapped as `SUM(Sales) / ANY_VALUE(total)` | Two custom calculations, denominator fixed under any grouping |
| `{EXCLUDE [Region] : SUM([Sales])}` | `SUM(Sales) AGGREGATE OVER (PARTITION BY * EXCEPT (Region))` | Calculated measure, respecting visualization filters except on the excluded dimension |
| Nested: `{FIXED [Region] : AVG({FIXED [Region],[Month] : SUM([Sales])})}` | Pin the inner grain in dataset SQL, then aggregate it in a measure | Dataset SQL plus a measure, inner grain fixed and outer following the visual |
| `{INCLUDE [Customer] : SUM([Sales])}`, re-aggregated as `AVG` | No dashboard keyword: group at customer grain in the dataset query | Dataset SQL, so verify filter behavior |

A nested LOD usually splits in two, on Databricks' own percent-of-total pattern: the pinned part as a dimension calculation, the outer part as a measure that references it. Percent of total itself, and anything mixing an LOD with a running total or a rank, lives on [table calculations](https://getantares.io/tableau-table-calculations-to-databricks/). Plain formulas are on [calculated fields](https://getantares.io/tableau-calculated-fields-to-databricks-sql/).

## How FIXED converts

Tableau's `FIXED` pins aggregation to the dimensions you name, and Databricks does the same with [SQL window functions](https://docs.databricks.com/aws/en/sql/language-manual/sql-ref-window-functions): `PARTITION BY` carries the pinned dimensions, and empty parentheses after `OVER` give the grand total. A fixed expression is a dimension, so using it inside a measure means wrapping it in an aggregate such as `ANY_VALUE`. A FIXED over `COUNTD` needs `ARRAY_SIZE` with `COLLECT_SET`, because `DISTINCT` is not allowed in a scalar window function.

Filters are where a converted number drifts quietly. Tableau states that [FIXED expressions](https://help.tableau.com/current/pro/desktop/en-us/calculations_calculatedfields_lod.htm) ignore every filter in the view other than context, data source and extract filters. Databricks states that fixed LOD expressions are computed before visualization groupings and filters are applied.

Making one respond to a dashboard filter means defining that filter as a [dashboard parameter](https://docs.databricks.com/aws/en/dashboards/manage/filters/parameters) , a named marker substituted into the dataset query text, `:region`. Inside a custom calculation it is referenced as `:keyword`, supported since [March 26, 2026](https://docs.databricks.com/aws/en/ai-bi/release-notes/2026). The context filter a FIXED expression respected maps to a parameter; the quick filter it ignored maps to a field filter. Read the worksheet's filters, not only the formula.

## How EXCLUDE converts

`EXCLUDE` drops a dimension the view already has and reports a coarser total on every row. The Databricks coarser form says the same from the other end: `PARTITION BY *` inherits the visualization's grouping, and `EXCEPT (...)` lists what to take back out. Multiple fields in one `EXCEPT` have been supported since [February 12, 2026](https://docs.databricks.com/aws/en/ai-bi/release-notes/2026). Databricks points the coarser form at calculations that should follow the visualization's own filters, where Tableau's EXCLUDE already sat; the exemption above applies to FIXED alone. The full filter-timing rule is on [table calculations](https://getantares.io/tableau-table-calculations-to-databricks/).

## How INCLUDE converts

INCLUDE has no named keyword in a dashboard custom calculation. Neither documented type adds a dimension the visualization lacks: `OVER` pins a static partition, and `AGGREGATE OVER` only widens the visual's grouping through `EXCEPT`. Finer than the view is the one direction that syntax does not go. The exception arrived one layer down, in metric views, below.

In a dashboard the conversion is modeling, not translation. Group at the finer grain inside the [dashboard dataset query](https://docs.databricks.com/aws/en/dashboards/manage/data-modeling/datasets), one row per customer, and let the visualization aggregate that upward, which is what the outer `AVG` did anyway. Then test the filters against that subquery: a field filter on the dataset result and a parameter substituted before the grouping can disagree.

## Which limits decide where the calculation lives

| [Databricks rule](https://docs.databricks.com/aws/en/dashboards/manage/data-modeling/custom-calculations/), as of September 2026 | What it means for a converted LOD |
| --- | --- |
| Columns must belong to one dataset | An LOD that spanned a blend needs the join done first |
| Up to 200 custom calculations per dataset | A workbook with hundreds of calculated fields will not fit one dataset |
| Table visualizations take calculated dimensions, not calculated measures | A fixed LOD can sit in a table visual, the coarser EXCLUDE form cannot |

A Tableau function absent from Databricks' [custom calculation function reference](https://docs.databricks.com/aws/en/dashboards/manage/data-modeling/custom-calculations/function-reference) moves into the dataset query.

## When the metric view is the better home

Custom calculations are scoped to one dataset and dashboard. A [Unity Catalog metric view](https://docs.databricks.com/aws/en/uc-semantics/metric-views/) is defined once and queried from dashboards, notebooks and alerts. Databricks documents [level of detail expressions in metric views](https://docs.databricks.com/aws/en/uc-semantics/metric-views/level-of-detail) on a page last updated August 17, 2026: a fixed LOD goes in a field's `expr` as a window function, and the coarser form is a window measure declared with `range: all`. The third Tableau keyword landed there on September 10, 2026, when the metric view editor gained Include-style expressions in YAML ([release notes](https://docs.databricks.com/aws/en/ai-bi/release-notes/2026)), ahead of the page itself.

The scoping rule: an LOD used by more than one workbook is a company metric and belongs in a metric view. One that makes a single chart behave stays a custom calculation.

## What Antares does with LOD expressions

LOD expressions have to be found before they can be placed. That is what the free Analyzer does: deterministic, metadata only, changing nothing in the source environment, and listing which workbooks carry them. The Converter is deterministic-first, with guardrailed and validated AI steps, flagging what it cannot verify rather than guessing. Antares is a BI migration tool and stops at the dashboard layer: it does not move data into Delta tables or build the model underneath. [Try a sample conversion](https://try.getantares.io).

The function-level mapping is on [calculated fields to Databricks SQL](https://getantares.io/tableau-calculated-fields-to-databricks-sql/), the running totals and ranks on [table calculations in Databricks AI/BI](https://getantares.io/tableau-table-calculations-to-databricks/), and the order of the whole job on the [migration guide](https://getantares.io/tableau-to-databricks-ai-bi-migration/). The Power BI answer is [Tableau LOD expressions to DAX](https://getantares.io/tableau-lod-expressions-to-dax/). Sources: Databricks on [level of detail expressions](https://docs.databricks.com/aws/en/dashboards/manage/data-modeling/custom-calculations/level-of-detail) and [custom calculations](https://docs.databricks.com/aws/en/dashboards/manage/data-modeling/custom-calculations/), Tableau on [LOD expressions](https://help.tableau.com/current/pro/desktop/en-us/calculations_calculatedfields_lod.htm).

## Related resources

- [Tableau to Databricks AI/BI Migration](https://getantares.io/tableau-to-databricks-ai-bi-migration/)
- [Calculated Fields to Databricks SQL](https://getantares.io/tableau-calculated-fields-to-databricks-sql/)
- [Table Calculations in Databricks AI/BI](https://getantares.io/tableau-table-calculations-to-databricks/)
- [Tableau LOD Expressions to DAX](https://getantares.io/tableau-lod-expressions-to-dax/)

## FAQ

### Does Databricks AI/BI support Tableau LOD expressions?

Databricks AI/BI has its own level of detail expressions, added for custom calculations on January 19, 2026. It names two types: fixed, written as an aggregate with OVER (PARTITION BY dims), and coarser, written as AGGREGATE OVER (PARTITION BY * EXCEPT (dim)). Tableau FIXED and EXCLUDE map onto those two.

### What is the Databricks equivalent of a Tableau FIXED LOD?

A scalar window function in a custom calculation. {FIXED [Region] : SUM([Sales])} becomes SUM(Sales) OVER (PARTITION BY Region). Drop PARTITION BY for a grand total. To use it inside a measure, wrap it in an aggregate such as ANY_VALUE, which is what the Databricks percent-of-total example does.

### How do you convert a Tableau INCLUDE LOD to Databricks?

A dashboard custom calculation has no named keyword for it: Databricks documents only fixed and coarser expressions, and neither adds a dimension the visualization lacks. Group at the finer grain inside the dataset query instead, then let the visualization re-aggregate the result. Unity Catalog metric views gained Include-style LOD expressions in YAML on September 10, 2026, ahead of their documentation.

### Should an LOD expression become a custom calculation or a metric view?

Custom calculations are scoped to one dataset and dashboard, up to 200 per dataset. A Unity Catalog metric view defines the measure once for dashboards, notebooks, alerts and Genie Agents, and documents the same fixed and coarser forms, with an Include-style form added to its editor on September 10, 2026. If the expression appears in several workbooks, put it in the metric view.

---

## Tableau Calculated Fields to Databricks SQL: Function Mapping and Conversion Reference

Canonical: https://getantares.io/tableau-calculated-fields-to-databricks-sql/
Published: 2026-09-08
Updated: 2026-09-08

A Tableau calculated field lands in one of three places in Databricks AI/BI: a column in the dataset SQL, a calculated dimension or measure on the dataset, or a measure in a Unity Catalog metric view. Which one you pick follows from whether the field is row-level, aggregate, or shared across dashboards.

The function names are the easy half. The argument orders and null rules below are what let a converted formula run cleanly and still return a different number.

## Where a calculated field lands in Databricks AI/BI

Tableau keeps every calculation inside the workbook. Databricks AI/BI spreads them across three layers, and the layer you choose decides who else can reuse the logic and when it runs. The third of them, a metric view, is a measure definition stored in Unity Catalog rather than inside a dashboard.

| Tableau calculated field | Where it goes in Databricks AI/BI | Why |
| --- | --- | --- |
| Row-level, used as a dimension, filter, or grouping | A column in the dataset SQL | The value belongs to the data, and other datasets can select it |
| Row-level, needed by one dashboard only | Calculated dimension | Added on the dataset without editing the query |
| Aggregate, such as `SUM`, `AVG`, `COUNTD` | Calculated measure | Re-aggregates automatically against whatever the chart groups by |
| Aggregate reused across dashboards and notebooks | Measure in a Unity Catalog metric view | Defined once, resolved at query time by every consumer |
| LOD expression | Window form of a custom calculation, or dataset SQL | [LOD expressions](https://getantares.io/tableau-lod-expressions-to-databricks-sql/) |
| Table calculation | `AGGREGATE OVER` measure, or a SQL window function | [Table calculations](https://getantares.io/tableau-table-calculations-to-databricks/) |

[Custom calculations](https://docs.databricks.com/aws/en/dashboards/manage/data-modeling/custom-calculations/) are scoped to the dataset and dashboard where they are defined, up to 200 per dataset, and results of 100,000 rows and 100MB or less compute in the browser rather than on the SQL warehouse (as of September 2026). Table visualizations accept calculated dimensions but not calculated measures, which bites in a rebuilt Tableau crosstab. [Dataset queries are read-only](https://docs.databricks.com/aws/en/dashboards/manage/data-modeling/datasets), so logic needing a temporary table belongs upstream.

## How the functions map

Signatures below come from the Databricks SQL language manual and [Tableau's function reference](https://help.tableau.com/current/pro/desktop/en-us/functions_all_categories.htm). Read the notes before any find and replace: `DATEDIFF` reverses its dates in one of its two Databricks forms and keeps them in the other.

| Tableau | Databricks SQL | Note |
| --- | --- | --- |
| `IF ... THEN ... ELSEIF ... ELSE ... END` | `CASE WHEN ... THEN ... ELSE ... END` | Tableau's `CASE [x] WHEN` maps to `CASE expr WHEN` |
| `IIF(test, then, else, [unknown])` | `iff(cond, expr1, expr2)` | Three arguments only; Tableau's optional unknown value needs its own branch |
| `ZN([x])` | `[zeroifnull(x)](https://docs.databricks.com/aws/en/sql/language-manual/functions/zeroifnull)` | A documented synonym for `coalesce(x, 0)`; prefer coalesce, since the `zeroifnull` page is labeled for Databricks Runtime 16.0 and above |
| `IFNULL(a, b)` / `ISNULL([x])` | `ifnull(a, b)`, `nvl(a, b)` or `coalesce(a, b)` / `isnull(x)` | Same argument order in all three; `isnull` returns a boolean |
| `DATEDIFF('day', [start], [end])` | `[datediff(end, start)](https://docs.databricks.com/aws/en/sql/language-manual/functions/datediff)` | **Argument order reverses**, and this form counts whole days only |
| `DATEDIFF('month', [start], [end])` | `[datediff(MONTH, start, end)](https://docs.databricks.com/aws/en/sql/language-manual/functions/datediff3)` | Keeps Tableau's order and takes an unquoted keyword; Databricks counts *whole elapsed units*, so check month and year differences against the workbook |
| `DATETRUNC('month', [d])` / `DATEPART('year', [d])` | `date_trunc('MONTH', d)` / `date_part('YEAR', d)` | Unit is a quoted string literal; `date_trunc` returns a `TIMESTAMP` |
| `DATEADD('month', 3, [d])` | `dateadd(MONTH, 3, d)` | Same order, unquoted unit, timestamp input |
| `CONTAINS` / `STARTSWITH` / `ENDSWITH` | `contains(expr, subExpr)`, `startswith`, `endswith` | Same order; matching is case-sensitive, so `endswith('SparkSQL', 'sql')` is false |
| `SPLIT(string, delimiter, token)` | `split_part(str, delim, partNum)` | A negative part number counts from the right in both |
| `REGEXP_EXTRACT(string, pattern)` | `regexp_extract(str, regexp [, idx])` | `idx` defaults to 1, the first capture group |
| `INT` / `FLOAT` / `STR` / `DATE` | `cast(x AS BIGINT / DOUBLE / STRING / DATE)` | `[try_cast](https://docs.databricks.com/aws/en/sql/language-manual/functions/try_cast)` returns `NULL` instead of failing on bad input |
| `COUNTD([x])` | `count(DISTINCT x)` | `approx_count_distinct(x)` trades exactness for speed |
| `ATTR([x])` | No direct equivalent | Tableau returns an asterisk when values differ; in SQL pick `min(x)` or `any_value(x)` |
| `SUM([a]) / SUM([b])` | `[try_divide(SUM(a), SUM(b))](https://docs.databricks.com/aws/en/sql/language-manual/functions/try_divide)` | Plain division by zero raises `DIVIDE_BY_ZERO` |

## What changes about nulls, dates and types

A formula that compiles is not a formula that agrees with the old dashboard. These differences surface in a total rather than in an error message.

| Difference | What Databricks SQL does | What to write instead |
| --- | --- | --- |
| Nulls in comparisons | `x <> 'A'` is null when `x` is null, so the row fails the test, as in Tableau, but easy to lose when a workbook relied on a `[Field] != 'A'` quick filter | Handle nulls on purpose with `isnull(x)` or `coalesce(x, 'Unknown')` |
| Division by zero | Raises `[DIVIDE_BY_ZERO](https://docs.databricks.com/aws/en/error-messages/divide-by-zero-error-class)`, SQLSTATE 22012, rather than returning a null | `try_divide(a, b)`, which returns `NULL` for a zero divisor |
| Start of week | Weeks start Monday: `date_trunc('WEEK', d)` truncates to Monday | Check any Tableau formula that passed a `start_of_week` argument |
| Date part names | Quoted string for `date_trunc` and `date_part`, unquoted keyword for `dateadd` and unit-form `datediff` | Copy the unit list from each function page |

## When to promote a calculation to a metric view

A [Unity Catalog metric view](https://docs.databricks.com/aws/en/uc-semantics/metric-views/) separates measure definitions from the fields used to group, filter and aggregate them, so a metric is defined once and resolved at query time by notebooks, dashboards, Genie Agents and alerts. A formula that exists to make one chart work is a calculated measure; a formula three teams argue about is a metric view.

In a migration the useful test is duplication. When one revenue definition turns up in eleven workbooks with four slightly different filters, converting each copy faithfully rebuilds the disagreement inside a new tool. Promote the shared definitions first and leave one-off calculations local. Nobody wrote those eleven copies carelessly: a deadline is always closer than a modeling meeting.

## What Antares does with calculated fields

Reading a workbook's calculated fields by hand is the part of scoping nobody wants to do twice. The free Analyzer does that pass deterministically, on metadata alone, without touching the source environment, and returns an inventory of the estate. The Converter is deterministic-first with guardrailed, validated AI steps, and any construct it cannot verify is flagged instead of guessed at.

That division is the whole job of a BI migration tool: the mapping is mechanical, and the judgment calls, including which definitions deserve a metric view, stay yours. Tableau to Databricks AI/BI is a shipped route, at a flat $200 per source dashboard with LLM costs on top, typically under $20. [Try a sample conversion](https://try.getantares.io) before you scope your own workbooks.

Next in this cluster: [LOD expressions in Databricks SQL](https://getantares.io/tableau-lod-expressions-to-databricks-sql/) for the pinned aggregates, [table calculations in Databricks AI/BI](https://getantares.io/tableau-table-calculations-to-databricks/) for the window functions, and the [migration guide](https://getantares.io/tableau-to-databricks-ai-bi-migration/) for the order of the work. The Power BI twin of this page is [Tableau calculated fields to DAX](https://getantares.io/tableau-calculated-fields-to-dax/). Sources: the Databricks [custom calculation function reference](https://docs.databricks.com/aws/en/dashboards/manage/data-modeling/custom-calculations/function-reference), Tableau's [type conversion functions](https://help.tableau.com/current/pro/desktop/en-us/functions_functions_typeconversion.htm) and its guide to [aggregate calculations](https://help.tableau.com/current/pro/desktop/en-us/calculations_aggregation.htm).

## Related resources

- [Tableau to Databricks AI/BI Migration](https://getantares.io/tableau-to-databricks-ai-bi-migration/)
- [LOD Expressions to Databricks SQL](https://getantares.io/tableau-lod-expressions-to-databricks-sql/)
- [Table Calculations to Databricks AI/BI](https://getantares.io/tableau-table-calculations-to-databricks/)
- [Calculated Fields to DAX](https://getantares.io/tableau-calculated-fields-to-dax/)

## FAQ

### Where do Tableau calculated fields go in Databricks AI/BI?

Into one of three homes. Row-level fields used as dimensions belong in the dataset SQL or as a calculated dimension. Aggregate fields become calculated measures on the dataset. Definitions shared across dashboards, notebooks and Genie Agents belong in a Unity Catalog metric view, where they are resolved at query time.

### Does Databricks SQL DATEDIFF work like Tableau DATEDIFF?

Not in its two-argument form. Tableau writes DATEDIFF('day', start, end); the Databricks two-argument datediff(end, start) reverses those dates and counts whole days only. The unit form, datediff(unit, start, end), keeps Tableau's order and takes an unquoted keyword such as MONTH or QUARTER.

### What replaces ZN and IFNULL in Databricks SQL?

ZN(x) becomes zeroifnull(x), which Databricks documents as a synonym for coalesce(x, 0); coalesce is the portable form, since the zeroifnull page is labeled for Databricks Runtime 16.0 and above. IFNULL(a, b) becomes ifnull(a, b), nvl(a, b) or coalesce(a, b), all with the same argument order. For ratios, try_divide returns NULL rather than raising DIVIDE_BY_ZERO.

### Should a converted calculation be a custom calculation or a metric view?

Custom calculations are scoped to one dataset on one dashboard, capped at 200 per dataset as of September 2026. That fits a formula serving a single chart. A definition several dashboards depend on belongs in a Unity Catalog metric view, so Genie Agents and notebooks answer from the same numbers.

---

## Tableau Table Calculations in Databricks AI/BI: Running Totals, Ranks, and Window Functions

Canonical: https://getantares.io/tableau-table-calculations-to-databricks/
Published: 2026-09-08
Updated: 2026-09-08

In Databricks AI/BI, a Tableau table calculation has two possible homes, computing at different moments. A calculated measure written with `AGGREGATE OVER` runs after the visualization groups its data. A window function written into the dataset SQL runs before dashboard field filters reach the result. Choosing the wrong home is the usual reason a converted total stops matching.

## Where a table calculation runs in Databricks AI/BI

Tableau states the rule plainly: a table calculation "computes on the local data", and table calculations "do not consider any measures or dimensions that are filtered out of the visualization", per Tableau's [documentation](https://help.tableau.com/current/pro/desktop/en-us/calculations_tablecalculations.htm). The marks left in the view are the input.

The [custom calculations page](https://docs.databricks.com/aws/en/dashboards/manage/data-modeling/custom-calculations/) splits that in two. Scalar window functions use `OVER` and aggregate "before being joined back to the untransformed underlying table as a dimension". Aggregate window functions use `AGGREGATE OVER` and "compute windowed aggregations after visualization grouping has been applied".

With the dataset query, that makes three places for the arithmetic. Databricks points `AGGREGATE OVER` at calculations that should respect visualization filters, and the scalar `OVER` form at calculations "that must ignore all visualization groupings and filters". The third differs again: a window written into [dataset SQL](https://docs.databricks.com/aws/en/dashboards/manage/data-modeling/datasets) has already run when a field filter arrives, while a parameter substituted into that query changes what the window sees. Which control to reach for is on [parameters in Databricks AI/BI](https://getantares.io/tableau-parameters-to-databricks-ai-bi-parameters/). The docs do not cover every combination, so tie one number out at two filter states.

| Tableau | AI/BI custom calculation | Dataset SQL alternative |
| --- | --- | --- |
| `RUNNING_SUM(SUM([Sales]))` | `SUM(Sales) AGGREGATE OVER (ORDER BY Date CUMULATIVE)` | `SUM(sales) OVER (ORDER BY Date RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)` |
| `WINDOW_AVG(SUM([Sales]), -2, 0)` | No direct equivalent: divide a windowed `SUM` by the number of periods | `AVG(daily_sales) OVER (ORDER BY day ROWS 2 PRECEDING)` |
| `TOTAL(SUM([Sales]))` | `SUM(Sales) AGGREGATE OVER (PARTITION BY * EXCEPT (Product))`, the `EXCEPT` list being whatever Compute Using totalled over; `AGGREGATE OVER (ORDER BY Date ALL)` is the other documented total | `SUM(sales) OVER (PARTITION BY Region)` |
| `SUM([Sales]) / TOTAL(SUM([Sales]))`, the Percent of Total quick table calculation | `SUM(Sales) / (SUM(Sales) AGGREGATE OVER (PARTITION BY * EXCEPT (Region)))` | `SUM(Sales) / SUM(SUM(Sales)) OVER ()` |
| `LOOKUP(SUM([Sales]), -1)` | No offset function; a one-period `TRAILING` range gives the previous period's aggregate | `LAG(sales) OVER (ORDER BY Date)` |
| `RANK`, `RANK_DENSE` | `RANK()` and `DENSE_RANK()`, ranking rows rather than marks | Rank a pre-aggregated query |
| Top N on a table calculation | Not documented | `QUALIFY RANK() OVER (PARTITION BY Region ORDER BY Sales DESC) = 1` |

## How running totals and moving windows convert

Running totals convert almost mechanically. Databricks documents `CUMULATIVE` as the equivalent of `RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW`, current mark included, as in Tableau's `RUNNING_SUM`.

Moving windows are where numbers drift. `WINDOW_AVG(SUM([Sales]), -2, 0)` averages three already aggregated marks. `TRAILING` and `LEADING` count time instead, in units of `DAY`, `MONTH` or `YEAR`, and they default to `EXCLUSIVE`, so add `INCLUSIVE` wherever the Tableau window ended at `0`. Check what a gap does too: a mark-counted window steps over an empty period and a time-counted window counts it, the tolerance Databricks gives as the reason to prefer the time form.

One correction matters more than the syntax. `AGGREGATE OVER` re-evaluates the aggregate over every row in its frame, so `AVG(Sales)` across a trailing range returns the row-level mean, not the mean of the daily totals Tableau was averaging. Divide a windowed `SUM` by the number of periods instead, or pre-aggregate to one row per day in the dataset query and average that with a [window frame](https://docs.databricks.com/aws/en/sql/language-manual/sql-ref-syntax-window-functions-frame) such as `ROWS 2 PRECEDING`, which ends at the current row. An `OFFSET` clause shifts a whole range, so `TRAILING 7 DAY OFFSET -1 YEAR` reads a year back.

## How ranks, LOOKUP and percent of total convert

Ranking needs the most care, because Tableau ranks the marks and the AI/BI ranking functions do not. All ranking and analytic window functions are supported in custom calculations, per the [function reference](https://docs.databricks.com/aws/en/dashboards/manage/data-modeling/custom-calculations/function-reference), but they belong to the scalar `OVER` family that computes before grouping. Ranking what a viewer sees means ranking an already aggregated result in dataset SQL.

Direction is the second trap, and it inverts a leaderboard without erroring. Tableau's `RANK` and `RANK_DENSE` default to descending, so the largest value ranks 1, while the example in Databricks' [QUALIFY reference](https://docs.databricks.com/aws/en/sql/language-manual/sql-ref-syntax-qry-select-qualify) ranks the smallest quantity 1. Add `DESC` to match. `RANK_PERCENTILE` defaults to ascending, lowest value at 0.

The documented percent-of-total pattern is `SUM(Sales) / (SUM(Sales) AGGREGATE OVER (PARTITION BY * EXCEPT (Region)))`. The nested form `SUM(Sales) / SUM(SUM(Sales)) OVER ()` also works for decomposable aggregates, though Databricks warns against it in a pivot table, where values get counted twice. `LOOKUP` with a negative offset has two answers: `LAG` at row level, or a one-period `TRAILING` range for an aggregated mark.

## Why partitioning and addressing become PARTITION BY

Tableau gives every dimension in the view one of two jobs. "Partitioning fields break the view up into multiple sub-views", and the remaining addressing fields "determine the direction of the calculation". None of it lives in the formula text, and in AI/BI the partition is inherited rather than declared.

| Tableau setting | What it controls | Databricks AI/BI |
| --- | --- | --- |
| Addressing (Compute Using) | The direction the calculation moves | `ORDER BY` inside `AGGREGATE OVER` or `OVER` |
| Partitioning (Restarting every) | Where the calculation resets | The visualization grouping picked up by `PARTITION BY *` |

Two limits bound custom calculations, as of September 2026. The [custom calculations page](https://docs.databricks.com/aws/en/dashboards/manage/data-modeling/custom-calculations/) caps them at 200 per dataset and notes that table visualizations take calculated dimensions but not calculated measures. The [dashboard limits page](https://docs.databricks.com/aws/en/dashboards/limits) puts chart rendering at 15,000 rows and tables at 100,000 rows before truncation; the visualization types page gives a lower table figure, so treat 100,000 as the ceiling and test.

## What Antares does with table calculations

Addressing settings are the reason a table-calculation inventory cannot be built with a text search, and that is where a BI migration tool earns its keep on this route: the free Analyzer is deterministic, reads workbook metadata only, and lists which workbooks carry table calculations.

Where a partition cannot be resolved from the workbook, the Converter flags it for a person instead of guessing, because a guessed partition returns a plausible wrong number rather than an error. It is deterministic-first, with guardrailed and validated AI steps that can run against your own private LLM endpoints. Nothing in the Tableau environment changes. [Try a sample conversion](https://try.getantares.io) on a dashboard you know well.

Two neighbors finish the story: [LOD expressions in Databricks SQL](https://getantares.io/tableau-lod-expressions-to-databricks-sql/) for pinned grains, and [calculated fields to Databricks SQL](https://getantares.io/tableau-calculated-fields-to-databricks-sql/) for row-level formulas. Sequencing is on the [migration guide](https://getantares.io/tableau-to-databricks-ai-bi-migration/), and the DAX version of this mapping is [Tableau table calculations to DAX](https://getantares.io/tableau-table-calculations-to-dax/). Sources: Databricks' [custom calculations](https://docs.databricks.com/aws/en/dashboards/manage/data-modeling/custom-calculations/), [level of detail](https://docs.databricks.com/aws/en/dashboards/manage/data-modeling/custom-calculations/level-of-detail) and [window functions](https://docs.databricks.com/aws/en/sql/language-manual/sql-ref-window-functions) pages, and Tableau's [table calculation functions](https://help.tableau.com/current/pro/desktop/en-us/functions_functions_tablecalculation.htm).

## Related resources

- [Tableau to Databricks AI/BI Migration](https://getantares.io/tableau-to-databricks-ai-bi-migration/)
- [LOD Expressions to Databricks SQL](https://getantares.io/tableau-lod-expressions-to-databricks-sql/)
- [Calculated Fields to Databricks SQL](https://getantares.io/tableau-calculated-fields-to-databricks-sql/)
- [Table Calculations to DAX](https://getantares.io/tableau-table-calculations-to-dax/)

## FAQ

### What is the Databricks equivalent of RUNNING_SUM?

A calculated measure using the CUMULATIVE frame keyword: SUM(Sales) AGGREGATE OVER (ORDER BY Date CUMULATIVE). Databricks documents CUMULATIVE as the equivalent of RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW, so the current mark is included, as it is in Tableau. The same frame works in dataset SQL, but it computes before dashboard field filters apply.

### How do you write a moving average like WINDOW_AVG in Databricks AI/BI?

Not as a single keyword. WINDOW_AVG(SUM([Sales]), -2, 0) averages three already aggregated marks, while AGGREGATE OVER re-evaluates the aggregate across every row in its frame. Divide a windowed SUM by the number of periods, or pre-aggregate to one row per day in the dataset query and average that with a ROWS frame. TRAILING and LEADING also count time rather than marks and default to EXCLUSIVE.

### Do Databricks AI/BI window calculations respect dashboard filters?

It depends on the syntax. Databricks recommends AGGREGATE OVER for window calculations that respect visualization filters, and the scalar OVER form for calculations that must ignore all visualization groupings and filters. A window inside dataset SQL runs before a field filter reaches it, though a parameter substituted into that query does change the result.

### What replaces Tableau's Compute Using setting in Databricks AI/BI?

The visualization's own grouping, read through PARTITION BY * with an EXCEPT list, plus ORDER BY for direction. Tableau's addressing and partitioning choices live in the worksheet rather than the formula text, so plan on opening each workbook instead of counting formulas when you scope this work.

---

## Tableau Parameters, Filters and Actions in Databricks AI/BI Dashboards

Canonical: https://getantares.io/tableau-parameters-to-databricks-ai-bi-parameters/
Published: 2026-09-09
Updated: 2026-09-09

In Databricks AI/BI, Tableau's filters, parameters and actions collapse into three mechanisms: field filters that act on dataset results, parameters substituted into dataset SQL as `:name`, and cross-filtering or drill-through between visuals built on the same dataset. The first decision on every dashboard is filter on a field or filter on a parameter.

A field filter acts on the resolved dataset result. A parameter is substituted into the query text before it runs. Almost every difference below follows from those two sentences; the docs behind them were read in September 2026.

## Where each Tableau control lands in Databricks AI/BI

| Tableau | Databricks AI/BI | Note |
| --- | --- | --- |
| Quick filter | Field filter widget | Six types, at global, page or widget scope |
| Context or data source filter | Widget-level filter, or a `WHERE` clause in the dataset | Widget-level values are fixed by the author |
| Relative date filter | Date range picker, relative mode | `now-30d/d`, re-evaluated each run |
| Parameter inside a calculation | Dashboard parameter written `:name` | String, Date, Date and Time or Numeric |
| Parameter plus CASE to swap a measure | Dashboard variable | Added June 4, 2026; works with metric views |
| Filter action | Cross-filtering | Visuals on the same dataset only |
| Go to Sheet action | Drill-through | Right-click, then Drill to a target page |

## Field filter or parameter: the first decision

Databricks publishes [its own comparison](https://docs.databricks.com/aws/en/dashboards/manage/filters/) of the two.

| Behavior | Field filter | Parameter |
| --- | --- | --- |
| Where it acts | On the resolved result, in a CTE at the end of the query | Substituted into the query at runtime |
| Performance | Typically faster; small results filter in the browser | The query reruns whenever the value changes |
| Versatility | Not usable in subqueries or custom conditional logic | Usable in subqueries, conditional logic, or to change query structure |
| Filter types | Six, including text entry and a range slider | Four: single and multiple values, date picker, date range |

A quick filter on a dimension becomes a [field filter](https://docs.databricks.com/aws/en/dashboards/manage/filters/field-filters), and field filters cascade by default, so one selection narrows what the others offer. A parameter that changed what the query did, rather than which rows survived it, stays a parameter.

## How a Tableau parameter is written in Databricks SQL

A [dashboard parameter](https://docs.databricks.com/aws/en/dashboards/manage/filters/parameters) is a named parameter marker in the dataset query, so a threshold typed into a Tableau calculation becomes a value the query reads at runtime. Set its default in the Data tab: that is what viewers see before touching a control, unless the filter widget carries a default of its own.

Three Tableau habits need exact syntax. A range parameter creates two markers, so the predicate reads `WHERE order_date BETWEEN :date_param.min AND :date_param.max OR :date_param IS NULL`. A parameter accepting several values is read with `WHERE array_contains(:region_param, region) OR :region_param IS NULL`, and multiple selections have to be enabled on the parameter or the query errors. A parameter that named a table or column maps to the [IDENTIFIER clause](https://docs.databricks.com/aws/en/sql/user/queries/query-parameters): `SELECT * FROM IDENTIFIER(:catalog || '.' || :schema || '.' || :table)`.

Tableau's dynamic parameter, whose list refreshes from a field, becomes a query-based parameter: a second dataset returns the values, and one filter widget binds field and parameter. Give that list its own dataset; if it also feeds a chart, a viewer's pick filters that chart too.

The measure-switching pattern, a parameter plus a CASE calculation, has a purpose-built home. A [dashboard variable](https://docs.databricks.com/aws/en/dashboards/manage/filters/dashboard-variables) groups fields so viewers can swap which one a visualization shows. Databricks says it replaces pairing IDENTIFIER with a parameter, because variables work with metric views and keep each field's formatting.

Parameters exist one layer below the dashboard as well. A Unity Catalog metric view can [define its own parameters](https://docs.databricks.com/aws/en/uc-semantics/metric-views/use-parameters) and is then called as a table-valued function, as in `catalog.schema.metric_view(discount => 0.15)`, with a dashboard parameter passed in. One limit and one requirement are documented: a parameterized metric view cannot be materialized, and querying one needs compute running Databricks Runtime 18.2 or above. Defaults have their own rule: once one parameter carries a default, every parameter after it needs one too.

## What happens to filter, highlight and URL actions

Tableau's [six action types](https://help.tableau.com/current/pro/desktop/en-us/actions.htm) do not map one to one. A filter action becomes cross-filtering: clicking a bar filters every other visualization built on the same dataset. A dashboard whose filter actions crossed data sources has a modeling task ahead of it, not a wiring task. Since [September 3, 2026](https://docs.databricks.com/aws/en/ai-bi/release-notes/2026), filters, selections and parameters carry across to widgets on datasets joined by a [dashboard relationship](https://docs.databricks.com/aws/en/dashboards/manage/data-modeling/dashboard-relationships/), in Public Preview. Line, combo and area charts joined the cross-filtering list on June 11, 2026, though the chart list on the filters page has not been updated to match, so confirm behavior on your own dashboard.

A Go to Sheet action that opened a detail view becomes drill-through: the viewer picks Drill to and a page, and every visualization there on the same dataset is filtered by the selection. Multi-selection across multiple categorical dimensions, multiple quantitative dimensions, or multiple date-binned temporal values is not yet supported.

Go to URL becomes the [Link action](https://docs.databricks.com/aws/en/dashboards/manage/visualizations/tables) on a table or pivot column, where the cell value substitutes into a templated URL through `{{@}}`. Highlight, Change Parameter and Change Set Values actions are the gap: the docs describe no equivalent, and do not say they are impossible either.

## What defaults, the Apply button and bookmarks change for viewers

Filter defaults apply when the dashboard refreshes without a selection, and the default is All. Filters apply instantly unless the dashboard is switched to With Apply Button, which lets viewers set several values before anything reruns: what a Tableau dashboard carrying eight quick filters wants.

State travels in the URL as `f_<page-name>~<widget-name>=<filter-value>`, so a bookmarked Tableau link keeps an equivalent, and editors can save named filter combinations as [shared bookmarks](https://docs.databricks.com/aws/en/dashboards/manage/), up to 10 per dashboard as of September 2026.

## What Antares does with parameters and actions

One Tableau parameter often holds two jobs in a workbook: a threshold inside a calculation on one sheet, a Top N control on another. Only usage shows the split, which is why a BI migration tool inventories parameters and actions before converting anything. The free Analyzer does that pass on metadata alone, deterministically, and lists which workbooks carry parameters and actions.

Where the target is unambiguous, the Converter handles it. Where it is not, it is flagged for a person rather than guessed: a filter on the wrong side of the query changes the number without changing the picture. Tableau to Databricks AI/BI is shipped, and the Converter runs as SaaS or inside your own environment. [Try a sample conversion](https://try.getantares.io) to see what it produces.

What a viewer is allowed to see is a separate mechanism, on [row-level security to Unity Catalog](https://getantares.io/tableau-row-level-security-to-unity-catalog/), and the order of the work is on the [migration guide](https://getantares.io/tableau-to-databricks-ai-bi-migration/). For Power BI: [parameters to Power BI](https://getantares.io/tableau-parameters-to-power-bi-parameters/) and [actions to drillthrough](https://getantares.io/tableau-actions-to-power-bi-drillthrough/). Sources: Tableau's [parameter documentation](https://help.tableau.com/current/pro/desktop/en-us/parameters_create.htm) and Databricks' guide to [dashboard filters](https://docs.databricks.com/aws/en/dashboards/manage/filters/).

## Related resources

- [Tableau to Databricks AI/BI Migration](https://getantares.io/tableau-to-databricks-ai-bi-migration/)
- [Table Calculations to Databricks](https://getantares.io/tableau-table-calculations-to-databricks/)
- [Parameters to Power BI](https://getantares.io/tableau-parameters-to-power-bi-parameters/)
- [Actions to Power BI Drillthrough](https://getantares.io/tableau-actions-to-power-bi-drillthrough/)

## FAQ

### What is the Databricks AI/BI equivalent of a Tableau parameter?

A dashboard parameter, written in the dataset query as a named parameter marker such as :region, with a String, Date, Date and Time or Numeric type. Bind it to a filter widget so viewers can change it. A parameter that only switched which measure a chart showed is better rebuilt as a dashboard variable.

### Should I filter on a field or on a parameter in a Databricks AI/BI dashboard?

Databricks describes field filters as typically faster: they apply to the resolved dataset result without modifying the query, and small results are filtered in the browser. Choose a parameter when the value has to sit inside the query, for example in a subquery, in conditional logic, or before a join.

### What happens to Tableau filter, highlight and URL actions?

Filter actions become cross-filtering, which is automatic between visuals built on the same dataset, and since September 3, 2026 carries across datasets joined by a dashboard relationship, in Public Preview. A Go to Sheet action becomes drill-through to a target page. A Go to URL action becomes the Link action on a table or pivot column, where the cell value fills a templated URL. Highlight, Change Parameter and Change Set Values actions have no equivalent described in the Databricks documentation.

### Do Databricks metric views support parameters?

Yes. A metric view can define its own parameters and is then called as a table-valued function, with arguments passed by name or position, and a dashboard parameter can be passed into that argument and bound to a filter widget. One documented limit and one requirement: a parameterized metric view cannot be materialized, and querying one needs Databricks Runtime 18.2 or above.

---

## Tableau Row-Level Security in Databricks: Unity Catalog Row Filters and Publish Modes

Canonical: https://getantares.io/tableau-row-level-security-to-unity-catalog/
Published: 2026-09-09
Updated: 2026-09-09

In Databricks, a Tableau user filter has no direct import. The rule is rebuilt in Unity Catalog as a row filter, a column mask or a dynamic view, and it evaluates per viewer only when the AI/BI dashboard is published with Individual data permissions. Publish mode, not the filter, decides whether row-level security reaches the person reading the dashboard.

## Why the publish mode decides whether row-level security works

Every AI/BI dashboard is published one of two ways. Under **Share data permissions**, the default, viewers "run queries using the publisher's data permissions", an arrangement that "might expose data to users who have not been granted direct access to it". Under **Individual data permissions**, "Viewers run queries using their own credentials" and "their data permissions determine what results they can see". Unity Catalog filters separate viewers only in the second mode; in the first, everyone sees the publisher's slice.

| Question | Shared (default) | Individual |
| --- | --- | --- |
| Who runs the query | Publisher or service principal | Each viewer |
| Whose filters apply | The publisher's | The viewer's |
| Viewer needs data access | No | Yes |
| Result cache | Shared | Per user |

Three details save arguments later. Individual data permissions need each viewer to have access to the underlying data, though not workspace membership. Drafts always apply the viewer's own permissions even when the published copy uses shared ones, so an author testing a draft sees per-user filtering published viewers will not get. And the publisher credential can be a service principal rather than a person, which keeps a dashboard off one employee's grants; the API calls it `embed_credentials`.

## How a Tableau user filter is rebuilt in Unity Catalog

Tableau offers two routes to row-level security: map users to values by hand in each workbook, which its own help calls "convenient but high maintenance", or build a dynamic filter from a security field in the data, usually an entitlements table. The dynamic route survives the move, with its logic already next to the data.

| Tableau | Databricks | What changes |
| --- | --- | --- |
| Dynamic user filter on `USERNAME()` | Row filter comparing the column to `session_user()` | Bound to the table with `ALTER TABLE ... SET ROW FILTER`, not the workbook |
| `ISMEMBEROF('Managers')` | `is_account_group_member('managers')` | Account-level groups, not Tableau site groups |
| Entitlements table in the data source | Row filter or dynamic view on the same table | The mapping table becomes a lookup inside the filter function |
| Columns hidden from some users | Column mask via `ALTER TABLE ... ALTER COLUMN ... SET MASK` | Each column can have one mask |
| Project and workbook permissions | Dashboard ACLs: CAN VIEW, CAN RUN, CAN EDIT, CAN MANAGE | Content and data access become separate |
| Viewer site role | Account user without workspace access, or consumer access | View-only, "with the added benefit of not requiring a special license" |

Unity Catalog gives three mechanisms. [Row filters and column masks](https://docs.databricks.com/aws/en/data-governance/unity-catalog/filters-and-masks) are SQL user-defined functions bound to one table. [Dynamic views](https://docs.databricks.com/aws/en/views/dynamic) gate rows and columns by group membership. For consistent rules across many tables, Databricks documents [ABAC policies](https://docs.databricks.com/aws/en/data-governance/unity-catalog/abac/), which attach at the catalog or schema level through governed tags, as of September 2026. Two limits shape the design: filters and masks cannot apply to a view, and Databricks Runtime below 12.2 LTS does not support them.

The function names change too. Use [`session_user()`](https://docs.databricks.com/aws/en/sql/language-manual/functions/session_user), documented as the replacement for `current_user()` on Databricks SQL and Databricks Runtime 14.1 and above. For group tests, `is_account_group_member()` is recommended against Unity Catalog data, because `is_member()` reads workspace-level groups. An [`ISMEMBEROF("Group Name")`](https://help.tableau.com/current/pro/desktop/en-us/functions_functions_user.htm) calculation becomes a group test inside a filter function, once the group exists at account level.

## Who can view a dashboard without a Databricks workspace

A Tableau [Viewer site role](https://help.tableau.com/current/online/en-us/users_site_roles.htm) has three landing places in Databricks. Account members can be granted a view-only copy of a published dashboard, signing in by one-time passcode or single sign-on; users without workspace access are capped at CAN RUN and cannot read workspace-bound catalogs. Consumer access covers people who run dashboards and Genie Agents in a workspace without creating anything.

External embedding is the third, and has the most moving parts: a service principal issues scoped tokens, an admin keeps an approved-domain list, and per-viewer filtering travels in a value dataset SQL reads as `__aibi_external_value`. It is rate limited to 20 dashboard loads per second, as of September 2026.

## What Genie does to your row filters

Published dashboards include a Genie Agent by default, and it inherits the publish mode; the partner-powered AI features page still labels companion Genie Agents Public Preview. One documented behavior deserves a decision rather than a discovery: "When viewers use Genie, their questions are answered from the full dataset query results. If a dataset query includes sensitive columns or rows, that data becomes available to Genie even if it is not shown in visualizations." Trim dataset SQL to what the dashboard needs, and rely on Unity Catalog masks rather than invisibility.

Downloads are a separate switch. Admins can turn off SQL results download and dashboard email subscriptions [workspace-wide](https://docs.databricks.com/aws/en/ai-bi/admin/), a decision to take alongside the publish mode, not after it.

## Why Unity Catalog comes first in the plan

Dashboards move first, Unity Catalog is not ready, so old workbooks keep their user filters while new dashboards run on shared permissions, and the rule lives in two systems for months. Every discrepancy then has two suspects. Sequencing the other way costs less: inventory which workbooks carry user filters and which entitlements tables feed them, agree the group model, write and test the filters, then convert dashboards into that.

Access is the change users feel first. A missing chart type gets a workaround; a manager who suddenly sees the whole country files a ticket that morning. Filters and parameters travel a different path, on [Tableau parameters in Databricks AI/BI](https://getantares.io/tableau-parameters-to-databricks-ai-bi-parameters/). Feature-level differences are on [Databricks AI/BI vs Tableau](https://getantares.io/databricks-ai-bi-vs-tableau/), and the same problem on a Tableau to Power BI move in [Tableau to Power BI for financial services](https://getantares.io/tableau-to-power-bi-migration-financial-services/).

## What Antares does with row-level security

Access rules are the one layer where a BI migration tool should hand work back rather than finish it. On the Tableau to Databricks AI/BI route, which Antares ships, the Converter is deterministic-first with guardrailed, validated AI steps and flags what it cannot verify instead of guessing. Mapping Tableau users and site groups onto account-level Databricks groups stays a project task, because only your team knows which identity is which.

The Analyzer reads metadata only, never business data, changes nothing in the source environment, and is fully deterministic, with no LLM involved. Antares runs as SaaS or inside your own environment, and where the Converter uses LLM steps your own private endpoints can serve them. [Run the free Analyzer](https://try.getantares.io) to see which workbooks carry user filters.

Sequencing Unity Catalog against the dashboard work is on the [migration guide](https://getantares.io/tableau-to-databricks-ai-bi-migration/). Sources: Databricks on [publish modes](https://docs.databricks.com/aws/en/dashboards/share/share), [row filters and column masks](https://docs.databricks.com/aws/en/data-governance/unity-catalog/filters-and-masks), [external embedding](https://docs.databricks.com/aws/en/dashboards/share/embedding/external-embed) and [Genie in dashboards](https://docs.databricks.com/aws/en/dashboards/genie-spaces), plus Tableau on [user filters](https://help.tableau.com/current/pro/desktop/en-us/publish_userfilters.htm) and [permissions](https://help.tableau.com/current/online/en-us/permissions.htm).

## Related resources

- [Tableau to Databricks AI/BI Migration](https://getantares.io/tableau-to-databricks-ai-bi-migration/)
- [Tableau Parameters in Databricks AI/BI](https://getantares.io/tableau-parameters-to-databricks-ai-bi-parameters/)
- [Databricks AI/BI vs Tableau](https://getantares.io/databricks-ai-bi-vs-tableau/)
- [Power BI RLS for Financial Services](https://getantares.io/tableau-to-power-bi-migration-financial-services/)

## FAQ

### Is there a Databricks equivalent of ISMEMBEROF?

Yes. Use is_account_group_member() inside a Unity Catalog row filter or dynamic view. It returns true when the connected user belongs to the named account-level group. Databricks recommends it over is_member(), which reads workspace-level groups. The group has to exist at the account level before a filter can reference it.

### Which publish mode do we need for row-level security to apply per viewer?

Individual data permissions. In that mode viewers run queries with their own credentials, so Unity Catalog row filters, column masks and dynamic views evaluate against each person. Share data permissions, the default, runs every query as the publisher, so all viewers see the same rows regardless of the filters.

### Can someone without a Databricks workspace open a filtered dashboard?

Yes, with limits. Account users granted a view-only copy sign in by one-time passcode or single sign-on and are capped at CAN RUN. They cannot read workspace-bound securables such as workspace-bound catalogs. For viewers outside your account, external embedding passes a per-viewer value that dataset SQL reads as __aibi_external_value.

### How do we stop viewers from downloading dashboard data?

Through workspace admin settings rather than dashboard permissions. Admins can turn off SQL results download and dashboard email subscriptions across the workspace. Decide both alongside the publish mode, because a viewer who can run a dashboard can otherwise export its results and share them outside your Unity Catalog rules.

---

## Databricks AI/BI vs Tableau: What Changes for Dashboard Owners

Canonical: https://getantares.io/databricks-ai-bi-vs-tableau/
Published: 2026-09-10
Updated: 2026-09-10

The difference that decides a Tableau to Databricks AI/BI migration is where the logic lives. Tableau keeps calculations, interactions and often security inside the workbook. Databricks AI/BI keeps them in dataset SQL and Unity Catalog, and most other differences follow. This page does not rank the platforms; it lists what your dashboards will meet.

## What changes, feature by feature

Accurate as of September 2026; the Databricks layer ships often, so re-check a row before planning.

### Building and calculating

| What you are comparing | Tableau | Databricks AI/BI |
| --- | --- | --- |
| Calculation language | Calculated fields, LOD expressions, table calculations, in the workbook | Dataset SQL, custom calculations ([Fixed and Coarser LOD](https://docs.databricks.com/aws/en/dashboards/manage/data-modeling/custom-calculations/level-of-detail)), or a metric view |
| Layout | Freeform canvas, tiled and floating objects | [A 12-column snap grid](https://www.databricks.com/blog/whats-new-aibi-february-2026-roundup), widened from 6 in February 2026 |
| Dashboard size | One workbook, many sheets and dashboards | [15 pages, 100 datasets, 100 widgets per page](https://docs.databricks.com/aws/en/dashboards/limits) |
| Visual types and custom visuals | Marks-based charts plus extensions | [Fixed list of built-in types](https://docs.databricks.com/aws/en/dashboards/manage/visualizations/types); [Vega-Lite custom visuals](https://docs.databricks.com/aws/en/dashboards/manage/visualizations/custom-visualizations) in Public Preview, no treemap |
| Dual axis | [Dual axes on any two measures](https://help.tableau.com/current/pro/desktop/en-us/multiple_measures.htm) | An [Enable dual axis](https://docs.databricks.com/aws/en/dashboards/manage/visualizations/types) option on combo charts |
| Interaction between visuals | [Filter, highlight, go to sheet, go to URL, parameter and set actions](https://help.tableau.com/current/pro/desktop/en-us/actions.htm) | [Cross-filtering](https://docs.databricks.com/aws/en/dashboards/manage/filters/) on the same dataset; drill-through to a target page, filters from the clicked mark |
| Tooltips | [Viz in Tooltip](https://help.tableau.com/current/pro/desktop/en-us/viz_in_tooltip.htm) embeds another view | [Number and label formatting](https://docs.databricks.com/aws/en/dashboards/manage/visualizations/); no viz-in-tooltip equivalent documented as of September 2026 |

### Sharing and running

| What you are comparing | Tableau | Databricks AI/BI |
| --- | --- | --- |
| Scheduled delivery | Email subscriptions on a schedule | [PDF by email](https://docs.databricks.com/aws/en/dashboards/share/schedule-subscribe); PNG and PDF to Slack and Teams; CSV, TSV or Excel attachments on all three; 100 subscribers |
| Embedding | Embedding API in the host application | [Light mode only](https://docs.databricks.com/aws/en/dashboards/share/embedding/basic); [external viewers](https://docs.databricks.com/aws/en/dashboards/share/embedding/external-embed) via a service principal, 20 loads per second, no Ask Genie |
| Natural language | [Tableau Pulse](https://help.tableau.com/current/online/en-us/pulse_about.htm) digests, Tableau Cloud only | [A companion Genie Agent](https://docs.databricks.com/aws/en/dashboards/genie-spaces), on by default, workspace members only; still labeled Public Preview on the partner-powered page |
| Version control | Revision history on the site | [Git folders track drafts only](https://docs.databricks.com/aws/en/dashboards/automate/git-support); a branch switch deletes dashboards absent on the target branch |
| Licensing shape | [Creator, Explorer and Viewer site roles](https://help.tableau.com/current/online/en-us/users_site_roles.htm) | ["There are no additional license fees ... $DBU rates apply"](https://www.databricks.com/product/business-intelligence) |
| Offline copy | [A .hyper extract](https://help.tableau.com/current/pro/desktop/en-us/extracting_data.htm) works offline | [A 24-hour best-effort cache](https://docs.databricks.com/aws/en/dashboards/caching) warmed by a schedule; no offline file documented |

## Where the logic lives

A Tableau workbook is self-contained: its calculations travel with the file, so it changes hands and still produces the same numbers. In AI/BI the same math sits in one of three homes and you pick which: dataset SQL, a custom calculation, or a Unity Catalog metric view that other dashboards and Genie Agents read too. That choice is the migration, and level of detail expressions have the longest mapping, in [LOD expressions in Databricks SQL](https://getantares.io/tableau-lod-expressions-to-databricks-sql/).

A metric view is not a free-form model, and its shape decides how much of a workbook fits. Databricks documents [joins in metric views](https://docs.databricks.com/aws/en/uc-semantics/metric-views/joins) as star and snowflake schemas, plus one-to-many joins that aggregate facts. Joins are many-to-one by default, and a many-to-many case takes the first matching row (as of September 2026). A workbook blending several fact tables at one grain is a modeling decision first.

## What the grid does to a freeform dashboard

Tableau places objects where you put them. The AI/BI canvas snaps to a 12-column grid, widened from six in February 2026. Geometry does not convert across that boundary, so copy the decisions instead: which number is largest, what sits above the fold, which filter is global.

One consequence reaches past layout. Charts truncate above 15,000 rows and tables above 100,000, per the [limits page](https://docs.databricks.com/aws/en/dashboards/limits) as of September 2026, so a wide Tableau crosstab needs an aggregation decision, not a resize. The render and refresh story is on the [migration guide](https://getantares.io/tableau-to-databricks-ai-bi-migration/).

## Which interactions have an equivalent

Filter actions have the closest match: cross-filtering between visuals on the same dataset, or on datasets joined by a dashboard relationship since September 3, 2026 (Public Preview), and drill-through to a target page with filters set by the clicked mark. Saved filter states have a direct equivalent: editors save named [shared bookmarks](https://docs.databricks.com/aws/en/dashboards/manage/), up to 10 per dashboard, and a published dashboard keeps filter and parameter selections in the URL. Go to URL survives as the [Link display type](https://docs.databricks.com/aws/en/dashboards/manage/visualizations/tables) in a table column. Highlight, parameter and set actions have no equivalent in the AI/BI docs as of September 2026, so plan them by hand. Parameters have their own page, [parameters in AI/BI dashboards](https://getantares.io/tableau-parameters-to-databricks-ai-bi-parameters/).

## What Genie replaces and what it does not

Published AI/BI dashboards carry a companion Genie Agent with the Enable Genie toggle on by default, so viewers get an Ask Genie button without anyone building one. Viewers have to be workspace members, and it is not in external embedding.

The governance decision: answers come from the full dataset query results, so a column the dataset selects but no chart shows is still in scope. Tableau Pulse does another job, watching defined metrics and pushing digests to email, Slack and Teams, on Tableau Cloud only. Genie answers on request. Pulse reports change unasked. Replace them separately.

## How the licensing shape differs

Tableau licenses people through Creator, Explorer and Viewer site roles. Databricks licenses compute, and the quotation in the table above is its whole licensing statement. Genie is the exception, and its terms moved twice. [Genie Agents went pay-as-you-go on July 8, 2026](https://docs.databricks.com/aws/en/ai-bi/release-notes/2026), then billing for Genie One and Genie Agents was paused on July 15; usage by users is free through January 31, 2027, service principals excluded and still billed. Genie Code stays pay-as-you-go, at 150 free DBUs per user a month and a 25% discount above that.

## Can Databricks AI/BI replace Tableau

The answer comes per dashboard rather than per estate, and four things decide it.

- Whether its logic already exists in SQL, or only inside the workbook.
- Who has to open it. Viewers outside your Databricks account, and viewers who each see different rows, are both answered by the publish mode and the embedding route, on [Tableau row-level security to Unity Catalog](https://getantares.io/tableau-row-level-security-to-unity-catalog/).
- Whether the design leans on freeform placement, or on an interaction the AI/BI docs do not describe.
- Who maintains it in two years, and whether that person writes SQL.

Estates answer unevenly, and the exceptions cluster in a small group of heavily built dashboards. Inventory first: a difference matters only where a dashboard uses it.

Antares is a BI migration tool whose Tableau to Databricks AI/BI route is shipped, at a flat $200 per source dashboard with LLM costs billed by your own provider on top. The route list is on the [Converter page](https://getantares.io/converter/).

Every Databricks cell in the tables above links the docs page it came from. The Tableau side comes from [dashboard actions](https://help.tableau.com/current/pro/desktop/en-us/actions.htm), [site roles](https://help.tableau.com/current/online/en-us/users_site_roles.htm) and [Tableau Pulse](https://help.tableau.com/current/online/en-us/pulse_about.htm).

## Related resources

- [Tableau to Databricks AI/BI Migration Guide](https://getantares.io/tableau-to-databricks-ai-bi-migration/)
- [Tableau LOD Expressions in Databricks SQL](https://getantares.io/tableau-lod-expressions-to-databricks-sql/)
- [Tableau Row-Level Security to Unity Catalog](https://getantares.io/tableau-row-level-security-to-unity-catalog/)

## FAQ

### Is Databricks AI/BI free?

Databricks words it as "There are no additional license fees to use AI/BI. Standard Databricks Lakehouse $DBU rates apply," so dashboards cost the SQL warehouse compute they use. Genie is metered separately, and the terms changed mid-2026: Genie Agents went pay-as-you-go on July 8, 2026, then billing was paused on July 15 and usage by users is free through January 31, 2027, with service principals still billed. Genie Code keeps the pay-as-you-go model: 150 free DBUs per user a month, then a 25% promotional discount through January 31, 2027.

### Does Databricks AI/BI have LOD expressions?

Yes, since 2026. The docs name two forms in custom calculations: Fixed LOD, an aggregate with an explicit PARTITION BY, and Coarser LOD, written with AGGREGATE OVER and PARTITION BY * EXCEPT. An Include-style expression has no keyword in a dashboard calculation and is modeled in dataset SQL, though the metric view editor gained one in YAML on September 10, 2026. The full mapping is on the LOD expressions page in this cluster.

### What are the limitations of Databricks AI/BI dashboards compared with Tableau?

Three surface early, as of September 2026: dual axis exists as a combo chart option rather than a property of any two measures, the canvas snaps to 12 columns instead of freeform placement, and custom visuals are Vega-Lite specifications in Public Preview with no treemap. All three are design decisions rather than data problems, which is why they come up in the first week.

### How does AI/BI Genie compare with Tableau Pulse?

They do different jobs. A companion Genie Agent answers questions typed against a published dashboard's datasets, on by default, for workspace members only, and not in external embedding. Tableau Pulse follows metric definitions and pushes digests to email, Slack and Teams, and applies to Tableau Cloud only. Replacing one does not replace the other.

### Does one Tableau dashboard convert to one Databricks AI/BI dashboard?

Usually yes, and that is the unit of conversion. The ceilings are roomy for a single dashboard as of September 2026: 15 pages, 100 datasets and 100 widgets per page. Workbooks that grew into a portal over the years are the ones worth splitting during the move rather than after it.

### Can Databricks AI/BI replace Tableau?

It answers per dashboard, not per estate. Each platform is a bargain of a different shape: Tableau gives design freedom and a long interaction list, and asks for its own platform and skills; AI/BI sits next to the data and shares the Unity Catalog permission model, and asks you to move logic into SQL.

---

## Tableau LOD Expressions to DAX: FIXED, INCLUDE, and EXCLUDE

Canonical: https://getantares.io/tableau-lod-expressions-to-dax/
Published: 2026-02-18
Updated: 2026-09-30

Tableau Level of Detail (LOD) expressions have no one-to-one DAX equivalent, because Tableau controls aggregation grain with a keyword while Power BI controls it with filter context. Each keyword maps to a different DAX construct: **FIXED** becomes `CALCULATE` with `ALLEXCEPT` or `REMOVEFILTERS`, **INCLUDE** becomes an iterator such as `AVERAGEX` over `VALUES`, and **EXCLUDE** becomes `CALCULATE` with `REMOVEFILTERS` on the excluded column.

## FIXED vs INCLUDE vs EXCLUDE

The three keywords differ in which dimensions set the grain of the calculation. Tableau's [LOD documentation](https://help.tableau.com/current/pro/desktop/en-us/calculations_calculatedfields_lod.htm) defines FIXED as computing with the named dimensions regardless of the view, INCLUDE as adding them to the dimensions already in the view, and EXCLUDE as subtracting them.

| Keyword | Grain of the result | Dimension filters | Returns |
| --- | --- | --- | --- |
| **FIXED** | Only the named dimensions, whatever the view shows | Ignored, unless added to context | Dimension or measure |
| **INCLUDE** | The view's dimensions plus the named ones, so finer | Applied before it | Always a measure |
| **EXCLUDE** | The view's dimensions minus the named ones, so coarser | Applied before it | Always a measure |

The filter column is the one that shapes the DAX. [FIXED is computed before dimension filters](https://help.tableau.com/current/pro/desktop/en-us/calculations_calculatedfields_lod_overview.htm), while INCLUDE and EXCLUDE are computed after them, so the filters a FIXED expression ignored have to be cleared explicitly in DAX, while an EXCLUDE total still respects a filter on the excluded dimension — the reason the EXCLUDE section below reaches for `ALLSELECTED`.

## Tableau LOD to DAX conversion table

Names below follow a standard star schema: a `Sales` fact table related to `Customer`, `Product`, and `Geography` dimensions.

| Tableau LOD | DAX equivalent | What it does |
| --- | --- | --- |
| `{FIXED [Region] : SUM([Sales])}` | `CALCULATE(SUM(Sales[Amount]), ALLEXCEPT(Sales, Sales[Region]))` | Aggregates at Region, ignoring the view and dimension filters |
| `{FIXED : SUM([Sales])}` | `CALCULATE(SUM(Sales[Amount]), REMOVEFILTERS())` | Grand total, ignoring everything |
| `SUM([Sales]) / MAX({FIXED [Region] : SUM([Sales])})` | `DIVIDE(SUM(Sales[Amount]), CALCULATE(SUM(Sales[Amount]), ALLEXCEPT(Sales, Sales[Region])))` | Percent of a fixed total |
| `{FIXED [Customer] : MIN([Order Date])}` | Calculated column on `Customer`: `CALCULATE(MIN(Sales[OrderDate]))` | An attribute of an entity, not a measure |
| `AVG({INCLUDE [Customer] : SUM([Sales])})` | `AVERAGEX(VALUES(Customer[CustomerKey]), CALCULATE(SUM(Sales[Amount])))` | Aggregates below the view grain, then re-aggregates up |
| `{EXCLUDE [Category] : SUM([Sales])}` | `CALCULATE(SUM(Sales[Amount]), REMOVEFILTERS(Product[Category]))` | Aggregates above the view grain |

## How FIXED converts

`FIXED` pins aggregation to the dimensions you name and ignores everything else in the view. In DAX the equivalent move is to clear filter context from every column except the ones you want to keep, which is what [ALLEXCEPT](https://learn.microsoft.com/en-us/dax/allexcept-function-dax) does.

There is one trap, and it accounts for most broken conversions. `ALLEXCEPT(Sales, …)` only clears filters on columns of the `Sales` table. A filter arriving from a related dimension table still propagates through the relationship, so a slicer on `Product[Category]` keeps shrinking the result even though the Tableau LOD ignored it. When the pinned dimension lives on a dimension table, combine [REMOVEFILTERS()](https://learn.microsoft.com/en-us/dax/removefilters-function-dax) with `VALUES(Geography[Region])` instead: the first clears the whole model, the second is evaluated in the outer filter context and puts the current region back.

It is also worth asking whether the LOD is a measure at all. A large share of FIXED expressions are attributes computed once per customer, order, or product — `{FIXED [Customer] : MIN([Order Date])}` is a cohort date. Modelled as a calculated column on the `Customer` table, `CALCULATE(MIN(Sales[OrderDate]))` is enough: inside a column, `CALCULATE` performs context transition and the relationship propagates the current customer. No `ALLEXCEPT` needed, and columns query faster than a measure re-evaluated per cell.

## How INCLUDE converts

`INCLUDE` pushes aggregation *below* the grain of the view, then re-aggregates the result upward. The DAX equivalent is an iterator over the included dimension, and the rule is mechanical: an `X` iterator over `VALUES` of the included column, wrapping the inner aggregate in `CALCULATE`. Match the iterator to the outer aggregate — `AVERAGEX` for `AVG`, `MAXX` for `MAX`, `MINX` for `MIN`. The inner `CALCULATE` is not optional: it triggers the context transition that makes each iterated customer filter the fact table.

One shortcut worth knowing: if the outer aggregate is `SUM`, the INCLUDE is almost always redundant, because summing per-customer sums returns the same total. INCLUDE only changes the answer when the outer aggregate is non-additive — average, max, min, or distinct count.

## How EXCLUDE converts

`EXCLUDE` drops a dimension that is present in the view, producing a coarser total on every row. In DAX you remove the filter on that one column and leave everything else alone.

If the excluded dimension is also on a slicer and the user's selection must still apply, use [ALLSELECTED](https://learn.microsoft.com/en-us/dax/allselected-function-dax) rather than `REMOVEFILTERS` — it restores the filter context from outside the visual instead of clearing it entirely. Note that `ALL(Product[Category])` used as a `CALCULATE` filter argument does the same job as `REMOVEFILTERS(Product[Category])`; the latter is the newer, unambiguous name and reads better in review.

## Why ALLEXCEPT does not always match FIXED

Tableau evaluates a worksheet through a fixed pipeline, and FIXED sits in the middle of it. DAX has no pipeline at all: there is only filter context, modified by `CALCULATE`. Reconciling the two is what makes LOD conversion hard, and it is why a formula-for-formula rewrite can look right and total wrong.

Tableau's [order of operations](https://help.tableau.com/current/pro/desktop/en-us/order_of_operations.htm) resolves extract filters first, then data source filters, then context filters, then FIXED, then dimension filters, then INCLUDE and EXCLUDE. What matters for conversion is which filters land before FIXED and therefore still affect it:

| Tableau filter | Affects a FIXED LOD? | How to reproduce in DAX |
| --- | --- | --- |
| Data source / extract filter | Yes | Filter the query in Power Query, not in the measure |
| Context filter | Yes | `ALLSELECTED` — keep what the user selected |
| Dimension filter (regular) | No | `ALLEXCEPT` or `REMOVEFILTERS` clears it |
| Measure filter | No — applied afterwards | Filter on the visual, not inside the measure |

The practical rule: a workbook that leaned on **context filters** converts to `ALLSELECTED`, and one that leaned on ordinary dimension filters converts to `ALLEXCEPT` or `REMOVEFILTERS`. The LOD formula alone will not tell you which — you have to look at how the worksheet filtered. Testing a converted measure with and without a slicer applied is the check that catches the difference.

## What Antares does with LOD expressions

Antares does not auto-translate LOD expressions, and that is deliberate: a silently wrong rewrite costs far more to find in UAT than a flagged one costs to write by hand. What the Analyzer does instead is find them. Every calculated field in the workbook is parsed and classified, and each LOD lands in the migration report as an explicit manual action with its type and the recommended DAX approach, rather than as a formula somebody discovers late.

That inventory is also what makes an estimate defensible — you know the LOD count and shape of an estate before committing to a date. [Run the free Analyzer](https://try.getantares.io) to get the breakdown for your own workbooks.

Related reading: [Tableau calculated fields to DAX](https://getantares.io/tableau-calculated-fields-to-dax/) for the function-level mapping, and [Tableau table calculations to DAX](https://getantares.io/tableau-table-calculations-to-dax/) for RUNNING_SUM, WINDOW_AVG, and RANK. Primary sources: Tableau's [LOD expression documentation](https://help.tableau.com/current/pro/desktop/en-us/calculations_calculatedfields_lod.htm) and Microsoft's [DAX function reference](https://learn.microsoft.com/en-us/dax/dax-function-reference).

## Related resources

- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [Calculated Fields to DAX](https://getantares.io/tableau-calculated-fields-to-dax/)
- [Table Calculations to DAX](https://getantares.io/tableau-table-calculations-to-dax/)
- [Sets to DAX Measures](https://getantares.io/tableau-sets-to-dax-measures/)
- [LOD Expressions in Databricks SQL and AI/BI](https://getantares.io/tableau-lod-expressions-to-databricks-sql/)

## FAQ

### What is the difference between FIXED, INCLUDE and EXCLUDE?

They set the grain differently. FIXED uses only the dimensions you name and ignores the rest of the view; INCLUDE adds dimensions to the view and computes at a finer grain; EXCLUDE removes dimensions from the view and computes at a coarser grain. FIXED runs before dimension filters and can return a dimension, while INCLUDE and EXCLUDE run after them and always return measures.

### What is the DAX equivalent of a Tableau FIXED LOD expression?

CALCULATE with ALLEXCEPT. {FIXED [Region] : SUM([Sales])} becomes CALCULATE(SUM(Sales[Amount]), ALLEXCEPT(Sales, Sales[Region])). When Region sits on a dimension table rather than the fact table, use REMOVEFILTERS() combined with VALUES(Geography[Region]) so filters arriving through relationships are cleared too.

### Does ALLEXCEPT behave exactly like FIXED?

No. ALLEXCEPT only clears filters on columns of the table you pass it, so in a star schema a slicer on another dimension still reduces the result — something the Tableau LOD ignored. It also does not reproduce context filters, which FIXED respects; those map to ALLSELECTED instead.

### How do you convert an INCLUDE LOD expression to DAX?

Use an iterator over the included dimension. AVG({INCLUDE [Customer] : SUM([Sales])}) becomes AVERAGEX(VALUES(Customer[CustomerKey]), CALCULATE(SUM(Sales[Amount]))). Match the iterator to the outer aggregate — MAXX for MAX, MINX for MIN. The inner CALCULATE is required: it triggers the context transition.

### Does Antares convert LOD expressions automatically?

No, by design — a silently wrong rewrite costs more to find in UAT than a flagged one costs to write by hand. The Analyzer parses every calculated field, identifies each LOD and its type, and reports it as a manual action with the recommended DAX approach, so the work is known before the migration starts.

---

## Tableau Calculated Fields to DAX: Function Mapping and Conversion Reference

Canonical: https://getantares.io/tableau-calculated-fields-to-dax/
Published: 2026-02-18
Updated: 2026-09-30

Most Tableau calculated fields convert to DAX by substituting function names. Two things break a naive rewrite: DAX has no row context inside a measure, and several DAX functions share a name with a Tableau function while doing something else entirely. This page maps the function library, then covers the traps that do not raise an error.

## Does Tableau use DAX?

**No.** DAX is [the formula language](https://learn.microsoft.com/en-us/dax/dax-overview) of Power BI, Analysis Services and Power Pivot in Excel. Tableau has [its own calculation language](https://help.tableau.com/current/pro/desktop/en-us/calculations_calculatedfields_create.htm), written in calculated fields. The DAX equivalent of a Tableau calculated field is a measure or a calculated column, and most Tableau functions have a direct DAX counterpart, often under a new name: `COUNTD` becomes `DISTINCTCOUNT`.

## Tableau to DAX function mapping

### Logic and conditionals

| Tableau | DAX | Note |
| --- | --- | --- |
| `IF … THEN … ELSEIF … END` | `IF()` or `SWITCH(TRUE(), …)` | `SWITCH(TRUE(), …)` is far more readable past two branches |
| `IIF(test, then, else, [unknown])` | `IF(test, then, else)` | DAX has no fourth "unknown" argument — handle blanks explicitly |
| `CASE [x] WHEN … THEN … END` | `SWITCH([x], …)` | Direct equivalent |
| `AND` / `OR` / `NOT` | `&&` / `\|\|` / `NOT` | `AND()` and `OR()` exist in DAX but take exactly two arguments |
| `ISNULL([x])` | `ISBLANK([x])` | A DAX blank is not a SQL null — it behaves as zero in arithmetic |
| `IFNULL(a, b)` | `COALESCE(a, b)` | Direct equivalent |
| `ZN([x])` | `COALESCE([x], 0)` | In ratios, prefer `DIVIDE(a, b, 0)` — see below |

### Aggregation

| Tableau | DAX | Note |
| --- | --- | --- |
| `SUM`, `MIN`, `MAX`, `MEDIAN` | Same names | Direct equivalents |
| `AVG([x])` | `AVERAGE([x])` | Renamed |
| `COUNTD([x])` | `DISTINCTCOUNT([x])` | Renamed |
| `COUNT([x])` | `COUNT([x])` or `COUNTA([x])` | DAX `COUNT` handles numbers, dates and text but not TRUE/FALSE — use `COUNTA` for boolean columns |
| `ATTR([x])` | `SELECTEDVALUE([x])` | Returns blank instead of `*` when values are not unique |
| `STDEV` / `VAR` | `STDEV.S` / `VAR.S` | **`VAR` is a reserved keyword in DAX** — it declares a variable |
| `SUM([a]) / SUM([b])` | `DIVIDE(SUM([a]), SUM([b]), 0)` | Third argument replaces the divide-by-zero result |

### Dates

| Tableau | DAX | Note |
| --- | --- | --- |
| `TODAY()` / `NOW()` | `TODAY()` / `NOW()` | Direct equivalents |
| `DATEDIFF('day', [a], [b])` | `DATEDIFF([a], [b], DAY)` | **Argument order differs**; the DAX interval is an unquoted keyword |
| `DATEADD('month', 3, [d])` | `EDATE([d], 3)` | **DAX `DATEADD` is a different function** — see below |
| `DATEPART('year', [d])` | `YEAR([d])` | Also `QUARTER`, `MONTH`, `DAY`, `HOUR` |
| `DATETRUNC('month', [d])` | `DATE(YEAR([d]), MONTH([d]), 1)` | Row-level form; `STARTOFMONTH` is time intelligence |
| `DATENAME('month', [d])` | `FORMAT([d], "MMMM")` | Returns text — sort it with a numeric month column |
| `MAKEDATE(y, m, d)` | `DATE(y, m, d)` | Renamed |
| `DATEPARSE(fmt, str)` | — | No DAX equivalent; parse in Power Query |

### Strings and type conversion

| Tableau | DAX | Note |
| --- | --- | --- |
| `LEFT`, `RIGHT`, `LEN`, `UPPER`, `LOWER`, `TRIM` | Same names | Direct equivalents |
| `MID(s, start)` | `MID(s, start, num_chars)` | DAX requires the third argument; pass `LEN(s)` to reach the end |
| `CONTAINS(s, sub)` | `CONTAINSSTRING(s, sub)` | DAX version is case-insensitive; `CONTAINSSTRINGEXACT` is not |
| `REPLACE(s, sub, new)` | `SUBSTITUTE(s, sub, new)` | **DAX `REPLACE` is positional**: `REPLACE(s, start, length, new)` |
| `FIND(s, sub)` | `SEARCH(sub, s, 1, 0)` | Argument order reverses; `SEARCH` is case-insensitive, while DAX's own `FIND` is case-sensitive |
| `REGEXP_EXTRACT`, `REGEXP_MATCH`, `REGEXP_REPLACE` | — | DAX has no regular expressions; move the logic to Power Query |
| `INT([x])` | `TRUNC([x])` | **Not `INT()`** — see below |
| `STR([x])` / `FLOAT([x])` | `FORMAT([x], "General Number")` / `VALUE([x])` | `CONVERT([x], STRING)` also works |

## Measure or calculated column?

Tableau splits calculated fields into row-level and aggregate. Power BI splits them into calculated columns and measures, and the two splits do not line up. Mapping them wrongly is the most common cause of a converted field that returns a plausible but incorrect number.

A calculated column is evaluated once per row on refresh and has row context, so `[Price] * [Quantity]` works exactly as it did in Tableau. A measure is evaluated at query time against a filter context and has no row context at all — the same expression fails, because there is no current row to read.

| Tableau calculated field | Power BI equivalent | Why |
| --- | --- | --- |
| Row-level, used as a dimension, filter, or slicer | Power Query column (preferred) or calculated column | Computed on refresh, compresses well, filterable |
| Row-level, only ever aggregated in the view | Measure with an iterator, e.g. `SUMX(Sales, Sales[Price] * Sales[Qty])` | Avoids materialising a column you never filter on |
| Aggregate (contains `SUM`, `AVG`, `COUNTD`) | Measure | Must respond to slicers and to the visual's grain |

The default should be a measure. Calculated columns cost memory on every refresh and cannot respond to a slicer, so reach for one only when the value has to be filterable or appear on an axis.

## Traps that silently change results

**1. `DATEADD` is not `DATEADD`.** Both languages have a function with this name and they are unrelated. Tableau's is row-level date arithmetic. The [DAX `DATEADD`](https://learn.microsoft.com/en-us/dax/dateadd-function-dax) is a time-intelligence function that returns a *table* of shifted dates and errors when the dates in context are not contiguous. For row-level month arithmetic use `EDATE`; keep `DATEADD` for shifting a measure across periods.

**2. `DATEDIFF` reverses its arguments.** Tableau takes the interval first, `DATEDIFF('day', [Start], [End])`; [DAX takes it last](https://learn.microsoft.com/en-us/dax/datediff-function-dax), `DATEDIFF([Start], [End], DAY)`. A converted formula that compiles is not proof of correctness — swapping the two date arguments returns the same magnitude with the opposite sign.

**3. `INT` rounds down instead of truncating.** Tableau's `INT()` truncates toward zero, so `INT(-9.7)` returns `-9`. The [DAX `INT()`](https://learn.microsoft.com/en-us/dax/int-function-dax) rounds down: Microsoft's own remark is that `TRUNC(-4.3)` returns `-4` but `INT(-4.3)` returns `-5`. The two agree on every positive number, which is why this survives testing and surfaces in production on refunds, adjustments, and variances. Use `TRUNC()`.

A fourth issue is not a trap so much as a habit: DAX blanks. A blank behaves as zero in arithmetic, and a measure that returns blank makes the row disappear from a visual entirely. Tableau's `ZN()` wrapper has no automatic counterpart, so ratios need explicit handling — which is what the third argument of [DIVIDE](https://learn.microsoft.com/en-us/dax/divide-function-dax) is for.

## What Antares does with calculated fields

Antares reads every calculated field in a workbook before any DAX is written, resolves what each formula depends on, and separates the mechanical conversions from the ones that need a person. Formulas with structural translation blockers (LOD expressions, table calculations, `RAWSQL_` passthrough, and R/Python `SCRIPT_` functions) are reported as manual actions with the recommended approach rather than guessed at, because a silently wrong rewrite costs more to find in UAT than a flagged one costs to write.

[Run the free Analyzer](https://try.getantares.io) to see the calculated-field breakdown for your own workbooks before committing to an estimate.

Related reading: [Tableau LOD expressions to DAX](https://getantares.io/tableau-lod-expressions-to-dax/) for FIXED, INCLUDE, and EXCLUDE, and [Tableau table calculations to DAX](https://getantares.io/tableau-table-calculations-to-dax/) for RUNNING_SUM, WINDOW_AVG, and RANK. Primary sources: Tableau's [function reference](https://help.tableau.com/current/pro/desktop/en-us/functions_all_categories.htm) and Microsoft's [DAX function reference](https://learn.microsoft.com/en-us/dax/dax-function-reference).

## Related resources

- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [LOD Expressions to DAX](https://getantares.io/tableau-lod-expressions-to-dax/)
- [Table Calculations to DAX](https://getantares.io/tableau-table-calculations-to-dax/)
- [Groups to Power BI](https://getantares.io/tableau-groups-to-power-bi/)
- [Calculated Fields to Databricks SQL](https://getantares.io/tableau-calculated-fields-to-databricks-sql/)

## FAQ

### Does Tableau use DAX?

No. DAX is Microsoft's formula language for Power BI, Analysis Services and Power Pivot; Tableau writes calculated fields, LOD expressions and table calculations in its own calculation language. Moving a workbook to Power BI therefore means rewriting each calculated field in DAX, as a measure or a calculated column, or moving row-level logic into Power Query.

### Is there a direct Tableau to DAX function mapping?

For most of the library, yes. AVG becomes AVERAGE, COUNTD becomes DISTINCTCOUNT, IFNULL becomes COALESCE, ATTR becomes SELECTEDVALUE, ZN(x) becomes COALESCE(x, 0). The exceptions are DATEADD, DATEDIFF, INT and REPLACE, which exist in both languages with different meanings or argument orders.

### Why does DAX DATEADD not work like Tableau DATEADD?

They are unrelated functions with the same name. Tableau DATEADD is row-level date arithmetic; DAX DATEADD is a time-intelligence function that returns a table of shifted dates and errors when the dates in the current context are not contiguous. For row-level month arithmetic in DAX use EDATE(date, months) instead.

### Should a Tableau calculated field become a DAX measure or a calculated column?

A measure by default. Use a calculated column only when the value has to be filterable, appear on an axis, or feed a slicer — Tableau row-level fields used as dimensions. Row-level fields that are only ever aggregated are better as a measure with an iterator such as SUMX.

### Why does INT() give a different answer after conversion?

Tableau INT truncates toward zero, so INT(-9.7) returns -9. DAX INT rounds down: Microsoft documents that TRUNC(-4.3) returns -4 while INT(-4.3) returns -5. The two agree on every positive number, which is why this survives testing and appears in production on refunds and variances. Use TRUNC().

---

## Tableau Extracts to Power BI Dataflows: What Maps Where, and When a Dataflow Is Worth It

Canonical: https://getantares.io/convert-tableau-extracts-to-power-bi-dataflows/
Published: 2026-02-18
Updated: 2026-07-28

The mapping most migration plans assume here is wrong. A Tableau extract is a cache belonging to one workbook, and its Power BI counterpart is Import mode inside a semantic model, not a dataflow. A dataflow is reusable preparation logic that many models can share. Its closest Tableau relatives are a published data source or a Tableau Prep flow. So the real question is not how to turn extracts into dataflows, it is which of your extracts were doing a job that deserves one.

## What each Tableau artefact actually maps to

| Tableau | Power BI | Notes |
| --- | --- | --- |
| Extract used by one workbook | Import-mode semantic model | No dataflow needed, see [Hyper files to Power BI](https://getantares.io/convert-hyper-files-to-power-bi/) |
| The same extract logic repeated in many workbooks | Dataflow | The case dataflows exist for |
| Published data source | Shared semantic model | Reuses the model, not just the tables |
| Tableau Prep flow | Dataflow | Preparation as its own scheduled artefact |
| Extract refresh schedule | Dataflow refresh plus model refresh | Two schedules to sequence, not one |
| Extract filters and aggregation | Power Query steps in the dataflow | Written once, inherited everywhere |
| Analysts connecting straight to production | Dataflow as the only exposed layer | A documented reason to use them |

## When a dataflow earns its place

Microsoft lists the scenarios [dataflows are designed for](https://learn.microsoft.com/en-us/power-bi/transform-model/dataflows/dataflows-introduction-self-service), and they map neatly onto problems Tableau estates usually have: reusable transformation logic that many semantic models and reports share, a single curated source of truth, persistence into your own Azure Data Lake Gen2 storage, and stronger security around the underlying sources by exposing dataflows to report creators instead of database credentials.

A practical rule follows from that. If one workbook owned the extract, import into the model and move on. If the same joins, filters and cleanup were pasted into five workbooks because that was the only way to share them in Tableau, that repetition is the dataflow. Migrations that skip this step reproduce the copy-paste estate in a new tool, which is the one outcome nobody is paying for.

## Gen1 or Gen2

Power BI Dataflow Gen1 is now in a legacy state and, in Microsoft's words, "won't receive new feature investment". [Dataflow Gen2](https://learn.microsoft.com/en-us/fabric/data-factory/dataflows-gen2-overview) is the recommended path for customers with Fabric access, and it requires a Fabric capacity, a Fabric trial capacity, or a Power BI Premium capacity. Pro and PPU customers can keep using Gen1.

| Capability | Gen1 | Gen2 |
| --- | --- | --- |
| Authoring in Power Query | Yes | Yes |
| Output destinations beyond internal storage | No | Yes, including Lakehouse, Warehouse, Azure SQL and Snowflake |
| DirectQuery through the dataflow connector | Yes | No |
| Runs inside pipelines | No | Yes |
| Licensing floor | Pro | Fabric or Premium capacity |

The DirectQuery row is the one that catches migrations out. A Tableau live connection that you planned to reproduce as DirectQuery over a dataflow works on Gen1 and not on Gen2, so that pairing has to be settled before anyone starts building.

## Computed tables, and the line where Premium starts

[Computed tables](https://learn.microsoft.com/en-us/power-query/dataflows/computed-tables) perform in-storage computation: transformations run against data already sitting in dataflow storage rather than going back to the source database. That is what makes a layered design possible, where a raw table is loaded once and enriched tables are derived from it, and it is also where the licensing line sits, since in-storage computation needs a Premium subscription.

It maps onto something Tableau users already do by hand. An extract that pulls a wide table and a second extract that aggregates the same data is exactly a raw table plus a computed table, built twice because Tableau had nowhere to keep the intermediate result.

## You now have two refresh schedules

An extract had one schedule. A dataflow feeding a semantic model has two, and the model's refresh has to run after the dataflow that supplies it, or reports show yesterday's numbers while everything reports success. Gen1 leaves that sequencing to you, spaced far enough apart that the first finishes before the second starts. Gen2 runs inside pipelines, so the dependency can be expressed rather than estimated, which is the stronger reason to prefer it for anything a business actually depends on.

## Dataflow or shared semantic model?

Both are reuse, at different layers, and the choice is not either-or. A dataflow reuses *tables*: the query logic, the cleanup, the source credentials. A semantic model reuses the *model*: relationships, measures, formatting and row-level security. A Tableau published data source carried both at once, which is why it splits into two decisions during migration rather than one.

For most estates the answer is layered. Dataflows where several models share preparation, shared semantic models where several reports share business logic, and neither where a single report owns its data end to end.

## What Antares does with extracts

The Analyzer inventories every data source in every workbook and records whether each is live or extract-backed, together with what it connects to. Read across workbooks, that inventory answers the question this page opens with: which preparation logic repeats, and therefore which extracts are dataflow candidates rather than one-off imports.

Moving the rows themselves is out of scope by design. Analysis and conversion read metadata only, never business data, and the data platform decisions stay with the people who own the platform. [Run the free Analyzer](https://try.getantares.io) to see which sources repeat across your own workbooks.

Related reading: [Hyper files to Power BI](https://getantares.io/convert-hyper-files-to-power-bi/) and [data sources to semantic models](https://getantares.io/tableau-data-sources-to-power-bi-datasets/). Primary sources: Microsoft's [dataflow configuration guide](https://learn.microsoft.com/en-us/power-bi/transform-model/dataflows/dataflows-configure-consume) and the [Gen1 versus Gen2 comparison](https://learn.microsoft.com/en-us/fabric/data-factory/dataflows-gen2-overview).

## Related resources

- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [Hyper Files to Power BI](https://getantares.io/convert-hyper-files-to-power-bi/)
- [Data Sources to Power BI Datasets](https://getantares.io/tableau-data-sources-to-power-bi-datasets/)
- [Custom SQL to Power BI](https://getantares.io/tableau-custom-sql-to-power-bi/)

## FAQ

### Is a Power BI dataflow the equivalent of a Tableau extract?

No. An extract is a cache belonging to one workbook, and its counterpart is Import mode inside a semantic model. A dataflow is reusable preparation logic that many models share, which puts it closer to a Tableau published data source or a Tableau Prep flow.

### When should a Tableau extract become a dataflow?

When the same joins, filters and cleanup were repeated across several workbooks because that was the only way to share them. One workbook owning an extract needs no dataflow. Microsoft also documents dataflows for exposing curated data instead of source credentials.

### Should I use Dataflow Gen1 or Gen2?

Gen2 for new work: Gen1 is in a legacy state and will not receive new feature investment. Gen2 needs a Fabric or Power BI Premium capacity, supports output destinations such as Lakehouse and Warehouse, and runs inside pipelines. One catch: DirectQuery through the dataflow connector works on Gen1 only.

### What replaces the extract refresh schedule?

Two schedules instead of one. The dataflow refreshes, then the semantic model that reads it refreshes, and the second must run after the first. Gen1 leaves the spacing to you; Gen2 can express the dependency inside a pipeline.

---

## Tableau Parameters to Power BI: What-If, Field, and Query Parameters

Canonical: https://getantares.io/tableau-parameters-to-power-bi-parameters/
Published: 2026-02-18
Updated: 2026-07-28

Tableau defines a parameter as "a workbook variable such as a number, date, or string that can replace a constant value in a calculation, filter, or reference line", and it is global across the workbook. Power BI has no single feature with that reach. One Tableau concept splits into four unrelated mechanisms, and the conversion goes wrong when the wrong one is chosen, not when the DAX is written badly. Start from what the parameter was used for.

## Which Power BI parameter to use

| What the Tableau parameter did | Power BI mechanism | Where it lives |
| --- | --- | --- |
| Fed a number into a calculation, such as a discount rate | What-if parameter | Modeling, New parameter, Numeric range |
| Switched which measure a chart shows | Field parameter | Modeling, New parameter, Fields |
| Switched which dimension a chart breaks down by | Field parameter | Same, with columns instead of measures |
| Moved a reference line | What-if parameter plus a measure | The measure drives the line |
| Drove a Top N filter | What-if parameter inside `TOPN` or `RANKX` | See [sets to DAX](https://getantares.io/tableau-sets-to-dax-measures/) |
| Changed a value inside custom SQL | Power Query parameter | Manage Parameters in Power Query |
| Let a user change that SQL value at view time | Dynamic M query parameter | DirectQuery sources only |
| Appeared in a title or caption | The parameter's own measure, in a card or dynamic title | Report layer |

## What-if parameters: the numeric case

Creating a [what-if parameter](https://learn.microsoft.com/en-us/power-bi/transform-model/desktop-what-if) generates three things at once: a table of values, a measure that returns the current selection, and optionally a slicer. Your own calculations reference the measure, never the column, which is the single most common mistake when converting from Tableau, where the parameter is simply a value you type into a formula.

Two documented limits shape the design. A parameter can hold at most 1,000 unique values, and beyond that the values are evenly sampled, so a Tableau parameter offering every date in a decade needs rethinking rather than porting. And parameters are designed for measures within visuals: Microsoft warns that using one in a dimension calculation might calculate incorrectly. A Tableau parameter used inside a row-level calculated field is therefore not a like-for-like move, and usually becomes a measure instead.

## Field parameters: the swap case

The Tableau pattern of a parameter plus a `CASE` calculation, used to let a viewer choose which measure a chart displays, has a purpose-built equivalent. [Field parameters](https://learn.microsoft.com/en-us/power-bi/create-reports/power-bi-field-parameters) let report readers change the measures or dimensions in a visual from a slicer, and one parameter can mix measures and dimensions. The definition is plain DAX using `NAMEOF`, so it can be edited directly rather than rebuilt through a dialog.

Check the limitations before promising a like-for-like rebuild. Implicit measures are not supported, so an aggregated column used in the Tableau version needs an explicit measure. Field parameters cannot be created on a live connection without a local model. They cannot be used as the linked field of a drillthrough or tooltip page, though the underlying fields can. And there is no "none" option: selecting nothing is the same as selecting everything.

## Parameters that change the query, not the calculation

When the Tableau parameter sat inside custom SQL, the equivalent is a Power Query parameter, and both have the same restriction: they replace literal values, not table names or expressions. To put that control in a report reader's hands rather than a developer's, bind a field to a [dynamic M query parameter](https://learn.microsoft.com/en-us/power-bi/connect-data/desktop-dynamic-m-query-parameters), which passes a slicer selection into the source query for DirectQuery sources.

Two cautions. Microsoft documents an injection risk when parameter values are concatenated into query text, and recommends consuming them through folding operations or the source's own parameter mechanism instead. And the supported filter types are narrow: relative date, hierarchy slicers, exclude filters and Top N filters are all unsupported, so a Tableau parameter driving anything of that shape needs a different design. Details are in [custom SQL to Power BI](https://getantares.io/tableau-custom-sql-to-power-bi/).

## The gap: parameter actions

Tableau's Change Parameter action lets users set a parameter by clicking marks in a viz. Power BI has no feature that writes a value back into a parameter from a selection. The workable substitutes are a field parameter driven by a slicer, a bookmark that switches between prepared states, or a disconnected table whose selection a measure reads back. Each is a design decision rather than a translation, so price parameter actions separately, as with [the other Tableau actions](https://getantares.io/tableau-actions-to-power-bi-drillthrough/).

## What Antares does with parameters

Parameters are inventoried rather than assumed. That matters because the same Tableau object splits four ways here, and the split is driven by usage, not by the parameter's own definition: the same parameter can feed a calculation on one sheet and a Top N filter on another.

Where the target is unambiguous, conversion handles it. Where it is not, it is flagged rather than guessed, because a parameter silently rewired to the wrong mechanism produces a report that works and answers a slightly different question. [Run the free Analyzer](https://try.getantares.io) to see how parameters are used across your own workbooks.

Related reading: [calculated fields to DAX](https://getantares.io/tableau-calculated-fields-to-dax/) and [sets to DAX](https://getantares.io/tableau-sets-to-dax-measures/). Primary sources: Tableau's [parameter documentation](https://help.tableau.com/current/pro/desktop/en-us/parameters_create.htm) and Microsoft's guides to [what-if parameters](https://learn.microsoft.com/en-us/power-bi/transform-model/desktop-what-if) and [field parameters](https://learn.microsoft.com/en-us/power-bi/create-reports/power-bi-field-parameters).

## Related resources

- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [Calculated Fields to DAX](https://getantares.io/tableau-calculated-fields-to-dax/)
- [Sets to DAX Measures](https://getantares.io/tableau-sets-to-dax-measures/)
- [Actions to Power BI Drillthrough](https://getantares.io/tableau-actions-to-power-bi-drillthrough/)
- [Parameters and Actions in Databricks AI/BI](https://getantares.io/tableau-parameters-to-databricks-ai-bi-parameters/)

## FAQ

### What is the Power BI equivalent of a Tableau parameter?

There are four, chosen by use. A numeric value feeding a calculation becomes a what-if parameter. Switching which measure or dimension a visual shows becomes a field parameter. A value inside custom SQL becomes a Power Query parameter, or a dynamic M query parameter when a report user should control it.

### How do what-if parameters differ from Tableau parameters?

A what-if parameter creates a table of values, a measure returning the current selection, and optionally a slicer, and your calculations must reference the measure rather than the column. They hold at most 1,000 unique values and are designed for measures within visuals, so using one in a dimension calculation can compute incorrectly.

### How do I let users switch measures like a Tableau parameter and CASE?

Field parameters. One parameter can mix measures and dimensions, and readers switch them from a slicer. Note the limits: no implicit measures, no creation on a live connection without a local model, no use as a drillthrough or tooltip link field, and no none option.

### Can Power BI reproduce a Tableau parameter action?

Not directly, since nothing writes a value back into a parameter from a mark selection. The substitutes are a field parameter driven by a slicer, bookmarks that switch prepared states, or a disconnected table whose selection a measure reads back. Treat these as design work rather than translation.

---

## Tableau Data Sources to Power BI Semantic Models: Embedded, Shared, and Endorsed

Canonical: https://getantares.io/tableau-data-sources-to-power-bi-datasets/
Published: 2026-02-18
Updated: 2026-07-28

Two things trip people up here, and only one of them is technical. The vocabulary changed: what Power BI called a dataset is now called a semantic model, and Microsoft's documentation uses the terms model and semantic model interchangeably. The substantive question is the one Tableau made you answer too, just under different names: does this data live inside a single report, or does it become a shared asset that many reports connect to?

## Tableau data sources in Power BI terms

| Tableau | Power BI | Notes |
| --- | --- | --- |
| Embedded data source | The model inside a single `.pbix` | One report owns it |
| Published data source | Shared semantic model in a workspace | Many reports connect to one model |
| Connecting to a published data source | Live connection to a semantic model | Report authors get the model, not the credentials |
| Extract on a published data source | Import mode with scheduled refresh | See [Hyper files to Power BI](https://getantares.io/convert-hyper-files-to-power-bi/) |
| Live connection | DirectQuery | Or Composite, mixing both |
| `.tds` and `.tdsx` files | No file equivalent | A semantic model is a workspace item |
| Certified data source | Endorsement: Promoted or Certified | Two levels, different permissions |
| User filters | Row-level security roles | Static or dynamic roles |
| Data source owner | Semantic model ownership | Non-owners see settings read-only |

## The decision the migration forces

In Tableau, embedding a data source in a workbook is the path of least resistance and publishing one is a deliberate act. Power BI works the same way, and a lift-and-shift migration inherits whatever the Tableau estate happened to do. That is the moment to choose rather than inherit.

Publish a shared model when several reports answer questions from the same numbers, when the measure definitions are the thing that must not diverge, or when report authors should never hold source credentials. Keep the model inside the report when one report owns its data end to end, when the refresh cadence is specific to it, or when a shared model would collect fields nobody else uses. A workbook estate with thirty embedded copies of the same sales data is telling you which way to go.

## Endorsement replaces the naming convention

Every Tableau estate has an informal signal for which data source to trust: a prefix, a folder, a wiki page. Power BI has [endorsement](https://learn.microsoft.com/en-us/power-bi/collaborate-share/service-endorse-content) built in, at two levels with different rules. Promotion can be applied by any content owner or workspace member with write permissions, and simply says the content is worth using. Certification means the content meets the organisation's quality standards and can only be applied by reviewers the Power BI administrator has authorised.

Endorsed semantic models can also be made discoverable, so users without access can find them and request it rather than rebuilding their own copy. That is worth configuring during migration rather than after, because the alternative is exactly the sprawl the migration was meant to end. Write the description while you are there: it is what users see in the semantic models hub.

## What a semantic model actually is

Technically, [a Power BI Desktop model is an Analysis Services tabular model](https://learn.microsoft.com/en-us/power-bi/connect-data/service-datasets-understand), and it comes in three modes: Import, DirectQuery and Composite. That has two consequences worth knowing during a migration. Import models must be fully loaded into memory to be queried and need refresh to stay current; DirectQuery models need live connectivity to the source, and a gateway when that source is not reachable over the internet.

It also means the model is not a per-report convenience the way a Tableau embedded data source can be. Relationships, measures, formatting, hierarchies and row-level security all live in it, and they are exactly what is worth writing once instead of thirty times.

## Row-level security and ownership

Tableau user filters become RLS roles, which are dynamic or static: dynamic roles filter by the report user, static roles apply the same filter to everyone assigned to the role. Both are defined in the model rather than per report, so a shared model gets its security defined once, which is another argument for publishing.

Ownership is the operational detail people meet later. If you are not the semantic model owner, its settings are read-only until you take ownership, and there is an API for taking over when an owner leaves the organisation. Decide who owns each model during the migration rather than discovering it during a failed refresh.

## What Antares does with data sources

The Analyzer inventories every data source in every workbook, records whether each is live or extract-backed, and captures what it connects to. Read across an estate, that is the evidence for the decision above: which connections repeat, which are unique, and therefore which become shared semantic models rather than thirty private copies.

The conversion itself produces the report layer, and analysis reads metadata only, never business data. Model ownership, endorsement and security stay where they belong, with the people who run the platform. [Run the free Analyzer](https://try.getantares.io) to see how the connections repeat across your own workbooks.

Related reading: [extracts to Power BI dataflows](https://getantares.io/convert-tableau-extracts-to-power-bi-dataflows/) and [blending to model relationships](https://getantares.io/tableau-blending-to-power-bi-relationships/). Primary sources: Tableau's [published data source documentation](https://help.tableau.com/current/pro/desktop/en-us/publish_datasources.htm) and Microsoft's guide to [connecting reports to shared semantic models](https://learn.microsoft.com/en-us/power-bi/connect-data/desktop-report-lifecycle-datasets).

## Related resources

- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [Extracts to Power BI Dataflows](https://getantares.io/convert-tableau-extracts-to-power-bi-dataflows/)
- [Blending to Power BI Relationships](https://getantares.io/tableau-blending-to-power-bi-relationships/)
- [Custom SQL to Power BI](https://getantares.io/tableau-custom-sql-to-power-bi/)

## FAQ

### What is the Power BI equivalent of a Tableau published data source?

A shared semantic model in a workspace, which reports connect to with a live connection. An embedded Tableau data source corresponds to the model held inside a single .pbix file. Note the vocabulary change: what Power BI called a dataset is now called a semantic model.

### Should each report have its own model or share one?

Share when several reports answer questions from the same numbers, when measure definitions must not diverge, or when authors should not hold source credentials. Keep the model in the report when one report owns its data end to end and a shared model would collect fields nobody else uses.

### What replaces certifying a Tableau data source?

Endorsement, at two levels. Promotion can be applied by any content owner or workspace member with write permissions. Certification means the content meets organisational quality standards and can only be applied by reviewers the Power BI administrator has authorised. Endorsed models can also be made discoverable.

### How do Tableau user filters convert?

Into row-level security roles on the semantic model, which are dynamic or static. Dynamic roles filter by the report user; static roles apply the same filter to everyone assigned to the role. Because RLS lives in the model, a shared model gets its security defined once.

---

## Tableau Custom SQL to Power BI: Native Queries, Query Folding, and What to Rewrite

Canonical: https://getantares.io/tableau-custom-sql-to-power-bi/
Published: 2026-02-18
Updated: 2026-07-28

Tableau runs custom SQL as a subquery: it has to wrap your statement in a `SELECT` of its own, because it cannot inject `WHERE` and `GROUP BY` clauses into SQL you wrote. Power BI does the same thing with a native database query, entered in the *SQL statement* box under Advanced options on the connector. The difference that matters is what happens to everything you do afterwards: in Power BI, how you paste the SQL decides whether later steps run on the database or on your own machine.

## Custom SQL to Power Query conversion table

| Tableau | Power BI equivalent | Notes |
| --- | --- | --- |
| Custom SQL query | Native database query in the *SQL statement* box | Simplest route, but subsequent steps stop folding |
| Custom SQL plus later filtering | `Value.NativeQuery(Source, "…", null, [EnableFolding = true])` | Keeps folding alive on supported connectors |
| Parameter inside custom SQL | Power Query parameter | Both replace literal values only |
| Parameter driven by a user control | Dynamic M query parameter bound to a field | DirectQuery sources only |
| Initial SQL | No equivalent | Move the logic into the query, a view, or the source |
| Joins on top of custom SQL | Model relationships, or a database view | Usually a sign the SQL should become a view |
| Live connection on custom SQL | DirectQuery with a native query | All partitions must query a single source |
| Extract on custom SQL | Import mode | The query runs at refresh, not at view time |

## Why the SQL statement box quietly costs you performance

[Query folding](https://learn.microsoft.com/en-us/power-query/query-folding-basics) is the mechanism that translates your Power Query steps into the data source's own language and pushes them down to it. Folding is full, partial or absent, and the difference is not cosmetic: without it, Power BI retrieves the raw result and filters, groups and sorts it locally.

A native query pasted into the *SQL statement* box returns a table, but Microsoft's own documentation is explicit that this route means your query "doesn't take advantage of any query folding from subsequent query steps". [The documented alternative](https://learn.microsoft.com/en-us/power-query/native-query-folding) is to connect at the database level, then call `Value.NativeQuery` with `EnableFolding = true`. Power Query then wraps your SQL as a subquery and folds later steps into it, which is the same shape Tableau uses, except that here you can watch it happen in the query plan.

That option is connector-specific. It is documented for Amazon Redshift, Dataverse with enhanced compute, Google BigQuery, PostgreSQL, SAP HANA, Snowflake and SQL Server. Anywhere else, assume the pasted statement is the end of folding, and put the filtering inside the SQL itself. Folding also decides whether [incremental refresh](https://getantares.io/convert-hyper-files-to-power-bi/) is worth configuring at all, since a policy whose filter does not fold pulls the whole table anyway.

## Not all custom SQL should survive the migration

Tableau's documentation states plainly that using custom SQL can affect workbook performance, and a workbook estate full of it usually means the modelling was done in SQL because the data source could not express it. Power BI moves that work somewhere else, so the migration is a good moment to sort custom SQL into three buckets.

| What the SQL does | Where it belongs in Power BI |
| --- | --- |
| Window functions, complex joins, security predicates | Stays SQL, ideally as a database view |
| Renaming, type casting, filtering, pivoting | Power Query steps that fold |
| Denormalising several tables into one wide result | Model tables plus [relationships](https://getantares.io/tableau-blending-to-power-bi-relationships/) |
| Unions of near-identical tables | Power Query append, or a view |

A view is the underrated option. It moves the statement to where the DBA can see and index it, gives every report the same definition, and leaves Power Query with a plain table to fold against. It also removes the duplicate-column trap Tableau warns about, where the same field name arriving from two joined tables makes the field unusable.

## Custom SQL under DirectQuery

When the Tableau workbook was live rather than extracted, the equivalent is DirectQuery over the same statement. Two things then change. All partitions of the model have to query a single source, so a native query that quietly reached across databases needs restructuring first. And report users can no longer be given free-form parameters: the supported route is a [dynamic M query parameter](https://learn.microsoft.com/en-us/power-bi/connect-data/desktop-dynamic-m-query-parameters), where a field in a table is bound to an M parameter so a slicer selection reaches the source query.

Treat that binding carefully. Microsoft documents an injection risk when parameter values are concatenated into query text, and recommends consuming them through operations that fold, a stored procedure, or the source language's own parameter mechanism instead. A Tableau parameter dropped into custom SQL carries the same exposure; it is simply less visible there.

## What Antares does with custom SQL

The Analyzer records which data sources are backed by custom SQL rather than tables, and what each one connects to. That matters for scoping because those data sources are not a mechanical conversion: each is a modelling decision about whether the statement becomes a view, a set of folded Power Query steps, or a relationship in the model.

Conversion itself covers the dashboard layer. The rule the product follows is the same one that applies here: where a mapping is ambiguous, it is flagged rather than guessed, because a silently rewritten query is far more expensive to find in testing than a flagged one is to review. [Run the free Analyzer](https://try.getantares.io) to see where custom SQL sits in your own estate.

Related reading: [data sources to Power BI datasets](https://getantares.io/tableau-data-sources-to-power-bi-datasets/) and [calculated fields to DAX](https://getantares.io/tableau-calculated-fields-to-dax/). Primary sources: Tableau's [custom SQL documentation](https://help.tableau.com/current/pro/desktop/en-us/customsql.htm) and Microsoft's guides to [native database queries](https://learn.microsoft.com/en-us/power-query/native-database-query) and the [Value.NativeQuery function](https://learn.microsoft.com/en-us/powerquery-m/value-nativequery).

## Related resources

- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [Data Sources to Power BI Datasets](https://getantares.io/tableau-data-sources-to-power-bi-datasets/)
- [Blending to Power BI Relationships](https://getantares.io/tableau-blending-to-power-bi-relationships/)
- [Hyper Files to Power BI](https://getantares.io/convert-hyper-files-to-power-bi/)

## FAQ

### What is the Power BI equivalent of Tableau custom SQL?

A native database query, entered in the SQL statement box under Advanced options on the connector. Power Query runs it much as Tableau does, wrapping it as a subquery. For anything that needs later filtering to reach the database, use Value.NativeQuery with EnableFolding set to true instead.

### Does custom SQL stop query folding in Power BI?

Through the SQL statement box, yes: Microsoft documents that subsequent query steps do not fold. Value.NativeQuery with EnableFolding = true keeps folding for later steps, and is documented for Amazon Redshift, Dataverse with enhanced compute, Google BigQuery, PostgreSQL, SAP HANA, Snowflake and SQL Server.

### Can Tableau parameters inside custom SQL be converted?

Yes. A Power Query parameter covers the same ground, since both replace literal values only. To let a report user drive the value, bind a field to a dynamic M query parameter, which works for DirectQuery sources. Avoid concatenating user values into query text, which Microsoft flags as an injection risk.

### Should custom SQL be kept or rebuilt during migration?

Keep SQL for what the database does best, such as window functions, complex joins and security predicates, ideally as a view. Move renaming, casting, filtering and pivoting into Power Query steps that fold, and turn denormalising statements into model tables with relationships.

---

## Tableau Sets to DAX: Converting Fixed, Dynamic, and Combined Sets to Power BI

Canonical: https://getantares.io/tableau-sets-to-dax-measures/
Published: 2026-02-18
Updated: 2026-07-28

Power BI has no object called a set. A Tableau set is two things at once: a stored list of members, and an IN/OUT field you can drop on a shelf to split the view into members and everything else. In DAX those two halves separate. Membership becomes a filter expression, and the IN/OUT field becomes either a calculated column, when membership is fixed, or a measure, when it has to be recomputed as the data changes.

## Set type to DAX conversion table

| Tableau | DAX equivalent | Approach |
| --- | --- | --- |
| Fixed set, one dimension | `Product[Color] IN { "Red", "Blue" }` | Table constructor with the `IN` operator |
| Fixed set, several dimensions | Calculated column combining the columns | Only fixed sets can span dimensions |
| Condition set | `FILTER(VALUES(Product[Product]), [Sales] > 100000)` | Evaluated at query time |
| Top N set | `TOPN(5, VALUES(Product[Product]), [Sales])` | Returns ties, so possibly more than N |
| Top N, exactly N rows | `RANKX(ALLSELECTED(Product[Product]), [Sales]) <= 5` | Ranking instead of a table |
| IN/OUT on a shelf | Calculated column, or a measure returning "In" or "Out" | A visual cannot group rows by a measure |
| All Members in Both Sets | `UNION` | Combined sets |
| Shared Members in Both Sets | `INTERSECT` | Combined sets |
| Except Shared Members | `EXCEPT` | Order of arguments matters |
| Set action | Cross-filtering, bookmarks, or a disconnected table | No stored, user-updatable set exists |

## Fixed sets are a column, dynamic sets are a measure

Tableau's own distinction is the one to convert against: the members of a fixed set do not change when the data changes, while a [dynamic set](https://help.tableau.com/current/pro/desktop/en-us/sortgroup_sets_create.htm) does, and a dynamic set can only be based on a single dimension. A fixed set is therefore a stored list, and a calculated column carrying a flag is the honest translation. It costs a little memory, it can be sliced, filtered and put on an axis, and it behaves exactly like the Tableau original.

A dynamic set cannot become a column, because its membership depends on aggregates that only exist at query time. It becomes a measure or a calculated table. That creates the one structural gotcha in this conversion: Power BI cannot group the rows of a visual by a measure. If the Tableau view puts IN/OUT on rows and users expect two bars, you either accept a calculated column with a condition built only from stored values, or you add a two-row table holding "In" and "Out" and write a measure that responds to which row is in context.

## Condition sets and the filter context they run in

A condition set is a rule such as "products whose sales exceed 100,000". In DAX that is a `FILTER` over the values of the column, wrapped in `CALCULATE` or `CALCULATETABLE` when you need it as a filter argument. The question the Tableau formula never had to answer is which context the rule is evaluated in.

Use `VALUES` or `ALLSELECTED` when the set should respect the user's slicers, so a product qualifies against sales in the selected period. Use `ALL` when membership is meant to be absolute regardless of what is filtered. Both are defensible, they produce different member lists, and the difference is invisible until somebody applies a slicer. Decide it deliberately during conversion rather than discovering it in testing.

## Top N sets

[TOPN](https://learn.microsoft.com/en-us/dax/topn-function-dax) is the direct equivalent of Tableau's Top tab, with one documented behaviour worth knowing: if values tie at the Nth row, every tied row is returned, so the function can return more than N rows. Tableau's Top N set has the same intent but not the same tie handling, so a "top 5" that quietly becomes seven rows after migration is a conversion artefact, not a data problem.

When exactly N rows matter, rank instead of taking a top slice: compare `RANKX` against the threshold and treat everything above it as the "Others" bucket. That also gives you the Top N plus Others pattern in one expression, which in Tableau usually needs a set and a calculated field working together.

## Set actions have no equivalent, and that is the expensive part

[Set actions](https://help.tableau.com/current/pro/desktop/en-us/actions_sets.htm) update the contents of a stored set from what the user selects in a viz, which is what makes proportional brushing, asymmetric drill-down and self-adjusting colour scales possible. Power BI has no stored set for a user to write into, so each of these is rebuilt from different parts: cross-filtering between visuals, drillthrough, bookmarks, or a disconnected table whose selection is read back with `SELECTEDVALUE`.

Those rebuilds are design work, not translation, and they are the reason a workbook with a handful of set actions can cost more than one with a hundred plain charts. Price them separately when scoping.

## What Antares does with sets

Sets are reported as manual work rather than auto-converted, alongside LOD expressions and table calculations. What the Analyzer contributes is the distinction that drives the estimate: a fixed set that becomes a calculated column is minutes of work, while a set action wired into a dashboard's interactions is a redesign. Both look like one line in a raw feature count.

Where a mapping is genuinely ambiguous, it is flagged rather than guessed, because a set whose membership silently shifted is the kind of error that surfaces only when a user asks why a total moved. [Run the free Analyzer](https://try.getantares.io) to get the breakdown for your own workbooks.

Related reading: [LOD expressions to DAX](https://getantares.io/tableau-lod-expressions-to-dax/), [table calculations to DAX](https://getantares.io/tableau-table-calculations-to-dax/) and [groups and hierarchies](https://getantares.io/tableau-groups-to-power-bi/). Primary sources: Tableau's [Top N sets guide](https://help.tableau.com/current/pro/desktop/en-us/sortgroup_sets_topn.htm) and Microsoft's references for the [DAX IN operator](https://learn.microsoft.com/en-us/dax/dax-operator-reference), [CALCULATETABLE](https://learn.microsoft.com/en-us/dax/calculatetable-function-dax) and [UNION](https://learn.microsoft.com/en-us/dax/union-function-dax).

## Related resources

- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [LOD Expressions to DAX](https://getantares.io/tableau-lod-expressions-to-dax/)
- [Table Calculations to DAX](https://getantares.io/tableau-table-calculations-to-dax/)
- [Groups and Hierarchies to Power BI](https://getantares.io/tableau-groups-to-power-bi/)

## FAQ

### What is the Power BI equivalent of a Tableau set?

There is no set object. A fixed set becomes a calculated column carrying a flag, or an IN test such as Product[Color] IN { "Red", "Blue" }. A dynamic set becomes a measure or a calculated table, because its membership depends on aggregates that only exist at query time.

### How do you convert a Tableau Top N set to DAX?

TOPN over the values of the column, ordered by the measure, is the direct equivalent. Note that TOPN returns every row tied at the Nth position, so it can return more than N rows. When exactly N rows are required, compare RANKX against the threshold instead.

### Can Power BI show IN and OUT like a Tableau set?

Only through a column. A visual cannot group its rows by a measure, so an IN/OUT axis needs either a calculated column, when the condition uses stored values, or a two-row helper table holding In and Out with a measure that responds to the row in context.

### What replaces Tableau set actions in Power BI?

Nothing directly, because Power BI has no stored set that a user selection can write into. Proportional brushing, asymmetric drill-down and self-adjusting colour scales are rebuilt from cross-filtering, drillthrough, bookmarks, or a disconnected table read back with SELECTEDVALUE. Scope these as design work.

---

## Tableau Table Calculations to DAX: Running Totals, Ranks, and Window Functions

Canonical: https://getantares.io/tableau-table-calculations-to-dax/
Published: 2026-02-18
Updated: 2026-07-27

Tableau table calculations run on the result set after aggregation, using the layout of the view to define direction and scope. DAX has no result set to walk, so every conversion rebuilds "Compute Using" as an explicit filter or window definition. The classic approach wraps `CALCULATE` around a `FILTER`. Newer DAX window functions (`OFFSET`, `WINDOW`, `ROWNUMBER`) express the same logic more directly where your Power BI version supports them.

Arrived with the broader question? [Does Tableau use DAX?](https://getantares.io/tableau-calculated-fields-to-dax/#does-tableau-use-dax) is answered in the calculated fields reference, which also maps the whole function library. This page covers the part that translates least directly: table calculations.

## Table calculation to DAX conversion table

| Tableau | DAX equivalent | Approach |
| --- | --- | --- |
| `RUNNING_SUM(SUM([Sales]))` | `CALCULATE(SUM(Sales[Amount]), FILTER(ALLSELECTED('Date'[Date]), 'Date'[Date] <= MAX('Date'[Date])))` | Cumulative filter |
| `WINDOW_AVG(SUM([Sales]))` | `AVERAGEX(ALLSELECTED('Date'[Month]), CALCULATE(SUM(Sales[Amount])))` | Iterate the partition |
| `WINDOW_AVG(SUM([Sales]), -2, 0)` | `AVERAGEX(WINDOW(-2, REL, 0, REL, …), CALCULATE(SUM(Sales[Amount])))` | Window function |
| `TOTAL(SUM([Sales]))` | `CALCULATE(SUM(Sales[Amount]), ALLSELECTED())` | Whole-partition total |
| `RANK(SUM([Sales]))` | `RANKX(ALLSELECTED(Product[Product]), CALCULATE(SUM(Sales[Amount])))` | Ranking |
| `INDEX()` | `ROWNUMBER(ALLSELECTED(…), ORDERBY(…))` | Positional |
| `SIZE()` | `COUNTROWS(ALLSELECTED(Product[Product]))` | Positional |
| `LOOKUP(SUM([Sales]), -1)` | `CALCULATE(SUM(Sales[Amount]), OFFSET(-1, ALLSELECTED('Date'[Month]), ORDERBY('Date'[Month])))` | Offset |
| `PERCENT_OF_TOTAL(SUM([Sales]))` | `DIVIDE(SUM(Sales[Amount]), CALCULATE(SUM(Sales[Amount]), ALLSELECTED(Product[Product])))` | Ratio to partition |
| `PREVIOUS_VALUE()` | — | Recursive; no DAX equivalent |

## Running totals and moving averages

A running total is a cumulative filter: sum everything up to and including the current row's position on the axis. Two details decide whether it matches Tableau. Use `ALLSELECTED` rather than `ALL`, so the running total stays inside the user's slicer selection the way Tableau's default addressing does. And read the current position with `MAX('Date'[Date])` — that idiom stands in for "the current row" when there is no row context. If the Tableau calculation restarts on a dimension ("Restarting every Year"), add that column back as a filter argument so it survives `ALLSELECTED`.

Moving averages need a bounded window rather than an open-ended one. The [WINDOW](https://learn.microsoft.com/en-us/dax/window-function-dax) function takes relative or absolute boundaries plus an explicit sort, so `WINDOW(-2, REL, 0, REL, …)` is the direct equivalent of Tableau's `-2, 0` offsets. Without window functions, the equivalent is `AVERAGEX` over `DATESINPERIOD`, which requires a date table. With no offsets at all, the window is the whole partition and the conversion collapses to an iterator over `ALLSELECTED` — the same shape covers `WINDOW_SUM`, `WINDOW_MIN`, `WINDOW_MAX`, and `WINDOW_MEDIAN`.

## Ranks and positions

Tableau's five ranking functions differ mainly in how they treat ties, and [RANKX](https://learn.microsoft.com/en-us/dax/rankx-function-dax) covers most of them through its optional `ties` argument. Note that DAX has its own functions called `RANK` and `INDEX`; neither is the equivalent of the Tableau function with the same name. Both languages rank from the highest value down by default, and `Skip` ties are the RANKX default, so the plain form already matches Tableau's `RANK`. Watch the direction on `RANK_PERCENTILE`, though: Tableau puts the *lowest* value at 0 and the highest at 1, which is the reverse of a descending rank.

| Tableau | Ties produce | DAX |
| --- | --- | --- |
| `RANK` | 1, 2, 2, 4 | `RANKX(…)` — `Skip` is the default |
| `RANK_DENSE` | 1, 2, 2, 3 | `RANKX(table, expr, , , "Dense")` — `ties` is the fifth argument |
| `RANK_UNIQUE` | 1, 2, 3, 4 | `ROWNUMBER(…, ORDERBY(…))` |
| `RANK_MODIFIED` | 1, 3, 3, 4 | No direct form — derive from `RANKX` and the tie count |
| `RANK_PERCENTILE` | 0–1 scale, lowest value is 0 | `DIVIDE(COUNTROWS(ALLSELECTED(…)) - RANKX(…), COUNTROWS(ALLSELECTED(…)) - 1)` |

`INDEX()` returns a position in the addressing order rather than a rank by value, so its equivalent is `ROWNUMBER`, not `RANKX`. From there, `SIZE()` is `COUNTROWS(ALLSELECTED(…))`, `FIRST()` is `1 - ROWNUMBER(…)`, and `LAST()` is `COUNTROWS(ALLSELECTED(…)) - ROWNUMBER(…)`.

## LOOKUP and PREVIOUS_VALUE

`LOOKUP` fetches a value from another position in the partition, and [OFFSET](https://learn.microsoft.com/en-us/dax/offset-function-dax) is the direct translation. When the offset is genuinely a time shift and a proper date table exists, time intelligence is clearer and faster — `PREVIOUSMONTH` or `DATEADD`. The difference matters when periods are missing from the data: `OFFSET` steps to the previous row that exists, time intelligence steps to the previous calendar month whether or not it has data.

`PREVIOUS_VALUE()` has no DAX equivalent. It is recursive by nature: each row reads the calculation's own output from the row before it, and a DAX measure cannot reference its own prior result. Every occurrence needs restructuring, usually into a running aggregate or a Power Query step that materialises the sequence at load time. These are the most expensive items in a table-calculation inventory and should be scoped separately.

## Compute Using: addressing and partitioning in DAX

The Compute Using dialog is the whole configuration of a table calculation, and it is not stored in the formula text. Two calculations with identical text return different numbers if their addressing differs, which is why reading formulas alone is not enough to plan this work — you have to open the workbook.

| Tableau concept | What it controls | DAX equivalent |
| --- | --- | --- |
| Addressing (Compute Using) | The direction the calculation moves | [`ORDERBY()`](https://learn.microsoft.com/en-us/dax/orderby-function-dax) |
| Partitioning (Restarting every) | Where the calculation resets | [`PARTITIONBY()`](https://learn.microsoft.com/en-us/dax/partitionby-function-dax) |
| Table (across) | Walk columns, reset per row | `ORDERBY` on the column field, `PARTITIONBY` on the row field |
| Table (down) | Walk rows, reset per column | The reverse pairing |
| Specific dimensions | An explicit list, with a sort order | `ORDERBY` plus `PARTITIONBY` naming those columns |
| Pane versus Table scope | Whether an outer dimension resets it | Add the outer column to `PARTITIONBY`, or leave it out |

## What Antares does with table calculations

Table calculations are not auto-converted — they are reported as manual DAX work, alongside LOD expressions and the other structural blockers. What the Analyzer does is inventory them precisely: each one is identified by kind, so a running total is not counted the same as a recursive calculation. It also detects Quick Table Calcs, which never appear as function names in the formula text and are therefore missed by any count based on searching formulas.

That distinction is what makes an estimate defensible. A workbook with thirty running totals is a day of mechanical work; a workbook with three `PREVIOUS_VALUE` calculations is a modelling problem. Both look identical in a raw formula count. [Run the free Analyzer](https://try.getantares.io) to get the breakdown for your own estate.

Related reading: [Tableau LOD expressions to DAX](https://getantares.io/tableau-lod-expressions-to-dax/) and [Tableau calculated fields to DAX](https://getantares.io/tableau-calculated-fields-to-dax/). Primary sources: Tableau's [table calculation function reference](https://help.tableau.com/current/pro/desktop/en-us/functions_functions_tablecalculation.htm) and Microsoft's [DAX function reference](https://learn.microsoft.com/en-us/dax/dax-function-reference).

## Related resources

- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [LOD Expressions to DAX](https://getantares.io/tableau-lod-expressions-to-dax/)
- [Calculated Fields to DAX](https://getantares.io/tableau-calculated-fields-to-dax/)
- [Sets to DAX Measures](https://getantares.io/tableau-sets-to-dax-measures/)
- [Table Calculations in Databricks AI/BI](https://getantares.io/tableau-table-calculations-to-databricks/)

## FAQ

### What is the DAX equivalent of RUNNING_SUM?

A cumulative filter: CALCULATE(SUM(Sales[Amount]), FILTER(ALLSELECTED('Date'[Date]), 'Date'[Date] <= MAX('Date'[Date]))). ALLSELECTED keeps the running total inside the user's slicer selection, matching Tableau's default addressing, and MAX('Date'[Date]) stands in for the current row's position.

### What is the DAX equivalent of Tableau's Compute Using setting?

ORDERBY and PARTITIONBY. Addressing — the direction a calculation moves — becomes ORDERBY; partitioning, or Restarting every, becomes PARTITIONBY. Compute Using is not stored in the formula text, so two identical Tableau formulas can return different numbers and must be inspected in the workbook.

### Can PREVIOUS_VALUE be converted to DAX?

No. PREVIOUS_VALUE is recursive — each row reads the calculation's own output from the previous row — and a DAX measure cannot reference its own prior result. Every occurrence needs restructuring, usually into a running aggregate or a Power Query step that materialises the sequence at load time.

### Does Antares convert Tableau table calculations automatically?

No — they are reported as manual DAX work. What the Analyzer does is inventory them by kind, so a running total is not counted the same as a recursive calculation, and it detects Quick Table Calcs, which never appear as function names in the formula text and are missed by any count based on searching formulas.

---

## Tableau Groups and Hierarchies to Power BI: Groups, Bins, and Mapping Tables

Canonical: https://getantares.io/tableau-groups-to-power-bi/
Published: 2026-02-18
Updated: 2026-07-28

Tableau groups combine dimension members, either to fix data errors, such as merging "CA" and "California", or to roll members up into a coarser category. Power BI has a feature with the same name and the same right-click gesture, so the conversion looks trivial. It usually should not be done that way. A Tableau group carries business meaning that deserves to live in the model as a column, not as a report-level convenience nobody can find later.

## Grouping options in Power BI

| Tableau | Power BI equivalent | Best when |
| --- | --- | --- |
| Group on a dimension | New group, List type | A handful of members, one report |
| Group on a dimension | Calculated column with `SWITCH` | The rule is logical, not a list |
| Group on a dimension | Conditional column in Power Query | The list is stable and should fold |
| Group with many members | Mapping table joined into the model | Business owns the mapping |
| Group across several dimensions | Calculated column combining the columns | Power BI groups work on one field |
| Other bucket | The *Other* group in the Groups dialog | Direct equivalent |
| Bins on a measure | New group, Bin type | Numeric and time fields |
| Hierarchy | Model hierarchy with drill mode | Drill replaces the plus icon |

## Four ways to group, and which one survives contact with a migration

[Power BI grouping](https://learn.microsoft.com/en-us/power-bi/create-reports/desktop-grouping-and-binning) is created by selecting elements in a visual and choosing Group, or by right-clicking a field and choosing New group. The result is a new field with *(groups)* appended, and members can be edited later in the Groups dialog, including moving leftovers into an *Other* group. For a small, report-specific grouping this is exactly right, and it is genuinely the closest match to the Tableau gesture.

It ages badly at scale. The membership list lives in the model's metadata, it is edited through a dialog, and nobody reviewing a change can see what moved. A calculated column with `SWITCH` states the rule in one readable expression. A conditional column in Power Query pushes the work upstream, keeps the model smaller, and can fold to the source. And when the grouping is a business mapping rather than a convenience, the honest answer is a mapping table loaded as a real dimension, joined on the key, and maintained by whoever owns the definition.

Use the Tableau group's size as the signal. Three members merged to fix a typo is a group. Two hundred products rolled into fifteen reporting categories is a dimension table that was living in a workbook because Tableau made that the easy option.

One clarification saves a recurring argument during migration. A group merges members into a coarser category and behaves like a column. A [set](https://getantares.io/tableau-sets-to-dax-measures/) answers a yes-or-no membership question and can be dynamic. A hierarchy defines a drill path between levels that already exist. Tableau users often reach for a group where the requirement is really a set, or the reverse, and the Power BI targets are genuinely different: a column, a filter expression, and a model hierarchy. Sort that out before writing anything.

## Binning

Tableau bins and Power BI bins line up closely. Right-click a field, choose New group and set a bin size, and a new field appears with *(bins)* appended. Two documented constraints matter when planning: bin sizes can be set for numerical and time fields, and you can create bins for calculated columns but not for measures. A Tableau bin built on an aggregate therefore needs the underlying value materialised as a column first, which is a modelling step rather than a formatting one.

## Hierarchies

A Tableau hierarchy adds the plus and minus controls on a shelf. A Power BI hierarchy is created in the model by dragging fields together, and users move through it with drill mode in the visual rather than by expanding the axis. The behaviour differs in one way worth explaining to users before go-live: by default, drilling one visual does not affect the others on the page, though you can set drill-down filters to apply to the entire page.

Watch date fields in particular. If auto date/time is enabled, Power BI builds a hidden date table for every date column, which inflates the model and interacts awkwardly with field parameters. Most estates are better served by one proper date table with an explicit hierarchy, defined once in the model.

## What Antares does with groups and hierarchies

Groups and hierarchies are inventoried with the rest of a workbook's structure, and the count is what makes the decision above cheap to take: a workbook with two typo-fixing groups and one with a two-hundred-member category mapping look identical in a feature list and are completely different pieces of work.

Where a group is a straightforward member list, conversion handles it. Where it encodes a business mapping that ought to become a dimension, that is a modelling decision for the team that owns the definition, and it is flagged rather than guessed. [Run the free Analyzer](https://try.getantares.io) to see the breakdown for your own workbooks.

Related reading: [sets to DAX](https://getantares.io/tableau-sets-to-dax-measures/) and [calculated fields to DAX](https://getantares.io/tableau-calculated-fields-to-dax/). Primary sources: Tableau's [grouping documentation](https://help.tableau.com/current/pro/desktop/en-us/sortgroup_groups.htm) and [hierarchies guide](https://help.tableau.com/current/pro/desktop/en-us/qs_hierarchies.htm), plus Microsoft's [SWITCH function reference](https://learn.microsoft.com/en-us/dax/switch-function-dax) and [star schema guidance](https://learn.microsoft.com/en-us/power-bi/guidance/star-schema).

## Related resources

- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [Sets to DAX Measures](https://getantares.io/tableau-sets-to-dax-measures/)
- [Calculated Fields to DAX](https://getantares.io/tableau-calculated-fields-to-dax/)
- [Blending to Power BI Relationships](https://getantares.io/tableau-blending-to-power-bi-relationships/)

## FAQ

### What is the Power BI equivalent of a Tableau group?

Power BI grouping, created by selecting elements in a visual and choosing Group, or by right-clicking a field and choosing New group. It produces a field with (groups) appended and supports an Other bucket. For anything larger than a few members, a calculated column, a Power Query conditional column or a mapping table ages better.

### When should a Tableau group become a mapping table instead?

When it encodes a business definition rather than a convenience. Three members merged to fix a typo is a group. Two hundred products rolled into fifteen reporting categories is a dimension table that was living in a workbook because Tableau made that the easy option.

### How do Tableau bins convert to Power BI?

Through New group with a Bin type, which produces a field with (bins) appended. Two constraints matter: bin sizes can be set for numerical and time fields, and bins can be created for calculated columns but not for measures, so a bin built on an aggregate needs that value materialised as a column first.

### What is the difference between a group, a set and a hierarchy?

A group merges members into a coarser category and behaves like a column. A set answers a yes-or-no membership question and can be dynamic. A hierarchy defines a drill path between levels that already exist. In Power BI those are three different targets: a column, a filter expression, and a model hierarchy.

---

## Tableau Data Blending to Power BI: Converting Blends into Model Relationships

Canonical: https://getantares.io/tableau-blending-to-power-bi-relationships/
Published: 2026-02-18
Updated: 2026-07-28

Tableau states the difference in one sentence: a join combines the data and then aggregates, while a blend aggregates and then combines. Blends never merge the data at all. They query each source independently, aggregate each result to the level of the view, and present the results together. Power BI has nothing shaped like that. Its model relationships propagate filters between tables and the aggregation happens afterwards, so converting a blend is a modelling decision about what the blend was standing in for.

## Blending concepts in Power BI

| Tableau | Power BI equivalent | Notes |
| --- | --- | --- |
| Primary data source | The table filters propagate from | Usually the dimension side of the relationship |
| Secondary data source | The related table | Filtered by the primary, never the reverse by default |
| Linking field | The relationship column | Both columns should have the same data type |
| Several linking fields | One relationship on a combined key | A relationship relates one column to one column |
| Secondary values must be aggregated | Measures over the related table | The same discipline, enforced by the engine |
| Asterisk for multiple values | An explicit aggregation, or a blank | No equivalent placeholder |
| Blend across databases | One model, or a composite model | Source groups matter, see below |
| Blended sources cannot be published | The semantic model is published once and reused | A real gain from the migration |
| Blend used to avoid duplicating rows | Star schema with a fact and dimensions | Often the honest answer |

## Cardinality and filter direction are the actual work

A blend has no cardinality setting. A [Power BI relationship](https://learn.microsoft.com/en-us/power-bi/transform-model/desktop-relationships-understand) has four options, one-to-many, many-to-one, one-to-one and many-to-many, and a cross filter direction of single or both. Power BI detects cardinality when the relationship is created, and it can get it wrong when tables are not yet loaded or when a column happens to hold unique values today.

Take the defaults seriously. One-to-many with a single filter direction is the fastest and the least ambiguous, and it is what a blend from a dimension to a fact usually means. Bi-directional filtering is tempting for reproducing a blend that seemed to work in both directions, but it costs performance and can produce ambiguous filter paths that Power BI resolves by its own priority rules or refuses outright. Where a Tableau workbook linked one dimension to a fact in more than one role, the equivalent is one active relationship plus inactive ones activated per calculation with `USERELATIONSHIP`.

| Cardinality | Cross filter options | Evaluated as |
| --- | --- | --- |
| One-to-many, many-to-one | Single or Both | Regular, within one source group |
| One-to-one | Both only | Regular, within one source group |
| Many-to-many | Single either way, or Both | Always limited |
| Anything across source groups | As above | Always limited |

## The trap: regular versus limited relationships

This is the part that changes numbers after a migration, and it is not a setting you choose. Power BI classifies each relationship as regular or limited, inferred from cardinality and source. A relationship is limited when it uses many-to-many cardinality, or when it crosses source groups in a composite model.

The difference is join semantics. Regular relationships expand tables using outer-join semantics, and a "many" side row with no match on the "one" side still appears, against a blank. Limited relationships join with inner-join semantics, so unmatched rows are dropped, no blank row is added, and `RELATED` cannot reach the other side. A blend tolerates unmatched members quietly, showing nulls in the view. Rebuild it as a many-to-many or cross-source relationship and those rows can disappear from totals instead. Reconcile counts against the Tableau view before anyone signs off.

## When there should be no relationship at all

Some blends exist precisely because a join would be wrong: the sources are at different grains, the keys are ragged, or a physical relationship would create ambiguity elsewhere in the model. For those, [TREATAS](https://learn.microsoft.com/en-us/dax/treatas-function-dax) applies the result of a table expression as a filter on an unrelated table, giving you a virtual relationship that exists only while that measure is evaluated. It is the closest DAX gets to the spirit of a blend: two independent queries, brought together at the point of display.

The related option is `CROSSFILTER`, which changes or disables filter propagation for one calculation without altering the model. Between them, the pattern is the same as the physical one: keep the model simple and single-directional, and handle the exceptions inside the measures that need them.

## What Antares does with blends

The Analyzer records which worksheets rely on blends and which data sources they combine, because each one is a decision about the model rather than a chart to convert. That distinction is what keeps an estimate honest: fifty blended worksheets sitting on one primary-to-secondary link are a single relationship plus fifty conversions, while five blends across five unrelated sources are five modelling problems.

Blends are also the clearest example of why the metadata comes first. The blend itself never appears in a formula, so any count based on reading calculations misses it entirely. [Run the free Analyzer](https://try.getantares.io) to see where blends sit in your own workbooks.

Related reading: [data sources to Power BI datasets](https://getantares.io/tableau-data-sources-to-power-bi-datasets/) and [custom SQL to Power BI](https://getantares.io/tableau-custom-sql-to-power-bi/). Primary sources: Tableau's [data blending documentation](https://help.tableau.com/current/pro/desktop/en-us/multiple_connections.htm) and Microsoft's guidance on [many-to-many relationships](https://learn.microsoft.com/en-us/power-bi/guidance/relationships-many-to-many) and the [USERELATIONSHIP function](https://learn.microsoft.com/en-us/dax/userelationship-function-dax).

## Related resources

- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [Data Sources to Power BI Datasets](https://getantares.io/tableau-data-sources-to-power-bi-datasets/)
- [Custom SQL to Power BI](https://getantares.io/tableau-custom-sql-to-power-bi/)
- [LOD Expressions to DAX](https://getantares.io/tableau-lod-expressions-to-dax/)

## FAQ

### What is the Power BI equivalent of Tableau data blending?

A model relationship, in most cases. Tableau blends query each source separately, aggregate each result, then present them together. Power BI relationships propagate filters between tables and aggregate afterwards, so the linking field becomes a relationship column and secondary values become measures.

### Why do totals change after converting a blend to a relationship?

Usually because the new relationship is limited rather than regular. Many-to-many relationships and relationships crossing source groups join with inner-join semantics, so rows with no match are dropped instead of showing against a blank. A blend tolerates unmatched members quietly; the relationship does not.

### Can Power BI blend on several linking fields?

Not directly. A relationship relates one column to one column, so several linking fields become a single combined key column, built in Power Query or with COMBINEVALUES for DirectQuery models. Both columns should carry the same data type.

### When should a blend not become a relationship?

When the sources are at different grains, the keys are ragged, or a physical relationship would create ambiguous filter paths. TREATAS applies a table expression as a filter on an unrelated table, giving a virtual relationship that exists only while that measure is evaluated.

---

## Tableau Hyper Files to Power BI: Converting Extracts, Refresh, and Model Size

Canonical: https://getantares.io/convert-hyper-files-to-power-bi/
Published: 2026-02-18
Updated: 2026-09-30

A `.hyper` file is a Tableau extract: a compressed, columnar snapshot of data that Tableau's engine queries locally. It is a cache, not a source system, and Power BI cannot open one. The [file connectors in Power BI Desktop](https://learn.microsoft.com/en-us/power-bi/connect-data/desktop-data-sources) are Excel, Text/CSV, XML, JSON, Folder, PDF, Parquet and SharePoint folder, with no Tableau format in the list, so converting a Hyper file means choosing between two routes: point the new model at the original source system, usually the right answer, or read the extract with Tableau's Hyper API and land it in a format Power BI can import.

## What is a .hyper file?

Tableau's [file type reference](https://help.tableau.com/current/pro/desktop/en-us/environ_filesandfolders.htm) defines a `.hyper` file as an extract: a local copy of a subset or an entire data set, used to share data, work offline and speed up queries. The name comes from [Hyper](https://tableau.github.io/hyper-db/docs/), the SQL engine behind Tableau's extracts and Tableau Prep's transformations, and `.hyper` [replaced the older `.tde` format](https://help.tableau.com/current/pro/desktop/en-us/extracting_upgrade.htm) in Tableau 2018.

You rarely receive one on its own. Tableau packages an extract with whatever uses it:

| File | What it is | Where the extract sits |
| --- | --- | --- |
| `.hyper` | A standalone extract | It is the extract |
| `.tdsx` | Packaged data source: the `.tds` connection file plus local data | Inside the zip, next to the `.tds` |
| `.twbx` | Packaged workbook: the `.twb` plus local data and images | Inside the zip, in the Data folder |
| `.tds` or `.twb` | A connection or workbook definition only | Not included; the file only points at the data |

Whichever wrapper it arrives in, Power BI reads none of them: a `.hyper` file is a database file for Tableau's own engine, and Power BI has no connector for it. The data inside is still reachable through the Hyper API, covered below.

## What a Tableau extract maps to in Power BI

| Tableau | Power BI equivalent | Notes |
| --- | --- | --- |
| `.hyper` extract | Import-mode semantic model | Both store compressed columnar data |
| Live connection | DirectQuery | Queries reach the source at report time |
| Extract embedded in a `.twbx` | No equivalent | The `.twbx` is a zip; the extract is inside it |
| Published data source | Shared semantic model | One model, many reports |
| Extract refresh schedule | Scheduled refresh | 8 per day on shared capacity, 48 on Premium or Fabric |
| Incremental extract refresh | Incremental refresh policy | Driven by `RangeStart` and `RangeEnd` |
| Extract filters | Power Query filter steps | Must fold to the source to stay efficient |
| Aggregate data for visible dimensions | Group By in Power Query | Or keep the detail and aggregate in DAX |
| `.tde` file (legacy) | Upgrade to `.hyper` first | Desktop 2024.2 is the last release that opens `.tde` |

## Should you convert the extract or reconnect to the source?

Reconnect whenever the upstream system still exists and you can get credentials. An extract is not a faithful copy of a source table: Tableau's [extract settings](https://help.tableau.com/current/pro/desktop/en-us/extracting_data.htm) offer filters, an *Aggregate data for visible dimensions* option with date roll-up, and a choice between all rows, a sample, or the top N rows, any of which may already be baked into the file you hold. Reconnecting also restores what Power BI needs later: a query that folds, a real date column to partition on, and a refresh path that does not depend on a file on somebody's laptop.

Convert from the file only when there is nothing to reconnect to: the source was decommissioned, the spreadsheet behind an ad-hoc upload is gone, or credentials will not arrive inside the migration window. Even then it is a bridge and not a destination, because a table loaded from a one-off export cannot be refreshed by anyone. Either way, keep the extract as your validation baseline: its totals are what the Tableau dashboards actually showed.

## How to read data out of a .hyper file

| Route | How | Best for |
| --- | --- | --- |
| Unpack the workbook | Rename `.twbx` to `.zip` and open it; extracts sit in the Data folder | Finding which workbooks carry embedded data |
| Hyper API | `pip install tableauhyperapi`, connect to the file, run `SELECT` against its tables | Repeatable extraction to CSV or Parquet |
| Tableau Desktop, whole source | `Data > Export Data to CSV` on the data source page | One table you need once |
| Tableau Desktop, single view | `Worksheet > Export > Data` | Exporting exactly what one view shows |

Start with unpacking, because it tells you what you have. Tableau's own instruction is to rename a packaged workbook with a `.zip` extension and open it, so unzipping a folder of workbooks cheaply reveals which ones carry embedded data. The [Hyper API](https://tableau.github.io/hyper-db/docs/) is the scriptable route, shipping for Python, C++ and Java, opening existing files and querying them with SQL. Prefer Parquet over CSV on the way out: Power BI reads it natively and it carries column types, sparing Power Query from guessing dates and decimals.

One caveat applies to every export route: Tableau warns that an export may exclude some table calculations and level of detail expressions, because those are computed in the view rather than stored as data. That is DAX work, not a gap in the data move, covered in [LOD expressions to DAX](https://getantares.io/tableau-lod-expressions-to-dax/) and [table calculations to DAX](https://getantares.io/tableau-table-calculations-to-dax/).

## How extract refresh becomes semantic model refresh

Tableau's incremental extract refresh watches a column you nominate and appends the rows above its last value. Power BI is declarative instead: create two Power Query date/time parameters with the reserved, case-sensitive names `RangeStart` and `RangeEnd`, filter the table with them, then set an archive period and a refresh period. The service creates and rolls the partitions itself, refreshing recent ones and dropping history as it ages out.

Three requirements decide whether that works. The filter has to fold to the source, or the engine retrieves every row and filters locally, defeating the policy. The parameters must be the date/time type even when the table is partitioned on an integer key such as `yyyymmdd`, which you convert inside the query. And the source has to be a live system, because a static CSV exported from an extract has nothing to filter incrementally. [Incremental refresh](https://learn.microsoft.com/en-us/power-bi/connect-data/incremental-refresh-overview) itself is supported on Pro, Premium per user, Premium and Embedded; only the real-time DirectQuery partition is Premium-only.

Budget the windows too: a refresh must finish within two hours on shared capacity and five on Premium, shared capacity allows eight scheduled refreshes a day against 48 on Premium or Fabric, and on-premises sources need an enterprise gateway.

## Model size and the 1 GB limit

The default size limit for a semantic model is 1 GB, and Fabric capacities, Premium per user and Embedded go past it once [Large semantic model storage format](https://learn.microsoft.com/en-us/fabric/enterprise/powerbi/service-premium-large-models) is on, when the ceiling becomes the capacity size. A model published from Power BI Desktop is separately capped at a 10 GB upload.

Those limits sound tight next to a multi-gigabyte extract and usually are not: Microsoft's [guidance for Import models](https://learn.microsoft.com/en-us/power-bi/guidance/import-modeling-data-reduction) puts VertiPaq compression at roughly 10x, so 10 GB of source data can land near 1 GB. Columns and cardinality drive the result rather than row count, and extracts are the bad case, because the Tableau author included every column of every table and nobody revisited it. Dropping unused columns is the highest-yield change available at import.

## What Antares does with extracts and Hyper files

Antares never touches the data inside an extract: analysis and conversion read metadata only, never business data. Moving rows between platforms is a data-platform job, not a dashboard-migration one.

What the Analyzer contributes is the inventory behind the decision above. It reads every data source in every workbook, records whether each is live or extract-backed, and captures what the connection points at. So before anyone opens a file, you know which dashboards can be repointed at a system that still exists and which are backed only by an extract with no reachable upstream. That second group is usually small, and it is where migration estimates go wrong. [Run the free Analyzer](https://try.getantares.io) for your own workbooks.

Related reading: [extracts to Power BI dataflows](https://getantares.io/convert-tableau-extracts-to-power-bi-dataflows/) and [data sources to Power BI datasets](https://getantares.io/tableau-data-sources-to-power-bi-datasets/). Primary sources: Tableau's [extract format notes](https://help.tableau.com/current/pro/desktop/en-us/extracting_upgrade.htm) and [export documentation](https://help.tableau.com/current/pro/desktop/en-us/save_export_data.htm), the [Hyper API installation guide](https://tableau.github.io/hyper-db/docs/installation), and Microsoft's [data refresh reference](https://learn.microsoft.com/en-us/power-bi/connect-data/refresh-data).

## Related resources

- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [Extracts to Power BI Dataflows](https://getantares.io/convert-tableau-extracts-to-power-bi-dataflows/)
- [Data Sources to Power BI Datasets](https://getantares.io/tableau-data-sources-to-power-bi-datasets/)
- [Custom SQL to Power BI](https://getantares.io/tableau-custom-sql-to-power-bi/)

## FAQ

### What is a .hyper file?

A Tableau extract: a local copy of all or part of a data set, stored in the format of Hyper, the SQL engine behind Tableau's extracts and Tableau Prep. It can be a standalone file or sit inside a packaged workbook (.twbx) or a packaged data source (.tdsx). It replaced the older .tde format in Tableau 2018, and Power BI cannot open it directly.

### Can Power BI open a Tableau .hyper file?

No. Power BI Desktop has no Tableau connector; its file connectors are Excel, Text/CSV, XML, JSON, Folder, PDF, Parquet and SharePoint folder. Either reconnect the new model to the original source, or read the .hyper file with Tableau's Hyper API and write it out as Parquet or CSV.

### How do I extract data from a .hyper file?

Open it with the Hyper API (pip install tableauhyperapi) and run SELECT against its tables. For a one-off, Tableau Desktop exports without code: Data > Export Data to CSV on the data source page. If the extract sits inside a .twbx, rename the workbook to .zip first.

### Should I convert the extract or reconnect to the source?

Reconnect if the source system still exists. An extract can carry filters, aggregation to visible dimensions and a row sample, so its numbers are not necessarily the source's, and a model loaded from a static export can never be refreshed. Keep the extract as a validation baseline.

### What is the Power BI equivalent of a Tableau extract refresh?

A scheduled semantic model refresh, plus an incremental refresh policy driven by the reserved RangeStart and RangeEnd parameters. Shared capacity allows eight scheduled refreshes a day and Premium or Fabric allows 48; a refresh must finish within two hours on shared capacity and five on Premium.

---

## Tableau Actions to Power BI: Drillthrough, Cross-Filtering, and Navigation

Canonical: https://getantares.io/tableau-actions-to-power-bi-drillthrough/
Published: 2026-02-18
Updated: 2026-07-28

The first thing to know is that the default is reversed. In Tableau, nothing happens between sheets until someone creates an action. In Power BI, visuals on a page cross-filter and cross-highlight each other out of the box, and the work is switching that off where it is unwanted. So converting Tableau actions is partly building features and partly deleting behaviour nobody asked for.

## Tableau action types in Power BI

| Tableau action | What it does | Power BI equivalent |
| --- | --- | --- |
| Filter | Uses one view to filter another | Cross-filtering, already on by default |
| Filter to a detail sheet | Opens a focused view of one item | Drillthrough page |
| Highlight | Dims all other marks | Cross-highlighting |
| Go to URL | Links to an external page or file | Button or column with a Web URL action |
| Go to Sheet | Navigates within the workbook | Page navigation button |
| Change Parameter | Sets a parameter from a mark | No equivalent, see [parameters](https://getantares.io/tableau-parameters-to-power-bi-parameters/) |
| Change Set Values | Rewrites a set from a selection | No equivalent, see [sets](https://getantares.io/tableau-sets-to-dax-measures/) |
| Action running on hover | Reveals detail without clicking | Report page tooltip |

## The default is the opposite, so start by subtracting

By default, [visualizations on a report page cross-filter and cross-highlight](https://learn.microsoft.com/en-us/power-bi/create-reports/service-reports-visual-interactions) the others. Turn on Edit interactions in the Format menu and every other visual gains three icons: filter, highlight, and none. Set them per pair of visuals, and the choices are saved with the report so consumers see what you designed.

One constraint is documented and worth memorising, because it decides layouts: line charts, scatter charts and maps can only be cross-filtered, never cross-highlighted. A Tableau dashboard whose highlight action targeted a line chart cannot be reproduced literally, and the honest conversion is a filter with the difference explained to users, not a workaround that half-works.

## Filter actions: cross-filter or drillthrough?

Tableau filter actions cover two jobs that Power BI separates. When the target sits on the same dashboard, the equivalent is cross-filtering and there is usually nothing to build. When the action opened a different sheet showing detail for one item, the equivalent is [drillthrough](https://learn.microsoft.com/en-us/power-bi/create-reports/desktop-drillthrough).

A drillthrough page carries drillthrough filter fields that determine what it shows, and Power BI adds a back button automatically. Users reach it by right-clicking a data point or through a button whose action is set to Drillthrough. Three details save time later: the drillthrough field has to be present in the source visual for the menu entry to appear, the field must not be aggregated in that visual, and cross-report drillthrough works only in the Power BI service, between reports in the same workspace, with matching field names and data types.

## Navigation, URLs and hover

Go to Sheet becomes a button with a page navigation action, which is more explicit than Tableau's version: the target is chosen per button rather than derived from a selection. Go to URL becomes a Web URL action on a button, or a column formatted as a web URL when the link belongs to each row of a table.

Actions that ran on hover are a different feature entirely. Power BI's report page tooltips let a whole page act as the tooltip for a visual, filtered to whatever the user is hovering over. That is often a better result than the Tableau original, because the tooltip page is designed rather than assembled from a mark's fields.

## The two that do not convert

Change Parameter and Change Set Values both write a value back from a user selection, and Power BI has nothing that does that. Parameter actions are approximated with field parameters, bookmarks, or a disconnected table read back in a measure. Set actions are rebuilt from cross-filtering, drillthrough or bookmarks, depending on which behaviour the dashboard actually relied on.

Neither substitution is a translation, and both are worth pricing separately during scoping. A dashboard with a dozen filter actions is routine. A dashboard whose interactivity rests on parameter and set actions is a redesign wearing a conversion's clothes.

## What Antares does with actions

Actions are part of the dashboard layer, so they are inside the conversion's scope rather than beside it. What the Analyzer contributes is the split above, taken before anyone opens a workbook: how many actions there are, of which kinds, and therefore how much of a dashboard's behaviour has a direct target in Power BI and how much has to be designed.

Where the mapping is unambiguous it is converted, and where it is not it is flagged rather than guessed. An action quietly reproduced as the nearest available behaviour is the kind of change that passes review and surprises users in week two. [Run the free Analyzer](https://try.getantares.io) to see the action inventory for your own workbooks.

Related reading: [parameters to Power BI](https://getantares.io/tableau-parameters-to-power-bi-parameters/) and [workbook to PBIX conversion](https://getantares.io/tableau-workbook-to-pbix-conversion/). Primary sources: Tableau's [actions documentation](https://help.tableau.com/current/pro/desktop/en-us/actions.htm) and Microsoft's guides to [buttons](https://learn.microsoft.com/en-us/power-bi/create-reports/desktop-buttons) and [report page tooltips](https://learn.microsoft.com/en-us/power-bi/create-reports/desktop-tooltips).

## Related resources

- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [Parameters to Power BI](https://getantares.io/tableau-parameters-to-power-bi-parameters/)
- [Sets to DAX Measures](https://getantares.io/tableau-sets-to-dax-measures/)
- [Workbook to PBIX Conversion](https://getantares.io/tableau-workbook-to-pbix-conversion/)
- [Parameters and Actions in Databricks AI/BI](https://getantares.io/tableau-parameters-to-databricks-ai-bi-parameters/)

## FAQ

### What is the Power BI equivalent of a Tableau filter action?

Cross-filtering, which is already on by default between visuals on a page, or a drillthrough page when the action opened a separate sheet showing detail for one item. Use Edit interactions to set filter, highlight or none for each pair of visuals.

### Why do Power BI visuals filter each other without any action defined?

Because that is the default. Visuals on a report page cross-filter and cross-highlight the others out of the box, which is the reverse of Tableau, where nothing happens until an action is created. Converting a Tableau dashboard therefore includes switching off interactions nobody asked for.

### Can every Tableau highlight action be reproduced?

No. Line charts, scatter charts and maps can only be cross-filtered, never cross-highlighted. A highlight action targeting one of those becomes a filter, and the difference is worth explaining to users rather than working around.

### Which Tableau actions have no Power BI equivalent?

Change Parameter and Change Set Values, because nothing in Power BI writes a value back from a user selection. They are approximated with field parameters, bookmarks, drillthrough, or a disconnected table read back in a measure. Both are design work and should be scoped separately.

---

## Tableau Workbook to PBIX: What Converting a .twbx Actually Involves

Canonical: https://getantares.io/tableau-workbook-to-pbix-conversion/
Published: 2026-02-18
Updated: 2026-09-30

There is no file-level converter from `.twbx` to `.pbix`, and there cannot easily be one, because the two formats describe different things. A `.twbx` is a zip holding a `.twb` workbook definition in XML plus any extracts and images that workbook needs. A `.pbix` holds two artifacts of its own: a semantic model and a report definition. Converting a workbook therefore means rebuilding both halves, by hand or with a tool that reads Tableau's XML and generates Power BI artifacts. What follows is what is actually inside each file, what maps to what, and what does not survive the trip.

## What is inside each file

| Layer | Tableau | Power BI |
| --- | --- | --- |
| Container | `.twbx`, a zip with the workbook, local data and images | `.pbix`, a single file, or `.pbip`, a folder of text files |
| Definition | `.twb` XML, no published schema | TMDL for the model, PBIR JSON for the report, both with public schemas |
| Data | `.hyper` extract inside the package | Compressed model cache, or no data at all in DirectQuery |
| Editing outside the tool | Not a supported workflow | Supported for PBIR, not for the legacy `report.json` |

## TWB vs TWBX: the difference

A `.twb` and a `.twbx` carry the same workbook. The `.twb` is the definition alone, in XML: worksheets, dashboards, stories, calculations and connection details. The `.twbx` is a zip that [packages that `.twb`](https://help.tableau.com/current/pro/desktop/en-us/save_savework_packagedworkbooks.htm) with the local files it needs, so the workbook opens on a machine that cannot reach them.

|  | `.twb` | `.twbx` |
| --- | --- | --- |
| What it is | Workbook definition in XML | Zip archive holding the `.twb` |
| Extracts, Excel and text files | Referenced by path, not included | Packaged inside |
| Background images, custom shapes | Referenced, not included | Packaged inside |
| Database connections | Connection details only | Connection details only, unless the data was extracted first |
| How to make one | Save as a Tableau Workbook | `File > Save As`, type Tableau Packaged Workbooks |
| How to get the other | Save as a packaged workbook | Rename to `.zip` and unzip; the `.twb` is inside |

So converting a `.twb` to a `.twbx` needs no converter: open the workbook in Tableau Desktop, choose `File > Save As` and pick Tableau Packaged Workbooks as the file type. Going the other way, unzipping gives you the `.twb` plus a folder of the packaged data and images.

For a Power BI migration the difference is what travels with the workbook, not how it converts. Everything that gets translated, from sheets and calculations to layout and connections, is in the `.twb` XML either way. A `.twbx` also carries any extract, which Power BI cannot open (see [Hyper files to Power BI](https://getantares.io/convert-hyper-files-to-power-bi/)), while a `.twb` built on local files points at paths on the author's machine. Collect the data along with the workbook before you start.

## What maps to what

| Tableau | Power BI | Notes |
| --- | --- | --- |
| Workbook | One report plus its semantic model | The report is the deliverable, the model is the prerequisite |
| Dashboard | Report page | The natural unit of conversion |
| Worksheet | Visual | A worksheet on no dashboard has no target of its own |
| Story | Bookmarks and navigation buttons | No direct equivalent |
| Data source | Model tables and relationships | Blends become real relationships |
| Calculated field | Measure or calculated column | The split is a modelling decision, not a translation |
| Parameter | What-if parameter or field parameter | Two different mechanisms in Power BI |
| Action | Drillthrough, cross-filtering or page navigation | Chosen per action |
| Layout containers | Absolute positions on a fixed canvas | Power BI has no flow container |
| Device layouts | Mobile layout, held per visual | Rebuilt, not carried over |

One line in that table constrains everything else. In Tableau, each worksheet binds to whichever data source it needs, so a single workbook can sit on several unrelated connections. A Power BI report has exactly one semantic model behind it. Several unrelated Tableau data sources therefore have to be merged into one model, which is real modelling work, or split across several reports, which changes what users see. Deciding that before conversion starts is cheaper than discovering it halfway through.

## Why the layout never comes across cleanly

Tableau dashboards are built from nested containers that resize with the window. A Power BI report page is a fixed canvas with every visual placed at an absolute position on it. The [canvas settings](https://learn.microsoft.com/en-us/power-bi/create-reports/power-bi-report-display-settings) default to a 16:9 page sized from a short list, 1280 x 720 upward, or to custom pixel dimensions, and the page is then scaled to fit the browser. So a dashboard designed to flow has to be re-pinned to a pixel grid, and the spacing decisions that looked automatic in Tableau become explicit coordinates in Power BI.

The other asymmetry is the chart unit itself. A Tableau worksheet is a query plus a mark specification, and one worksheet can carry several mark types on a dual axis. A Power BI visual is a chart type with fixed field wells. One worksheet is usually one visual, sometimes two, and occasionally a combination that has no equivalent and needs a design decision instead of a conversion.

## What converts mechanically and what gets rebuilt

| Element | What to expect |
| --- | --- |
| Bar, line, area, scatter and map charts | Convert mechanically |
| Row-level calculated fields | Mostly mechanical, into DAX or Power Query |
| LOD expressions and table calculations | Manual DAX, the largest single cost |
| Sets, groups and parameters | Rebuilt on Power BI's own mechanisms |
| Custom SQL data sources | Power Query or DirectQuery |
| Dashboard layout and formatting | Re-laid out on the fixed canvas |
| Worksheets on no dashboard | A scoping decision, not a conversion |

The rows near the bottom are where estimates go wrong. Charts are the visible work and the cheap part; [LOD expressions](https://getantares.io/tableau-lod-expressions-to-dax/), [table calculations](https://getantares.io/tableau-table-calculations-to-dax/) and [custom SQL](https://getantares.io/tableau-custom-sql-to-power-bi/) are the invisible work and the expensive part.

## Inspect the .twbx before scoping the work

Rename the workbook to `.zip` and open it. The `.twb` inside is XML, so you can count dashboards against worksheets before committing to anything, and the two numbers are usually far apart. Only the dashboard count drives conversion work; a long tail of worksheets that appear on no dashboard is a decision about what to keep. The same archive shows whether data travels with the workbook as an [embedded extract](https://getantares.io/convert-hyper-files-to-power-bi/) or whether the connection is live. Note that Tableau publishes no schema for the `.twb`, so anything reading it works against an undocumented format.

## PBIX or PBIP as the target

[Power BI projects](https://learn.microsoft.com/en-us/power-bi/developer/projects/projects-overview) save the report and the semantic model as folders of plain text rather than one binary file: TMDL for the model, and the [PBIR](https://learn.microsoft.com/en-us/power-bi/developer/projects/projects-report) format for the report, where every page and visual is its own JSON file with a public schema. That matters for migration specifically, because generated output becomes reviewable in Git instead of arriving as an opaque file.

Two caveats. Projects are still in preview at the time of writing, and conversion between the two formats happens only through Save As in Power BI Desktop, not programmatically. The service also enforces limits on PBIR reports that are worth knowing before folding many dashboards into one: 1,000 pages per report, 1,000 visuals per page, and 300 MB across all report files.

## What Antares does with workbooks

The Converter takes a source dashboard and produces a Power BI report page, then deploys it. The unit is the dashboard an end user opens, so a workbook with several dashboards is several units of work rather than one. The pipeline is deterministic first, with AI steps confined to the places where the mapping is genuinely ambiguous, and anything it cannot resolve is flagged rather than guessed.

Before that, the Analyzer reads the workbooks themselves and separates the two counts above, so the scope is dashboards rather than files, and the manual items are named before anyone commits to a date. [Run the free Analyzer](https://try.getantares.io) on your own workbooks, or [see how conversion works](https://getantares.io/converter/).

Related reading: [calculated fields to DAX](https://getantares.io/tableau-calculated-fields-to-dax/) and [actions to drillthrough](https://getantares.io/tableau-actions-to-power-bi-drillthrough/). Primary sources: Tableau's [file type reference](https://help.tableau.com/current/pro/desktop/en-us/environ_filesandfolders.htm) and [packaged workbook documentation](https://help.tableau.com/current/pro/desktop/en-us/save_savework_packagedworkbooks.htm), plus Microsoft's documentation of the [project semantic model folder](https://learn.microsoft.com/en-us/power-bi/developer/projects/projects-dataset).

## Related resources

- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [Calculated Fields to DAX](https://getantares.io/tableau-calculated-fields-to-dax/)
- [Actions to Power BI Drillthrough](https://getantares.io/tableau-actions-to-power-bi-drillthrough/)
- [Hyper Files to Power BI](https://getantares.io/convert-hyper-files-to-power-bi/)

## FAQ

### What is the difference between .twb and .twbx?

A .twb is the workbook definition alone, saved as XML, with local data and images referenced by path. A .twbx is a zip that packages that .twb with its extracts, local files and images, so it opens without access to them. To turn a .twb into a .twbx, open it in Tableau Desktop and use File > Save As > Tableau Packaged Workbooks.

### Can you convert a .twbx file to .pbix directly?

No. No tool reads one format and writes the other as a file conversion, because a .twbx holds a Tableau workbook definition plus its packaged data, while a .pbix holds a semantic model and a report definition. Conversion means regenerating both, by hand or with a converter that reads Tableau's XML and emits Power BI artifacts.

### What is inside a .twbx file?

A zip archive: the .twb workbook definition in XML, plus the local data, extracts and images the workbook needs. Rename the file to .zip and open it. Tableau publishes no schema for the .twb itself, so any tool that reads it is working against an undocumented format.

### Does one Tableau worksheet become one Power BI visual?

Usually, but not always. Power BI visuals have fixed field wells, so a worksheet with several mark types or a dual axis can become two visuals or need a redesign. Worksheets that sit on no dashboard have no target at all and need a scoping decision before conversion starts.

### Should converted output be PBIX or PBIP?

PBIP when the output is generated or reviewed in Git, since it stores the report and the model as plain text files with published schemas. Power BI projects are still in preview, and conversion between PBIX and PBIP happens only through Save As in Power BI Desktop, not programmatically.

---

## How to Export or Connect Tableau to Power BI (There Is No Export Button)

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

There is no export button and no direct way to export Tableau to Power BI: Tableau Desktop has no *Export to Power BI* command, and the [Power Query connector list](https://learn.microsoft.com/en-us/power-query/connectors/) that Power BI uses has no Tableau entry, so Power BI cannot open a workbook, a published data source or an extract. What people mean by "export Tableau to Power BI" is one of five different jobs, and each has a route that works. The right route depends on the job.

## What "export or connect Tableau to Power BI" usually means

| What you want | Route that works | What you get | What you do not get |
| --- | --- | --- | --- |
| The data behind a Tableau dashboard, in Power BI | Reconnect Power BI to the same source; export the extract if the source is gone | Tables to model | Visuals, calculations, filters |
| The dashboard itself, in Power BI | Rebuild by hand, or convert the workbook definition with a tool | A report page and a semantic model | A file that opens as-is |
| A Power BI semantic model, read from Tableau | Tableau's Analysis Services connector over the XMLA endpoint | A live connection to the model | Tableau support; the connector is documented as not for production |
| A Power BI report shown inside a Tableau dashboard | Secure embed URL in a Web Page object | Both tools on one screen during coexistence | Cross‑filtering between them |
| Both tools reading the same numbers | One shared source or warehouse layer feeding both | Agreement at the table level | Agreement on calculations built in the tools |

## Why there is no export button

Tableau's own [export documentation](https://help.tableau.com/current/pro/desktop/en-us/save_export_data.htm) is entirely about data: CSV from the data source page, crosstabs to Excel, view data to Access or CSV. Nothing in it produces a Power BI artifact, because the two formats describe different things (the detail is on [workbook to PBIX conversion](https://getantares.io/tableau-workbook-to-pbix-conversion/)), and as of September 2026 the only BI vendor with an in‑product importer for another vendor's workbook files is Databricks, whose [Genie Code importer](https://docs.databricks.com/aws/en/dashboards/manage/import-bi) reads `.twb`, `.twbx`, `.tds`, `.tdsx` and `.pbit` files and lands the result in Databricks AI/BI, not in Power BI.

The *connect* phrasing fails for the same reason. Power BI connects to databases, files, services and other Power BI semantic models; a Tableau published data source is none of those, and Tableau exposes it to Tableau clients and its own APIs, not over a database protocol.

## Route 1: get the data out of Tableau

If the source system behind the workbook still exists, point Power BI at it directly and you inherit a refreshable query. Every route below produces a snapshot that nobody can refresh, so treat it as a bridge for sources that have gone away.

| Route | Where | Produces | Best for |
| --- | --- | --- | --- |
| `Data > Export Data to CSV` | Tableau Desktop, data source page | CSV of the whole data source | One table, once |
| `Worksheet > Export > Data` or `Crosstab to Excel` | Tableau Desktop, a view | What one view shows | Reconciliation baselines |
| Hyper API | Script against a `.hyper` file | CSV or Parquet per table | Many extracts, repeatably |
| REST API *Query View Data* | Tableau Server or Tableau Cloud | CSV per view (a dashboard request returns its first view only) | Scheduled pulls without Desktop |
| REST API *Download Data Source* | Tableau Server or Tableau Cloud | `.tdsx`, with or without the extract | Recovering the extract inside a packaged source |
| REST API *Download Workbook* | Tableau Server or Tableau Cloud | `.twb` or `.twbx` with any embedded extract | Bulk retrieval before a conversion; see [Tableau Cloud to Power BI](https://getantares.io/tableau-online-to-power-bi-migration/) |
| VizQL Data Service | Tableau Cloud, Tableau Server 2025.1 or later | JSON query results from published sources | Programmatic reads with Tableau's own semantics |

Two caveats apply to every view‑level export. Tableau warns that an export *may exclude some table calculations and level of detail expressions*, because those are computed in the view, and fields on the Filters shelf are left out unless they also sit on Detail. The CSV carries the data; the dashboard's logic gets rebuilt as DAX, which is covered under [LOD expressions](https://getantares.io/tableau-lod-expressions-to-dax/) and [table calculations](https://getantares.io/tableau-table-calculations-to-dax/). Extract mechanics, including the fact that a packaged `.tdsx` carries a copy of the extract, are on [Hyper files to Power BI](https://getantares.io/convert-hyper-files-to-power-bi/); how a published data source becomes a shared semantic model is on [data sources to semantic models](https://getantares.io/tableau-data-sources-to-power-bi-datasets/).

## Route 2: move the dashboard itself

Because no file conversion exists, moving a dashboard means regenerating a report page and a model from what the workbook describes. A rebuild reads the Tableau dashboard as a specification and authors the Power BI version by hand, which is also the moment most teams redesign. A conversion tool generates the model and report from the workbook definition and leaves review to people. Either way the same items decide the effort: LOD expressions, table calculations, dashboard actions, data blending and custom SQL, none of which map one to one. The [migration guide](https://getantares.io/tableau-to-power-bi-migration/) walks the whole list, and [automated migration](https://getantares.io/tableau-to-power-bi-automated-migration/) is specific about what converts cleanly and what does not.

## Can Tableau connect to a Power BI semantic model?

Yes, with a warning attached. Power BI semantic models on Premium, Premium Per User or Fabric capacity expose an [XMLA endpoint](https://learn.microsoft.com/en-us/fabric/enterprise/powerbi/service-premium-connect-tools), read‑only by default, and Microsoft lists third‑party visualization tools among the clients that can query it. Tableau's Microsoft Analysis Services connector speaks that protocol, so Tableau Desktop on Windows can open a Power BI model as a cube.

Tableau's [Fabric connector page](https://help.tableau.com/current/pro/desktop/en-us/examples_ms_fabric.htm) documents the steps and then says, in as many words, that the connector *is not recommended for production situations and not supported by Tableau*, citing schema resolution issues and functionality gaps between Tableau and the semantic model engine. Its recommended Fabric route is the Azure SQL Database connector against a warehouse or lakehouse SQL endpoint, which reaches tables, not the model. Use the XMLA route only while both platforms are live, and plan for it to be gone by cutover.

## How to run Tableau and Power BI side by side

Migrations of any size run both platforms in parallel for a period, and "connect" often means making that period bearable. A Power BI report can be placed inside a Tableau dashboard through a [Web Page object](https://help.tableau.com/current/pro/desktop/en-us/dashboards_create.htm) holding Power BI's [secure embed URL](https://learn.microsoft.com/en-us/power-bi/collaborate-share/service-embed-secure); viewers sign in to Power BI inside the frame and, unless both the report and its semantic model sit on Premium or F64‑plus capacity, each needs a Pro or Premium Per User license. A shared warehouse layer keeps both tools reading the same tables, leaving only the calculations to reconcile. And the [Tableau Metadata API](https://help.tableau.com/current/api/metadata_api/en-us/index.html) answers, per workbook, which databases and tables it touches, which is the inventory that decides what moves in which order. One rule keeps the parallel period short: once a dashboard is converted and validated, changes go to the Power BI version only, or the validation has to be repeated.

## What Antares does here

Antares is a BI migration tool for Route 2. The **Analyzer** connects to Tableau Server or Tableau Cloud, reads metadata only, never business data, and returns the inventory: every workbook, what each data source points at, whether it is live or extract‑backed, and which dashboards carry the constructs that do not map one to one. It is free and fully deterministic. The **Converter** takes a source dashboard and produces a Power BI report page with its semantic model, deployed into a Fabric workspace, at a flat 200 USD (or 200 EUR) per source dashboard, with LLM costs on top, typically under 20 USD (or 20 EUR) per dashboard. It converts dashboards, not databases: live sources are reconnected on the Power BI side, which is Route 1. [Run the free Analyzer](https://try.getantares.io) to see which route each of your dashboards needs.

Related reading: [workbook to PBIX conversion](https://getantares.io/tableau-workbook-to-pbix-conversion/), [Hyper files to Power BI](https://getantares.io/convert-hyper-files-to-power-bi/) and [data sources to semantic models](https://getantares.io/tableau-data-sources-to-power-bi-datasets/). Primary sources: Microsoft on [data sources in Power BI Desktop](https://learn.microsoft.com/en-us/power-bi/connect-data/desktop-data-sources) and the [XMLA endpoint](https://learn.microsoft.com/en-us/fabric/enterprise/powerbi/service-premium-connect-tools); Tableau on [exporting data](https://help.tableau.com/current/pro/desktop/en-us/save_export_data.htm), [saved data sources](https://help.tableau.com/current/pro/desktop/en-us/export_connection.htm), the [REST API](https://help.tableau.com/current/api/rest_api/en-us/REST/rest_api_ref_workbooks_and_views.htm), the [VizQL Data Service](https://help.tableau.com/current/api/vizql-data-service/en-us/index.html) and the [Hyper API](https://tableau.github.io/hyper-db/docs/).

## Related resources

- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [Workbook (.twbx) to PBIX Conversion](https://getantares.io/tableau-workbook-to-pbix-conversion/)
- [Hyper Files to Power BI](https://getantares.io/convert-hyper-files-to-power-bi/)
- [Data Sources to Power BI Datasets](https://getantares.io/tableau-data-sources-to-power-bi-datasets/)

## FAQ

### Is there a Tableau connector in Power BI?

No. Power BI gets data through Power Query, and the Power Query connector list has no Tableau entry, so Power BI cannot read a workbook or a published data source. Connect Power BI to the database or files the Tableau workbook reads instead.

### Can Tableau connect to a Power BI semantic model?

Technically, through Tableau's Microsoft Analysis Services connector against the model's XMLA endpoint, which needs Premium, Premium Per User or Fabric capacity. Tableau's own documentation says this configuration is not recommended for production and not supported by Tableau, so plan for it to be replaced before cutover.

### Does Export Data in Tableau give me the dashboard?

No. It writes the rows a view shows. Export Data and Crosstab to Excel carry the data of one view, Tableau warns that some table calculations and level of detail expressions may be excluded, and fields on the Filters shelf are left out. Visuals, filters and calculations are rebuilt on the Power BI side.

### Is there a Tableau to Power BI dataflow connector?

No. A Power BI dataflow reads from the same Power Query connectors as a report, and Tableau is not among them. Point the dataflow at the source Tableau was reading; whether an extract should become a dataflow at all is a separate question, covered on the extracts-to-dataflows page.

### Can Power Query read Tableau data?

Not from Tableau itself. Power Query has no Tableau connector; it reads the database or files behind the workbook, or a CSV or Parquet file exported from Tableau Desktop, the REST API or the Hyper API. Reconnecting to the original source is the only route that stays refreshable.

---

## Tableau to Power BI Migration Planning Guide: What a Migration Plan Must Contain

Canonical: https://getantares.io/tableau-migration-planning-guide/
Published: 2026-02-18
Updated: 2026-08-10

A Tableau to Power BI migration plan contains six sections, and each one locks a single decision before conversion starts: what is in scope, in what order the estate moves, who does the work, what counts as validated, how cutover happens, and how users find out. It is not a schedule. Dates are what falls out of those six sections once they are settled.

Plans fail on the decisions they leave open, not on the detail they omit. A plan that names a start date but never defines acceptance produces a project that can be worked on forever without finishing.

## What a migration plan must contain

Six sections, each locking one decision. Used as a migration plan template, every row below becomes a heading in the plan document. If a section cannot be written yet, that is the next thing to resolve, not a formatting problem.

| Plan section | Decision it locks | What a gap here costs |
| --- | --- | --- |
| Scope and inventory | Which dashboards move, which retire, which merge | Estimates drift because the denominator keeps changing |
| Sequencing and waves | Which content converts in which order, against which dates | A single cutover weekend carrying all of the risk |
| Staffing and roles | Who converts, who validates, who signs | Validation lands on whoever is free, and no one signs |
| Validation policy | Which measures reconcile, at what grain, within what tolerance | Review with no definition of done |
| Cutover policy | When Tableau edits freeze, when workbooks are retired | Parallel drift and two versions of the same number |
| Communication and enablement | Who is told what, when, and what training they receive | Content that is live and unused |

Microsoft's migration series splits the same material across [requirements gathering](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-requirements) and [deployment planning](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-planning), with tenant-level groundwork treated separately in its [pre-migration steps](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-pre-migration-steps). Read the plan as one document and those as its sources.

## Which decisions to lock before Tableau conversion starts

Scope goes first and hardest. A count of published workbooks is not a scope, because part of any estate is dead and part is duplicated; scope is the list that survives a retirement decision with an owner's signature on it. Everything downstream, including budget and dates, is a multiple of that number.

Sequencing needs a stated rule rather than a list. Simplest content first is the usual choice, because early waves surface model problems while they are still cheap; ordering by business criticality is defensible when a renewal date forces it, but it front-loads the risk. Either way the rule belongs in the plan, since the argument otherwise reappears at every wave boundary. Scores from [dashboard complexity analysis](https://getantares.io/tableau-dashboard-complexity-analysis/) are what make that rule executable.

Validation policy is the section most often skipped and the one that decides when the project ends. Name the measures that must reconcile, the grain they reconcile at, the tolerance you accept for rounding and time-zone handling, and the person who signs. Microsoft's guidance on [creating and validating migrated content](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-create-validate-content) is a reasonable starting shape.

The cutover policy is short and unpopular: a date after which Tableau authors stop editing content that is being converted. Without it, the target is compared against a moving original, and reconciliation never closes.

## Who does what in a migration team

Six roles appear in almost every migration, sometimes as six people and sometimes as two people wearing three hats each. The load matters as much as the responsibility, because the roles peak at different moments and the plan has to reserve them then.

| Role | Responsibility | Where the load falls |
| --- | --- | --- |
| Project owner | Scope, dates, budget, sign-off | Heaviest at planning and at cutover |
| BI developer | Conversion, calculation review, manual rebuilds | Steady through every conversion wave |
| Data engineer | Semantic model, sources, refresh, gateway | Front-loaded, before the first wave converts |
| Validator or QA | Reconciliation, interaction and security testing | Peaks one wave behind conversion |
| Dashboard owners | Retirement decisions, acceptance of their own reports | Short bursts at prune and at sign-off |
| Platform admin | Workspaces, licensing, permissions, promotion | Setup, then every release |

Two staffing mistakes are common enough to plan against. Dashboard owners are treated as reviewers who will respond within a day, when they are usually the scarcest resource in the project. And validation is left to the people who did the conversion, which removes the only independent check the plan had.

## How the migration plan feeds budget and timeline

The plan itself does not produce numbers; it produces the inputs that numbers are computed from. Scope gives a dashboard count, scoring gives an effort distribution, and the sequencing rule gives a shape for the calendar. Feed those into [cost estimation](https://getantares.io/tableau-migration-cost-estimation/) for the budget lines, [the timeline page](https://getantares.io/how-long-does-tableau-to-power-bi-migration-take/) for duration, and [the cost calculator](https://getantares.io/tableau-to-power-bi-migration-cost-calculator/) for the business case.

Approach belongs in the plan as a decision, not as an assumption. Whether conversion is automated, manual or split is settled on [automated versus manual economics](https://getantares.io/automated-vs-manual-tableau-migration/), and the plan simply records which one was chosen and why. Above a few hundred dashboards, governance and wave coordination start to dominate everything else, which is the subject of [enterprise migration strategy](https://getantares.io/enterprise-tableau-migration-strategy/).

## What Antares does for planning

Antares is a BI migration tool, and the part of the plan it fills in is the evidence layer. Because the Analyzer costs nothing, runs deterministically and reads metadata only, the inventory, the usage-based retirement candidates and the per-dashboard complexity scores that scope and sequencing rest on can exist before any commitment is made. That is the difference between a plan built on measurements and one built on a workbook count.

For the budget section, each source Tableau dashboard converts for a flat $200, nothing is charged per user, nothing expires, and the model provider you already use bills the LLM work at usually under $20 a dashboard, private endpoints included. Deterministic-first with guardrailed, validated AI steps, the engine converts like-to-like, so a plan using it still budgets review time and still keeps redesign in a project with its own budget. [Run the free Analyzer](https://try.getantares.io) to put measured numbers into the scope section.

Related reading: [the Tableau to Power BI migration guide](https://getantares.io/tableau-to-power-bi-migration/), [the 36-task migration checklist](https://getantares.io/tableau-migration-checklist/) and [the risk register](https://getantares.io/tableau-migration-risk-assessment/). Primary sources: Microsoft's [Power BI migration series](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-overview), its [implementation planning](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-implementation-planning-introduction) and [workspace planning](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-implementation-planning-workspaces-overview) guidance, [change management](https://learn.microsoft.com/en-us/power-bi/guidance/fabric-adoption-roadmap-change-management) in the adoption roadmap, and [license types by feature](https://learn.microsoft.com/en-us/power-bi/fundamentals/service-features-license-type).

## Related resources

- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [Migration Checklist](https://getantares.io/tableau-migration-checklist/)
- [Migration Risk Assessment](https://getantares.io/tableau-migration-risk-assessment/)
- [Migration Timeline](https://getantares.io/how-long-does-tableau-to-power-bi-migration-take/)

## FAQ

### What should a Tableau to Power BI migration plan contain?

Six sections: scope and inventory, sequencing and waves, staffing and roles, validation policy, cutover policy, and communication and enablement. Each one exists to lock a decision. A plan that lists dates without defining acceptance or a change freeze leaves the two decisions that most often stall a migration unmade.

### How is a migration plan different from a migration checklist?

The plan records decisions and holds them stable; the checklist records tasks and tracks their completion. Scope, sequencing rule, validation tolerance and cutover dates belong in the plan. Exporting the inventory, testing row-level security and retiring a workbook belong on the checklist, one wave at a time.

### Who should own a Tableau migration project?

A single project owner with authority over scope and dates, supported by a BI developer, a data engineer, an independent validator, a platform admin, and the dashboard owners who accept their own content. Having conversion and validation done by the same person removes the only independent check in the plan.

### How long should migration planning itself take?

Long enough to produce a signed scope, a complexity score per dashboard, a source map and a written validation policy. On a small estate that is days; on a large one it runs alongside the first wave. Extracting the inventory and scores from metadata is faster than assembling them by interview.

---

## Tableau to Power BI Migration Cost Estimation: What Goes Into the Budget

Canonical: https://getantares.io/tableau-migration-cost-estimation/
Published: 2026-02-18
Updated: 2026-08-10

A Tableau to Power BI migration budget breaks into six lines: conversion labor, licensing delta, parallel running, validation and QA, training and enablement, and data-platform rework. Conversion labor is where estimates start. The lines that overrun are usually the parallel run and the modeling work underneath the reports.

What follows prices the cost side only. Whether the total is worth spending is answered on [the cost calculator](https://getantares.io/tableau-to-power-bi-migration-cost-calculator/); which approach comes out cheaper is settled on [automated versus manual economics](https://getantares.io/automated-vs-manual-tableau-migration/).

## What goes into a migration budget

Six lines, six drivers. A blended cost per dashboard hides that, which is why such budgets come out roughly right about conversion and wrong about everything else.

| Budget line | What sits in it | What sets its size |
| --- | --- | --- |
| Conversion labor | Converting or rebuilding each dashboard, reviewing calculations, rebuilding features with no counterpart | Dashboard count multiplied by effort per dashboard, which is a function of complexity |
| Licensing delta | Power BI licenses for authors and consumers, less what Tableau stops costing after decommission | Audience size by role, and the date the Tableau contract actually ends |
| Parallel running | Both platforms licensed, supported and refreshed while content is validated in production | Length of the parallel window, counted in months |
| Validation and QA | Reconciliation, interaction and security testing, plus the hours owners spend accepting their own content | Measures under the validation policy, and owner availability |
| Training and enablement | Separate sessions for consumers and authors, documentation, support through the first weeks | Number of people, not number of dashboards |
| Data-platform rework | Sources unreachable from the target tenant, gateways, refresh schedules, semantic modeling | Number of distinct sources and how much preparation logic Tableau extracts were hiding |

## How to price conversion labor

Manual conversion is priced as `dashboards × hours per dashboard × blended hourly rate`. On this site's ROI defaults, 100 dashboards at 80 hours and $85 an hour, that line reads $680,000. Tool-assisted conversion replaces most of that labor with a fee: at a flat $200 per source dashboard and review effort of roughly a tenth of a manual rebuild, the same estate is $20,000 of fees plus $68,000 of review, or $88,000. The one-tenth review share is Antares' product claim for its own conversions rather than an industry figure, and [the cost calculator](https://getantares.io/tableau-to-power-bi-migration-cost-calculator/) carries the full worked comparison and its sensitivity. LLM usage sits outside that $88,000: typically under $20 per dashboard billed to your own provider, roughly $2,000 across a 100-dashboard estate.

Both are estimates, and hours per dashboard moves the total more than the rate does. That input spans 4 to 160 hours, because a page of standard charts on a clean source and one carrying nested level-of-detail logic across blended sources are not the same unit of work. Score the estate with [complexity analysis](https://getantares.io/tableau-dashboard-complexity-analysis/) first, then multiply band by band.

## Power BI vs Tableau licensing costs: build the delta, not the total

The licensing line is the gap between two subscriptions with different shapes, and it becomes a saving only when the Tableau contract ends. Prices below come from the vendors' public pricing pages as of August 2026, before discounts.

| Plan | List price, August 2026 | Note |
| --- | --- | --- |
| [Power BI](https://www.microsoft.com/en-us/power-platform/products/power-bi/pricing) free account | Free | Included with a Microsoft Fabric free account; sharing reports requires Pro or Premium |
| Power BI Pro | $14.00 per user per month, paid yearly | The default author and consumer license outside capacity-based plans |
| Power BI Premium Per User | $24.00 per user per month, paid yearly | Microsoft's pricing page footnote lists a $14.00 per user step-up add-on for Pro, Microsoft 365 E5 and Office 365 E5 holders, as of August 2026 |
| Power BI Embedded | Variable, contact sales | Listed without a figure on the Microsoft pricing page |
| [Microsoft Fabric](https://azure.microsoft.com/en-us/pricing/details/microsoft-fabric/) capacity | Priced by capacity, region and commitment | No single list figure applies; size it against your own region and reservation |
| [Tableau](https://www.tableau.com/pricing/teams-orgs) Standard edition | Starting at $15 per user per month, billed annually | Cloud and Server both start here; every deployment needs at least one Creator |
| Tableau Enterprise edition | Starting at $35 per user per month, billed annually | Adds Advanced Management and Data Management |
| Tableau Cloud+ and Tableau+ bundle | Pricing on request | Listed as contact sales rather than as a rate |

Power BI list prices are per user per month, so the annual delta is one multiplication: 100 authors on Pro is 100 by $14 by 12, or $16,800 a year, against what the equivalent seats cost today. Per-role Creator, Explorer and Viewer figures are not published there, so take those from your own contract. Which features need which license is set out in [features by license type](https://learn.microsoft.com/en-us/power-bi/fundamentals/service-features-license-type), with capacity options under [Premium capacity](https://learn.microsoft.com/en-us/power-bi/enterprise/service-premium-what-is).

## Which costs migrations usually miss

Parallel running is the line most often left out of a first estimate. Both platforms stay live, and both meters run, while validation and user transition proceed. Shorten the window with waves and a change freeze rather than skipping it and finding the gaps in production.

Owner time rarely appears in a BI budget at all, because it sits on other departments' payroll. Those hours are still consumed, and owner calendars, not developer calendars, are what acceptance waits on. A plan assuming same-day sign-off from finance during a close has mispriced both schedule and budget.

Data-platform rework is the largest of the three when it lands. Tableau extracts can carry a lot of preparation logic, and reproducing it as a governed model with a [gateway](https://learn.microsoft.com/en-us/power-bi/connect-data/service-gateway-onprem) and [scheduled refresh](https://learn.microsoft.com/en-us/power-bi/connect-data/refresh-data) is engineering rather than conversion work. Size it from the count of distinct sources; Microsoft's [proof of concept](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-proof-of-concept) stage exists largely to expose it before a budget is signed.

## What Antares changes in the budget

Two of these six lines move when a BI migration tool is involved. The inventory and complexity scores the conversion line depends on come from an Analyzer that is free, deterministic and metadata-only, so they cost nothing to produce, and the retirement candidates it surfaces leave the count altogether. Scope reduction is the only budget lever with no offsetting cost.

The fee itself is a multiplication rather than a negotiation: $200 per source Tableau dashboard, flat, with nothing charged per user and no expiry. Your own provider invoices the LLM work, under $20 per dashboard in most cases, and private endpoints are supported. Because the engine runs deterministic-first with guardrailed, validated AI steps toward like-to-like output, keep review time in the budget and redesign in a project of its own. [Run the free Analyzer](https://try.getantares.io) to replace the assumptions above with counts.

Related reading: [the migration guide](https://getantares.io/tableau-to-power-bi-migration/), [the planning guide](https://getantares.io/tableau-migration-planning-guide/), [migration duration](https://getantares.io/how-long-does-tableau-to-power-bi-migration-take/) and [the Converter](https://getantares.io/converter/). Primary sources: [Power BI pricing](https://www.microsoft.com/en-us/power-platform/products/power-bi/pricing) and [Tableau pricing for teams and organizations](https://www.tableau.com/pricing/teams-orgs), both as of August 2026, plus Microsoft on [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 [user enablement](https://learn.microsoft.com/en-us/power-bi/guidance/fabric-adoption-roadmap-mentoring-and-user-enablement).

## Related resources

- [Migration Cost Calculator](https://getantares.io/tableau-to-power-bi-migration-cost-calculator/)
- [How Long a Migration Takes](https://getantares.io/how-long-does-tableau-to-power-bi-migration-take/)
- [Migration Planning Guide](https://getantares.io/tableau-migration-planning-guide/)
- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)

## FAQ

### How much does a Tableau to Power BI migration cost?

It depends on dashboard count and complexity, and only conversion labor is directly computable. At the ROI calculator defaults of 100 dashboards, 80 hours each and $85 an hour, that line is $680,000 rebuilt by hand. Licensing, parallel running, validation, training and data-platform rework sit on top of it. The manual against tool-assisted comparison is worked through on the migration cost calculator page.

### What is usually missing from a migration budget?

Three items: the parallel period when both platforms are licensed at once, the hours dashboard owners spend accepting their own content, and rework on the data platform when Tableau extracts turn out to have carried preparation logic. None of them scale with dashboard count, which is why per-dashboard estimates miss them.

### What do Power BI and Tableau licenses list for?

As of August 2026, Microsoft lists Power BI Pro at $14.00 per user per month paid yearly and Premium Per User at $24.00, with a free account included in Fabric. Tableau lists its Standard edition starting at $15 per user per month billed annually and Enterprise at $35, with per-role licensing quoted separately.

### Does a conversion tool remove the review cost?

No, and a budget should not assume it. The model used here keeps roughly a tenth of the manual effort as review, which is $68,000 on the default estate. Validation of the numbers by the people who own them is unchanged either way, since only they can confirm that a converted figure still means what it meant.

---

## Tableau Migration Risk Assessment: Risks, Early Signals and Mitigations

Canonical: https://getantares.io/tableau-migration-risk-assessment/
Published: 2026-02-18
Updated: 2026-08-11

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](https://getantares.io/tableau-dashboard-complexity-analysis/) 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](https://learn.microsoft.com/en-us/power-bi/transform-model/desktop-relationships-understand) 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](https://getantares.io/tableau-blending-to-power-bi-relationships/) |
| A feature with no counterpart surfaces late | Sets and [set actions](https://help.tableau.com/current/pro/desktop/en-us/actions_sets.htm) 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](https://getantares.io/tableau-sets-to-dax-measures/) |
| A calculation is restated plausibly but wrongly | Nested [LOD expressions](https://help.tableau.com/current/pro/desktop/en-us/calculations_calculatedfields_lod.htm), 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](https://getantares.io/tableau-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](https://learn.microsoft.com/en-us/power-bi/connect-data/service-gateway-onprem) 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](https://learn.microsoft.com/en-us/power-query/power-query-folding) back to the source. Move the logic into a view or the model. See [custom SQL to Power BI](https://getantares.io/tableau-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](https://help.tableau.com/current/server/en-us/adminview.htm) | 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](https://learn.microsoft.com/en-us/fabric/security/service-admin-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](https://learn.microsoft.com/en-us/power-bi/guidance/fabric-adoption-roadmap-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](https://getantares.io/tableau-migration-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](https://getantares.io/enterprise-tableau-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](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-create-validate-content) as one stage. The [migration checklist](https://getantares.io/tableau-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](https://try.getantares.io) to fill in the signal column for your own workbooks.

Related reading: [the Tableau to Power BI migration guide](https://getantares.io/tableau-to-power-bi-migration/), [dashboard complexity scoring](https://getantares.io/tableau-dashboard-complexity-analysis/), [table calculations to DAX](https://getantares.io/tableau-table-calculations-to-dax/) and [the Analyzer](https://getantares.io/analyzer/). Primary sources: Microsoft on [many-to-many relationships](https://learn.microsoft.com/en-us/power-bi/guidance/relationships-many-to-many), plus Tableau's [table calculation reference](https://help.tableau.com/current/pro/desktop/en-us/functions_functions_tablecalculation.htm).

## Related resources

- [Dashboard Complexity Analysis](https://getantares.io/tableau-dashboard-complexity-analysis/)
- [Enterprise Migration Strategy](https://getantares.io/enterprise-tableau-migration-strategy/)
- [Migration Checklist](https://getantares.io/tableau-migration-checklist/)
- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)

## FAQ

### 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.

---

## Tableau Dashboard Complexity Analysis: A Scoring Rubric for Migration Effort

Canonical: https://getantares.io/tableau-dashboard-complexity-analysis/
Published: 2026-02-18
Updated: 2026-08-11

Migration effort per Tableau dashboard is set by what the workbook calculates and where it reads from, not by how many charts sit on the canvas. Five dimensions account for most of the spread: calculation logic, data sources, interactivity, visualization types, and size and layout. Score those five across an estate and a dashboard count becomes an effort estimate you can defend.

Scores are worth producing only if something depends on them. Here they drive three decisions: which dashboards move in which wave, how many hours to budget per band, and which content is worth retiring instead of converting. Duration ranges built on those hours live on [how long a migration takes](https://getantares.io/how-long-does-tableau-to-power-bi-migration-take/).

## What drives migration effort in a Tableau dashboard

Each dimension moves effort for its own reason, so they are scored separately rather than averaged into a single number too early.

| Dimension | Why it drives effort | Where to look next |
| --- | --- | --- |
| Calculation logic | [LOD expressions](https://help.tableau.com/current/pro/desktop/en-us/calculations_calculatedfields_lod.htm) and [table calculations](https://help.tableau.com/current/pro/desktop/en-us/functions_functions_tablecalculation.htm) restate into DAX under different evaluation rules, so each one is reviewed rather than transcribed | [LOD to DAX](https://getantares.io/tableau-lod-expressions-to-dax/), [table calculations to DAX](https://getantares.io/tableau-table-calculations-to-dax/) |
| Data sources | Blends, extracts and [custom SQL](https://help.tableau.com/current/pro/desktop/en-us/customsql.htm) have to become a model with explicit relationships before any report page can be validated against anything | [blending to relationships](https://getantares.io/tableau-blending-to-power-bi-relationships/), [custom SQL](https://getantares.io/tableau-custom-sql-to-power-bi/) |
| Interactivity | Sets, set actions and chained dashboard actions have no single Power BI object behind them, so they are rebuilt from cross-filtering, drillthrough and bookmarks | [sets to DAX](https://getantares.io/tableau-sets-to-dax-measures/), [actions to drillthrough](https://getantares.io/tableau-actions-to-power-bi-drillthrough/) |
| Visualization types | Bar, line and scatter charts map across directly; dual-axis combinations, custom shapes, dense cross-tabs and bespoke maps take design time per view | [workbook to PBIX conversion](https://getantares.io/tableau-workbook-to-pbix-conversion/) |
| Size and layout | Sheets per [dashboard](https://help.tableau.com/current/pro/desktop/en-us/dashboards_create.htm), floating containers and device-specific layouts multiply assembly work even when nothing is calculated | Assembly, theming and layout standards |

## The simple, moderate and complex rubric

Three bands are enough. A finer scale invites argument over whether something is a six or a seven without changing what anybody does next.

| Band | Criteria | What it means for the approach |
| --- | --- | --- |
| Simple | No LOD expressions or table calculations, one governed source or one extract, filters and standard chart types, a handful of sheets | Convert first, then reconcile the numbers. The right content for the earliest wave and for calibrating hours per dashboard |
| Moderate | A few LOD expressions or table calculations, two or three sources that become relationships, parameters, filter and highlight actions | Convert, then review every flagged calculation against the original before the report page reaches its owner |
| Complex | Nested LOD logic over blended sources, custom SQL, sets and set actions, dense dual-axis views, bespoke layouts, row-level filters | Plan design work before converting. Parts of these are rebuilds, and they belong in a later wave with named specialists |

Two habits keep the bands stable. Score the highest dimension instead of the average, because one set action wired through six sheets outweighs forty plain calculated fields. And score the workbook together with the source underneath it, since a tidy page sitting on a database the target tenant cannot reach is not a simple migration.

## How to use the scores

Sequencing is where a rubric pays off soonest. Moving simple dashboards early gives the team a working semantic model, a report theme, a validation routine and a measured hours-per-dashboard figure that everything harder then borrows. Opening with the most visible and most complex content buys the slowest possible first delivery and no baseline to defend the schedule with.

Pruning benefits nearly as much. Cross the scores against 90-day view counts from Tableau's [administrative views](https://help.tableau.com/current/server/en-us/adminview.htm) and one quadrant answers itself: a complex dashboard nobody has opened in a quarter is work you can subtract outright, provided its owner signs the retirement. The [migration checklist](https://getantares.io/tableau-migration-checklist/) carries that as a task with an exit criterion attached.

Estimates take their shape from the bands too. Multiply band by band rather than applying one blended average to the whole estate, then recalibrate once a representative dashboard has actually been converted. Microsoft's [proof of concept](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-proof-of-concept) stage exists for that measurement, and it is what turns assumed hours into observed ones. The same bands feed [the budget lines](https://getantares.io/tableau-migration-cost-estimation/), since conversion labor is the only line that moves with complexity.

## Where complexity scoring goes wrong

Counting objects is the usual failure. Visual count, sheet count and calculated-field count are easy to extract and correlate weakly with effort, because they treat a dual-axis chart and a set action as comparable line items. What correlates is whether a feature has a direct Power BI counterpart, and how many of the features that lack one are wired into the dashboard's interactions.

Scoring only the top layer is the other. A workbook rated simple on its calculations can still hold a live connection nobody in the target tenant can open, or an extract that was quietly performing the data preparation. That work does not evaporate, it moves to the data engineer, and it belongs inside the score. Which dashboards carry which of those problems is a separate exercise, kept as a [risk register](https://getantares.io/tableau-migration-risk-assessment/) rather than folded into the band.

## What Antares does with complexity scoring

This rubric is the job the Antares Analyzer performs. It costs nothing to run, behaves deterministically and reads workbook metadata only, so it crosses an estate without touching data and returns the inventory, a per-workbook feature breakdown and a complexity score for every dashboard instead of a spreadsheet somebody has to populate by hand. Genuinely ambiguous mappings are flagged rather than guessed, which stops a score from hiding the work it was meant to expose.

Antares is a BI migration tool, and its Converter builds on the same analysis: each source Tableau dashboard becomes a Power BI report page for $200 flat, with no per-user licensing and no time limit. Your own provider carries the LLM usage, typically under $20 a dashboard, and private endpoints can be used. Because the method stays deterministic-first with guardrailed, validated AI steps producing like-to-like pages, the complex band still carries review time. [Run the free Analyzer](https://try.getantares.io) to score your own estate before you commit to a sequence.

Related reading: [the Tableau to Power BI migration guide](https://getantares.io/tableau-to-power-bi-migration/), [the migration risk register](https://getantares.io/tableau-migration-risk-assessment/), [enterprise migration strategy](https://getantares.io/enterprise-tableau-migration-strategy/) and [the Analyzer](https://getantares.io/analyzer/). Primary sources: Tableau on [set actions](https://help.tableau.com/current/pro/desktop/en-us/actions_sets.htm) and [blending data sources](https://help.tableau.com/current/pro/desktop/en-us/multiple_connections.htm), plus Microsoft on [star schema design](https://learn.microsoft.com/en-us/power-bi/guidance/star-schema), [data reduction for import models](https://learn.microsoft.com/en-us/power-bi/guidance/import-modeling-data-reduction) and [gathering requirements](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-requirements).

## Related resources

- [Migration Risk Register](https://getantares.io/tableau-migration-risk-assessment/)
- [Enterprise Migration Strategy](https://getantares.io/enterprise-tableau-migration-strategy/)
- [How Long a Migration Takes](https://getantares.io/how-long-does-tableau-to-power-bi-migration-take/)
- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)

## FAQ

### How do you measure Tableau dashboard complexity for a migration?

Score five dimensions separately: calculation logic, data sources, interactivity, visualization types, and size and layout. Take the highest dimension rather than the average, because one set action wired through several sheets costs more than dozens of plain calculated fields sitting next to each other.

### What makes a Tableau dashboard hard to convert to Power BI?

Nested LOD expressions over blended sources, table calculations with unusual addressing, custom SQL, and sets with set actions. Those features either change meaning when restated in DAX or have no Power BI object at all, so they need review or a rebuild rather than a translation.

### Does the number of visuals predict migration effort?

Weakly. Visual, sheet and calculated-field counts are easy to extract and treat a dual-axis chart and a set action as equivalent line items. What predicts effort is whether each feature has a direct Power BI counterpart, and whether the source underneath the workbook is reachable and modeled.

### What do complexity scores change in a migration plan?

Three things: wave order, with simple content first to establish the model, theme and validation routine; hours budgeted per band instead of one blended average across the estate; and retirement decisions, since a complex dashboard with no recent viewers is better retired than converted.

---

## How Long Does a Tableau to Power BI Migration Take? Duration by Estate Size

Canonical: https://getantares.io/how-long-does-tableau-to-power-bi-migration-take/
Published: 2026-02-18
Updated: 2026-08-10

A Tableau to Power BI migration takes weeks for a ten-dashboard estate and many months for a thousand, and the pace is set by validation rather than by conversion. Per dashboard, a hand rebuild runs 80 hours on the default assumption used here, anywhere between 4 and 160 depending on what the workbook contains; a conversion tool turns most of that into review, a fraction of the manual time.

Every range on this page is planning arithmetic derived from those per-dashboard hours. None of it is survey data or an industry average. Substitute your own scored hours and the same multiplications produce a schedule that belongs to your estate.

## How long a migration takes by estate size

Effort comes first and the calendar second. The manual column multiplies dashboards by the 80-hour default. The tool-assisted column is the review effort that remains, modeled at a tenth of those manual hours, alongside a flat fee per dashboard. That tenth is Antares' own claim for its conversions and the first assumption to test on a pilot. Person-weeks convert at a 40-hour week, a unit of measure rather than a claim about how teams spend their days.

| Estate size | Manual effort | Tool-assisted review effort | Typical calendar range | What sets the pace |
| --- | --- | --- | --- | --- |
| 10 dashboards | 800 hours, about 20 person-weeks | 80 hours, about 2 person-weeks | 2 to 6 weeks | Source access, gateway and model setup, which barely shrink with estate size |
| 50 dashboards | 4,000 hours, about 100 person-weeks | 400 hours, about 10 person-weeks | 1 to 3 months | Reconciliation cycles and how fast owners respond |
| 200 dashboards | 16,000 hours, about 400 person-weeks | 1,600 hours, about 40 person-weeks | 4 to 9 months | Wave coordination and validation throughput |
| 1,000 dashboards | 80,000 hours, about 2,000 person-weeks | 8,000 hours, about 200 person-weeks | 9 to 18 months or more, in waves | Governance, ownership decisions and change management |

Rescale the table by complexity before quoting from it. Simple dashboards at 4 hours each divide those figures by twenty; nested calculations at 160 hours double them. The whole table comes from one multiplication, so a wrong figure for hours per dashboard is wrong in every row at once, which is the argument for scoring the estate with [complexity analysis](https://getantares.io/tableau-dashboard-complexity-analysis/) before any date is promised. The cost side of the same inputs is on [cost estimation](https://getantares.io/tableau-migration-cost-estimation/), the savings arithmetic on [the cost calculator](https://getantares.io/tableau-to-power-bi-migration-cost-calculator/).

## Why calendar time is not effort

Effort divided by people gives a floor, not a date, and two things sit in the gap. Part of the work refuses to run in parallel: a semantic model has to exist before report pages can be validated against it, and a reconciliation cycle ends when somebody signs rather than when a developer finishes. Part of it is not yours to schedule, because owners accept their own content around their own quarter ends.

A wave therefore takes as long as its slowest review, and a project takes the number of waves multiplied by that. Two levers shorten it honestly. Retiring a dead dashboard removes a unit from every column and from the calendar, which is why pruning belongs before conversion. And validating one wave while the next converts keeps the two from queuing, provided the validator is not the person who converted.

## Which migration phases take the longest

Phases scale against different things, so a schedule assuming all of them track dashboard count will be wrong at both ends of the estate.

| Phase | What it scales with | What stretches it |
| --- | --- | --- |
| Inventory and prune | Published workbooks, and how many owners must sign a retirement | Content nobody will claim, and sign-off that circulates for weeks |
| Analysis and scoring | Dashboard count, cheap per unit when read from metadata | Assembling the same picture through interviews instead |
| Data platform and model | Number of distinct sources, not dashboards | Sources unreachable from the target tenant, and extracts that hid preparation logic |
| Conversion | Dashboard count multiplied by effort per dashboard | Features with no counterpart, which are rebuilt by hand |
| Validation | Measures under the validation policy and owner availability | Reconciliation cycles that reopen after every fix |
| Cutover and enablement | Number of people, not number of dashboards | Permissions, redirects, training and the agreed parallel window |

## What actually extends migration timelines

Owner availability leads the list. Acceptance needs the person who reads the report every week, and that person has another job. Booking their time in the plan, at prune and at sign-off, costs less than discovering in week nine that nobody has looked at wave one.

Editing during the migration is next. Without a change freeze, every fix is re-checked against a source that has already moved, and each reconciliation cycle reopens the last. The freeze is a policy decision for the document described in [the planning guide](https://getantares.io/tableau-migration-planning-guide/), agreed with owners before the wave starts.

Data-platform rework is the surprise that moves dates most. Sources unreachable from the target tenant, refresh windows that will not fit, and modeling that Tableau extracts quietly absorbed all surface as engineering work with its own schedule. Microsoft's [proof of concept](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-proof-of-concept) and [pre-migration steps](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-pre-migration-steps) exist to find it early, and [refresh configuration](https://learn.microsoft.com/en-us/power-bi/connect-data/refresh-data) plus [row-level security](https://learn.microsoft.com/en-us/fabric/security/service-admin-row-level-security) testing are the usual detail underneath.

Redesign mid-flight is the last and the most self-inflicted. Like-to-like output can be checked against the original; a redesigned report cannot, so every redesign decision adds a review loop ending in opinion rather than reconciliation. Keep it as a project starting after cutover, the position taken in [the migration guide](https://getantares.io/tableau-to-power-bi-migration/). Release mechanics are cheap once [deployment pipelines](https://learn.microsoft.com/en-us/fabric/cicd/deployment-pipelines/intro-to-deployment-pipelines) and the [deploy and monitor](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-deploy-support-monitor) stage are set up and reused per wave.

## What Antares does to the schedule

A BI migration tool compresses two phases here and leaves one alone. Inventory and scoring come out of an Analyzer run at the estimate stage, free, deterministic and reading metadata only, replacing the discovery interviews that usually open a project. Conversion moves from a rebuild to a review at $200 flat for each source Tableau dashboard, nothing per user and nothing that expires, with LLM charges landing on your own provider, usually less than $20 per dashboard, private endpoints available.

Validation does not compress, and no schedule should assume it will. What changes is where review begins: with the mappings the tool flagged as ambiguous rather than with every measure on every page, since the pipeline is deterministic-first with guardrailed, validated AI steps. [Run the free Analyzer](https://try.getantares.io) to turn an estate into scored hours before committing to a date.

Related reading: [the migration guide](https://getantares.io/tableau-to-power-bi-migration/), [the checklist](https://getantares.io/tableau-migration-checklist/), [cost estimation](https://getantares.io/tableau-migration-cost-estimation/) and [the cost calculator](https://getantares.io/tableau-to-power-bi-migration-cost-calculator/). Primary sources: Microsoft's [Power BI migration series](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-overview), [creating and validating migrated content](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-create-validate-content), [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), with Tableau's [administrative views](https://help.tableau.com/current/server/en-us/adminview.htm) for the usage data the prune runs on.

## Related resources

- [Migration Cost Estimation](https://getantares.io/tableau-migration-cost-estimation/)
- [Migration Cost Calculator](https://getantares.io/tableau-to-power-bi-migration-cost-calculator/)
- [Dashboard Complexity Analysis](https://getantares.io/tableau-dashboard-complexity-analysis/)
- [Migration Planning Guide](https://getantares.io/tableau-migration-planning-guide/)

## FAQ

### How long does a Tableau to Power BI migration take?

Small estates run in weeks and large ones in months. The arithmetic behind that: at the 80-hour default per dashboard, 10 dashboards is about 20 person-weeks of manual effort against 2 with a conversion tool, and 200 dashboards is about 400 person-weeks against 40. Calendar time then depends on how much of that can run in parallel.

### How long does it take to convert one dashboard?

Hours with a conversion tool, most of them review, against a default of 80 hours to rebuild by hand. That default spans 4 to 160 hours, because the hours depend on what the workbook calculates: a plain chart page sits at the bottom of the range, nested level-of-detail logic over blended sources at the top. Score the dashboard before quoting a figure for it.

### Which phase of a migration takes the longest?

Validation, once conversion is automated. It scales with the measures under the validation policy and with owner availability rather than with dashboard count, and it reopens after every fix. Automation moves work out of conversion and into review, which makes validation the constraint on the schedule instead of a step near the end.

### Can a migration finish before the Tableau renewal date?

Work backwards. Take the dashboard count that survives pruning, multiply by scored hours per dashboard, divide by the people who can actually work in parallel, then add the validation cycles and the parallel window. If the result overruns the renewal, the choices are a smaller scope, more parallelism, or another contract year.

---

## Tableau to Power BI Migration Checklist: 36 Tasks Across Six Phases

Canonical: https://getantares.io/tableau-migration-checklist/
Published: 2026-02-18
Updated: 2026-08-10

A Tableau to Power BI migration runs 36 tasks across six phases: inventory and prune, analysis and scoring, plan and sequence, convert, validate, and cutover and enablement. Every task below carries an owner and an exit criterion, so a phase ends when its outputs exist rather than when the team feels ready.

This page lists what to remember, not how each step works: the [six-step migration process](https://getantares.io/migrate-tableau-dashboards-to-power-bi/) covers the how, the [planning guide](https://getantares.io/tableau-migration-planning-guide/) the plan document, and Microsoft's [Power BI migration series](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-overview) the vendor sequence. Very large estates add task families beyond these 36: subscriptions and alerts, Tableau Prep flows, gateway clustering, capacity sizing.

## Phase 1: inventory and prune the Tableau estate (6 tasks)

Nothing can be estimated until the estate is counted, and the cheapest dashboard to migrate is one you retire instead. Tableau's [administrative views](https://help.tableau.com/current/server/en-us/adminview.htm) supply the usage figures. Seasonality skews them: quarterly-close and annual-planning dashboards look unused for months, so check a full cycle or ask the owner first.

| # | Task | Owner | Exit criteria |
| --- | --- | --- | --- |
| 1 | Export every published workbook, data source and owner | Platform admin | One inventory covering all sites and projects |
| 2 | Attach 90-day view counts to each workbook | Platform admin | A usage figure on every inventory row |
| 3 | Mark workbooks unused for 90 days as retirement candidates | Platform admin | Draft retirement list |
| 4 | Group duplicates and near-duplicates | Dashboard owners | Consolidation list naming the surviving version |
| 5 | Confirm a named owner for everything that stays | Project owner | No unowned content left in scope |
| 6 | Obtain written sign-off on the retirement list | Project owner | Frozen count of dashboards to migrate |

## Phase 2: analysis and scoring (6 tasks)

Scoring turns a dashboard count into an effort estimate. The rubric lives on [dashboard complexity analysis](https://getantares.io/tableau-dashboard-complexity-analysis/); these tasks make sure it covers every workbook in scope before the schedule is signed.

| # | Task | Owner | Exit criteria |
| --- | --- | --- | --- |
| 7 | Inventory calculations per workbook: LOD, table calcs, custom SQL | BI developer | Feature list per workbook |
| 8 | Score each dashboard simple, moderate or complex | BI developer | A score on every in-scope dashboard |
| 9 | Flag features with no Power BI counterpart, such as sets and set actions | BI developer | Manual-rebuild backlog sized on its own |
| 10 | Record the source behind each workbook: extract, live or blended | Data engineer | Source map for the estate |
| 11 | Check whether each source is reachable from the target tenant | Data engineer | List of sources needing rework first |
| 12 | Convert one representative dashboard as a [proof of concept](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-proof-of-concept) | BI developer | Measured effort per complexity band |

## Phase 3: plan and sequence (6 tasks)

This phase produces waves, workspaces, licenses and the two policies that prevent later arguments: what counts as validated, and when Tableau edits stop. Duration assumptions live on [the timeline page](https://getantares.io/how-long-does-tableau-to-power-bi-migration-take/).

| # | Task | Owner | Exit criteria |
| --- | --- | --- | --- |
| 13 | Group the estate into waves, simplest first | Project owner | Wave plan with dates and dashboard lists |
| 14 | Map waves to target workspaces and a naming standard | Platform admin | Workspace and naming decision recorded |
| 15 | Size [licensing](https://learn.microsoft.com/en-us/power-bi/fundamentals/service-features-license-type) per audience against current Microsoft pricing | Project owner | License counts entered in the budget |
| 16 | Write the validation policy: measures, grain, tolerance, signatory | Validator | One-page definition of acceptance |
| 17 | Set a Tableau change freeze window per wave | Project owner | Freeze dates agreed with dashboard owners |
| 18 | Set cutover and decommission dates per wave | Project owner | Dated plan ending before the Tableau renewal |

## Phase 4: convert Tableau dashboards to Power BI (6 tasks)

Most plans overweight this phase and underweight the two around it. The model comes first: a report page on an unfinished model cannot be validated against anything.

| # | Task | Owner | Exit criteria |
| --- | --- | --- | --- |
| 19 | Build or confirm the semantic model for the wave | Data engineer | Model published, relationships documented |
| 20 | Configure the gateway and refresh schedule | Data engineer | Scheduled refresh succeeding twice in a row |
| 21 | Convert each source dashboard into a report page | BI developer | One report per source dashboard |
| 22 | Review every flagged calculation against the original | BI developer | No open flags left in the wave |
| 23 | Rebuild features that have no counterpart | BI developer | Rebuilt interaction accepted by its owner |
| 24 | Apply the report theme and layout standard | BI developer | Consistent presentation across the wave |

## Phase 5: validate (6 tasks)

Validation compresses least: someone who knows the original still has to confirm the numbers. Microsoft treats [creating and validating content](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-create-validate-content) as one stage.

| # | Task | Owner | Exit criteria |
| --- | --- | --- | --- |
| 25 | Reconcile the agreed measures against Tableau at the agreed grain | Validator | Signed reconciliation sheet |
| 26 | Test filters, drillthrough and cross-filtering paths | Validator | Interaction test log completed |
| 27 | Test [row-level security](https://learn.microsoft.com/en-us/fabric/security/service-admin-row-level-security) with one user per role | Platform admin | A recorded result for every role |
| 28 | Measure refresh duration and page render time | Data engineer | Both inside the agreed limits |
| 29 | Have each dashboard owner review their own report page | Dashboard owners | Owner sign-off per report |
| 30 | Re-test after fixes and close the defect list | Validator | Defects closed or accepted in writing |

## Phase 6: cutover and enablement (6 tasks)

This is where a technically finished migration still fails, because consumers were never moved deliberately. Microsoft's [deploy, support and monitor](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-deploy-support-monitor) stage is the same ground.

| # | Task | Owner | Exit criteria |
| --- | --- | --- | --- |
| 31 | Promote validated content through a [deployment pipeline](https://learn.microsoft.com/en-us/fabric/cicd/deployment-pipelines/intro-to-deployment-pipelines) | Platform admin | Production matches what was tested |
| 32 | Set permissions and app audiences to match current access | Platform admin | Access review signed |
| 33 | Run the agreed parallel period with Tableau edits frozen | Project owner | Parallel window completed without drift |
| 34 | Train consumers and authors [separately](https://learn.microsoft.com/en-us/power-bi/guidance/fabric-adoption-roadmap-mentoring-and-user-enablement) | Project owner | Training delivered to each audience |
| 35 | Redirect links, then unpublish and archive the Tableau workbook | Platform admin | Old workbook retired, archive retained |
| 36 | Review usage after 30 days and release unused licenses | Project owner | Adoption figures and a license decision |

## What Antares does with this checklist

Antares is a BI migration tool covering phases 1, 2 and 4. Metadata-only, deterministic and free, the Analyzer returns the inventory, the usage-based retirement list and a complexity score per workbook. Mappings it cannot resolve with confidence come back flagged, which narrows calculation review in phase 5 to that list. Owner reconciliation of the agreed measures still runs in full.

Phase 4 runs on the Converter: $200 flat per source Tableau dashboard, nothing charged per user, nothing that expires, LLM work billed by your own provider at typically under $20 per dashboard, private endpoints supported. The approach is deterministic-first with guardrailed, validated AI steps and the output like-to-like, so redesign is missing from this list on purpose. [Run the free Analyzer](https://try.getantares.io) to close phases 1 and 2 before committing to dates.

Related reading: [the Tableau to Power BI migration guide](https://getantares.io/tableau-to-power-bi-migration/) and [the migration risk register](https://getantares.io/tableau-migration-risk-assessment/). Primary sources: Microsoft on [pre-migration steps](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-pre-migration-steps), [requirements](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-requirements) and [deployment planning](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-planning).

## Related resources

- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [Migration Planning Guide](https://getantares.io/tableau-migration-planning-guide/)
- [Migration Timeline](https://getantares.io/how-long-does-tableau-to-power-bi-migration-take/)
- [Dashboard Complexity Analysis](https://getantares.io/tableau-dashboard-complexity-analysis/)

## FAQ

### What should a Tableau to Power BI migration checklist cover?

Six phases: inventory and prune, analysis and scoring, plan and sequence, convert, validate, and cutover and enablement. The list on this page runs to 36 tasks. What separates a usable checklist from a wish list is an owner and an exit criterion on each line, so completion is evidence rather than opinion.

### What has to be finished before Tableau to Power BI conversion starts?

Four things: a frozen inventory with retirement decisions signed off, a complexity score on every dashboard still in scope, a source map showing which data is reachable from the target tenant, and a written validation policy. Without the last one, review runs indefinitely because nobody agreed what finished means.

### Who owns the tasks in a migration checklist?

Six roles recur: a project owner for scope, dates and sign-off; a BI developer for conversion and calculation review; a data engineer for the model, sources and refresh; a validator for reconciliation and testing; dashboard owners for accepting their own content; and a platform admin for workspaces, licensing and permissions.

### How many tasks does a Tableau migration actually involve?

This checklist uses 36 as a working baseline for a single estate moving in waves. Small estates collapse several tasks into one sitting, and large ones split conversion and validation per wave, so the count multiplies across waves while the six phases stay the same.

---

## Enterprise Tableau Migration Strategy: What Changes at Scale

Canonical: https://getantares.io/enterprise-tableau-migration-strategy/
Published: 2026-02-18
Updated: 2026-08-11

Past roughly 500 dashboards and more than one business unit, the binding constraint stops being conversion throughput and becomes coordination. Deciding what survives, sequencing waves across units that share no calendar, naming owners for content nobody claims, and fixing standards before hundreds of report pages exist: that is where large migrations are won or lost.

Everything below is work a fifty-dashboard project can skip. Converting a workbook does not change with estate size, and that mechanic is covered on [the migration guide](https://getantares.io/tableau-to-power-bi-migration/). What changes is that every decision now has to hold across teams that will never be in the same room.

## What changes at enterprise scale

| Scale challenge | What breaks without it | What to put in place |
| --- | --- | --- |
| Ownerless and duplicated content | Validation stalls because nobody can say which version is authoritative, and the same report is migrated three times | An inventory keyed on owner and usage, with consolidation and retirement signed off before any wave starts |
| Wave sequencing across business units | Every unit assumes it is in wave one, and the program renegotiates the same scope every month | A dated wave plan per unit, published, with the rule that decides ordering stated openly |
| Report standards and theming | Hundreds of report pages land in a dozen visual dialects and get retrofitted after the fact | A [report theme](https://learn.microsoft.com/en-us/power-bi/create-reports/desktop-report-themes) and layout standard fixed before the first wave converts |
| Endorsement workflow | Consumers cannot distinguish an official report from somebody's copy, and the estate re-fragments on the new platform | [Promoted and Certified](https://learn.microsoft.com/en-us/power-bi/collaborate-share/service-endorse-content) endorsement, with authorized reviewers named before certification is offered |
| Central capacity versus unit autonomy | Workspaces multiply without a rule and licensing gets sized after the bill arrives | A [workspace](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-implementation-planning-workspaces-overview) model per unit, with [license types](https://learn.microsoft.com/en-us/power-bi/fundamentals/service-features-license-type) mapped to audiences |
| Release control | Content gets edited in production because there is nowhere else to test at volume | [Deployment pipelines](https://learn.microsoft.com/en-us/fabric/cicd/deployment-pipelines/intro-to-deployment-pipelines) running development to test to production for every workspace in scope |
| Security across units | Row-level rules are rebuilt inconsistently per unit, and access review becomes the cutover blocker | One [row-level security](https://learn.microsoft.com/en-us/fabric/security/service-admin-row-level-security) pattern, tested per role and reused across units |
| Change management at consumer scale | A technically finished migration that hundreds of people keep asking to reverse | [Change management](https://learn.microsoft.com/en-us/power-bi/guidance/fabric-adoption-roadmap-change-management) and [enablement](https://learn.microsoft.com/en-us/power-bi/guidance/fabric-adoption-roadmap-mentoring-and-user-enablement) staffed as workstreams, not booked as a training day |

## Prune before planning waves

Large estates accumulate content that no longer has readers: superseded copies, one-off analyses published and forgotten, personal variants of an official report. Retiring that content is the only move in a migration that costs nothing and subtracts work from every later phase, and at several hundred dashboards it deserves evidence rather than intuition.

Usage data settles most of it. Tableau's [administrative views](https://help.tableau.com/current/server/en-us/adminview.htm) give view counts per workbook, and a workbook unopened for a quarter becomes a retirement candidate its owner has to defend rather than one the program has to justify. Near-duplicates still need a person, since two similarly named workbooks may genuinely serve two units differently. The [migration checklist](https://getantares.io/tableau-migration-checklist/) holds this as its opening phase with exit criteria.

## Waves by business unit or by complexity

Two orderings compete at scale and they optimize for different things. Sequencing by complexity gives the delivery team a smooth learning curve and an early measured baseline, but leaves individual units half migrated for months, running two platforms and answering questions about both. Sequencing by business unit gives each unit one clean cutover and one change-management conversation, at the price of whatever complexity that unit happens to own.

What survives contact is usually business unit as the outer loop with complexity as the inner one. Pick a unit, move its simple content first to establish the model and the theme, follow with its harder content, cut the unit over, then start the next. Which content sits in which band comes from [complexity scoring](https://getantares.io/tableau-dashboard-complexity-analysis/), and the effort those bands imply from [duration by estate size](https://getantares.io/how-long-does-tableau-to-power-bi-migration-take/).

One dependency deserves drawing before anyone quotes a finish date: shared data ignores unit boundaries. When a semantic model serves four units, it gets built in the first wave that needs it and the other three inherit both the model and its release schedule.

## Who owns what after cutover

Scale forces a decision that small migrations can postpone, which is whether report ownership sits centrally or with the units. Microsoft's adoption roadmap frames it as [content ownership and management](https://learn.microsoft.com/en-us/power-bi/guidance/fabric-adoption-roadmap-content-ownership-and-management), and the practical version is narrower: somebody owns each shared semantic model, somebody owns each report page, and somebody decides what gets certified.

Endorsement makes those answers visible to consumers. Any workspace member with write permission can mark content as Promoted, while Certified is limited to reviewers a Power BI administrator has authorized, according to Microsoft's endorsement documentation. Naming those reviewers before the first wave lands is what keeps certification meaningful. A [center of excellence](https://learn.microsoft.com/en-us/power-bi/guidance/center-of-excellence-establish) is the usual home for that authority, along with standards, mentoring and the shared model layer.

## Where a systems integrator fits

Enterprise programs often run with a delivery partner, because scoping, testing and enablement across business units is program management rather than BI work. Antares works with systems integrators including T1A and OBV, listed on [partners](https://getantares.io/partners/): the partner carries delivery and accountability, and a migration tool removes the mechanical translation so partner hours go into modeling, validation and each unit's own definition of correct. Whether to involve a partner at all is worked through on [consultant versus tool](https://getantares.io/tableau-migration-consultant-vs-tool/).

## What Antares does at enterprise scale

Antares is a BI migration tool, and at this size the free Analyzer replaces the manual spreadsheet inventory that otherwise opens the program. Deterministic, metadata-only and running inside your own environment, it inventories, scores and de-duplicates a multi-site estate without data crossing your boundary. What comes back is a per-workbook feature and source breakdown, which is what wave planning needs and what usage figures alone cannot supply.

Volume is where the Converter's pricing matters: $200 flat for every source Tableau dashboard, priced without per-user licensing and without a time limit, keeps the tooling line a multiplication instead of a per-unit negotiation. LLM charges sit with your own provider, usually under $20 per dashboard, and private endpoints are supported. Deterministic-first with guardrailed, validated AI steps, the conversion produces like-to-like report pages, so standardization and redesign stay program decisions with their own budget. [Run the free Analyzer](https://try.getantares.io) on one business unit and calibrate the rest from it.

Related reading: [the migration planning guide](https://getantares.io/tableau-migration-planning-guide/), [the migration risk register](https://getantares.io/tableau-migration-risk-assessment/), [dashboard complexity scoring](https://getantares.io/tableau-dashboard-complexity-analysis/) and [the Analyzer](https://getantares.io/analyzer/). Primary sources: Microsoft on [endorsing content](https://learn.microsoft.com/en-us/power-bi/collaborate-share/service-endorse-content), [content ownership and management](https://learn.microsoft.com/en-us/power-bi/guidance/fabric-adoption-roadmap-content-ownership-and-management) and [establishing a center of excellence](https://learn.microsoft.com/en-us/power-bi/guidance/center-of-excellence-establish).

## Related resources

- [Migration Planning Guide](https://getantares.io/tableau-migration-planning-guide/)
- [Migration Risk Register](https://getantares.io/tableau-migration-risk-assessment/)
- [Dashboard Complexity Analysis](https://getantares.io/tableau-dashboard-complexity-analysis/)
- [Consultant vs Migration Tool](https://getantares.io/tableau-migration-consultant-vs-tool/)

## FAQ

### What is different about an enterprise Tableau migration?

Coordination replaces conversion as the constraint. Content without owners, duplicate reports across units, wave sequencing between units with different fiscal calendars and freeze windows, standards agreed before hundreds of report pages exist, and change management for thousands of consumers are all work a small project never has to do.

### Should migration waves follow business units or complexity?

Business unit as the outer loop, complexity as the inner one. Each unit gets one cutover and one change-management conversation, while simple content inside that unit moves first to establish the semantic model, the theme and the validation routine before harder dashboards follow.

### What is the difference between Promoted and Certified in Power BI?

Promoted content can be marked by any workspace member with write permission, so it signals that an author considers it ready. Certified is restricted to reviewers a Power BI administrator has authorized, which makes it the stronger signal. Decide who those reviewers are before the first wave.

### Do we need a systems integrator for a large Tableau migration?

It depends on who should carry delivery accountability across units. Partners such as T1A and OBV run the program, the scoping and the enablement, while a migration tool removes the mechanical translation so partner hours go into modeling and validation instead of rebuilding charts.

---

## Tableau to Power BI Conversion Tool: What It Converts, What It Flags, and How to Evaluate One

Canonical: https://getantares.io/tableau-to-power-bi-conversion-tool/
Published: 2026-02-18
Updated: 2026-08-06

A Tableau to Power BI conversion tool reads workbook metadata — worksheets, visuals, fields, calculations, layout — and writes the equivalent Power BI semantic model and report pages. It moves definitions, not rows of data and not pixels. Nearly everything such a tool can and cannot do follows from that one fact, including why parts of a dashboard arrive finished and other parts arrive needing a decision.

## What a conversion tool actually converts

The raw material is metadata that both platforms already expose. On the Tableau side, the [Metadata API](https://help.tableau.com/current/api/metadata_api/en-us/index.html) indexes workbooks, data sources, flows and metrics along with their schema and lineage, and the [REST API](https://help.tableau.com/current/api/rest_api/en-us/REST/rest_api.htm) lists and downloads published content. On the Power BI side, the natural output format is a [Power BI Project (PBIP)](https://learn.microsoft.com/en-us/power-bi/developer/projects/projects-overview), where the report and the semantic model are saved as plain text files in separate folders. PBIP is documented as a preview feature, and every PBIP deployment route other than publishing from Desktop moves metadata only.

Work splits into three stages. A tool that skips one has not removed that stage from your project; it has handed it back to you.

| Stage | Input | Output | What you still decide |
| --- | --- | --- | --- |
| Inventory and analysis | Site metadata: workbooks, dashboards, fields, usage | A scored inventory with complexity and feature usage | Which dashboards are worth moving at all |
| Conversion | One source dashboard definition | Report pages plus the model objects behind them | Anything the tool marks as ambiguous |
| Validation and deployment | Converted output and the original side by side | Items in a workspace, or a project folder under source control | Whether numbers and interactions actually match |

Within the conversion stage, outcomes are not uniform. Grouping them this way is more useful than a single coverage percentage, because the three groups cost very different amounts of review time.

| Tableau element | Typical outcome | Why |
| --- | --- | --- |
| Bar, line, area, scatter, map, text table | Converts | Direct counterparts exist among Power BI's [core visuals](https://learn.microsoft.com/en-us/power-bi/visuals/power-bi-report-visualizations) |
| Fields, data types, folders, hierarchies | Converts | Structural metadata with a one-to-one equivalent |
| Row-level calculated fields | Converts | Most Tableau functions have a [DAX](https://learn.microsoft.com/en-us/dax/dax-function-reference) counterpart |
| Joins between tables | Converts with review | The model shape is the question: Power BI performs best against a [star schema](https://learn.microsoft.com/en-us/power-bi/guidance/star-schema) |
| [LOD expressions](https://getantares.io/tableau-lod-expressions-to-dax/) | Converts with review | Filter context has to be restated, not copied |
| [Table calculations](https://getantares.io/tableau-table-calculations-to-dax/) | Converts with review | Addressing and partitioning become window or filter arguments |
| [Data blends](https://getantares.io/tableau-blending-to-power-bi-relationships/) | Converts with review | Cardinality and cross-filter direction are choices |
| [Custom SQL](https://getantares.io/tableau-custom-sql-to-power-bi/) | Converts with review | Whether it belongs in a view, Power Query or the model is a modeling call |
| [Sets and set actions](https://getantares.io/tableau-sets-to-dax-measures/) | Manual redesign | Power BI has no stored set a user selection can write into |
| [Custom visuals](https://learn.microsoft.com/en-us/power-bi/developer/visuals/power-bi-custom-visuals) and extensions | Manual redesign | Both platforms have their own marketplaces and their own APIs |

## What no tool converts automatically

Layout fidelity is the first boundary. Tableau lays out a dashboard with tiled and [floating containers](https://help.tableau.com/current/pro/desktop/en-us/dashboards_organize_floatingandtiled.htm); Power BI uses a fixed report canvas with its own display settings. Positions and sizes translate; the rendering engines do not. Fonts, padding and label wrapping land close to the original rather than identical to it. Expect a like-for-like report page, not a screenshot.

Vocabulary is the second, and it causes more confusion than it should. In Power BI, a [dashboard](https://learn.microsoft.com/en-us/power-bi/create-reports/service-dashboards) is a single page of tiles pinned from reports, cannot be filtered, and exists only in the service. A Tableau dashboard becomes a Power BI [report page](https://learn.microsoft.com/en-us/power-bi/explore-reports/end-user-reports), which supports pages, filters and drilling. When a vendor says it converts dashboards, ask which of the two it means.

Governance is the third. Workspace structure, [row-level security](https://learn.microsoft.com/en-us/fabric/security/service-admin-row-level-security) roles, permissions, subscriptions and refresh schedules sit outside the artifact and have to be designed for the target tenant. A tool can place content into a workspace you name; deciding what that workspace is for stays with your team.

## How to evaluate a conversion tool

Six questions separate tools quickly. Each one has a wrong answer to listen for, shown in the last column.

| Question | Why it matters | Answer to be wary of |
| --- | --- | --- |
| Can I see the analysis before I pay? | Scope drives every estimate you will make | Analysis only after a contract |
| What is the unit of pricing? | Per dashboard, per credit and per seat produce very different bills | Pricing that depends on details you cannot count yourself |
| Does it tell me what it will not convert? | Known gaps are schedulable; unknown gaps surface in testing | A single coverage percentage with no breakdown |
| How is output validated? | Converted is not the same as correct | Validation described as the customer's responsibility only |
| Does it deploy, or hand over files? | Bulk publishing is real work at estate scale | Manual upload for every artifact |
| What does it access? | Metadata-only access is a much smaller security review | Vague answers about business data |

Two red flags deserve naming. A claim of full automation is not credible, because sets, set actions and custom extensions have no mechanical target. And a tool that cannot describe its failure modes has not been run against a messy estate.

## What Antares does

Antares is a BI migration tool built in two parts. The Analyzer connects to the source environment and produces the inventory: what exists, how complex it is, and which features drive the effort. It is deterministic and free, so scoping does not depend on a purchase. The Converter turns one source dashboard into a Power BI report page and deploys it, priced at a flat $200 per source dashboard, with no per-user licensing and no time limits.

The pipeline is deterministic-first, with guardrailed and validated AI steps where a rule alone is not enough. Only metadata is read, never business data, and LLM usage is billed by your own provider, typically under $20 per dashboard, with private endpoints supported. Where a mapping is genuinely ambiguous, it is flagged rather than guessed. [Run the free Analyzer](https://try.getantares.io) to see the breakdown for your own estate before committing to anything.

Related reading: the [Tableau to Power BI migration guide](https://getantares.io/tableau-to-power-bi-migration/), [how to compare tool categories](https://getantares.io/tableau-vs-power-bi-migration-tools/), and the [named options available today](https://getantares.io/best-tableau-to-power-bi-migration-tool/). Primary sources: Microsoft on [project report folders](https://learn.microsoft.com/en-us/power-bi/developer/projects/projects-report) and [the Power BI REST API](https://learn.microsoft.com/en-us/rest/api/power-bi/), and Tableau on the [Metadata API](https://help.tableau.com/current/api/metadata_api/en-us/docs/meta_api_start.html).

## Related resources

- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [How to Compare Migration Tools](https://getantares.io/tableau-vs-power-bi-migration-tools/)
- [Automated Migration: What Converts](https://getantares.io/tableau-to-power-bi-automated-migration/)
- [Best Tableau to Power BI Migration Tools](https://getantares.io/best-tableau-to-power-bi-migration-tool/)

## FAQ

### What does a Tableau to Power BI conversion tool convert?

Metadata: worksheets, visuals, fields, data types, hierarchies, joins and calculations, rewritten as a Power BI semantic model and report pages. It does not move rows of data, and it does not reproduce the original pixel for pixel. Layout translates as position and size, not as identical rendering.

### Does a conversion tool produce a Power BI dashboard?

No. A Tableau dashboard becomes a Power BI report page. In Microsoft's own vocabulary a Power BI dashboard is a single page of tiles pinned from reports, cannot be filtered, and exists only in the service. Report pages are what carry filters, drilling and interactions.

### What can no conversion tool automate?

Sets and set actions, because Power BI has no stored set a user selection can write into. Custom visuals and extensions, because each platform has its own marketplace and APIs. Governance decisions such as workspace design, row-level security and refresh schedules also sit outside the artifact.

### How much does a Tableau to Power BI conversion tool cost?

Pricing units vary: per dashboard, per workbook credit, per subscription tier, or bundled into a services engagement. Several vendors quote only after an assessment. Antares publishes a flat $200 per source dashboard, with the Analyzer free and no per-user licensing or time limits; LLM usage is billed separately by your own provider, typically under $20 per dashboard.

---

## Automated Tableau to Power BI Migration: What Converts, What Needs Review, What Breaks

Canonical: https://getantares.io/tableau-to-power-bi-automated-migration/
Published: 2026-02-18
Updated: 2026-08-06

Automated Tableau to Power BI migration works for most of what a typical dashboard is made of: visuals, fields, joins and row-level calculations. It stops at features that have no counterpart in the target, chiefly sets, set actions and custom extensions. The boundary is sharp and knowable in advance, and projects go wrong when nobody looks for it until conversion has already started.

## What converts, what needs review, what has to be rebuilt

Coverage is better described in three buckets than as one percentage. The first bucket costs almost nothing to accept. The second costs a reviewer some minutes and a decision. The third is design work, priced separately, and it is where estimates usually break.

| Tableau feature | Fate under automation | What decides it |
| --- | --- | --- |
| Standard chart types, text tables, maps | Converts | Direct counterparts among Power BI's [core visuals](https://learn.microsoft.com/en-us/power-bi/visuals/power-bi-report-visualizations) |
| Fields, data types, folders, [groups and hierarchies](https://getantares.io/tableau-groups-to-power-bi/) | Converts | Structural metadata with a one-to-one target |
| Row-level [calculated fields](https://getantares.io/tableau-calculated-fields-to-dax/) | Converts | Most Tableau functions map onto a [DAX](https://learn.microsoft.com/en-us/dax/dax-function-reference) function |
| [Parameters](https://getantares.io/tableau-parameters-to-power-bi-parameters/) | Converts with review | Some become what-if parameters, some become [field parameters](https://learn.microsoft.com/en-us/power-bi/create-reports/power-bi-field-parameters) |
| [LOD expressions](https://getantares.io/tableau-lod-expressions-to-dax/) | Converts with review | Whether the target should respect slicers or ignore them |
| [Table calculations](https://getantares.io/tableau-table-calculations-to-dax/) | Converts with review | Addressing and partitioning become explicit arguments |
| [Data blends](https://getantares.io/tableau-blending-to-power-bi-relationships/) | Converts with review | Cardinality and cross-filter direction on the [relationship](https://learn.microsoft.com/en-us/power-bi/transform-model/desktop-relationships-understand) |
| Filter and highlight [actions](https://help.tableau.com/current/pro/desktop/en-us/actions.htm) | Converts with review | Rebuilt from [visual interactions](https://learn.microsoft.com/en-us/power-bi/create-reports/service-reports-visual-interactions) or [drillthrough](https://learn.microsoft.com/en-us/power-bi/create-reports/desktop-drillthrough) |
| [Custom SQL](https://getantares.io/tableau-custom-sql-to-power-bi/) | Converts with review | Whether it belongs in a view, in Power Query, or in the model |
| [Sets and set actions](https://getantares.io/tableau-sets-to-dax-measures/) | Manual redesign | Power BI has no stored set a selection can write into |
| Dashboard extensions and custom visuals | Manual redesign | Separate marketplaces, separate APIs |

## Why converted is not the same as done

The most expensive misunderstanding in an automated migration is treating a successful conversion run as a finished deliverable. Two classes of defect survive it, and neither shows up as an error.

One is numeric. A measure can be syntactically valid, render without complaint, and still aggregate in a different context than the Tableau original did. This is the normal failure mode for anything derived from an LOD expression or a table calculation, because Tableau resolves those against its own [order of operations](https://help.tableau.com/current/pro/desktop/en-us/order_of_operations.htm) while DAX resolves them against filter context. Reconciling a handful of headline totals per report page, with slicers applied and then cleared, catches most of it.

The other is behavioral. A report page can show correct numbers and still feel wrong because a click that used to filter three other charts now filters one, or a tooltip lost the worksheet embedded in it. Tableau builds interaction from actions on a dashboard; Power BI builds it from visual interactions, [bookmarks](https://learn.microsoft.com/en-us/power-bi/create-reports/desktop-bookmarks), drillthrough and [report page tooltips](https://learn.microsoft.com/en-us/power-bi/create-reports/desktop-tooltips). Those are different building blocks assembled to the same intent, so they need to be exercised by a person who used the original.

## What automation does better than a hand rebuild

Consistency is where automation genuinely beats people: the same Tableau pattern produces the same DAX and the same model shape on dashboard one and dashboard two hundred, whereas four developers rebuilding by hand produce four dialects of the same measure and four opinions about naming. On a large estate that consistency is worth more than the hours saved, because it is what makes the result maintainable.

Automation is also repeatable. When the source workbook changes mid-project, or a mapping decision turns out to be wrong, re-running conversion costs minutes rather than restarting a rebuild. That matters in practice, because estates are rarely frozen while a migration runs.

## Why the last stretch costs the most

Effort in a migration is not distributed like content. A dashboard built almost entirely from standard charts can still owe most of its remaining hours to two set actions and a custom extension, because those are the parts with no mechanical target. This is why coverage percentages quoted without a feature breakdown are close to meaningless for planning: two estates with identical headline coverage can differ by weeks.

The product claim is 90% less manual work in Antares conversions, and the ROI model on this site assumes roughly a tenth of a hand rebuild remains as review effort. Treat that as a product claim with an explicit assumption behind it, not as an industry constant. The share that survives automation in your estate is an empirical fact about your workbooks, and it is measurable before you spend anything.

Three properties drive it more than anything else: how many distinct dashboards actually get used, how heavily the estate leans on sets and set actions, and how much modeling was pushed into custom SQL. A dashboard-level inventory answers all three. For the process that turns that inventory into a schedule, see the [step-by-step migration process](https://getantares.io/migrate-tableau-dashboards-to-power-bi/); for the cost comparison against a hand rebuild, see [automated versus manual migration](https://getantares.io/automated-vs-manual-tableau-migration/).

## What Antares does

Antares is a BI migration tool with two parts. The Analyzer is deterministic, free, and reads only metadata; it returns the feature breakdown above for your actual estate rather than a generic coverage claim. The Converter turns one source Tableau dashboard into a Power BI report page and deploys it, at a flat $200 per source dashboard, with no per-user licensing and no time limits. LLM costs are not included and are typically under $20 per dashboard, paid to your own provider, and private endpoints are supported.

The pipeline is deterministic-first with guardrailed, validated AI steps. The rule that matters most for expectation setting is what happens at the boundary: an ambiguous mapping is flagged rather than guessed, because a silently rewritten calculation is far more expensive to find in user testing than a flagged one is to review. [Run the free Analyzer](https://try.getantares.io) to see your own split before committing budget.

Related reading: the [Tableau to Power BI migration guide](https://getantares.io/tableau-to-power-bi-migration/) and [what a conversion tool actually converts](https://getantares.io/tableau-to-power-bi-conversion-tool/). Primary sources: Tableau on [set actions](https://help.tableau.com/current/pro/desktop/en-us/actions_sets.htm) and [LOD expressions](https://help.tableau.com/current/pro/desktop/en-us/calculations_calculatedfields_lod.htm), and Microsoft's [Power BI migration guidance](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-overview).

## Related resources

- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [What a Conversion Tool Converts](https://getantares.io/tableau-to-power-bi-conversion-tool/)
- [Step-by-Step Dashboard Migration](https://getantares.io/migrate-tableau-dashboards-to-power-bi/)
- [Automated vs Manual Migration](https://getantares.io/automated-vs-manual-tableau-migration/)

## FAQ

### Can Tableau to Power BI migration be fully automated?

No. Standard visuals, fields, joins and row-level calculations convert reliably. Sets, set actions, dashboard extensions and custom visuals have no mechanical target in Power BI and are rebuilt by hand. Treat any claim of full automation as a reason to ask for the feature-level breakdown.

### What breaks most often in an automated Tableau migration?

Anything whose result depends on evaluation context. LOD expressions and table calculations convert to valid DAX that can still aggregate differently, because Tableau resolves them through its order of operations and DAX resolves them through filter context. Reconcile headline totals with slicers applied and then cleared.

### How accurate are quoted automation percentages?

A single percentage is not useful for planning. Effort concentrates in the small share of features with no counterpart. Ask for the coverage split by feature instead: converts, converts with review, and manual redesign.

### Do converted reports still need validation?

Yes, in two passes. A numeric pass reconciles headline measures per report page against the Tableau original, filtered and unfiltered. A behavioral pass checks interactions, since Tableau dashboard actions are rebuilt from visual interactions, bookmarks, drillthrough and report page tooltips rather than copied.

---

## How to Migrate Tableau Dashboards to Power BI: A Six-Step Process

Canonical: https://getantares.io/migrate-tableau-dashboards-to-power-bi/
Published: 2026-02-18
Updated: 2026-08-06

Migrating Tableau dashboards to Power BI runs in six steps: inventory and prune the estate, score what remains for complexity, sequence the work, convert, validate numbers and interactions, then cut over with user enablement. Automation compresses step four and part of step five. The other four steps stay with your team no matter which tool you buy, and skipping the first one is the most common way to overspend.

Microsoft frames its own guidance the same way, with [pre-migration steps followed by five stages](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-overview): gather requirements and prioritize, plan for deployment, conduct a proof of concept, create and validate content, then deploy, support and monitor. What follows maps that shape onto a dashboard estate specifically.

## Step 1: Inventory the estate and prune it

Start by counting what you actually have and, more importantly, what anyone actually opens. Tableau Server and Tableau Cloud both ship [administrative views](https://help.tableau.com/current/server/en-us/adminview.htm) covering traffic to views and workbooks, stale content and actions by user; Tableau Cloud exposes [the equivalent set](https://help.tableau.com/current/online/en-us/adminview.htm) for a site. Cross those with the [Metadata API](https://help.tableau.com/current/api/metadata_api/en-us/index.html), which indexes workbooks, data sources and lineage, and you have both usage and structure.

The typical outcome is uncomfortable and useful: a meaningful share of published dashboards are duplicates, abandoned drafts or one-off analyses that nobody has opened in a year. Every one of those you decline to migrate is effort and license cost you never spend. Typical mistake: treating the workbook count as the project size. The unit that matters is the dashboard, because that is what a user opens and what a converter produces.

## Step 2: Score what remains for complexity

Two dashboards with the same number of charts can differ by an order of magnitude in effort. What separates them is feature mix: [LOD expressions](https://getantares.io/tableau-lod-expressions-to-dax/), [table calculations](https://getantares.io/tableau-table-calculations-to-dax/), [sets and set actions](https://getantares.io/tableau-sets-to-dax-measures/), [custom SQL](https://getantares.io/tableau-custom-sql-to-power-bi/), blends and extensions. Score each dashboard on those, not on chart count, and you get an estimate that survives contact with the work.

Typical mistake: estimating from a sample of the dashboards the team likes. The expensive ones are usually the old finance and operations dashboards nobody volunteers to demo.

## Step 3: Sequence the work

Order the queue so the team learns before it commits. Simple, low-risk dashboards first, to shake out the target workspace structure, naming and refresh setup. High-visibility dashboards second, once the pattern is proven, because those are what buy sponsor confidence. The complex remainder last, when everybody knows which parts of Power BI they are working with.

Set up the target before conversion starts, not after: [workspaces](https://learn.microsoft.com/en-us/power-bi/collaborate-share/service-create-the-new-workspaces) for the content, and [deployment pipelines](https://learn.microsoft.com/en-us/fabric/cicd/deployment-pipelines/intro-to-deployment-pipelines) if you want development, test and production stages rather than publishing straight into production.

## Step 4: Convert

One Tableau dashboard becomes one Power BI report page. Keep the vocabulary straight, because in Microsoft's terms a [Power BI dashboard](https://learn.microsoft.com/en-us/power-bi/create-reports/service-dashboards) is a single page of pinned tiles that cannot be filtered, while a [report](https://learn.microsoft.com/en-us/power-bi/explore-reports/end-user-reports) holds one or more pages and carries the filtering and drilling. Very tall Tableau dashboards sometimes read better split across two report pages, since the Power BI canvas has fixed [display settings](https://learn.microsoft.com/en-us/power-bi/create-reports/power-bi-report-display-settings) rather than a long scroll.

Typical mistake: converting and redesigning in the same pass. Like-for-like conversion is verifiable against the original; a redesign is not, and mixing them makes every discrepancy a debate. If a dashboard genuinely needs rethinking, schedule that as separate work after cutover.

## Step 5: Validate numbers, then behavior

Validation is two passes. The numeric pass reconciles headline measures on each report page against the Tableau original, once unfiltered and once with slicers applied, because context-dependent calculations agree at the total and diverge under filtering. The behavioral pass exercises interactions: a click that filtered three charts in Tableau should still filter three, and tooltips should still carry their detail.

Typical mistake: validating with the migration team only. The person who wrote the original dashboard finds problems in minutes that a reviewer will not find in a day.

## Step 6: Cut over and enable users

Run both platforms in parallel for a defined window, publish the new location, and set a date after which the Tableau version is read-only. Plan enablement alongside the cutover: Microsoft's own migration guidance puts training, support and a communication plan among the practices that separate successful migrations, and the [Fabric adoption roadmap](https://learn.microsoft.com/en-us/power-bi/guidance/fabric-adoption-roadmap) covers the governance side. Then [monitor usage](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-implementation-planning-auditing-monitoring-overview) in the new tenant, which also tells you which migrated content was worth migrating.

| Step | Manual path | With a migration tool |
| --- | --- | --- |
| Inventory and prune | Admin views exported and reconciled by hand | Automated inventory with usage and complexity together |
| Score complexity | Workbooks opened and read one by one | Feature usage counted across the estate |
| Sequence | Team judgment | Team judgment, informed by the score |
| Convert | Rebuild each report page in Desktop | Generated report page plus flagged items to review |
| Validate | Manual reconciliation | Manual reconciliation, narrowed to flagged areas first |
| Cut over and enable | Team owns it | Team owns it |

## What Antares does

Antares is a BI migration tool covering steps one, two and four, and narrowing step five. The Analyzer connects to the source environment, reads metadata only, and returns the inventory and complexity scoring that steps one and two need; it is deterministic and free, so pruning happens before any spend. The Converter produces the Power BI report page and deploys it, at a flat $200 per source dashboard, with no per-user licensing and no time limits. LLM usage is billed by your own provider, typically under $20 per dashboard, with private endpoints supported.

Conversion is like-for-like by design, not a redesign, which is what keeps step five verifiable. Where a mapping is ambiguous it is flagged rather than guessed, so review starts with the items that need judgment. [Run the free Analyzer](https://try.getantares.io) to produce the step one inventory for your own site.

Related reading: the [Tableau to Power BI migration guide](https://getantares.io/tableau-to-power-bi-migration/), [what converts and what breaks](https://getantares.io/tableau-to-power-bi-automated-migration/), and [consultant versus tool](https://getantares.io/tableau-migration-consultant-vs-tool/). Primary source: Microsoft's [deployment planning stage](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-planning).

## Related resources

- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [Automated Migration: What Converts](https://getantares.io/tableau-to-power-bi-automated-migration/)
- [What a Conversion Tool Converts](https://getantares.io/tableau-to-power-bi-conversion-tool/)
- [Consultant vs Migration Tool](https://getantares.io/tableau-migration-consultant-vs-tool/)

## FAQ

### What are the steps to migrate Tableau dashboards to Power BI?

Inventory and prune the estate, score the remaining dashboards for complexity, sequence the queue simple first, convert, validate numbers and then interactions, and cut over with user enablement. Microsoft's own guidance follows the same shape: pre-migration steps, then five stages ending in deploy, support and monitor.

### Does one Tableau dashboard become one Power BI dashboard?

No, it becomes a Power BI report page. In Microsoft's vocabulary a Power BI dashboard is a single page of tiles pinned from reports and cannot be filtered. A very tall Tableau dashboard sometimes reads better split across two report pages, because the Power BI canvas is a fixed size rather than a long scroll.

### Which dashboards should be migrated first?

Simple, low-risk ones, to settle workspace structure, naming and refresh before anything visible is at stake. High-visibility dashboards second, once the pattern is proven. Complex dashboards last. Anything nobody has opened in a year is a candidate for retirement rather than migration.

### Should dashboards be redesigned during migration?

Not in the same pass. Like-for-like conversion can be verified against the original, a redesign cannot, and mixing them turns every discrepancy into a debate about intent. Schedule redesign as separate work after cutover, when users are already on the new platform.

---

## Comparing Tableau to Power BI Migration Tools: Classes, Criteria, and Red Flags

Canonical: https://getantares.io/tableau-vs-power-bi-migration-tools/
Published: 2026-02-18
Updated: 2026-08-06

Tableau to Power BI migration tools cannot be compared head to head until you know which class each one belongs to. There are four: analyzers that only measure the estate, converters that produce artifacts, accelerators bundled inside a services engagement, and building it yourself. Comparing a converter against a services accelerator on features is a category error. Pick the class first, then compare within it.

## The four classes and what each one costs you

Each class buys down a different risk. Analyzers reduce scoping risk, converters reduce execution risk, accelerators reduce delivery risk, and doing it in-house reduces cash outlay while raising schedule risk. Most real programs end up using two of them.

| Class | What it gives you | What you pay with | Output |
| --- | --- | --- | --- |
| Analyzer | Inventory, usage, complexity and feature counts across the estate | Little or nothing | A scoped plan, and no converted content |
| Converter | Generated report pages and model objects, usually deployed | A per-unit fee and your review time | Working content, plus flagged items |
| Accelerator inside a service | A team that owns the outcome, tooling included | Day rates and a longer sales cycle | A delivered project |
| In-house rebuild | Full control and target-platform skills you keep | Your team's calendar | Whatever your team can finish |

The class question also settles most sales conversations early. If you need someone accountable for the whole program including change management, no converter will satisfy that, and evaluating converters is wasted effort. If you have a capable BI team and a hard deadline, the constraint is throughput, and a services engagement is the costlier way to buy it.

## Seven criteria that actually separate tools

Within a class, feature checklists are a poor discriminator because everyone claims the same features. These seven questions produce answers that differ.

| Criterion | Why it matters | Ask the vendor |
| --- | --- | --- |
| Analysis depth | Feature-level counts beat dashboard counts for estimating | What does the analysis output look like, and can I see it before buying? |
| Coverage honesty | Known gaps are schedulable; unknown gaps surface in user testing | Which Tableau features do you not convert, by name? |
| Pricing unit | Per dashboard, per workbook credit and per seat produce different bills | What exactly counts as one billable unit? |
| Validation story | A converted artifact is not a verified one | Who reconciles the numbers, and against what? |
| Deployment | Publishing hundreds of items by hand is real work | Do you deploy into [workspaces](https://learn.microsoft.com/en-us/power-bi/collaborate-share/service-create-the-new-workspaces), or hand over files? |
| Data access | Metadata-only access is a far shorter security review | What is read, and does anything leave our tenant? |
| Lock-in | Output you cannot edit without the vendor is a liability | Is the output native, editable Power BI content? |

On deployment, the useful detail is what the tool writes: [Power BI Project (PBIP)](https://learn.microsoft.com/en-us/power-bi/developer/projects/projects-overview) folders are plain text, source-control friendly and currently a preview feature, and every PBIP deployment path except publishing from Desktop moves metadata only. That is a genuine advantage if you intend to use [deployment pipelines](https://learn.microsoft.com/en-us/fabric/cicd/deployment-pipelines/intro-to-deployment-pipelines), and irrelevant if you plan to publish straight into production.

On data access, the question is narrower than it sounds. Both platforms expose enough through metadata interfaces to do the job: Tableau through its [Metadata API](https://help.tableau.com/current/api/metadata_api/en-us/index.html), Power BI through its [REST API](https://learn.microsoft.com/en-us/rest/api/power-bi/) and [tenant settings](https://learn.microsoft.com/en-us/fabric/admin/tenant-settings-index). A vendor that needs more than metadata should be able to say precisely why.

## Red flags

A claim of complete automation is the clearest one. [Sets and set actions](https://getantares.io/tableau-sets-to-dax-measures/) have no stored equivalent in Power BI, and custom extensions live in a different marketplace with a different API, so a vendor claiming to convert everything either has not met those features or is not counting them.

The second is a coverage percentage offered without a feature breakdown. Effort concentrates in the small share of features that do not map, so two estates with identical headline coverage can differ by weeks of work. The third is a process where analysis only happens after a contract, which asks you to commit budget before scope exists. Microsoft's own guidance puts [gathering requirements and prioritizing](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-requirements) as stage one and a [proof of concept](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-proof-of-concept) as stage three, both before content creation.

## Matching a class to your situation

Small estate, strong internal DAX skills, no deadline pressure: in-house, with a free analysis tool to decide what not to migrate. Large estate, capable team, hard renewal date: a converter, with the team on review and validation. No BI team at all, or a program with regulatory reporting and change management for hundreds of users: services, ideally a partner who brings tooling rather than only people. For a like-for-like look at the automation and manual paths, see [automated versus manual migration](https://getantares.io/automated-vs-manual-tableau-migration/); for the services decision specifically, [consultant versus tool](https://getantares.io/tableau-migration-consultant-vs-tool/).

## What Antares does, and where it does not fit

Antares is a BI migration tool that spans the first two classes. The Analyzer is deterministic and free, so the scoping output exists before any purchase decision. The Converter produces a Power BI report page per source Tableau dashboard and deploys it, at a flat $200 per source dashboard, with no per-user licensing and no time limits. Only metadata is read, never business data. LLM usage sits outside the flat fee, typically under $20 per dashboard, billed by your own provider, and conversion can be pointed at your own private endpoints. The pipeline is deterministic-first with guardrailed, validated AI steps.

Against this rubric it is honest to say where it does not fit. Antares does not sell delivery accountability, does not manage your change program, and does not promise pixel-perfect output, because like-for-like conversion between platforms with different rendering engines cannot deliver that. If you need a team to own the outcome end to end, look at [delivery partners](https://getantares.io/partners/) or a services vendor. [Run the free Analyzer](https://try.getantares.io) if you want the scope numbers first.

Related reading: the [Tableau to Power BI migration guide](https://getantares.io/tableau-to-power-bi-migration/), [what a conversion tool converts](https://getantares.io/tableau-to-power-bi-conversion-tool/), and the [named options on the market](https://getantares.io/best-tableau-to-power-bi-migration-tool/). Primary source: Microsoft's [Power BI migration series](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-overview).

## Related resources

- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [Best Tableau to Power BI Migration Tools](https://getantares.io/best-tableau-to-power-bi-migration-tool/)
- [What a Conversion Tool Converts](https://getantares.io/tableau-to-power-bi-conversion-tool/)
- [Consultant vs Migration Tool](https://getantares.io/tableau-migration-consultant-vs-tool/)

## FAQ

### How do you compare Tableau to Power BI migration tools?

Classify before you compare. Analyzers measure the estate, converters produce artifacts, accelerators come bundled inside a services engagement, and in-house rebuilding is the fourth option. Comparing across classes on features is a category error, because each class buys down a different risk.

### What should you ask a migration tool vendor?

Seven questions: how deep the analysis goes and whether you can see it before buying, which Tableau features they do not convert by name, what counts as one billable unit, who reconciles the numbers, whether they deploy into workspaces, what data they read, and whether the output is native editable Power BI content.

### What are the red flags in a migration tool evaluation?

A claim of complete automation, since sets, set actions and custom extensions have no mechanical target. A coverage percentage with no feature breakdown, since effort concentrates in the features that do not map. And a process where analysis only starts after a contract, which asks for budget before scope exists.

### Is a services accelerator better than a self-serve tool?

They answer different questions. A services engagement buys accountability for the outcome, including change management and training, at day rates. A self-serve tool buys execution capacity for a team you already have, at a per-unit fee. Programs with a capable BI team and a deadline usually want the second.

---

## Best Tableau to Power BI Migration Tools in 2026: Seven Options Compared

Canonical: https://getantares.io/best-tableau-to-power-bi-migration-tool/
Published: 2026-02-18
Updated: 2026-08-06

The best Tableau to Power BI migration tool depends on which of two things you are buying: self-serve execution capacity for your own team, or a services offering that takes accountability for the outcome. The options that cover the field today are Antares, BiChart, USEReady MigratorIQ, Kanerika FLIP, Sparity BIPort, DataTerrain, and rebuilding in-house. Antares publishes this page; competitor facts come from each vendor's public site, linked at every claim.

| Option | Category | Public pricing | Free analysis | Best for |
| --- | --- | --- | --- | --- |
| Antares | Self-serve tool | Flat $200 per source dashboard | Yes, free Analyzer | Teams with review capacity and a per-unit budget |
| BiChart | Self-serve tool | Quoted; credits by volume tier | Yes, free assessment | Tableau-only estates heading to Fabric |
| USEReady MigratorIQ | Platform plus services | Not published | Yes, free assessment | Multi-source legacy consolidation |
| Kanerika FLIP | Accelerator plus services | Not published | ROI calculator and consultation | Azure-committed organizations |
| Sparity BIPort | Accelerator plus services | Not published | Yes, free migration analysis | Accelerator work run by its vendor |
| DataTerrain | Services | Not published | Yes, free proof of concept | Mixed legacy reporting estates |
| In-house rebuild | Your team | Your team's time | Not applicable | Small estates with existing DAX skills |

## Antares

A self-serve BI migration tool in two parts. The Analyzer connects to the source environment and returns an inventory with complexity and feature usage; it is deterministic and free, so scoping happens before any spend. The Converter turns one source Tableau dashboard into a Power BI report page and deploys it, at a flat $200 per source dashboard with no per-user licensing and no time limits. LLM costs sit outside that fee, are typically under $20 per dashboard paid to your own provider, and private endpoints are supported. Only metadata is read. Targets today are Power BI, including deployment to Fabric, and [Databricks AI/BI](https://www.databricks.com/product/business-intelligence), where one source dashboard becomes one [Databricks dashboard](https://docs.databricks.com/aws/en/dashboards/).

Strengths: published per-dashboard price, a free analysis you can run before deciding anything, metadata-only access, and a deterministic-first pipeline with guardrailed, validated AI steps rather than a single model pass. Not ideal if you need pixel-perfect reproduction, which no cross-platform conversion delivers; if you want an outside team to own delivery and change management, which is what [delivery partners](https://getantares.io/partners/) are for; or if your source platform is not Tableau today. It is also a new product without a public reference list, which is a fair objection; the answer offered is a free Analyzer run and a sample conversion rather than a case study.

## BiChart

[BiChart](https://bichart.ai/) positions itself as an AI-powered BI migration platform for Tableau to Power BI and Microsoft Fabric. Its documentation states support for Tableau 2023 and greater, output in [PBIP format](https://learn.microsoft.com/en-us/power-bi/developer/projects/projects-overview) for the Power BI Service, and conversion of workbook metadata including fields, measures, calculated fields and relationships. It offers a free Tableau to Power BI migration assessment. Its [pricing page](https://bichart.ai/pricing) describes an annual subscription based on migration credits, where one credit represents one Tableau workbook, priced by volume tier, with no numeric price published.

Strengths: a single well-defined corridor, a free assessment before purchase, and public [documentation](https://bichart.ai/docs) that states its own limits, including that it does not migrate underlying data and does not perform automated testing or validation. Best for teams standardizing on Fabric who are comfortable with an annual subscription and counting work in workbooks rather than dashboards.

## USEReady MigratorIQ

[MigratorIQ](https://www.useready.com/services/migrator-iq) is an agent-based migration platform from an established analytics services firm. It names five agents covering discovery and assessment, migration, semantic layer intelligence, trust and validation, and enterprise compatibility. Documented sources span Cognos, MicroStrategy, Qlik, Domo, Looker, BusinessObjects, Tableau Server, ThoughtSpot, Oracle BI and Hyperion; documented targets are Amazon QuickSight, Tableau Cloud and Power BI. A free assessment is offered and agents are available through AWS Marketplace. Pricing is not published.

Strengths: the broadest published source coverage of anything on this list, an explicit validation agent, and a services organization behind it. Best for estates where Tableau is one of several platforms being consolidated, rather than a Tableau-only move.

## Kanerika FLIP

[Kanerika](https://kanerika.com/services/migration/tableau-to-power-bi/) is a consulting firm whose Tableau to Power BI page is built around FLIP, its proprietary migration accelerator, which the page states automates 80% of the conversion work across dashboards, data models and calculated fields. The accelerators are listed on Azure Marketplace and described as eligible for Azure committed spend. Engagements start from an ROI calculator and a consultation; pricing is not published.

Strengths: the Azure commitment route is a genuine budget advantage for Microsoft-committed organizations, and the offering covers several migration corridors beyond Tableau. Best for buyers who want the migration delivered rather than run in-house and who have existing Microsoft spend to draw down.

## Sparity BIPort

[BIPort](https://www.sparity.com/accelerators/tableau-to-power-bi-migration-accelerator/) is a migration accelerator from the services firm Sparity. Its page describes automated conversion of Tableau workbooks (.twb, .twbx) and data sources (.tds), with LOD expressions and calculations translated into native DAX, and offers a free demo and a migration analysis report for your own workbooks alongside a cost calculator. Pricing is not published, and the accelerator sits inside Sparity's migration services rather than being sold as a standalone purchase.

Strengths: published detail on which Tableau artifacts the conversion covers, and an analysis report that shows results on your own workbooks before any commitment. Best for teams that want accelerator tooling with the vendor's own services team running it.

## DataTerrain

[DataTerrain](https://dataterrain.com/) is a services company built around automated BI report conversion using proprietary automation tools. Its site describes a framework running from legacy reports through automation, best practices, quality assurance and business-user review to deployment, and states 400+ customers in the USA and 27,000+ BI reports and dashboards built. Its FAQ offers a free proof of concept converting a representative sample of real reports, and describes fixed-cost migration; no prices are published.

Strengths: long experience with older reporting estates such as Crystal Reports, Cognos, OBIEE and Jasper, and a no-cost proof of concept that lets you judge output quality before committing. Best for mixed legacy estates where Tableau is one source among several.

## Rebuilding in-house

The option nobody sells you. No license spend, complete control over the result, and the team finishes with real Power BI skills instead of a delivered artifact they did not build. It works when the estate is small enough that per-dashboard effort never compounds into a schedule problem, and when someone already knows DAX and dimensional modeling well enough to make the [LOD](https://getantares.io/tableau-lod-expressions-to-dax/) and [table calculation](https://getantares.io/tableau-table-calculations-to-dax/) decisions correctly.

In-house rebuilds fail on consistency, not capability. Consistency degrades with headcount: the same measure ends up written three different ways, and the divergence surfaces as maintenance cost after the project is declared finished. Best for a few dozen dashboards, or for estates where a redesign was wanted anyway, in which case it is a rebuild rather than a migration.

## How to choose

Decide what you are buying before comparing features: execution capacity for a team you already have, or accountability for the whole program. That single question removes most of the list. Then apply the evaluation criteria in the [migration tool comparison rubric](https://getantares.io/tableau-vs-power-bi-migration-tools/), which covers analysis depth, coverage honesty, pricing unit, validation, deployment and data access. If cost is the deciding factor, compare against the hand-rebuild baseline in [automated versus manual migration](https://getantares.io/automated-vs-manual-tableau-migration/), or price your own estate by complexity band in the [Tableau to Power BI migration cost calculator](https://getantares.io/tableau-to-power-bi-migration-cost-calculator/). [Run the free Analyzer](https://try.getantares.io) if you want your own numbers before any of these conversations.

Related reading: the [Tableau to Power BI migration guide](https://getantares.io/tableau-to-power-bi-migration/), [Antares as a BiChart alternative](https://getantares.io/bichart-alternative-tableau-migration/), and [consultant versus tool](https://getantares.io/tableau-migration-consultant-vs-tool/).

## Related resources

- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [How to Compare Migration Tools](https://getantares.io/tableau-vs-power-bi-migration-tools/)
- [Antares as a BiChart Alternative](https://getantares.io/bichart-alternative-tableau-migration/)
- [Automated vs Manual Migration](https://getantares.io/automated-vs-manual-tableau-migration/)

## FAQ

### What is the best Tableau to Power BI migration tool?

It depends on whether you are buying execution capacity or delivery accountability. Self-serve tools such as Antares and BiChart give an existing BI team throughput. USEReady, Kanerika, Sparity and DataTerrain wrap tooling in a services engagement. For a few dozen dashboards with in-house DAX skills, rebuilding directly is still reasonable.

### Which Tableau migration tools publish their pricing?

Of the options here, only Antares publishes a number: a flat $200 per source dashboard, with the Analyzer free. BiChart describes an annual subscription based on migration credits, one credit per Tableau workbook, priced by volume tier without published figures. USEReady, Kanerika, Sparity and DataTerrain quote on request.

### Which migration tools offer a free assessment?

Antares offers a free Analyzer run over the source environment. BiChart offers a free Tableau to Power BI migration assessment. USEReady offers a free assessment through its discovery agent. DataTerrain offers a free proof of concept on a sample of real reports, and Sparity BIPort a free demo with a migration analysis report. Kanerika starts from an ROI calculator and a consultation.

### When is rebuilding in Power BI by hand the better choice?

When the estate is small enough that per-dashboard effort never becomes a schedule problem, someone on the team already knows DAX and dimensional modeling, and no license renewal is forcing a date. It is also the right call when a redesign was wanted anyway, since that is a rebuild rather than a migration.

---

## Automated vs Manual Tableau Migration: Cost, Timeline, and Where Each One Wins

Canonical: https://getantares.io/automated-vs-manual-tableau-migration/
Published: 2026-02-18
Updated: 2026-08-06

At estate scale, automated Tableau migration is usually the cheaper path, and manual effort survives in two places: validation, and the features with no Power BI counterpart. Every project of any size ends up doing both, so the working question is what share of the work automation removes. Automation absorbs the repetitive translation of visuals, fields and calculations. Manual effort concentrates in validation and in the features that have no target, and that concentration is what decides the budget.

## Where the money actually goes

A hand rebuild spends its hours on three things: reproducing each visual, rewriting each calculation, and reconciling the result. Only the third survives automation. That is why the comparison below is uneven by row rather than uniformly favoring one column.

| Criterion | Automated | Manual |
| --- | --- | --- |
| Cost shape | Per-unit fee plus review time | Hours times a blended rate, per dashboard |
| Timeline | Compresses with estate size | Scales linearly with dashboard count |
| Consistency across dashboards | Same pattern produces the same output every time | Varies by developer and by week |
| Redesign opportunity | None; conversion is like-for-like | Full, at full cost |
| Skills required | Review-level DAX and modeling | Author-level DAX and modeling |
| Main risk | Silent context differences in converted measures | Schedule slip and inconsistent output |
| What remains afterwards | Content, plus a repeatable process | Content, plus deeper team expertise |

## A worked example, with its assumptions visible

Numbers only mean something with their assumptions attached, so here are the ones behind the [cost calculator on this site](https://getantares.io/tableau-to-power-bi-migration-cost-calculator/): a hand rebuild takes 80 hours per dashboard end to end, the blended internal rate is $85 per hour, and roughly a tenth of that effort remains as review after automation. All three are adjustable defaults, not measurements of your estate.

On those defaults, one dashboard rebuilt by hand costs about $6,800 in team time. The same dashboard through a converter costs the $200 flat fee, under $20 in LLM usage paid to your own provider, and about eight hours of review, roughly $900 in total. The ratio, not the absolute figure, is the useful output, and it moves sharply with complexity: a dashboard built from standard charts beats that ratio comfortably, while one carrying [set actions](https://getantares.io/tableau-sets-to-dax-measures/) and a custom extension can consume most of its original estimate in redesign regardless of tooling.

Two costs are easy to leave out of both columns. Validation happens either way and is not compressible by much, since somebody who knows the original still has to confirm the numbers. And Microsoft's own migration guidance treats [requirements gathering](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-requirements) and a [proof of concept](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-proof-of-concept) as stages of their own, before content is created at all.

## When manual is the cheaper option

Three situations are worth checking before you price anything. A small estate is the clearest: below roughly a few dozen dashboards, per-unit fees and the effort of onboarding a tool are a meaningful share of the project, and a capable team can simply do the work.

An estate that should shrink rather than move is another. If half the published dashboards are duplicates or abandoned, the cheapest migration is the one you decline to perform, and that decision needs an inventory rather than a converter.

The last is a redesign that was wanted anyway. Rebuilding is expensive because it is design work, and design work does not automate: someone has to decide what the report should say. Mind the label, though. A rebuild is not a migration, it cannot be validated against the original, and it should be budgeted and scheduled as new development. Mixing the two in one pass is how migrations lose their acceptance criteria.

One constraint overrides all three, and it is the reason most estates end up automating anyway: a license renewal date. Manual rebuilding scales linearly with dashboard count, so a fixed deadline converts directly into a headcount requirement. If the arithmetic says your team cannot finish in the time available, the choice is not between approaches but between automating and paying for another renewal year.

## Hybrid is what actually happens

At estate scale the split is not a choice so much as an observation. Standard content converts, [LOD expressions](https://getantares.io/tableau-lod-expressions-to-dax/) and [table calculations](https://getantares.io/tableau-table-calculations-to-dax/) convert and then get reviewed, and sets, set actions and extensions are rebuilt by hand. A sensible plan names which bucket each dashboard falls into before work starts, then schedules the manual bucket as its own workstream with its own estimate rather than letting it hide inside a coverage percentage.

The sequencing that follows from this is covered in the [six-step migration process](https://getantares.io/migrate-tableau-dashboards-to-power-bi/). If the decision in front of you is whether to bring in outside help at all rather than which tool to use, see [consultant versus tool](https://getantares.io/tableau-migration-consultant-vs-tool/).

## What Antares does

Antares is a BI migration tool priced to make this arithmetic simple. The Analyzer is deterministic, free, and reads only metadata, so the inventory and complexity scoring that decide what not to migrate cost nothing. The Converter is a flat $200 per source Tableau dashboard, with no per-user licensing and no time limits, which means the per-unit column above is a number you can multiply rather than a quote you have to negotiate. LLM usage is billed by your own provider, typically under $20 per dashboard, and private endpoints are supported.

The claim attached to it is 90% less manual work in Antares conversions, which is the same tenth-remaining assumption the calculator above uses. It is a product claim with a stated assumption, not an industry constant, and the way to test it is on your own estate. [Run the free Analyzer](https://try.getantares.io), or try a sample conversion, before putting a number in a business case.

Related reading: the [Tableau to Power BI migration guide](https://getantares.io/tableau-to-power-bi-migration/) and [what converts and what breaks](https://getantares.io/tableau-to-power-bi-automated-migration/). Primary sources: Microsoft on [creating and validating migrated content](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-create-validate-content) and the [migration series overview](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-overview), Tableau on [set actions](https://help.tableau.com/current/pro/desktop/en-us/actions_sets.htm) and [LOD expressions](https://help.tableau.com/current/pro/desktop/en-us/calculations_calculatedfields_lod.htm), and the [DAX function reference](https://learn.microsoft.com/en-us/dax/dax-function-reference) plus Microsoft's [star schema guidance](https://learn.microsoft.com/en-us/power-bi/guidance/star-schema) for the modeling work a rebuild implies.

## Related resources

- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [Automated Migration: What Converts](https://getantares.io/tableau-to-power-bi-automated-migration/)
- [Migration Cost Calculator](https://getantares.io/tableau-to-power-bi-migration-cost-calculator/)
- [Consultant vs Migration Tool](https://getantares.io/tableau-migration-consultant-vs-tool/)

## FAQ

### Is automated Tableau migration cheaper than rebuilding by hand?

Usually at estate scale, and the ratio matters more than the figure. On this site's calculator defaults of 80 hours per dashboard at an $85 blended rate, a hand rebuild is roughly $6,800 per dashboard against about $900 for a $200 conversion plus review. Change either input and the ratio moves; treat it as a model, not a quote.

### When is manual Tableau migration the better option?

Three cases: a small estate where per-unit fees and tool onboarding are a large share of the project, an estate that should mostly be retired rather than moved, and a project where a redesign was wanted anyway. The third is a rebuild rather than a migration and should be budgeted as new development.

### Does automation remove the validation work?

No. Validation is the least compressible part of either approach, because someone who knows the original still has to confirm the numbers and the interactions. What automation changes is where review starts: with the items a tool has flagged as ambiguous, rather than with every measure on every page.

### What does a hybrid Tableau migration look like in practice?

Standard visuals, fields and row-level calculations convert. LOD expressions and table calculations convert and are then reviewed for context. Sets, set actions and custom extensions are rebuilt by hand. Naming which bucket each dashboard falls into before work starts is what keeps the manual share from hiding inside a coverage percentage.

---

## Tableau Migration Consultant vs Migration Tool: Choosing an Operating Model

Canonical: https://getantares.io/tableau-migration-consultant-vs-tool/
Published: 2026-02-18
Updated: 2026-08-06

Choosing between a Tableau migration consultant and a migration tool is not a procurement question about software. It is a choice of operating model, and the variable underneath it is accountability: whether an outside party owns the outcome, or your team owns it with better instruments. Consultants sell delivery. Tools sell capacity. The third option, a partner who brings a tool, sells both and is what most large programs end up with.

## What each option actually sells

Comparing day rates against per-unit fees produces a misleading answer, because the two are not buying the same thing. Compare on what changes hands instead.

| Dimension | Consultant | Tool | Partner with a tool |
| --- | --- | --- | --- |
| Cost model | Day rates or fixed bid | Per-unit fee plus your review time | Reduced day rates plus per-unit fees |
| Who is accountable | The vendor, contractually | Your team | The partner, with tooling risk removed |
| Load on your team | Low during delivery, high at handover | High throughout | Moderate and scheduled |
| Target-platform expertise | Rented | Required | Rented, with transfer planned |
| Change management | Usually included | Not included | Usually included |
| What remains after | Content and documentation | Content, skills and a repeatable process | Content, plus whatever the statement of work transfers |

## When a consultant is the right call

Three situations justify the premium without much argument. The first is no team: if there is nobody who can review a converted measure and say whether it is right, a tool has nothing to accelerate. The second is a regulated reporting estate, where sign-off, traceability and evidence of testing are contractual obligations rather than good practice, and somebody has to carry that risk professionally.

The third is change management at scale. Microsoft's own migration guidance lists training, support and a transparent communication plan among the practices that separate successful migrations, and treats [executive sponsorship](https://learn.microsoft.com/en-us/power-bi/guidance/fabric-adoption-roadmap-executive-sponsorship) and [user enablement](https://learn.microsoft.com/en-us/power-bi/guidance/fabric-adoption-roadmap-mentoring-and-user-enablement) as first-class workstreams. Moving several hundred report consumers onto a different interaction model is an organizational project that converted artifacts do not address.

## When a tool is enough

The mirror image. You have BI people who already write DAX and model data, the target tenant exists, and the constraint is throughput against a renewal date rather than expertise. In that case a services engagement is an expensive answer to a scheduling problem, and it introduces a handover that a self-run project never has to survive.

The competence bar is lower than authoring but not trivial. Reviewers need to judge whether a converted [LOD expression](https://getantares.io/tableau-lod-expressions-to-dax/) respects the right filter context, and whether a [table calculation](https://getantares.io/tableau-table-calculations-to-dax/) was restated correctly. If that describes at least one person on your team, the tool path is open.

## The third option: a partner who brings a tool

These are not opposites, and the strongest arrangement on large programs is usually both. The systems integrator owns delivery, scoping, testing and enablement. The tool removes the mechanical translation, so the consultant's hours go into the parts that need judgment rather than into rebuilding bar charts at a day rate. The commercial effect is that the same budget buys more of the work you actually wanted.

It also changes what the engagement leaves behind. When a partner delivers using a tool your organization can keep using, the second wave of dashboards does not require a second engagement. Ask for that explicitly in the statement of work; it is rarely offered unprompted.

## How to read a proposal

Whichever model you choose, the same three questions separate a proposal you can hold someone to from one you cannot. What is the unit of work, and does the price move when the estate turns out to be larger or messier than the sample? A fixed bid written against an unmeasured estate is a change order waiting to be raised, which is the practical argument for running an inventory before the proposal, not after it.

Second, what does acceptance mean? Converted content and validated content are different deliverables, and the difference is usually several weeks. Ask which measures get reconciled, against what, and who signs. Third, what transfers at handover? Documentation of the target model, the workspace and security design, and the ability to run the next wave without the vendor are worth negotiating for explicitly, because none of them appear by default.

## What stays with you either way

Some decisions cannot be outsourced because they are statements about how your organization runs. [Workspace structure](https://learn.microsoft.com/en-us/power-bi/collaborate-share/service-create-the-new-workspaces), [row-level security](https://learn.microsoft.com/en-us/fabric/security/service-admin-row-level-security) roles, [tenant settings](https://learn.microsoft.com/en-us/fabric/admin/tenant-settings-index), refresh windows and whether you use [deployment pipelines](https://learn.microsoft.com/en-us/fabric/cicd/deployment-pipelines/intro-to-deployment-pipelines) are governance choices you live with afterwards. A consultant can recommend them and a tool can populate them, but the ownership does not transfer. Microsoft's [center of excellence guidance](https://learn.microsoft.com/en-us/power-bi/guidance/center-of-excellence-establish) and its [implementation planning series](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-implementation-planning-introduction) cover the shape of that responsibility.

## What Antares does

Antares is a BI migration tool, not a services firm, and it is priced to sit inside either model. The Analyzer is deterministic, free and metadata-only, which makes it useful during evaluation itself: running it before you brief a consultant means the scope in the proposal is measured rather than assumed. The Converter is a flat $200 per source Tableau dashboard, with no per-user licensing and no time limits, so the tooling line in a delivery budget is a multiplication rather than a negotiation. LLM usage is billed by your own provider, typically under $20 per dashboard, with private endpoints supported.

For organizations that want delivery accountability, Antares works through [systems integrator partners](https://getantares.io/partners/) who run the project and use the tool inside it. That is the third column above, and it is the right answer when the question is really about who carries the risk. [Run the free Analyzer](https://try.getantares.io) first either way, because every one of these conversations goes better with an inventory in hand.

Related reading: the [Tableau to Power BI migration guide](https://getantares.io/tableau-to-power-bi-migration/), [automated versus manual economics](https://getantares.io/automated-vs-manual-tableau-migration/), and [how to compare migration tools](https://getantares.io/tableau-vs-power-bi-migration-tools/). Primary source: Microsoft's [Power BI migration series](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-overview) and its [deploy, support and monitor stage](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-deploy-support-monitor).

## Related resources

- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [Automated vs Manual Migration](https://getantares.io/automated-vs-manual-tableau-migration/)
- [How to Compare Migration Tools](https://getantares.io/tableau-vs-power-bi-migration-tools/)
- [Six-Step Dashboard Migration Process](https://getantares.io/migrate-tableau-dashboards-to-power-bi/)

## FAQ

### Should we hire a consultant or buy a Tableau migration tool?

It depends on who should be accountable for the outcome. Hire a consultant when there is no internal team to review converted content, when the estate is regulated and needs professional sign-off, or when change management for hundreds of users is the real work. Buy a tool when you have BI people and the constraint is throughput.

### Who is responsible for quality if we use a tool?

Your team, which is the trade for the lower cost. A tool can narrow where review starts by flagging ambiguous mappings rather than guessing at them, but reconciling numbers against the Tableau original and confirming interactions stays an internal task. With a services engagement, that responsibility is contractual instead.

### Can a consultant use our migration tool?

Yes, and on large programs that is usually the strongest arrangement. The integrator owns delivery, scoping and enablement while the tool removes the mechanical translation, so consultant hours go into the parts that need judgment. Ask for it explicitly in the statement of work.

### What happens after the migration project ends?

Governance stays with you either way: workspace structure, row-level security, tenant settings, refresh windows and deployment pipelines are choices you live with. A tool your organization keeps also means the next wave of dashboards does not require a second engagement, which a pure services project rarely leaves behind.

---

## Antares as a BiChart Alternative for Tableau to Power BI Migration

Canonical: https://getantares.io/bichart-alternative-tableau-migration/
Published: 2026-02-18
Updated: 2026-08-06

Antares and [BiChart](https://bichart.ai/) both automate Tableau to Power BI migration. Three differences decide most comparisons: Antares bills per source dashboard where BiChart bills per Tableau workbook credit, Antares also targets Databricks AI/BI, and Antares publishes a flat price where BiChart quotes an annual subscription. Everything below comes from what each vendor publishes today.

## Why teams look for a BiChart alternative

The reasons are usually structural rather than complaints. Billing in workbook credits and billing per dashboard behave differently depending on your estate: a workbook holding six dashboards is one credit and six units respectively, so estates with dense workbooks and estates with one dashboard per workbook reach opposite conclusions. Count both ways before comparing anything else.

Procurement shape is another reason. BiChart's [pricing page](https://bichart.ai/pricing) describes an annual subscription based on migration credits priced by volume tier, quoted rather than listed. Some organizations prefer that; teams migrating a known number of dashboards once, without an annual commitment, generally prefer a published per-unit price. Scope closes the list: if the target is Databricks AI/BI rather than Power BI, BiChart's [documentation](https://bichart.ai/docs) states it supports Tableau to Power BI only.

## Side by side, on published facts

| Dimension | Antares | BiChart |
| --- | --- | --- |
| Category | BI migration tool: analysis plus conversion | AI-powered BI migration platform |
| Source | Tableau | Tableau, documented as 2023 and greater |
| Targets | Power BI including Fabric deployment, and [Databricks AI/BI](https://www.databricks.com/product/business-intelligence) | Power BI and Microsoft Fabric |
| Output | Report pages deployed to the target | [PBIP](https://learn.microsoft.com/en-us/power-bi/developer/projects/projects-overview) download, optional publish to Fabric |
| Billing unit | One source dashboard | One migration credit, stated as one workbook |
| Published price | Flat $200 per source dashboard | Quoted; volume tiers, annual subscription |
| Free analysis | Analyzer, deterministic and free | Free Tableau to Power BI migration assessment |
| Data accessed | Metadata only, private LLM endpoints supported | States it does not migrate underlying data or handle credentials |
| Validation | Ambiguous mappings flagged for review | States it does not perform automated testing or validation |

## What BiChart does well

Its published [knowledge base](https://bichart.ai/knowledge) of Tableau expression and function documentation, covering FIXED and EXCLUDE expressions, RUNNING_SUM, RANK, REGEXP_MATCH and conditional logic alongside their Power BI counterparts, is a genuinely useful public resource whether or not you buy anything. Its documentation is also unusually direct about its own limits.

The offering is focused on one corridor, Tableau into Power BI and Fabric, and a focused product is a reasonable thing to want. The site also lists SOC 2 certification and Azure Marketplace partnership, both of which matter if procurement gates on attestations or on marketplace purchasing.

## Where Antares differs

The Analyzer is deterministic, with no model involved, and free; it produces the inventory, complexity scoring and feature usage that decide which dashboards are worth migrating at all. The Converter is a flat $200 per source dashboard with no per-user licensing and no time limits, published rather than quoted. LLM usage sits outside the fee, typically under $20 per dashboard billed by your own provider, and conversion can be pointed at your private endpoints. Only metadata is read.

Technically, the pipeline is deterministic-first with guardrailed, validated AI steps rather than a single model pass, and the operating rule at the boundary is that an ambiguous mapping is flagged rather than guessed. Deployment into the target is part of conversion. The target list also includes [Databricks AI/BI dashboards](https://docs.databricks.com/aws/en/dashboards/), which matters only if that is where your organization is going.

What Antares does not offer: pixel-perfect reproduction, which no cross-platform conversion delivers because rendering engines differ; a public reference list, since it is a new product; and white-glove delivery, for which see [systems integrator partners](https://getantares.io/partners/).

Antares converts the dashboard layer and the semantic model behind it; it is not a data migration tool, so nothing changes in the warehouse or lake, and source data quality issues visible on the Tableau original will be visible on the converted report page. That is a property of like-for-like conversion generally, not a gap specific to either vendor.

## Who should stay with BiChart

If your estate is measured in workbooks that each contain several dashboards, credit-based billing may map onto it more cheaply than per-dashboard billing, and the arithmetic is worth doing before anything else. If an annual subscription with a support commitment suits your procurement better than transactional per-unit spend, that is a legitimate preference rather than a compromise. If SOC 2 attestation or Azure Marketplace purchasing is a hard procurement gate today, BiChart lists both; the Antares answer to a security review is metadata-only access and the option to run inside your own environment with private LLM endpoints.

None of those are weaknesses in the alternative; they are differences in how two products are packaged. The mistake to avoid is choosing on the surface of the pricing page rather than on what the pricing page multiplies against in your estate.

## How to compare them on your own estate

Both offer a free assessment, so the comparison does not have to be theoretical. Run both against the same source site, then compare four things: the dashboard and workbook counts each one reports, how each describes the features it will not convert, what the resulting unit price works out to for your specific mix, and what the output looks like when opened in Power BI Desktop. The evaluation criteria in the [migration tool rubric](https://getantares.io/tableau-vs-power-bi-migration-tools/) cover the rest, and the wider field is in the [list of options](https://getantares.io/best-tableau-to-power-bi-migration-tool/).

[Run the free Analyzer](https://try.getantares.io) or try a sample conversion without signing up. Related reading: the [Tableau to Power BI migration guide](https://getantares.io/tableau-to-power-bi-migration/) and [what converts and what breaks](https://getantares.io/tableau-to-power-bi-automated-migration/). Primary sources: BiChart's [Tableau to Power BI page](https://bichart.ai/tableau-to-power-bi) and Microsoft's [migration guidance](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-overview).

## Related resources

- [Best Tableau to Power BI Migration Tools](https://getantares.io/best-tableau-to-power-bi-migration-tool/)
- [How to Compare Migration Tools](https://getantares.io/tableau-vs-power-bi-migration-tools/)
- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [Automated Migration: What Converts](https://getantares.io/tableau-to-power-bi-automated-migration/)

## FAQ

### What is the main difference between Antares and BiChart?

The billing unit and the target list. Antares charges a published flat $200 per source Tableau dashboard; BiChart's pricing page describes an annual subscription of migration credits, one credit per Tableau workbook, quoted by volume tier. Antares also targets Databricks AI/BI, while BiChart's documentation covers Tableau to Power BI and Fabric.

### Does BiChart or Antares include a free analysis?

Both. BiChart offers a free Tableau to Power BI migration assessment of your inventory. Antares offers the Analyzer free: a deterministic pass over the source environment returning inventory, complexity and feature usage. Running both against the same site is the cheapest way to compare them.

### Which is better for a Tableau to Fabric migration?

Both convert Tableau into Power BI content that deploys to Fabric. BiChart's documentation describes PBIP output with optional publishing to Fabric; Antares deploys report pages to the target as part of conversion. The deciding factors are usually the billing unit against your workbook and dashboard counts, and procurement preferences.

### When should a team stay with BiChart?

When workbooks in the estate each hold several dashboards, so credit-based billing may map onto it more cheaply. When an annual subscription with a support commitment suits procurement better than transactional per-unit spend. Or when SOC 2 attestation and Azure Marketplace purchasing are hard gates today.

---

## Tableau Server to Power BI Migration: Moving the Platform, Not Just the Content

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

Retiring Tableau Server moves three separate things into Power BI: content, access, and schedules. Only the first one is a conversion problem. Permissions get rebuilt against a different model, and every on-premises source the server used to reach from inside your network now needs an [on-premises data gateway](https://learn.microsoft.com/en-us/power-bi/connect-data/service-gateway-onprem) before a single refresh runs.

The report layer gets the attention because it is what people see. The platform layer is where dates slip. This page covers that layer: what each server object becomes, what has no counterpart, and which decisions belong before the first workbook is touched. Workbook mechanics are on [the migration guide](https://getantares.io/tableau-to-power-bi-migration/).

## What moves from Tableau Server and what does not

Power BI Service is tenant-wide SaaS, so objects you administered on your own hardware become settings inside someone else's. Most of the mapping is workable. The rows that cost time are the ones rebuilt by hand.

| Tableau Server | Power BI equivalent | What to watch |
| --- | --- | --- |
| Site | The tenant, separated by workspaces and capacities | A multi-site server collapses into one tenant; isolation comes from workspaces |
| [Project](https://help.tableau.com/current/server/en-us/projects.htm), including nested projects | [Workspace](https://learn.microsoft.com/en-us/power-bi/collaborate-share/service-create-the-new-workspaces) | Workspaces do not nest, so the tree is flattened and filing is separated from permissions |
| Permissions and server groups | Workspace roles plus app audiences | Four roles replace granular capability grants; Entra groups replace server groups |
| User filters | [RLS roles](https://learn.microsoft.com/en-us/fabric/security/service-admin-row-level-security) with DAX filters | Rebuilt, not translated; entitlement logic has to reach the semantic model |
| Extract refresh schedules | [Semantic model refresh](https://learn.microsoft.com/en-us/power-bi/connect-data/refresh-scheduled-refresh) | On-premises sources need the gateway, and daily refresh counts are capped by license |
| Subscriptions and data alerts | Report subscriptions and alerts | Recreated per report and per owner; nobody inherits somebody else's list |
| Promotion between projects | [Deployment pipelines](https://learn.microsoft.com/en-us/fabric/cicd/deployment-pipelines/intro-to-deployment-pipelines) | Real development, test and production stages, with rules that repoint sources per stage |
| [Administrative views](https://help.tableau.com/current/server/en-us/adminview.htm) | Usage metrics | Different measures, no history carried over; capture your usage baseline before decommissioning |
| Certified data sources | Endorsement: Promoted or Certified | Certification rights are granted separately, so decide who holds them before publishing starts |

The shorter list is more often forgotten. None of it converts.

| Does not move | Why |
| --- | --- |
| Server topology and configuration: nodes, processes, TSM settings, SSL and proxy setup | You no longer run the platform, so the settings have no destination |
| Custom administrative views built on the server repository | There is no repository database to query |
| [tabcmd](https://help.tableau.com/current/server/en-us/tabcmd.htm) and REST API automation | A different API surface entirely; rewriting is a workstream, not an afternoon |
| Schedules as reusable server objects | Refresh timing is configured per semantic model, not attached to a shared schedule |
| Historical view counts and usage statistics | Export what the prune decision needs while the server is still up |

## How on-premises data sources reach Power BI

This is the specific problem of leaving a server, and the one genuinely new component in the target architecture. Tableau Server sat inside your network and connected to databases directly. Power BI Service does not, so anything unreachable from the public cloud goes through a gateway in standard mode: a service installed on a machine inside the network, making outbound connections only, holding data source credentials centrally.

Three decisions follow: where it runs, since the host needs network access to every source and memory for concurrent refreshes; whether it is clustered, because one gateway is a single point of failure for every scheduled refresh in the tenant; and who administers it, since gateway and workspace administration are separate jobs in most organizations. Cloud-hosted sources need none of this.

## What happens to schedules and subscriptions

On your own server, refresh frequency was a hardware question. In Power BI it is a licensing one. Microsoft documents a maximum of 8 scheduled refreshes per day for a semantic model on Power BI Pro, and up to 48 per day with Premium Per User or a Premium or Fabric capacity, as of August 2026.

So sort the Tableau schedules by frequency before choosing a license; the hourly extracts decide the answer. Where a full reload will not fit the window, [incremental refresh](https://learn.microsoft.com/en-us/power-bi/connect-data/incremental-refresh-overview) is a design choice to plan for, not a fix to discover late. Subscriptions and alerts are recreated by hand, so give owners a deadline and a list.

## How to size the licensing change

Tableau Server charged for named users on infrastructure you also paid to run, patch and upgrade. Power BI charges per user or per capacity, and the hosting line disappears apart from the gateway host. Microsoft's public list prices are [$14.00 per user per month for Power BI Pro and $24.00 for Premium Per User](https://www.microsoft.com/en-us/power-platform/products/power-bi/pricing), billed yearly, as of August 2026. Capacity is priced separately, and [free-licensed users can only open shared content](https://learn.microsoft.com/en-us/power-bi/fundamentals/service-features-license-type) on a Fabric F64 or larger capacity, which is what makes a large read-only population affordable.

The sizing question is therefore not how many Tableau seats you had, but how many people author, how many only read, and whether the reader count justifies capacity over seats. Build it with the other budget lines on [migration cost estimation](https://getantares.io/tableau-migration-cost-estimation/), and re-read the pricing page the day you write the business case.

## If your Tableau is Tableau Cloud, not Server

Then most of this page does not apply: no server configuration to abandon, no administrative views to rebuild, no gateway at all when sources are cloud-hosted. Identical are the content conversion, the security rework, the validation effort, and the two-subscription overlap. That version is on [Tableau Cloud to Power BI](https://getantares.io/tableau-online-to-power-bi-migration/).

## What Antares does when the server goes away

Antares is a BI migration tool, and it addresses the content column of the three, not the platform column. The free **Analyzer** inventories what Tableau Server holds: which workbooks are still opened, which sources repeat, where user filters and blends live, and how complex each dashboard is to convert. It is deterministic, reads metadata only, never business data, runs inside your own environment, and changes nothing in the source.

The **Converter** turns each source Tableau dashboard into a Power BI report page for a flat $200, with no per-user licensing and no time limit; LLM costs go to your own provider at typically under $20 per dashboard, private endpoints supported. It runs deterministic-first with guardrailed, validated AI steps, and flags mappings it cannot resolve confidently instead of guessing. Conversion is like-to-like rather than pixel-perfect, and it is not a data migration tool: gateways, warehouses and network paths remain your work. [Run the free Analyzer](https://try.getantares.io) to get the content inventory before you plan the platform cutover.

Related reading: [enterprise scale](https://getantares.io/enterprise-tableau-migration-strategy/), [data sources to semantic models](https://getantares.io/tableau-data-sources-to-power-bi-datasets/) and [the Analyzer](https://getantares.io/analyzer/). Primary sources: Microsoft on [the on-premises data gateway](https://learn.microsoft.com/en-us/power-bi/connect-data/service-gateway-onprem) and [scheduled refresh](https://learn.microsoft.com/en-us/power-bi/connect-data/refresh-scheduled-refresh), plus Tableau on [projects](https://help.tableau.com/current/server/en-us/projects.htm).

## Related resources

- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [Tableau Cloud to Power BI Migration](https://getantares.io/tableau-online-to-power-bi-migration/)
- [Tableau to Microsoft Fabric Migration](https://getantares.io/tableau-to-microsoft-fabric-migration/)
- [Enterprise Tableau Migration Strategy](https://getantares.io/enterprise-tableau-migration-strategy/)

## FAQ

### Can Tableau Server permissions be migrated to Power BI automatically?

No. Tableau grants capabilities on projects, workbooks and data sources; Power BI grants four workspace roles plus app audiences, with row-level security handled separately in the semantic model. The structures do not correspond, so permissions are redesigned rather than copied. Export the current permission set as a requirements document, then map groups to Microsoft Entra groups before the first workspace exists.

### Do we need an on-premises data gateway if our data is already in the cloud?

No. Power BI connects to cloud-hosted sources directly, and a gateway in standard mode is only needed for sources unreachable from the public cloud. In practice most Tableau Server estates keep a few on-premises databases or file shares, so plan a gateway host anyway and decide early whether it is clustered.

### How many times a day can a Power BI semantic model refresh?

Microsoft documents up to 8 scheduled refreshes per day on a Power BI Pro license, and up to 48 per day with Premium Per User or a Premium or Fabric capacity, as of August 2026. Sort your Tableau schedules by frequency before choosing a license, and plan incremental refresh for models that will not reload fully inside the window.

### What happens to our tabcmd scripts and Tableau REST API automation?

They stop working, because the target platform exposes a different API surface. Treat the automation inventory as its own workstream: list what each script does, decide what is still needed, and rebuild against Power BI APIs. Publishing and promotion scripts often disappear entirely once deployment pipelines take over that job.

---

## Tableau Online to Power BI Migration: What Cloud-to-Cloud Really Saves

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

Tableau Online is now Tableau Cloud, as [Tableau's release notes state](https://help.tableau.com/current/online/en-us/whatsnew_online.htm). Moving from it to Power BI drops the infrastructure work entirely: no servers, no upgrades, no gateway for cloud-hosted sources. It changes nothing about three things: rebuilding every connection and its authorization, living inside refresh limits on both platforms, and paying two subscriptions until the last report is accepted.

Worth saying plainly, because cloud-to-cloud gets sold as the easy case and then surprises people at the same points. The content conversion is identical either way and lives on [the migration guide](https://getantares.io/tableau-to-power-bi-migration/). What follows is only what differs from [leaving Tableau Server](https://getantares.io/tableau-server-to-power-bi-migration/).

## What actually gets easier in a cloud-to-cloud migration

| Area | Cloud-to-cloud effect | Why |
| --- | --- | --- |
| Server infrastructure and upgrades | Gone | Neither platform is yours to run, so there is no decommissioning project and no final upgrade |
| Gateway for cloud-hosted sources | Not needed | Power BI reaches a cloud warehouse directly, as Tableau Cloud did |
| Capacity and sizing work | Reduced to a licensing decision | You pick per-user licenses or a capacity instead of sizing hardware |
| Dashboard conversion | Unchanged | Workbook logic is the same logic whatever hosted it |
| Row-level security | Unchanged | User filters become [RLS roles](https://learn.microsoft.com/en-us/fabric/security/service-admin-row-level-security) and are rebuilt by hand; the detail is on [the access-heavy version of this migration](https://getantares.io/tableau-to-power-bi-migration-financial-services/) |
| Validation and sign-off | Unchanged | Numbers are proved against a source of truth wherever either platform runs |
| Enablement and adoption | Unchanged | Users learn a different tool, not a different hosting model |

## How Tableau Cloud content maps to Power BI

Object mapping mostly matches the server case. Connections are where the cloud case has its own character, because a Tableau Cloud site holds authorizations rather than a network route, and authorizations do not transfer.

| Tableau Cloud | Power BI | Notes |
| --- | --- | --- |
| Site | Tenant, separated by workspaces | Several Tableau Cloud sites usually consolidate into workspaces and capacities |
| Project | [Workspace](https://learn.microsoft.com/en-us/power-bi/collaborate-share/service-create-the-new-workspaces) | Flat containers, so nested projects are flattened |
| Published data source | Shared semantic model | Several reports connect to one model, as several workbooks connected to one published source |
| Extract on a refresh schedule | Import model with [scheduled refresh](https://learn.microsoft.com/en-us/power-bi/connect-data/refresh-scheduled-refresh) | No file moves; both platforms cap how often it runs, and the caps are shaped differently |
| OAuth connection to a cloud source | A cloud connection authorized in Power BI | Tokens do not migrate; every Snowflake, Salesforce or BigQuery connection is authorized again, ideally by an account that still exists next year |
| [Tableau Bridge](https://help.tableau.com/current/online/en-us/to_bridge_client.htm) | [On-premises data gateway](https://learn.microsoft.com/en-us/power-bi/connect-data/service-gateway-onprem) | If Bridge is running anywhere, you do need a gateway, with the same design conversation as on the server page |
| Subscriptions | Report subscriptions | Recreated per report and per owner |
| Web authoring | Editing in the service, or Power BI Desktop | Authors who never installed Tableau Desktop will meet a desktop application for the first time |

On the caps: Tableau documents [Tableau Cloud extract capacity](https://help.tableau.com/current/online/en-us/to_site_capacity.htm) as up to 8 backgrounder hours per Creator license per site, with an individual refresh limited to 120 minutes, as of August 2026. Power BI counts runs instead of hours: up to 8 scheduled refreshes per day on Pro, up to 48 with Premium Per User or a capacity, also as of August 2026. A team used to trading long refreshes against each other has to re-plan around a count of runs, which usually means [incremental refresh](https://learn.microsoft.com/en-us/power-bi/connect-data/incremental-refresh-overview) for the largest models.

## How to get content out of Tableau Cloud

There is no file system to copy from, the practical difference in week one. Workbooks come out through the web interface one at a time, or through the [REST API](https://help.tableau.com/current/api/rest_api/en-us/REST/rest_api_ref_workbooks_and_views.htm), which is how anyone with more than a few dozen workbooks should do it. Site administrator access and a personal access token are the prerequisites, so raise that request early; it is a small task that has blocked large projects for a week.

One caution while exporting. A downloaded packaged workbook can carry an embedded extract, and Tableau documents [the contents of a `.twbx` file as stored in plain text](https://help.tableau.com/current/pro/desktop/en-us/save_savework_packagedworkbooks.htm), readable by anyone who opens it. Where data is regulated, that download is a data movement event and belongs inside the controlled environment; [the healthcare version of this migration](https://getantares.io/tableau-to-power-bi-migration-healthcare/) works through where else that matters.

## How long you pay for both platforms

This is the cost only cloud-to-cloud migrations feel sharply, because the Tableau contract keeps running whether or not anyone opens a viz. Through the parallel period you hold Tableau seats you cannot yet drop and Power BI licenses you already provisioned, so the overlap costs about the sum of both per month. Power BI's side is public at [$14.00 per user per month for Pro and $24.00 for Premium Per User](https://www.microsoft.com/en-us/power-platform/products/power-bi/pricing), billed yearly, as of August 2026. Tableau's side is whatever your contract says.

Which makes the length of the overlap the variable worth managing, and it is set by conversion throughput and owner availability, not by hosting. On the assumptions behind our own calculator, a hundred dashboards at 80 hours each and $85 an hour is $680,000 of manual conversion, against roughly $88,000 with a conversion tool once about 10% review time is added. The number to take from that is not the gap but the calendar behind it: the same team finishes months earlier, and every month saved is a month of two subscriptions nobody pays. Budget lines are on [migration cost estimation](https://getantares.io/tableau-migration-cost-estimation/), the arithmetic on [the migration cost calculator](https://getantares.io/tableau-to-power-bi-migration-cost-calculator/).

## What Antares does in a cloud-to-cloud move

Antares is a BI migration tool. The free **Analyzer** connects to your Tableau Cloud site through the same APIs you would otherwise script by hand and returns the inventory: workbooks and their usage, published data sources and where they repeat, the calculations and features that will need attention, and a complexity read per dashboard. It is deterministic, metadata-only, and alters nothing in the source site.

The **Converter** converts each source Tableau dashboard into a Power BI report page and deploys it, at a flat $200 per dashboard with no per-user licensing and no time limit; LLM costs sit with your own provider, typically under $20 per dashboard, private endpoints supported. It runs deterministic-first with guardrailed, validated AI steps, and flags what it cannot map confidently rather than guessing. Conversion is like-to-like, not a redesign, and connections are reauthorized by you on the Power BI side, because credentials are yours and stay yours. [Run the free Analyzer](https://try.getantares.io) to see the estate before the two-subscription clock starts.

Related reading: [Tableau Server to Power BI](https://getantares.io/tableau-server-to-power-bi-migration/), [Tableau to Microsoft Fabric](https://getantares.io/tableau-to-microsoft-fabric-migration/), [the migration risk register](https://getantares.io/tableau-migration-risk-assessment/) and [the Converter](https://getantares.io/converter/). Primary sources: Tableau on [Tableau Cloud release notes](https://help.tableau.com/current/online/en-us/whatsnew_online.htm) and [site capacity](https://help.tableau.com/current/online/en-us/to_site_capacity.htm), plus Microsoft on [scheduled refresh](https://learn.microsoft.com/en-us/power-bi/connect-data/refresh-scheduled-refresh).

## Related resources

- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [Tableau Server to Power BI Migration](https://getantares.io/tableau-server-to-power-bi-migration/)
- [Tableau to Microsoft Fabric Migration](https://getantares.io/tableau-to-microsoft-fabric-migration/)
- [Tableau Migration Cost Estimation](https://getantares.io/tableau-migration-cost-estimation/)

## FAQ

### Is Tableau Online the same thing as Tableau Cloud?

Yes. Tableau Online was renamed Tableau Cloud, and Tableau's release notes state it directly, although the help URLs still carry the old name. Older internal runbooks, contracts and inventories will use both terms for one platform, which is worth checking when migration scope is written against an existing document.

### Do we still need a gateway after moving from Tableau Cloud to Power BI?

Only if you were running Tableau Bridge. Bridge exists to reach private-network data from Tableau Cloud, and its Power BI counterpart is the on-premises data gateway. If every source is cloud-hosted and Bridge is installed nowhere, Power BI connects directly and no gateway is required.

### Do data source credentials transfer from Tableau Cloud to Power BI?

No. OAuth authorizations belong to the Tableau site and cannot be exported. Every cloud connection is authorized again on the Power BI side, so build that list early and decide which account owns each connection. Service accounts that outlive individual employees save a second round of this work later.

### How do we export dashboards out of Tableau Cloud in bulk?

Through the REST API, using site administrator access and a personal access token; the web interface downloads one workbook at a time. Note that a downloaded packaged workbook can contain an embedded extract, and Tableau documents that file's contents as plain text, so bulk downloads of regulated data count as a data movement event.

---

## Tableau to Microsoft Fabric Migration: What Moves, What Changes, What Waits

Canonical: https://getantares.io/tableau-to-microsoft-fabric-migration/
Published: 2026-02-18
Updated: 2026-08-10

Fabric is a bigger word than the migration. Microsoft Fabric is [one SaaS platform holding several workloads](https://learn.microsoft.com/en-us/fabric/fundamentals/microsoft-fabric-overview) — data engineering, warehousing, data factory, real-time intelligence and Power BI — over a single store called OneLake. Power BI is the BI workload inside it. So a Tableau estate does not land in "Fabric" in general: reports and semantic models land in the Power BI experience, which now lives in Fabric workspaces. That is the honest scope of a Tableau to Microsoft Fabric migration: the report work is the same report work, with more options underneath it.

## Tableau concepts in the Fabric world

Most of the mapping is the ordinary Tableau-to-Power-BI mapping, because that is where the content lands. The rows worth remembering are where Fabric adds a second answer, or where a Tableau habit has no home.

| Tableau | Fabric equivalent | Notes |
| --- | --- | --- |
| Workbook (`.twbx`) | A report plus a semantic model | Two items in a workspace, not one file |
| Dashboard | Report page | What users open, and the unit of migration work |
| Worksheet | Visuals on a report page | Moves as part of the dashboards that use it |
| Published data source | Shared semantic model | Many reports connect to one model |
| Embedded data source | The model inside a single report | One report owns it |
| Extract (`.hyper`) | Import-mode model, or Delta tables in a lakehouse | No file moves; a refresh schedule replaces the extract schedule |
| Live connection | DirectQuery, or Direct Lake once the data is in OneLake | See storage modes below |
| Project | Workspace | Flat, four roles, and it belongs to one capacity |
| Site | No direct equivalent | One tenant, one OneLake; separation comes from workspaces and capacities |
| Publishing to consumers | Workspace app | Apps are the distribution surface |
| Certified data source | Endorsement: Promoted or Certified | Two levels, different permissions |
| Tableau Bridge | On-premises data gateway | For sources not reachable from the cloud |
| Tableau Prep flow | Dataflow Gen2 or a data pipeline | A separate Fabric workload, not part of the report |

One vocabulary trap: in Power BI's own language a "dashboard" is a pinned-tile artifact in the service, not what a Tableau user means. The target of a converted Tableau dashboard is a **report page**.

## OneLake is the part that is genuinely new

Every Fabric tenant gets exactly [one OneLake](https://learn.microsoft.com/en-us/fabric/onelake/onelake-overview), which you cannot delete or duplicate. It is built on Azure Data Lake Storage and stores tables in open formats, Delta Parquet or Iceberg, so several engines read one copy instead of each making its own. Shortcuts point at data that already lives elsewhere, without moving it.

Set that against a Tableau estate: an extract per published data source, on its own schedule, duplicated wherever someone needed a copy. Nothing forces you to consolidate during the migration. But when an inventory shows the same source extracted again and again, OneLake is the answer to a question the estate has been asking for years.

## Import, DirectQuery and Direct Lake

Storage mode is the decision Tableau made as "extract or live". Fabric adds a third option.

| Mode | What it does | Closest Tableau habit |
| --- | --- | --- |
| Import | Loads a copy of the data into the model's memory; a refresh rebuilds that copy | An extract |
| DirectQuery | Sends a query to the source for each visual interaction | A live connection |
| Direct Lake | Reads Delta tables in OneLake straight into memory; a refresh re-points the model at the newest files | No equivalent |

Microsoft calls that Direct Lake refresh [framing](https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview): it updates metadata rather than copying data, which is why it takes seconds where an import refresh takes minutes. The prerequisite is the catch — the data has to sit in OneLake as Delta tables, in a lakehouse or warehouse, which is a data-platform project, not a reporting one. A migration arriving before that project is finished uses Import or DirectQuery, mirroring what the workbook already did. That is a legitimate landing place, not a compromise.

## Licensing changes shape, not just price

Tableau licenses people: Creator, Explorer, Viewer, per seat. Fabric [bills compute](https://learn.microsoft.com/en-us/fabric/enterprise/licenses). Capacity comes as F SKUs bought through Azure, billed per second with an optional yearly reservation, and one capacity serves every workload, so pipelines and report queries draw on the same units. A 60-day trial capacity at F64-equivalent size is available.

Per-user licensing does not disappear. Creating and sharing Power BI content still needs a Pro or Premium Per User license, and viewers need one too — unless the workspace sits on an F64 or larger capacity, where a Free license plus the viewer role is enough. Below F64, every reader is licensed individually. Non-Power BI Fabric items — lakehouses, warehouses, notebooks — need an F or trial capacity regardless. Price the target the way you will run it: seats for authors, capacity for readers and refreshes — and re-read Microsoft's licensing page on the day you build the business case, because these rules move.

## Workspaces, pipelines and governance

Tableau projects nest, and permissions flow down the tree. Fabric workspaces are flat containers with four roles — Admin, Member, Contributor, Viewer — and each belongs to one capacity. An estate that used deep project hierarchies for both filing and permissions has to split the jobs: workspaces carry permissions, and [domains](https://learn.microsoft.com/en-us/fabric/governance/domains) group workspaces by business area.

Two mechanisms have no Tableau habit to inherit. [Deployment pipelines](https://learn.microsoft.com/en-us/fabric/cicd/deployment-pipelines/intro-to-deployment-pipelines) give content development, test and production stages, with rules that repoint data source settings as an item moves between them. Sensitivity labels attach to items and follow the data into exports. Both are cheaper to decide during the migration than to retrofit afterwards, item by item.

## Sequence the BI layer first

The tempting plan is everything at once: move the dashboards, build the lakehouse, switch the models to Direct Lake. The plan that finishes is narrower. Migrate the report layer first — reports and semantic models reading the sources you already have — and treat the data-platform work as the next project rather than a prerequisite.

Three reasons. First, a BI-layer migration has a clean ending: when the report pages are accepted and users have moved, the Tableau contract can lapse, and that is the date the business actually cares about. Second, doing both at once gives every mismatched number two suspects, the conversion or the new data path, and telling them apart costs more than sequencing would have. Third, waiting costs nothing structural: adopting Direct Lake later changes what a model reads, not what the report pages look like.

The one thing worth doing early is the inventory, because it sets the order: which workbooks are still opened, which sources repeat, which dashboards everybody actually uses.

## How Antares fits in

This is the product-dependent section. Everything above stays true whichever tool you use.

Antares is a BI migration tool with two modules. The **Analyzer** connects to the Tableau environment and produces the inventory described above — fully deterministic, no LLM involved, and free. It reads metadata only, never business data. The **Converter** converts dashboards to the target platform and deploys them; Tableau to Power BI, including deployment into Fabric, is shipped today. It is deterministic-first with guardrailed, validated AI steps, at a flat $200 per migrated dashboard, with LLM costs on top — typically under $20 per dashboard, and your own private LLM endpoints can be used. The unit is the source dashboard: one Tableau dashboard becomes one Power BI report page, and the worksheets it uses ride along.

What it does not do matters as much for planning. The conversion is like-to-like, not pixel-perfect and not a redesign — parity across platforms with different capabilities does not exist. And it is not a data migration tool: it converts the dashboard's semantic data model, but it does not move your data into OneLake or change anything in the warehouse. That is the follow-on project, which is where this page argues it belongs. [Run the free Analyzer](https://try.getantares.io) to see what your estate holds before you size the capacity.

Related reading: [Tableau Server to Power BI Service](https://getantares.io/tableau-server-to-power-bi-migration/) and [data sources to semantic models](https://getantares.io/tableau-data-sources-to-power-bi-datasets/). Primary sources: Microsoft on [Fabric](https://learn.microsoft.com/en-us/fabric/fundamentals/microsoft-fabric-overview), [OneLake](https://learn.microsoft.com/en-us/fabric/onelake/onelake-overview), [Direct Lake](https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview) and [licenses and capacity](https://learn.microsoft.com/en-us/fabric/enterprise/licenses), plus Tableau on [projects](https://help.tableau.com/current/server/en-us/projects.htm).

## Related resources

- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [Tableau Server Migration](https://getantares.io/tableau-server-to-power-bi-migration/)
- [Tableau Online Migration](https://getantares.io/tableau-online-to-power-bi-migration/)

## FAQ

### Do I need Fabric capacity to run migrated Tableau reports?

Not necessarily. Reports and semantic models are Power BI items and can run in a Pro workspace on the tenant's shared capacity. An F capacity is required for non-Power BI Fabric items such as lakehouses, warehouses and notebooks, for Direct Lake models, and if you want viewers to open content on a Free license, which needs F64 or larger.

### Is Power BI Pro enough after migrating from Tableau?

For a report-layer migration, usually yes. Pro lets users create and share Power BI content, and other Pro or Premium Per User holders can view it. Free-licensed viewers only work on an F64 or larger capacity. Fabric items beyond Power BI need an F or trial capacity whatever per-user licenses you hold.

### What happens to Tableau extracts in Fabric?

No file moves. The default equivalent is an Import-mode semantic model with a scheduled refresh, which is the closest match to how the extract behaved. If the same data later lands in OneLake as Delta tables, a Direct Lake model can serve it instead, with no extract left to rebuild.

### Can we adopt Direct Lake later, or must we decide during the migration?

Later is fine. Direct Lake requires the data to sit in a Fabric lakehouse or warehouse as Delta tables, which is a data-platform project. Migrate with Import or DirectQuery mirroring what the workbook did, then change the storage mode when the data moves. That changes what the model reads, not what the report pages look like.

### Is migrating to Fabric different from migrating to Power BI?

For the BI layer, no. Reports and semantic models are the Power BI experience inside Fabric, and the conversion work is the same. What differs is where they run (capacity rather than per-seat licensing alone), what they can read (OneLake), and how they are governed (workspaces, domains, sensitivity labels).

### Do Tableau projects and sites map to Fabric workspaces?

Projects map to workspaces, but workspaces are flat: no nesting, four roles, one capacity each. A Tableau site has no direct equivalent, because a tenant has a single OneLake. Separation between business units comes from workspaces, domains, and separate capacities where isolation matters.

---

## Tableau to Power BI Migration in Financial Services: Access and Provable Numbers

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

In banks, insurers and asset managers a Tableau to Power BI migration rarely breaks on visuals. It breaks on two layers: row-level security, which is rebuilt rather than converted, and the requirement to demonstrate that the numbers still tie out afterwards. Everything between those two layers is the ordinary migration project.

Industry specificity is not a different process, only a tighter set of constraints over the same one. The process is on [the migration guide](https://getantares.io/tableau-to-power-bi-migration/); what follows is the two constraints that set the schedule, plus one decision about the estate you are leaving.

## Why row-level security is the first thing to check

Tableau lets access rules sit close to the workbook. Power BI puts them in the semantic model, as [roles with DAX filters](https://learn.microsoft.com/en-us/fabric/security/service-admin-row-level-security) assigned in the service. The relocation usually reduces the number of rule sets, since reports that each carried a filter end up sharing one model, and it moves ownership, which is the part that surprises people.

| How Tableau restricted access | Power BI equivalent | What to check |
| --- | --- | --- |
| Static [user filter](https://help.tableau.com/current/pro/desktop/en-us/publish_userfilters.htm) with users mapped to values by hand | Role membership assigned in the service | Tableau's own documentation calls manual mapping high maintenance with security that can be tentative; replace it with an entitlements table now |
| Dynamic filter comparing the signed-in user against a security table | A role whose DAX filter uses `USERPRINCIPALNAME()` | The entitlements table has to be reachable from the model, and the identity string is formatted differently |
| Server groups driving who sees what | Microsoft Entra groups added to roles | Membership administration leaves the BI team and joins identity administration |
| Filter applied to a published data source | Row-level security on the shared semantic model | One model may now serve reports that carried different filters; reconcile before consolidating |
| Hidden or dashboard-level filter used as if it were security | Nothing, because it was never security | The rows stay in the model, and [exporting from a visual](https://learn.microsoft.com/en-us/power-bi/visuals/power-bi-visualization-export-data) returns them; the classic first-review finding |
| Certified data sources | [Endorsement](https://learn.microsoft.com/en-us/power-bi/collaborate-share/service-endorse-content): Promoted or Certified | The right to certify is granted separately; decide who holds it before publishing |
| Classification stated in the workbook title | [Sensitivity labels](https://learn.microsoft.com/en-us/power-bi/enterprise/service-security-sensitivity-label-overview) | Labels travel with exports to Excel, PowerPoint and PDF, so classification survives the platform |

One behavior quietly undoes the whole table. Microsoft documents that row-level security restricts data only for users with Viewer permission: it does not apply to the workspace Admin, Member or Contributor roles. A Tableau habit of granting analysts publishing rights becomes a bypass once those rights turn into workspace membership. Distribute through apps, and keep membership to people meant to see everything.

## How to prove the numbers still tie out

Where a figure feeds a control, acceptance is evidence rather than opinion, and evidence has a shape. Agreeing it before conversion keeps sign-off from becoming a negotiation.

| Evidence item | What to record | Why it matters |
| --- | --- | --- |
| Source of truth | The system and query the figure is reconciled against | "It matches Tableau" is no answer if Tableau was never reconciled |
| As-of point | The date and time both sides were read at | Totals move; without a frozen point the comparison is unrepeatable |
| Method | Totals by dimension, row counts, sampled rows, or all three | States what was checked rather than what was glanced at |
| Tolerance | The rounding or aggregation difference accepted, agreed in advance | Stops a penny becoming a week of argument |
| Sign-off | Named person, role and date of acceptance | Acceptance has an owner, and it is not the migration team |
| Retention | Where the artifact is stored and for how long | Evidence nobody can find later is not evidence |

Microsoft treats [creating and validating content](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-create-validate-content) as one stage for the same reason. Two practices make the evidence hold. Freeze Tableau edits for the reports under validation, since a source changing underneath a comparison invalidates it. And when totals differ, look at semantics before arithmetic: blended sources and many-to-many joins are the usual cause, covered on [blending to relationships](https://getantares.io/tableau-blending-to-power-bi-relationships/).

## Where the regulated part actually is

It sits in the data and the access path, not in the dashboard. A report page renders a model; what matters upstream is which figure fed which control, who could see which rows, and whether both are demonstrable months later. Power BI provides the controls you map your own policy onto, documented across [its security planning guidance](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-implementation-planning-security-overview): roles, labels, endorsement, audit logging. The obligation stays with your organization.

So the practical version of a regulatory question is the one worth asking early. Not what a rule requires in the abstract, but what your own control owners need to see: which reports feed a control, what evidence they accept for a converted one, and how later changes get recorded. Settle that before conversion and acceptance is administrative; settle it afterwards and it is a renegotiation.

## What to do with the legacy Tableau environment

Keep it read-only for a lookback period rather than switching it off on cutover day. Questions about a figure produced under the old system arrive weeks later, and answering from a screenshot is not answering from the report. Freeze editing at cutover so two platforms cannot produce two truths, and budget the seats that window still costs. Its length is a question for your own audit and retention review.

## What Antares does in a financial services migration

Antares is a BI migration tool, and the useful part here is the analysis that comes first. The free **Analyzer** inventories where access logic lives across the estate: which workbooks carry user filters, which published sources carry their own, and where blends will change totals. That turns security rework from a discovery during testing into a scoped task before conversion. It is deterministic, reads metadata only rather than business data, runs inside your own environment, and changes nothing in the source.

The **Converter** produces a Power BI report page from each source Tableau dashboard at a flat $200, no per-user licensing and no time limit, with LLM costs going to your own provider at typically under $20 per dashboard and private endpoints supported. It is deterministic-first with guardrailed, validated AI steps, flags what it cannot map confidently instead of guessing, and stays like-to-like. Validation and sign-off stay yours, as they should in a controlled process. We make no claims about certification or regulatory status: bring the technical facts to your own security review. [Run the free Analyzer](https://try.getantares.io) to see where the access rules are before planning the rebuild.

Related reading: [the migration risk register](https://getantares.io/tableau-migration-risk-assessment/), [migrating without touching patient data](https://getantares.io/tableau-to-power-bi-migration-healthcare/) and [the Analyzer](https://getantares.io/analyzer/). Primary sources: Microsoft on [row-level security](https://learn.microsoft.com/en-us/fabric/security/service-admin-row-level-security) and [sensitivity labels](https://learn.microsoft.com/en-us/power-bi/enterprise/service-security-sensitivity-label-overview), plus Tableau on [row-level security options](https://help.tableau.com/current/server/en-us/rls_options_overview.htm).

## Related resources

- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [Healthcare Tableau Migration](https://getantares.io/tableau-to-power-bi-migration-healthcare/)
- [Tableau Migration Risk Assessment](https://getantares.io/tableau-migration-risk-assessment/)
- [Enterprise Tableau Migration Strategy](https://getantares.io/enterprise-tableau-migration-strategy/)

## FAQ

### Do Tableau user filters convert automatically into Power BI row-level security?

No. Tableau applies user filters at workbook or data source level; Power BI defines roles with DAX filters inside the semantic model and assigns membership in the service. The logic is rebuilt rather than translated. What automation helps with is scope: an analysis pass tells you which workbooks and sources carry filters before anyone starts rebuilding them.

### Does Power BI row-level security apply to everyone with workspace access?

No, and this is the most common finding of a first security review. Microsoft documents that row-level security restricts data only for users with Viewer permission; it does not apply to the workspace Admin, Member or Contributor roles. Distribute content through apps and viewer roles, and keep workspace membership to people meant to see everything.

### What evidence should we keep when validating a converted report?

Six things: the source of truth the figure was reconciled against, the as-of date and time both sides were read at, the comparison method, the tolerance agreed in advance, a named sign-off with a date, and where the artifact is stored and for how long. Agree that list before conversion starts rather than at acceptance.

### What should our security review ask about a migration tool?

Four technical questions: whether it reads business data or only metadata, where it runs, where any model calls go and whether private endpoints are supported, and whether anything in the source environment is modified. For Antares the answers are metadata only, inside your own environment if you choose, your own private LLM endpoints, and nothing changed in the source. We make no claims about certification or regulatory status; that assessment belongs to your review.

---

## Tableau to Power BI Migration in Healthcare: Moving Dashboards Without Moving Patient Data

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

Converting a dashboard does not require access to patient data. What moves is structure: field references, calculation logic, filters, layout. The rows stay where they are. The exposure in a healthcare migration sits in the artifacts that accumulate around the work, beginning with packaged workbooks that carry an extract inside them.

Nothing about the process is healthcare-specific; the constraints laid over it are. The process is on [the migration guide](https://getantares.io/tableau-to-power-bi-migration/). This page is about keeping protected health information out of the migration itself, and about the one architectural question that decides how much rework a clinical estate needs.

## What a dashboard migration actually touches

The input to a conversion is workbook metadata: which fields a view references, how calculated fields are written, what the filters select, how the objects are arranged, and how the connection to the source is defined. None of that is a patient record. A conversion step can therefore run in a setting where nobody involved has rights to read a row, which is not true of the rest of the project.

Metadata is not nothing, though. Field names, calculation logic and hard-coded filter values describe a population without containing any rows of it, and Tableau notes that filter values alone give semantic clues to the data. Treat the inventory as internal material with a named owner: a smaller problem than the one below, but not zero.

## Where PHI leaks during a migration

| Migration artifact | Can it hold patient data | What to do about it |
| --- | --- | --- |
| Packaged workbook (`.twbx`) with an embedded [extract](https://help.tableau.com/current/pro/desktop/en-us/extracting_data.htm) | Yes. Tableau documents [the contents of the file as plain text](https://help.tableau.com/current/pro/desktop/en-us/save_savework_packagedworkbooks.htm), readable by anyone who opens it | Keep downloads inside the controlled environment, never as an attachment |
| Screenshots for documentation and acceptance | Yes, and the easiest artifact to forget | Capture against de-identified or synthetic data, and store with the project |
| Excel or CSV [exports](https://learn.microsoft.com/en-us/power-bi/visuals/power-bi-visualization-export-data) taken during reconciliation | Yes, at row level, exactly the level reconciliation tempts you to | Compare inside the environment; export aggregates if at all |
| Screen sharing on a review or demo call | Yes, to everyone on the call and to the recording | Use a de-identified dataset, or restrict the attendee list |
| Ticket attachments and chat threads | Yes, and they outlive the project | Reference record identifiers or report links rather than values |
| Non-production environments loaded from a production copy | Yes, under weaker access controls | Subset or de-identify before the refresh, not after someone notices |
| The metadata inventory itself | No rows, but field names and filter values are descriptive | Handle as internal; assign an owner and a retention decision |

Leaks happen where the controlled environment meets the convenience of getting work done. Deciding once where migration work physically happens, and what may leave, removes most of the table at a stroke. Power BI's [sensitivity labels](https://learn.microsoft.com/en-us/power-bi/enterprise/service-security-sensitivity-label-overview) extend the same discipline to the target, since a label follows content into Excel, PowerPoint and PDF exports.

## How to validate without exposing patient data

Split validation in two, because the halves need different people. Structural validation asks whether the report page carries the same fields, filters, interactions and layout, and whether measures behave the same. It runs on de-identified or synthetic data and can involve anyone. Numeric reconciliation needs real data and belongs to a restricted group working inside the environment.

In the second half, compare aggregates rather than exporting row-level detail, and record what was checked: source of truth, as-of point, method, tolerance, named sign-off. That evidence template is set out on [the financial services page](https://getantares.io/tableau-to-power-bi-migration-financial-services/), and it applies unchanged here. Microsoft treats [creating and validating content](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-create-validate-content) as a single stage for the same reason: a report is not finished when it looks right.

## Why clinical sources are usually reached through a warehouse

Clinical systems rarely serve reporting directly. Most estates read from a warehouse or reporting layer that already applies the de-identification, the encounter grain and the agreed definitions. Good news for a migration: the converted semantic model points at the same warehouse, and connection rework is a credentials and gateway task, not a modeling project.

Where dashboards bypass that layer with custom SQL against a clinical database, the shape of the project changes. Those queries get rebuilt as model logic or pushed back into the warehouse, which is data-platform work with its own owners and timeline. [Custom SQL to Power BI](https://getantares.io/tableau-custom-sql-to-power-bi/) and [data sources to semantic models](https://getantares.io/tableau-data-sources-to-power-bi-datasets/) cover the mechanics; for planning, it is a separate workstream.

Access restriction moves with the model rather than with the report, which is worth mapping before the first conversion.

| Restriction | Usual Tableau implementation | Power BI equivalent |
| --- | --- | --- |
| By facility or site | User filter on a facility field | An [RLS role](https://learn.microsoft.com/en-us/fabric/security/service-admin-row-level-security) filtering the facility dimension |
| By department or service line | User filter, or a dashboard filter treated as security | An RLS role; a hidden dashboard filter is not security on either platform |
| To a clinician's own patients | Dynamic filter against an entitlements table | A dynamic RLS role on the same entitlements table |

One warning carries over from the access-heavy version of this migration: row-level security applies to viewers, not to workspace members, so distribution through apps matters more than it did in Tableau.

## What Antares does in a healthcare migration

Antares is a BI migration tool, and metadata-only is the literal answer to the question this page asks. The free **Analyzer** reads what the workbooks declare, never the business data behind them, and returns the inventory: usage, sources, calculations needing attention, complexity per dashboard. It is deterministic, runs inside your own environment, and changes nothing in the source. The **Converter** turns each source Tableau dashboard into a Power BI report page for a flat $200, no per-user licensing and no time limit, LLM costs going to your own provider at typically under $20 per dashboard, private endpoints supported where model calls must stay inside your boundary.

What it does not do matters as much. It is not a data migration tool: clinical data is not moved, no warehouse is built, nothing is de-identified on your behalf. Conversion is deterministic-first with guardrailed, validated AI steps, like-to-like rather than a redesign, and mappings it cannot resolve confidently are flagged instead of guessed. On business associate agreements, residency and retention we make no claims about certification or regulatory status; put those to your own privacy and security review with the technical facts in hand. [Run the free Analyzer](https://try.getantares.io) before anyone downloads a workbook.

Related reading: [access and provable numbers](https://getantares.io/tableau-to-power-bi-migration-financial-services/), [custom SQL to Power BI](https://getantares.io/tableau-custom-sql-to-power-bi/) and [the Analyzer](https://getantares.io/analyzer/). Primary sources: Tableau on [packaged workbooks](https://help.tableau.com/current/pro/desktop/en-us/save_savework_packagedworkbooks.htm), plus Microsoft on [data protection in Power BI](https://learn.microsoft.com/en-us/power-bi/enterprise/service-security-data-protection-overview) and [security planning](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-implementation-planning-security-overview).

## Related resources

- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [Financial Services Tableau Migration](https://getantares.io/tableau-to-power-bi-migration-financial-services/)
- [Tableau Custom SQL to Power BI](https://getantares.io/tableau-custom-sql-to-power-bi/)
- [Tableau Migration Risk Assessment](https://getantares.io/tableau-migration-risk-assessment/)

## FAQ

### Does converting Tableau dashboards to Power BI require access to patient data?

The conversion itself does not. What a conversion reads is workbook metadata: field references, calculation logic, filter definitions, layout and connection details. Numeric reconciliation later does need real data, which is why validation is worth splitting into a structural half that anyone can do and a numeric half restricted to people already cleared for the source.

### What is the biggest patient-data exposure in a migration project?

Downloaded packaged workbooks. A .twbx can contain an embedded extract, and Tableau documents that the file's contents are stored in plain text and readable by anyone who opens it. Bulk exports out of Tableau are therefore a data movement event, and they belong inside the controlled environment rather than in tickets, shared drives or laptops.

### Can we validate converted reports using synthetic or de-identified data?

For structural validation, yes, and it is the better default: layout, fields, filters, interactions and measure behavior can all be checked without real records. Numeric reconciliation against the source of truth still needs production data, so restrict who performs it, keep the comparison inside the environment, and compare aggregates rather than exporting rows.

### Do we need a business associate agreement with a migration tool vendor?

That determination belongs to your privacy office, and it applies to every vendor in the workflow rather than to migration tools specifically. Bring them the technical facts: Antares reads metadata rather than business data, can run inside your own environment, and can call your own private LLM endpoints. We make no claims about our regulatory or certification status.

---

## Tableau to Power BI Migration in Retail: Wide Estates and the Retail Calendar

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

Retail estates are wide rather than deep: hundreds of near-identical store and region reports drawn from a handful of sources. The largest saving in a retail migration therefore comes from not migrating most of them. The largest technical surprise is the retail calendar, which Power BI will not infer from a date column.

Neither of those is a different migration process, only a different pressure on the same one, which [the migration guide](https://getantares.io/tableau-to-power-bi-migration/) describes. This page covers what a wide estate and a non-Gregorian calendar do to the plan.

## Why retail estates shrink the most in migration

| Estate pattern | What to do with it | Why |
| --- | --- | --- |
| Near-duplicate dashboards per store, region or banner | One report page with row-level security by store, not N copies | The copies existed because distribution was per workbook, not because the analysis differed |
| Seasonal and promotional dashboards built for a single quarter | Retire rather than convert | They were disposable when built; converting them makes them permanent |
| Reports with no identifiable owner | Prune before conversion starts | Nobody validates them afterwards, and unvalidated content blocks sign-off for everything around it |
| The same metric defined three ways in three reports | Settle the definition first | Conversion preserves a disagreement faithfully; it does not resolve one |
| Daily operational reports for store and supply-chain teams | Keep, and schedule them first | They set the refresh window every other model has to fit around |

The consolidation move is the same one every time: a shared semantic model, one report page, security by store rather than a page per store. It changes who maintains the report, so name that owner before the copies disappear. Sequencing the survivors into waves is covered on [enterprise migration strategy](https://getantares.io/enterprise-tableau-migration-strategy/), and the scoring that decides order on [dashboard complexity analysis](https://getantares.io/tableau-dashboard-complexity-analysis/).

## What the retail calendar breaks

Retail time is not calendar time. The fiscal year starts in some month other than January, periods run 4-4-5 or 4-5-4, and occasional years carry a 53rd week. Tableau absorbs much of this in [a fiscal year start setting](https://help.tableau.com/current/pro/desktop/en-us/dates_fiscal.htm) plus calculated fields and table calculations. Power BI's [time intelligence](https://learn.microsoft.com/en-us/dax/time-intelligence-functions-dax) instead requires [a date table](https://learn.microsoft.com/en-us/power-bi/guidance/model-date-tables), and Microsoft's requirements for one are specific: unique date values, no blanks, no missing dates, and full years, though a year need not run January to December.

| Retail calendar behavior | Usual home in Tableau | What Power BI needs |
| --- | --- | --- |
| Fiscal year starting in a non-January month | Fiscal year start property on the date field | A date table carrying explicit fiscal year, quarter and period columns |
| 4-4-5 or 4-5-4 period structure | Calculated fields deriving the period from a date | Period and week columns generated once in the date table, not per report |
| Week-over-week comparison | Table calculation by position in the view | Measures over a contiguous week index column |
| Year over year across a 53-week year | Manual adjustment nobody documented | Comparison on the week index; date-shifting functions move by calendar date and will misalign |
| Moving holidays such as Easter or Lunar New Year | Ad hoc filters and hard-coded date ranges | An aligned-week or aligned-day column maintained in the date table |

Two consequences for the project. Turn off [auto date/time](https://learn.microsoft.com/en-us/power-bi/transform-model/desktop-auto-date-time), which Microsoft recommends keeping only for calendar periods and simple requirements. And build the date table before conversion rather than after, because the logic arriving from [table calculations](https://getantares.io/tableau-table-calculations-to-dax/) and [LOD expressions](https://getantares.io/tableau-lod-expressions-to-dax/) has to land on columns that already exist.

## What high-cardinality data does to the model

SKU, customer and basket-line grain is where retail models get heavy. Microsoft documents a default semantic model size limit of 1 GB, lifted by the large semantic model storage format on Fabric capacities, with Power BI Desktop uploads still capped at 10 GB, as of August 2026. Those are architecture facts to check against your estate, not tuning knobs.

Three documented levers matter more than any threshold. [Data reduction](https://learn.microsoft.com/en-us/power-bi/guidance/import-modeling-data-reduction) comes first: drop unused columns, raise the grain, shorten the history nobody queries. A [star schema](https://learn.microsoft.com/en-us/power-bi/guidance/star-schema) compresses better than the wide flat extract a Tableau workbook often carried. And [aggregations](https://learn.microsoft.com/en-us/power-bi/transform-model/aggregations-advanced) over a [DirectQuery](https://learn.microsoft.com/en-us/power-bi/connect-data/desktop-directquery-about) detail table keep summary pages fast while leaving line-level detail in the warehouse. The Tableau habit of extracting everything and filtering later does not survive the move intact.

## When not to cut over

Not during peak trading. The reasons are practical rather than superstitious: the people who validate figures are unavailable, a mis-stated number costs the most, and nobody wants to learn a new report while the stores are full. Set the freeze window early, plan waves so the last one lands clearly before it or after it, and remember that a delayed wave extends the period you pay for both platforms.

A second freeze is separate and easy to conflate. During validation, editing of the Tableau reports under comparison stops, whatever the trading calendar is doing, because a source that moves underneath a comparison invalidates it.

## What Antares does with a wide retail estate

Antares is a BI migration tool, and on a wide estate its first value is subtraction. The free **Analyzer** inventories the whole environment and shows what usage alone cannot: which workbooks repeat each other, which sources they share, which reports nobody opens, and how complex each dashboard is to convert. That is the prune list, produced before anyone commits budget. It is deterministic, reads metadata only rather than business data, runs inside your own environment, and changes nothing in the source.

Because the **Converter** prices by source dashboard at a flat $200, with no per-user licensing and no time limit, every report you decide not to convert is a visible budget line rather than a rounding error. LLM costs go to your own provider at typically under $20 per dashboard, private endpoints supported. Conversion is deterministic-first with guardrailed, validated AI steps, and it is like-to-like: collapsing a set of store reports into one parameterized page is a design decision you make first, not something the converter infers. [Run the free Analyzer](https://try.getantares.io) to see how much of the estate is worth carrying.

Related reading: [manufacturing migrations](https://getantares.io/tableau-to-power-bi-migration-manufacturing/), [table calculations to DAX](https://getantares.io/tableau-table-calculations-to-dax/) and [the Analyzer](https://getantares.io/analyzer/). Primary sources: Microsoft on [date tables](https://learn.microsoft.com/en-us/power-bi/guidance/model-date-tables), [data reduction](https://learn.microsoft.com/en-us/power-bi/guidance/import-modeling-data-reduction) and [large semantic models](https://learn.microsoft.com/en-us/power-bi/enterprise/service-premium-large-models), plus Tableau on [fiscal dates](https://help.tableau.com/current/pro/desktop/en-us/dates_fiscal.htm).

## Related resources

- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [Manufacturing Tableau Migration](https://getantares.io/tableau-to-power-bi-migration-manufacturing/)
- [Tableau Table Calculations to DAX](https://getantares.io/tableau-table-calculations-to-dax/)
- [Tableau Dashboard Complexity Analysis](https://getantares.io/tableau-dashboard-complexity-analysis/)

## FAQ

### Do we need a date table for a 4-4-5 retail calendar in Power BI?

Yes. DAX time intelligence requires a date table, and Microsoft's requirements are specific: unique date values, no blanks, no missing dates, and full years, although a year does not have to run January to December. Retail periods, week indexes and fiscal columns are generated once in that table rather than derived in each report.

### How do we handle 53-week years in year-over-year comparisons?

Compare on a week index column rather than by shifting dates. Date-shifting time intelligence moves by calendar date, so in a 53-week year it lines up week 1 against the wrong week and the error propagates through every comparison on the page. Build the index into the date table, and decide in advance which week the extra one is compared against.

### Should we convert every store-level dashboard?

Usually not. Most near-identical store and region reports exist because Tableau distribution was per workbook, not because the analysis differed. One report page with row-level security by store replaces them, and reports that nobody opens or nobody owns should be retired before conversion rather than migrated and then abandoned again.

### Import or DirectQuery for SKU-level retail data?

It depends on grain and size rather than on a rule of thumb. Microsoft documents a default semantic model size limit of 1 GB, lifted by the large semantic model storage format on Fabric capacities. Before choosing DirectQuery, try data reduction and a star schema; where line-level detail must stay in the warehouse, aggregations over a DirectQuery table keep summary pages fast.

---

## Tableau to Power BI Migration in Manufacturing: Plant Displays, Shifts and OEE

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

On a plant floor, part of the estate behaves like equipment: mounted on a wall display, refreshing without anyone touching it, watched by people who never sign in. Check those dashboards first. Power BI's automatic page refresh carries requirements a Tableau wall display never had, and the login-free terminal turns out to be a licensing question rather than a conversion one.

The rest of a manufacturing migration is the process described on [the migration guide](https://getantares.io/tableau-to-power-bi-migration/). What is specific is where the reports live, how the calculations are built, and how differently each plant built them.

## Which manufacturing dashboards are actually devices

| Plant-floor scenario | Power BI equivalent | What to check |
| --- | --- | --- |
| Wall display refreshing itself all shift | [Automatic page refresh](https://learn.microsoft.com/en-us/power-bi/create-reports/desktop-automatic-page-refresh) | It requires a [DirectQuery](https://learn.microsoft.com/en-us/power-bi/connect-data/desktop-directquery-about) source; Import mode does not support it at all |
| Sub-minute refresh on a line-side screen | Fixed-interval page refresh | Minimum 30 minutes in shared capacity; as low as 1 second on a dedicated capacity, subject to a capacity admin minimum that defaults to 5 minutes, as of August 2026 |
| Rotating between views on one screen | Report pages, with no presentation rotation of their own | Tableau [stories](https://help.tableau.com/current/pro/desktop/en-us/story_create.htm) have no direct counterpart; rotation is usually handled by the display client |
| Shared terminal with no personal login | An identity and licensing decision, not a report setting | Viewers need [licenses](https://learn.microsoft.com/en-us/power-bi/fundamentals/service-features-license-type) unless the content sits on an F64 or larger capacity; embedding is a separate route with its own work |
| Shift supervisor on a tablet on the floor | [Power BI mobile](https://learn.microsoft.com/en-us/power-bi/consumer/mobile/mobile-apps-for-mobile-devices) with a phone layout | A report designed for a wall screen is not a phone report; layouts are authored separately |
| Threshold alerting on a running metric | [Alerts](https://learn.microsoft.com/en-us/power-bi/create-reports/service-set-data-alerts) and subscriptions | They evaluate on refresh, so an alert is never more timely than the model behind it |

## What plant-floor refresh costs you

Automatic page refresh sends queries continuously, and the load lands twice: on the capacity, and on whatever the historian or warehouse is. Microsoft builds in two safeguards worth knowing before promising a number to operations. Those queries run at a lower priority than interactive ones, and a new refresh query is not sent until the previous one returns, so a one-second interval against a four-second query effectively refreshes every four seconds.

There is also an honest check to run per screen. Many Tableau displays described as real time were rendering an extract refreshed every so often, not a live query. The equivalent of that is a scheduled refresh, capped at 8 per day on Power BI Pro and 48 with Premium Per User or a capacity, as of August 2026. Hold each screen's actual expectation against those two options before conversion, and the awkward conversation on the shop floor never happens.

## Where OEE logic breaks

Manufacturing calculations are unusually dense for their visual simplicity. A single tile showing OEE can rest on a chain of ratios, shift boundaries and event ordering that Tableau expressed compactly and DAX will not.

| Logic or source | Usual home in Tableau | What it needs in Power BI |
| --- | --- | --- |
| OEE as availability times performance times quality | Ratios of aggregates inside LOD expressions | Measures evaluated at the right grain over a [star schema](https://learn.microsoft.com/en-us/power-bi/guidance/star-schema); a ratio of sums is not a sum of ratios |
| Downtime duration between state changes | Table calculations over ordered rows | Explicit DAX over an event table, with the ordering stated rather than implied |
| Yield and scrap by shift | Shift boundaries buried in calculated fields | A shift dimension joined to the fact table, so every measure inherits the same definition |
| Rollups across plants | Blends across per-plant extracts | One model with real relationships; blend semantics do not survive the move unchanged |
| Historian and OT tag data | Direct connections or per-plant extracts | Read through a warehouse or time-series layer, at a grain a report can query |
| Plants on restricted networks | Server or Bridge inside the plant network | An on-premises data gateway, sized and sited as on [the Tableau Server page](https://getantares.io/tableau-server-to-power-bi-migration/) |

The first three rows are where converted numbers most often disagree with the originals, and the mechanics are on [LOD expressions to DAX](https://getantares.io/tableau-lod-expressions-to-dax/) and [table calculations to DAX](https://getantares.io/tableau-table-calculations-to-dax/). Validate OEE at line and shift grain rather than at the plant total, because offsetting errors hide neatly in a daily figure.

## Why plant estates diverge and what to do about it

Every site grew its own version of the same report, because every site had its own analyst, its own line layout and its own idea of when a stoppage counts. A migration is the natural moment to decide whether to standardize or to preserve that, and the decision has to be made before conversion. Made afterwards, it becomes a redesign in the middle of a delivery schedule, and the schedule stops being predictable.

A rule that survives contact with plant managers: standardize the model and the metric definitions, preserve local layout. Definitions are what a group rollup depends on, and layout is what an operator recognizes at a glance. Running that decision across sites is coordination work rather than conversion work, which [enterprise migration strategy](https://getantares.io/enterprise-tableau-migration-strategy/) covers.

## What Antares does in a manufacturing migration

Antares is a BI migration tool, and in a multi-plant estate the analysis matters before anything is converted. The free **Analyzer** inventories every site's content in one pass: which reports repeat across plants, where LOD expressions and table calculations concentrate, which sources each plant reaches, and how complex each dashboard is to convert. That is the input to the standardize-or-preserve decision above. It is deterministic, reads metadata only rather than business data, runs inside your own environment, and changes nothing in the source.

The **Converter** turns each source Tableau dashboard into a Power BI report page for a flat $200, no per-user licensing and no time limit, with LLM costs going to your own provider at typically under $20 per dashboard and private endpoints supported. It is deterministic-first with guardrailed, validated AI steps, and flags calculations it cannot map confidently instead of guessing, which is the behavior you want on OEE logic. It converts the dashboard's semantic model but is not a data migration tool: historians, gateways and time-series layers stay your work. [Run the free Analyzer](https://try.getantares.io) across two plants and calibrate the rest from the difference.

Related reading: [retail migrations](https://getantares.io/tableau-to-power-bi-migration-retail/), [LOD expressions to DAX](https://getantares.io/tableau-lod-expressions-to-dax/) and [the Converter](https://getantares.io/converter/). Primary sources: Microsoft on [automatic page refresh](https://learn.microsoft.com/en-us/power-bi/create-reports/desktop-automatic-page-refresh), [DirectQuery](https://learn.microsoft.com/en-us/power-bi/connect-data/desktop-directquery-about) and [star schema design](https://learn.microsoft.com/en-us/power-bi/guidance/star-schema).

## Related resources

- [Tableau to Power BI Migration Guide](https://getantares.io/tableau-to-power-bi-migration/)
- [Retail Tableau Migration](https://getantares.io/tableau-to-power-bi-migration-retail/)
- [Tableau LOD Expressions to DAX](https://getantares.io/tableau-lod-expressions-to-dax/)
- [Tableau Server to Power BI Migration](https://getantares.io/tableau-server-to-power-bi-migration/)

## FAQ

### Can a Power BI report refresh itself on a plant-floor screen?

Yes, through automatic page refresh, with conditions. The report has to use a DirectQuery source, because Import mode does not support it. In a shared-capacity workspace the minimum interval is 30 minutes; on a dedicated capacity it goes as low as 1 second, subject to a capacity admin minimum that defaults to 5 minutes, as of August 2026.

### Do we need a Power BI license for a shared shop-floor terminal?

This is a licensing and identity question rather than a conversion one, and it is worth settling early. Viewers need licenses unless the content sits on a Fabric F64 or larger capacity, where free-licensed users can open shared content. Shared accounts, kiosk devices and embedding each carry their own conditions, so involve whoever owns identity.

### Where should historian and OT tag data connect in Power BI?

Through a warehouse or time-series layer, at a grain a report can query, rather than directly from the historian. Most Tableau estates already do this, and the migration inherits it. Where a dashboard reads raw tags directly, treat the rework as data-platform work with its own owners rather than as part of the report conversion.

### Will OEE numbers match after conversion?

They should, but that is exactly the calculation to validate deliberately. OEE is a chain of ratios, and a ratio of sums is not a sum of ratios, so grain errors survive at the plant total while showing up per line and per shift. Validate at line and shift grain, where offsetting errors cannot hide, before anyone signs off the summary.

---

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

Canonical: https://getantares.io/migration-library/why-tableau-migrations-fail/
Published: 2026-02-09
Author: Antares Team

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](https://try.getantares.io) on your Tableau environment — you'll see complexity scores, usage data, and a prioritized migration plan before you commit to anything.*