How to Swap Power BI Data Sources Without Rebuilding Your Report

One of the more frustrating moments in Power BI development is realizing you’ve chosen the wrong data source connection method.

Maybe you started with Direct Lake and later discovered a SQL Endpoint would have been a better choice. Maybe you’re moving from CSV files into a Lakehouse. Maybe an upstream system changed and now your model needs to point somewhere else entirely.

Your first instinct might be to rebuild everything from scratch.

In many cases, that’s unnecessary.

I recently discovered a workflow that allows you to swap out the semantic model underneath an existing report while keeping the report itself intact. Once you understand the process, it only takes a few minutes.

When This Approach Is Useful

#

This technique works well when:

• The new data source contains the same logical tables as the old one
• You want to preserve an existing report and its visuals
• You’re migrating between storage or connectivity mechanisms
• Rebuilding the report would be time-consuming

Examples include:

• Direct Lake to SQL Endpoint
• CSV files to Lakehouse tables
• One database connection to another database with matching schema

Overview

#

The basic idea is:

1. Build a new semantic model against the new data source.
2. Recreate relationships, calculated columns, and measures.
3. Use PBIP project files to swap the semantic model underneath the original report.

Because the report continues to reference the original semantic model name, the visuals generally continue working without modification.

Step 1: Save the Existing Report as PBIP

#

From Fabric, download or save a copy of the existing report.

Open it in Power BI Desktop and save it as a Power BI Project (PBIP).

This will create a project structure containing folders similar to:

My Report.Report
My Report.SemanticModel
My Report.pbip

Step 2: Create a New Semantic Model

#

Create a new Power BI report.

Connect it to the new data source and import the tables you need.

Important: Keep the table names identical to those used in the original semantic model.

If table names differ, you’ll likely create additional work later.

Step 3: Recreate Relationships

#

For a simple model, manually recreate the relationships.

For larger models, use TMDL.

In the original report:

1. Open TMDL View.
2. Switch the Data pane from Tables to Model.
3. Expand Relationships.
4. Select all relationships.
5. Drag them into the TMDL editor.
6. Copy the generated TMDL.

In the new report:

1. Open TMDL View.
2. Paste the copied relationship definitions.
3. Click Apply.

Verify the relationships appear correctly in Model View.

Step 4: Recreate Calculated Columns

#

Next, recreate any calculated columns.

Unfortunately, I haven’t found a particularly elegant way to identify these beyond recognizing the calculated column icon within the model.

You can either:

• Copy and paste the DAX manually, or
• Transfer them using the same TMDL process used for relationships

Step 5: Recreate Measures

#

Measures can also be recreated manually or through TMDL.

For a small number of measures:

• Copy the DAX
• Create the measures in the appropriate tables

For larger models:

1. Switch to TMDL View.
2. Expand Measures.
3. Select all measures.
4. Drag them into the TMDL editor.
5. Copy the generated code.
6. Paste it into the new model’s TMDL editor.
7. Click Apply.

Once complete, verify all measures appear as expected.

Step 6: Verify the New Model

#

Before moving on, spend a few minutes validating the model.

Check that:

• All expected tables exist
• Relationships are present
• Calculated columns have been recreated
• Measures have been recreated
• Visual calculations and dependencies don’t show errors

It is much easier to fix issues now than after the model swap.

Step 7: Save the New Model as PBIP

#

Save the new report as a PBIP project.

Close both reports.

You should now have two project structures:

Old Report.Report
Old Report.SemanticModel

New Report.Report
New Report.SemanticModel

Step 8: Swap the Semantic Model

#

This is where the magic happens.

Navigate to the PBIP folders in File Explorer.

Rename the original semantic model folder:

Old Report.SemanticModel

to:

Old Report.SemanticModel.old

Then rename the new semantic model folder:

New Report.SemanticModel

to:

Old Report.SemanticModel

In other words, replace the semantic model folder while preserving the name expected by the original report.

The original report will continue looking for a semantic model with the same name, but it will now be loading your newly created model instead.

Step 9: Open the Original PBIP

#

Open:

Old Report.pbip

If everything was recreated correctly:

• The report opens successfully
• Visuals load normally
• Measures resolve correctly
• Data is sourced from the new semantic model

At this point, your report is effectively pointing at the new data source.

Step 10: Save and Publish

#

Save the report as a standard PBIX file.

Publish it back to Fabric.

One quirk I’ve noticed is that Power BI may occasionally publish a second report with the same name rather than overwriting the existing one.

If that happens, you may need to remove the old report manually from the workspace and republish.

Why This Works

#

A PBIP project separates the report layer from the semantic model layer.

By recreating the semantic model and then swapping it into the original project’s expected location, you’re effectively replacing the engine underneath the report while leaving the report itself untouched.

As long as the expected tables, relationships, columns, and measures continue to exist, the report generally doesn’t care where the data originally came from.

Caveats

#

This is not the correct solution for every migration.

In some scenarios, Power Query changes are faster.

In others, parameterization or source replacement may be the better approach.

The value of this technique is that it allows you to preserve an existing report structure while replacing the semantic model underneath it.

If your schema is similar and rebuilding the report would be painful, this can save a surprising amount of time.

Final Thoughts

#

I wish I had learned this sooner.

I’ve seen multiple projects where teams spent hours rebuilding models after moving from one connectivity method to another. Once you understand the PBIP and TMDL pieces involved, the process becomes straightforward and can often be completed in just a few minutes.

If you’re working heavily with Fabric, Direct Lake, SQL Endpoints, Lakehouses, or evolving data architectures, this is a useful trick to keep in your toolbox.

And if you’re not sure whether this is the right approach for your scenario, there are often shortcuts available through Power Query or other model migration techniques that may be even simpler.