Tableau Published Data Sources vs Power BI Semantic Models

Why this matters

In Tableau Server or Tableau Cloud, teams often publish a data source once and point many workbooks at it. That published source holds the connection, joins or relationships, calculated fields, and often an extract schedule. In Power BI, the equivalent reuse boundary is the semantic model (formerly “dataset”): tables, relationships, measures, hierarchies, and row-level security live in the model; reports bind to it.

If you migrate workbooks as if each file were self-contained, you recreate the same connection and business logic dozens of times. If you ignore published sources, you ship reports that look right in a demo and break when the shared extract or calc library was the real system of record.

What a Tableau published data source actually contains

A published Tableau data source is more than a connection string. Typical contents:

Connection(s) to databases, files, or cloud warehouses, including auth method and any initial SQL
Physical layer — joins, unions, custom SQL, or relationships between tables
Logical / semantic layer — field names, aliases, folders, default aggregations, number formats
Calculations — row-level and aggregate calculated fields maintained once for many workbooks
Extract definition — which tables, filters, incremental refresh settings, and schedule
Permissions — who can connect, edit, or download the source

Embedded data sources live inside a single workbook. They are easier to miss in inventory because they do not appear on the “Data Sources” list the same way, but they still need a destination model strategy.

What a Power BI semantic model contains

A Power BI (or Fabric) semantic model typically includes:

Tables loaded via Power Query (M) or DirectQuery / Direct Lake
Relationships with explicit cardinality and cross-filter direction
Measures (and sometimes calculated columns / tables) in DAX
Roles for row-level security
Perspectives, hierarchies, display folders for usability
Refresh configuration (gateway, schedule, incremental policies)

Reports and dashboards in Power BI are usually thin: visuals + filters that query a shared model. That is closer to “many workbooks → one published source” than to “every workbook embeds its own copy of the world.”

Side-by-side mapping

Tableau concept	Power BI / Fabric concept	Notes
Published / shared data source	Shared semantic model in a workspace	Prefer one model per subject area, not one per report
Embedded workbook data source	Report-local model, or promote into a shared model	Promote anything reused by 2+ reports
Calculated fields on the source	Measures or calculated columns	Aggregates → measures; row-level → columns or upstream transforms
Extract on published source	Import mode (or hybrid tables)	Match refresh SLA to former extract schedule
Live connection to published source	DirectQuery, Direct Lake, or Analysis Services live	Re-evaluate latency and concurrency
Permissions on the data source	Workspace roles, apps, RLS, object-level security	Do not assume Tableau group names map 1:1

How to implement the migration (without assuming automation)

1. Inventory published sources and consumers

From Tableau Server/Cloud (or admin views / Metadata API):

List published data sources with owner, project, connection type, extract vs live, last refresh
For each source, list workbooks (and Prep flows) that connect to it
Flag sources with high fan-out (many workbooks) vs orphans (zero or one consumer)

Output should be a dependency table: data_source → workbook_count → criticality.

2. Classify each source

Class	Definition	Destination pattern
Platform	Used by many workbooks; owned by a data team	One shared semantic model (or warehouse mart + model)
Domain	Used by one department / subject area	Shared model per domain
Local	Embedded or single-workbook	Start report-local; promote if reuse appears
Retire	Unused, duplicate, or superseded	Do not migrate; document decommission

3. Redesign the semantic model before mass report migration

For each platform/domain source:

Choose storage mode — Import for most analytical models; DirectQuery / Direct Lake when freshness or size requires it.
Rebuild the physical layer in Power Query or the warehouse — Prefer curated warehouse views or lakehouse tables over opaque Tableau Custom SQL copied verbatim into every model.
Translate calculations — Tableau calculated fields become DAX measures or Power Query / SQL columns. Document grain carefully: Tableau often hides LOD grain that must become explicit in DAX.
Define relationships — Replace Tableau blends and multi-connection workbooks with a clear star or snowflake schema where possible.
Implement RLS — Map Tableau user filters / entitlements to Power BI roles or OLS.
Publish and certify — Place the model in the target workspace; set refresh; name it so report authors can find it.

4. Rebind reports to the shared model

When recreating or converting dashboards:

Point each report at the shared semantic model instead of embedding a private copy of the same tables
Keep report-level measures only for layout-specific logic
Regression-test totals against Tableau on agreed filters and date ranges

5. Cut over and decommission

Freeze changes on the Tableau published source once the Power BI model is certified
Migrate remaining workbooks in waves by dependency
Archive or delete the Tableau source after consumers are gone

Common pitfalls

Cloning the published source into every PBIX — recreates the sprawl you were trying to leave.
Migrating workbooks first — you invent N private models, then struggle to consolidate.
Treating extracts as “just a file” — the extract filter and refresh policy are part of the business contract.
Ignoring calculated fields on the source — workbook-only conversion misses logic that lived only on the published source.
Assuming permissions are identical — Tableau project permissions and Power BI workspace/app/RLS models differ; redesign access explicitly.

Practical checklist

[ ] Inventory all published + embedded sources with consumer counts
[ ] Classify platform / domain / local / retire
[ ] Design one semantic model per platform or domain source
[ ] Translate connection, grain, calcs, and RLS
[ ] Certify model refresh before mass report cutover
[ ] Rebind reports; avoid duplicate private models
[ ] Decommission Tableau sources after consumers migrate