Tableau to Power BI Migration: Inventory, Effort, and Acceptance Guide

Section 01

What changes when Tableau workbooks move to Power BI?

The table below is an editorial migration method. The product facts identify where the two platforms make different operating choices; the acceptance evidence is the work a buyer should require before approving a wave.

The source behavior in the calculation and relationship rows is documented by Tableau in its level-of-detail expression guide and data-model guide. The mapping and evidence columns are our editorial judgment. They are intended to prevent a visual comparison from standing in for a model or access test.

A worked metric check

Consider an illustrative report with two regions: one has revenue of 200 and profit of 50; the other has revenue of 20 and profit of 10. If the agreed metric is total profit divided by total revenue, the combined margin is 60 / 220 = 27.27%. Averaging the regional margins, 25% and 50%, would instead display 37.5%.

Both reports could contain the same rows and look similar. The acceptance test must check the combined total, each region, and the result after filtering. Record the approved calculation and filter behavior in the inventory before translating the Tableau calculation into Data Analysis Expressions (DAX). These figures are a constructed arithmetic example, not an observed migration result or a claim about either platform's default behavior.

Section 02

Build the inventory before estimating effort

Download the Tableau to Power BI migration inventory CSV and make a row for each retained workbook, dashboard, shared data source, or other artifact that needs a separate migration decision. The file contains blank input rows and one clearly marked illustrative row. Replace or remove the example before using the worksheet as a project record.

Inventory work should answer four questions early:

1. What should exist after migration? Record the report or semantic-model outcome, the business owner, and whether the artifact will be rebuilt, retained, retired, or piloted.
2. What gives the number its meaning? Capture material calculations, the intended grain, relationships, filters, and metric definitions. This is where Tableau’s level-of-detail logic and relationship behavior deserve review.
3. Who may see it and how does it stay current? Record audience, access rules, identity dependencies, source ownership, refresh mode, gateway need, delivery behavior, and operational owner.
4. What evidence proves it is ready? Write the agreed metric comparison, access test, refresh result, and sign-off owner before development begins.

Do not turn the sheet into a list of every visual by default. A dashboard and its shared semantic dependency may belong in one row; an executive report with a distinct security rule or a material calculation may need its own. Record enough detail to assign the work, state the assumptions, and approve the result.

What should a conversion tool demonstrate?

Evaluate an accelerator against the same inventory. Ask its supplier to demonstrate which workbook objects it reads, which target artifacts it produces, and which calculations, relationships, access rules, refresh settings, and subscriptions require manual work. Keep an exception list and run the metric and access tests against the generated result. This is an editorial evaluation method; it makes no claim that a particular tool can automate those tasks or deliver a fixed conversion rate.

Section 03

Estimate effort from the estate, not a conversion rate

There is no defensible universal cost, timeline, or per-dashboard conversion rate for Tableau to Power BI. The same number of dashboards can hide very different model logic, source access, security, refresh, and acceptance work.

Start with this effort model and fill it using the inventory:

Total effort = discovery + sum of artifact review, rebuild, test, and approval effort + target operating setup + cutover and parallel validation + risks found in the pilot.

For each row, state the effort assumption in plain language. Examples include: “reuse a governed source after connection testing,” “rebuild because the calculation’s required grain is unclear,” or “retire after the owner confirms no active use.” Do not fill the field with a generic hours-per-dashboard factor. The pilot should replace assumptions with observed work and identify dependencies that need a separate plan, such as data-gateway ownership, source credentials, capacity, or a shared model.

Licensing belongs in the same estimate because it can affect what the target operating model can do. Microsoft’s current US page lists Power BI Pro at $14 per user/month and Premium Per User at $24 per user/month when paid yearly, and it states that actual price can vary by market and offer. Treat those figures as a checked-date reference, not a project price: verify the organization’s tenant, region, capacity, existing Microsoft agreements, and feature requirements against Microsoft’s current pricing page before approval.

Section 04

Test security, refresh, and delivery as production behavior

These controls are often discovered after a report looks finished. They should be pilot acceptance gates.

For RLS, define roles and DAX filters, publish the semantic model and report, and assign members. Use Test as role where supported. For DirectQuery models with single sign-on (SSO), Microsoft says that feature is unavailable; validate with actual Viewer accounts. Dynamic or external business-to-business (B2B) identities also need tests in the target environment, including the identity value resolved by the model. RLS does not restrict workspace Admin, Member, or Contributor roles, so an access test needs the intended workspace role as well as the row filter. Microsoft’s RLS guidance explains these limits.

For refresh, test the actual source, identity, storage mode, gateway, schedule, and failure notification path. Microsoft recommends checking refresh history and notes that Import models must refresh to remain current, while DirectQuery queries the source at use time and has its own constraints. The relevant refresh documentation should be rechecked when the target operating model changes.

If Tableau subscriptions or scheduled distribution matter, treat recipient access and delivery as test cases, not a post-cutover tidy-up. Microsoft documents report and dashboard email subscriptions as scheduled snapshots, links, or attachments, with permissions, tenant settings, and licensing conditions. See the current subscription guide before finalizing the delivery design.

Section 05

Reconcile metrics before cutover, then keep a rollback path

The acceptance set should be small enough to run for every wave and strong enough to catch a material difference. Agree it with the business owner before the first parallel run:

• named report pages and filters that represent real decisions;
• expected metric values, tolerances where a source refresh window makes them necessary, and an explanation for every approved difference;
• model-grain checks for totals, distinct counts, and drill paths;
• RLS results for representative allowed and denied users;
• a successful target refresh and scheduled delivery test where those functions are in scope; and
• a named approval owner and a recorded decision to cut over, remediate, or retain Tableau for that wave.

Parallel validation is not a claim that both platforms will always produce identical screens. It is the agreed process for proving that the reports, metrics, access, and operating behavior needed for a decision work in the target state. Keep the Tableau artifact available until the evidence is approved and the recovery decision is understood. The database migration testing guide offers complementary validation principles for teams that also need to verify data movement.

Section 06

When to rebuild, retain, retire, or pilot

Rebuild when an active report has a clear owner and material business logic that needs a governed Power BI model. Retain Tableau temporarily when a high-consequence report lacks a tested target design or an acceptance owner. Retire unused or duplicate content only after its owner confirms that no dependent process requires it. Pilot a representative slice when the estate includes complex calculations, relationship behavior, RLS, on-premises sources, or scheduled delivery that has not been proven in the target tenant.

Power BI is a poor fit for a forced, broad conversion when the program cannot identify report owners, source access, or an approval method. In that situation, a rationalization exercise or a small pilot creates better evidence than commissioning a factory-style conversion estimate.

Section 07

Decide the first migration wave

Start with a slice that contains the real decision risks: a meaningful report, its shared source or semantic dependency, a material calculation, the intended access rule, and the target refresh or delivery path. Use the completed inventory to specify what is being rebuilt, the effort assumptions that remain, and the acceptance owner for every row.

For the surrounding warehouse, governance, and operating-model decisions, use the data modernization research hub. This guide is independent desk research. Products are not ranked by sponsorship, and Software Modernization Intelligence is not a delivery candidate. The method is based on stated platform behavior and explicit fit criteria; it is not a claim of implementation experience or a conversion benchmark. Read our methodology or use the data modernization services guide to prepare an engagement brief built around your documented estate.

Section 08

Sources and review note

Primary documentation was checked on August 30, 2026. Product features, licenses, capacity, and support conditions can change, so recheck the linked Microsoft and Tableau documentation before approving a pilot or procurement decision. The repository research record maintains the detailed claim ledger and source limits for this page.