Data Source Migration: Tableau to Power BI¶

A comprehensive guide for migrating Tableau data connections, extracts, published data sources, and data blending to Power BI semantic models, DirectQuery, and Direct Lake.

Overview¶

Data source migration is the foundation of a Tableau-to-Power BI migration. Get the data layer right and report conversion is straightforward. Get it wrong and every report will carry technical debt. This guide covers every Tableau data connection pattern and maps it to the optimal Power BI approach, with specific guidance for organizations running csa-inabox.

1. Connection type mapping¶

1.1 Tableau connection types to Power BI equivalents¶

1.2 Decision tree for connection type selection¶

flowchart TD
    START[Source data] --> Q1{Is data in OneLake<br/>Delta format?}
    Q1 -->|Yes| DL[Direct Lake<br/>Zero-copy, always fresh]
    Q1 -->|No| Q2{Is data < 1 GB and<br/>refresh latency OK?}
    Q2 -->|Yes| IMPORT[Import mode<br/>Scheduled refresh]
    Q2 -->|No| Q3{Is source fast<br/>enough for live query?}
    Q3 -->|Yes| DQ[DirectQuery<br/>Live query at render]
    Q3 -->|No| Q4{Can you land data<br/>in OneLake/ADLS?}
    Q4 -->|Yes| DL
    Q4 -->|No| IMPORT

2. Eliminating extract sprawl with Direct Lake¶

2.1 The extract problem¶

Tableau extracts (.hyper files) are the most common data connection pattern in Tableau deployments. They provide fast performance but create significant operational overhead:

• Data duplication — every extract is a copy of the source data on Tableau Server storage
• Stale data — data is only as fresh as the last extract refresh
• Refresh failures — extract refreshes fail due to timeouts, source connectivity, or server resource pressure
• Storage consumption — large extracts consume significant Tableau Server disk and backgrounder resources
• Governance gap — each workbook can create its own extract with its own SQL, leading to divergent data

2.2 Direct Lake eliminates every extract problem¶

Direct Lake is a Power BI storage mode exclusive to Microsoft Fabric. It connects Power BI semantic models to Delta tables in OneLake and reads the Parquet files directly with Vertipaq-like compression and performance.

2.3 Direct Lake prerequisites¶

1. Data must be in Delta format in OneLake (or ADLS Gen2 via shortcut)
2. Fabric capacity (F64 or higher recommended for production)
3. Lakehouse or Warehouse in Fabric workspace
4. Tables must be Delta tables (not CSV, Parquet, or other formats)

2.4 Migration path: Extract to Direct Lake¶

Step 1: Identify the source system the Tableau extract queries
Step 2: Verify the source data lands in csa-inabox Gold layer (Delta format)
Step 3: Create a Fabric Lakehouse with shortcuts to the Gold tables
Step 4: Create a Power BI semantic model with Direct Lake storage mode
Step 5: Define relationships and measures in the semantic model
Step 6: Validate data freshness and row counts against the old extract
Step 7: Decommission the Tableau extract

3. Published data sources to shared semantic models¶

3.1 Concept mapping¶

3.2 Semantic model design principles¶

When migrating Tableau published data sources to Power BI shared semantic models:

One semantic model per data domain. Do not create one semantic model per report (Tableau's default pattern). Create one semantic model for Sales, one for Finance, one for HR, etc. Reports connect to these shared models.

Star schema design. Power BI performs best with star schemas: fact tables (transactions, events) surrounded by dimension tables (customers, products, dates). Tableau is forgiving with denormalized tables. Power BI is not. Invest in the star schema.

Measures in the model, not the report. Define all DAX measures in the semantic model. Reports should consume measures, not redefine them. This is the Power BI equivalent of Tableau's calculated fields in published data sources.

Certify the model. Use Power BI endorsement to mark the semantic model as "Certified." This makes it discoverable in the data hub and signals governance approval.

flowchart TD
    subgraph Tableau["Tableau Pattern"]
        PDS1[Published Data Source A] --> WB1[Workbook 1]
        PDS1 --> WB2[Workbook 2]
        PDS2[Published Data Source B] --> WB3[Workbook 3]
        PDS2 --> WB4[Workbook 4]
    end

    subgraph PowerBI["Power BI Pattern"]
        SM1[Shared Semantic Model A<br/>Star schema, certified<br/>Measures defined here] --> RPT1[Report 1<br/>Thin report, no measures]
        SM1 --> RPT2[Report 2]
        SM2[Shared Semantic Model B<br/>Star schema, certified] --> RPT3[Report 3]
        SM2 --> RPT4[Report 4]
    end

3.3 Migration steps for published data sources¶

1. Inventory — list all published data sources, their connections, calculated fields, and dependent workbooks
2. Group by domain — cluster data sources into data domains (sales, finance, operations, etc.)
3. Design star schema — for each domain, design fact and dimension tables
4. Build in Power BI Desktop — connect to the source (prefer csa-inabox Gold tables), define relationships, create measures
5. Migrate calculated fields — convert Tableau calculated fields to DAX measures (see Calculation Conversion)
6. Publish and certify — publish the semantic model to a dedicated workspace, apply "Certified" endorsement
7. Connect reports — build reports using live connection to the shared semantic model

4. Data blending migration¶

4.1 The blending problem¶

Tableau data blending allows ad-hoc cross-source analysis by linking a primary data source to a secondary data source on a shared dimension. It is convenient but creates several issues: performance is poor for large datasets, blending is workbook-specific (not reusable), and the linking logic is implicit.

4.2 Power BI alternatives to data blending¶

4.3 Composite model example¶

// Scenario: Sales data in SQL Server, Budget data in Excel
// Tableau: Data blending with Sales as primary, Budget as secondary

// Power BI:
// 1. Create semantic model
// 2. Add Sales connection (DirectQuery to SQL Server)
// 3. Add Budget connection (Import from Excel)
// 4. Create relationship: Sales[Region] → Budget[Region]
// 5. Create measures that reference both tables
// This is a composite model — mixing DirectQuery and Import

5. Custom SQL migration¶

5.1 Tableau custom SQL patterns¶

Tableau allows custom SQL at the data source level. Common patterns:

• Pre-aggregated queries for performance
• Complex joins not possible in the visual join interface
• Parameterized queries
• Stored procedure calls

5.2 Power BI alternatives¶

With csa-inabox, transformation logic should live in dbt models (Silver and Gold layers), not in Power Query or custom SQL inside the semantic model. Create dbt views or tables that encapsulate the logic, then connect Power BI to those views via Direct Lake or DirectQuery.

6. Tableau Bridge to on-premises data gateway¶

6.1 Concept mapping¶

6.2 Gateway migration steps¶

1. Install the on-premises data gateway on a server with network access to on-prem data sources
2. Configure gateway data sources for each on-prem database the Tableau Bridge connects to
3. Map credentials — configure authentication for each data source (Windows, SQL, OAuth)
4. Add gateway to workspace — associate the gateway with the Power BI workspace
5. Configure semantic model — point the semantic model's data source to the gateway connection
6. Test connectivity — validate that Power BI Service can reach on-prem sources through the gateway
7. Decommission Tableau Bridge — once all data sources are migrated

7. File-based source migration¶

7.1 Common file patterns¶

7.2 File-based refresh considerations¶

For file-based data sources, consider moving files to a governed location:

• SharePoint Online / OneDrive — Power BI connects directly, supports auto-refresh
• ADLS Gen2 / OneLake — best for large files; supports Direct Lake
• SQL database — load files into tables via ADF/Fabric pipeline for better governance

8. Cloud data warehouse connections¶

8.1 Common cloud connections¶

8.2 Databricks-specific guidance¶

For organizations using Databricks (common with csa-inabox), the optimal path is:

1. Databricks SQL warehouse → DirectQuery (for real-time)
2. Databricks + OneLake shortcuts → Direct Lake (for best performance with zero-copy)
3. Databricks Unity Catalog tables → Direct Lake via Fabric Lakehouse shortcuts

9. Union and join migration¶

9.1 Tableau unions to Power Query append¶

// Tableau: Union (append rows from multiple tables/files)
// Drag tables onto each other in the data source pane

// Power BI: Append Queries in Power Query
// Home → Append Queries → select tables to append
// M code equivalent:
= Table.Combine({Table1, Table2, Table3})

9.2 Tableau joins to Power Query merge¶

// Tableau: Join (merge columns from two tables)
// Drag tables side by side, configure join type and keys

// Power BI: Merge Queries in Power Query
// Home → Merge Queries → select tables, join columns, join type
// M code equivalent:
= Table.NestedJoin(
    Table1, {"KeyColumn"},
    Table2, {"KeyColumn"},
    "Table2",
    JoinKind.LeftOuter
)

9.3 Tableau relationships to Power BI model relationships¶

Tableau relationships (introduced in 2020.2) map closely to Power BI model relationships:

10. Migration validation checklist¶

After migrating each data source:

• Row counts match between Tableau and Power BI at the table level
• Key aggregate measures (SUM, COUNT, AVG) match at the grain level
• Date ranges match (no missing or extra data)
• Null handling is consistent
• Data types match (especially dates, decimals, and text encoding)
• Refresh schedule is configured and tested (for Import mode)
• DirectQuery performance is acceptable (< 5 seconds for typical queries)
• RLS rules produce the same filtered results as Tableau user filters
• Calculated fields are migrated to DAX measures and validated
• Relationships are correctly defined with proper cardinality

Last updated: 2026-04-30 Maintainers: CSA-in-a-Box core team Related: Prep Migration | Server Migration | Calculation Conversion | Migration Playbook