How do you handle semantic model name changes and schema differences during merges?

[jaryszek]

Hi everyone,

I’m looking for advice on the best developer approach when working with multiple semantic models in Power BI.

In our setup, we have a develop semantic model and feature branch models (for example, RES-477). When merging changes from a branch back into develop, we face a challenge:

Fabric doesn’t allow having two semantic models with the same name, so when we can not rename RES-477 to develop, we need to renamed old semantic model develop to a different name, like develop_old, and use the existing one.

The issue is that this new model may have schema changes — some fields removed or renamed, new measures introduced — and the reports that used the old develop model can break as a result. 

How are other developers handling this scenario? Do you follow a specific process or naming convention to avoid report issues during merges?

Best,
Jacek

[jaryszek]

"your semantic model is backwards compatible"

Question is if there are tools to migrate things from one semantic model to another?

Best,
Jacek

[KevinChant]

I think the issue lies with your development process, if you are changing semantic models used by reports then ideally you should be testing that the reports still work in your feature branch as well.

If the reports are elsewhere then you need to make sure that either your semantic model is backwards compatible or actually deploy a brand new semantic model to be used.

[jaryszek]

thank you. 

[v-veshwara-msft]

Hi @jaryszek ,

Thanks for posting this question in Microsoft Fabric Community.

Fabric currently doesn’t support having two semantic models with the same name, so renaming or replacing a model directly can break existing report connections. The common approach is to keep the main develop model name fixed and validate schema changes in a separate workspace or temporary model before merging. Once verified, the changes can be promoted back to develop through deployment or Git integration to maintain report stability.

You can refer to these related discussions for more context:
Solved: Duplicate Reports/Semantic Models in Workspace - Microsoft Fabric Community
Solved: Re: Using seperate workspaces for Semantic Models ... - Microsoft Fabric Community

These threads discuss similar challenges and outline how developers isolate model changes to avoid breaking dependencies during merges.

Hope this helps. Please reach out for further assistance.

Thank you.

[jaryszek]

Thanks but this is not about it. 

Semantic model is remote one so it means that it will be not saved to disc using git. 

I need to use rest apis to renames semantic model or make a manual changes to connect to different sematnic model. 

Again, 
How to solve it using naming convention ? 
If i have new semantic model created for branch and on develop i have develop, how to maintain continuity?

Best Wishes,
Jacek

[v-veshwara-msft · Accepted solution]

Thanks for the clarification, Jacek.

When the semantic model is remote and not connected through Git, renaming via REST API isn’t supported in a way that keeps the same object ID. If a model is renamed or replaced, reports will treat it as a new object, so maintaining continuity depends on using a consistent naming convention and connection process. The usual approach is to keep a consistent model naming pattern for each environment or branch (for example, develop, feature_477, staging) and reconnect reports only after the structure has been checked for compatibility.

For migrating schema or measure definitions between models, tools like ALM Toolkit and Tabular Editor are the standard approach. They allow comparing two semantic models and deploying structural changes such as measures, relationships, or calculated columns without rebuilding the model.

You can check the following for reference:
Solved: Comparing two Semantic Models - Microsoft Fabric Community

Solved: Rename Semantic Model? - Microsoft Fabric Community
External Tools in Power BI Desktop - Power BI | Microsoft Learn

This approach helps maintain version continuity for remote models where Git integration isn’t applicable.

Thanks @KevinChant  for sharing your inputs.

Hope this helps. Please reach out for further assistance.

Thank you.