Workspace migration between different regions

Administration, MS Fabric, Power BI

Workspace migration between different regions

One of my first articles here was Core concepts of Power BI Service. In this article I explain a lot of important concepts like Tenant, Capacity and Workspace. Understanding them is critical for this article, make sure to catch up if these terms are blurry to you.

Problem statement

Workspace migration between different Capacities is rather a standard practice. You can do it to balance the workloads between your Capacities, or when you see an opportunity to consolidate smaller Capacities into a bigger one. Why moving the workspace to different Capacity Region? That’s a bit different story.

It often happens that companies want to move their entire Tenant to different Region, maybe they bought a new Capacity that is closer to end users, or simply Workspace was created in wrong Region by mistake. With introduction of Fabric, there is another reason why might want to move your Workspaces. Price of Fabric Capacities, like everything in Azure, is heavily dependent on region. As a part of cost optimization for your company, you might decide to move your assets to different region, that is still close to your end users but maybe it’s significantly cheaper.

Regardless of the reason, if you are thinking about cross-region migration, you must be aware what can go wrong.

What works just fine

Let’s start with the most basic scenario -your workspace contains Power BI Reports and standard Semantic Models (Large Semantic Model Storage format is not enabled). In this scenario you are good to go. When you move you Workspaces to different Capacity Region, everything will work as expected. What can go wrong?

Fabric Artifacts

If your Workspace contains any Fabric Items, Workspace will not be moved to a different region – period. There are no conditions that make it possible, you will simply see an error like the one below:

*Figure 1. Error while moving a Workspace with Fabric items to a different region.*

Unlike regular Power BI Semantic Models, Fabric Items are heavily dependent on underlying infrastructure and data storage specific for the selected region. Changing this behavior requires original infrastructure to be re-created in new region and destroyed in original one. Not sure if this will be possible at any point of time. What can be done with Fabric Items? Git integration feature can help here, and I will try to show it in next article.

Workspaces with Fabric Items Workspaces containing Fabric Items can't be moved to different Region.

Power BI Large Semantic Models (LSMs)

As much as there is no problem with standard Semantic Models, Large Semantic Models are completely different game. I tried to explain this feature in my previous article: Large Semantic Models Storage Format. In this scenario, we are closer to Fabric Items case. Due to the fact the Large Semantic Models use PremiumFiles storage format under the hood, we deal with the setup that is tightly integrated with underlying infrastructure. However, behavior is slightly different here. As explained in previous article, we have two different behaviors suggested in official communication, and only one is correct:

Workspaces with Large Semantic Models You are allowed to move Workspaces containing Large Semantic Models, but reports linked to them will stop working. You will not be allowed to refresh these models either.

Why does it work like that? System allows to move Workspaces with Large Semantic Models but not the models themselves. As their storage is tied to original region, models stay in that region while reports and model definition are being moved. This makes it impossible to refresh this Semantic Model anymore, and Reports will not be able to fetch the data from them. In this scenario, Reports based on Large Semantic Models must be republished. Is there any exception? Yes, there is. In previous article, I was talking about benefits of LSMs and the most obvious one is that it allows your Semantic Models to grow beyond 10 GB limit. But there are more benefits. If size limit was not your concern, and you enabled the setting due to other reasons, you might disable the LSM setting before workspace is being moved to different Capacity Region and enable it again once Workspace is already migrated. But this will of course work only for the models smaller than 10 GB. Otherwise, you will not be able to disable the setting, unless you manage to reduce the size of the model. It won’t work if you try to disable the LSM setting after workspace is already migrated. It must be done before the migration.

This sounds relatively simple, but what if you have dozens / hundreds of workspaces to be migrated, and you are not even sure how many LSMs you have there? On top of that, it takes some time to disable the LSM setting on your model, and this change must be completed before you move workspace. If you move workspace too soon, while the change is still “spinning”, your update will be stuck. It will force you to move the Workspace back to previous region and wait for the change to complete. This already sounds as a quite complex process, especially when we talk about large numbers of Workspaces and Semantic Models impacted. In one of next articles, I will show you a programmatic approach to solve this problem using PowerShell.

Dataflows (Gen 1)

I added Gen 1 in brackets, as Dataflows Gen 2 are covered within Fabric Items section – like any other Fabric Item, Dataflows Gen 2 can’t be moved between Capacity Regions. Dataflows Gen 1 can be moved to different Capacity Region, but you should be aware of few things. First – you may not be able to refresh them shortly after Workspace is migrated. It should be resolved in a matter of 15-30 minutes, but during that time you may get following error:

Dataflow refresh error - Capacity migration is in progress. — *Figure 2. Dataflow refresh error – Capacity migration is in progress.*

Second problem might appear (it doesn’t appear always) for Dataflows using Enhanced Compute Engine feature. In this scenario, you may turn off the setting (even after workspace was migrated), refresh your Dataflow and turn on the setting again. This should help you solve this refresh error which looks as follows:

Figure 3. Dataflows refresh error – The operation failed likely due to cross-region migration.

Luckily for us, Dataflows Gen 1 scenario is not that serious, still, it’s good to know what may happen during migration.

Conclusion

Cross-region workspace migration is a serious task and must be properly planned. Let’s summarize quickly what already know regarding different types of Power BI / Fabric Artifacts:

Power BI Reports based on SSMs (Small Semantic Models) – no issues with migration
Power BI Reports based on LSMs – Workspace can be migrated but Reports don’t work anymore.
Dataflows Gen 1 – small problems may occur but in general it is possible to migrate the items
Fabric Items – Workspace can’t be migrated to different Capacity Region

In next articles we will discuss the programmatic approach to handle LSMs with PowerShell, as well as how to handle Fabric Items.

For now, as always thank you for reading and see you in next article 🙂

Pawel Wrona

Lead author and founder of the blog | Works as a Power BI Architect in global company | Passionate about Power BI and Microsoft Tech

Did you enjoy this article? Share with others :)

5 2 votes

Article Rating

Comments notifications

0 Comments

Oldest

Newest Most Voted

Inline Feedbacks

View all comments