Power BI Tenant Migration: Trade-offs, risks, and realities

Power BI tenant migrations have shifted from a niche topic to a regular field conversation, usually triggered by an acquisition, divestment, data residency requirement, or overdue modernisation.

This post complements the official Microsoft Learn documentation on Power BI tenant migration patterns and strategies. While the documentation covers the end-to-end process, this post focuses on how to decide if a tenant migration is the right choice—and the trade-offs to evaluate before committing.

Across most customer engagements, one principle seems to hold true: tenant migration is typically a trade-off between potential gains and added complexity. This post covers common triggers, migration types, key risks, and scenarios where the benefits may justify the effort. The goal is to help you weigh that trade-off before the project gathers momentum of its own

Why we are seeing more tenant migration requests

Over the past year, there has been an uptick in tenant migration conversations. Most fall into one of the following patterns.

Power BI tenants created before a regional data centre was available. Many organizations set up their Power BI tenant before Microsoft had a data center in the region they wanted, so the home tenant region was chosen by necessity rather than preference. Now that the regional footprint has expanded, many are revisiting that decision, especially where latency, residency, or sovereignty matter more.

The Premium-to-Fabric SKU transition. As customers move from Power BI Premium P SKUs to Fabric F SKUs, the SKU change often becomes a natural point for a broader architectural review, including whether the tenant is still in the right home region. 

Maturing data residency and sovereignty regulation. Industry and jurisdictional requirements have tightened. What was acceptable two years ago may no longer satisfy a regulator or internal compliance review, particularly in financial services, healthcare, and the public sector.

Mergers, acquisitions, and divestments. Corporate activity continues to surface tenant questions of its own: whether to consolidate, separate, or run in parallel. 

Types of Power BI tenant migration

Before going further, it is worth being precise about terminology. “Tenant migration” covers three distinct scenarios that differ across risk, cost, and duration profile: side-by side (cross-tenant) migration, tenant split, and tenant remap.

Side-by-side (cross-tenant) migration

This scenario commonly arises after an acquisition. Two separate tenants run in parallel, and artifacts are moved individually. The process can be lengthy, but it carries relatively low risk of data or artifact loss and usually causes minimal end-user downtime because you control when users move across. The trade-off is cost: licensing and capacity must be maintained in both tenants, and M365 user and group migration must be planned.

 Figure: Cross-tenant migration workflow between source and target tenant.

Tenant split

A tenant split usually happens during a divestment or spin-off in which one Power BI tenant must be separated into two independent tenants. Unlike an acquisition, this requires selectively carving out the artifacts, data, workspaces, and users that belong to the departing business while leaving the rest untouched. That adds complexity because dependencies, shared datasets, gateways, and capacity assignments must all be untangled. As with a side-by-side migration, M365 user and group migration must also be planned.

 

Figure: Tenant split migration workflow between source and target tenant.

Tenant remap (tenant relocation)

This scenario is the most complex. To relocate the home tenant region while keeping the same Microsoft 365 tenant and domain, you must request a tenant remap through Microsoft Support. The process deletes the existing Power BI tenant and creates a new, empty tenant in the target region linked to the original Microsoft 365 tenant. That preserves the Power BI or Fabric tenant ID and user access, but Microsoft only handles the deletion and remap. Migration remains your responsibility, so you need a clear rehydration plan for data and artifacts. Downtime may range from three to 24 hours, with additional time needed to restore content.

 Figure: Tenant remap (relocation) migration workflow.

Consider the alternatives

In many cases, tenant migration isn’t required. Several alternatives can meet the same goals with significantly less effort and risk. Depending on the requirement, alternatives such as multi-geo deployment, custom Azure relay, or bring your own storage account fo dataflows may address residency, performance, or architectural concerns without requiring a full tenant migration. 

 

 Figure: Decision tree for alternative options to tenant migration.

Understanding the risks

There is no one-click Power BI tenant migration tool, and Microsoft Support plays a limited role. Migration inside the tenant is entirely customer-led: scripted where the Admin APIs allow it, manual where they do not, and fully validated by the customer.

Before you begin, it’s important to understand where complexity and risk typically arise. In practice, these factors can affect both timeline and outcome.

Fabric items require additional planning 

Most Power BI items support definition export through the Admin APIs, but most Fabric items do not. Git integration helps for some Fabric item types: you can commit a definition, unlink it in the source, and relink it in the target. But Lakehouse delta tables and schemas do not come with it.

If a tenant contains significant Fabric content, expect this portion of the migration to require additional planning and effort.

Some Power BI items must be rebuilt

Not all Power BI items support programmatic migration. For example, apps, dashboards, row-level security role memberships, and dataset refresh schedules must be rebuilt manually in the target tenant. Tenant- and capacity-level governance, such as tenant settings, must also be reconfigured.

Backup validation is critical for tenant remap scenarios

In a tenant remap, the source Power BI tenant is deleted and recreated in a new region. This makes backup validation especially important. A backup is complete only once all required items have been verified and can be successfully restored, not simply when export scripts complete.

A comprehensive inventory (including workspaces, reports, semantic models, dataflows, gateways, Fabric items, and governance settings) can help ensure nothing is missed, then cross-check it against the backup output. Build confidence in the backup strategy through multiple pilots before you migrate.

Personal workspaces require special handling

There is no supported method to move content directly between users’ My Workspace across tenants. In practice, you can export content into a per-user Pro workspace in the target tenant, then ask users to claim and reorganise it, but the operational overhead is high.

Most organizations leave personal workspace content behind. If you take this approach, communicate it early so users have time to move anything important into a shared workspace before cutover.

Data is not included in artifact migration

Tenant migration moves definitions, not data.

After migration, semantic models require refresh before they are usable. The same is true for Lakehouses and other Fabric data stores: the artifact definition can be recreated, but the underlying data must be reingested through a pipeline, a Dataflow, or another ingestion path in the target environment. None of this happens automatically.

During validation, this can create a spike in refresh and ingestion activity. Planning for temporary capacity scaling during this phase can help avoid contention.

Identity and licensing must be remapped (cross-tenant migrations only)

In a tenant remap, user object IDs are preserved. In a side-by-side migration or tenant split, user object IDs change, so every workspace and artifact permission must be remapped. Power BI licence assignments also need to be recreated through Microsoft 365 and Microsoft Graph, not the Power BI APIs.

Downstream dependencies need to be updated

Embedded reports in SharePoint, Power Apps, Power Automate, Teams, and bookmarked links all point to Power BI URLs that change after cutover. These references need to be catalogued during discovery.

Plan for realistic timelines 

Tenant migrations typically involve extensive planning, communication, and validation—especially in larger environments.

Running pilots and completing discovery work early can help reduce risk and improve predictability during execution.

If an existing P SKU capacity is expiring before that work can finish, a same-region capacity migration to F SKU first is usually the right move.

Understanding the benefits

Despite the complexity, there are cases where a tenant migration is the right call—primarily when requirements cannot be met through alternative approaches.

Strict data residency requirements 

Tenant migration may be appropriate when regulatory requirements extend beyond data storage to include metadata, settings, policies, or identity information, that must remain in a specific region. Capacity-region controls alone are not enough but confirm that this requirement genuinely applies before committing.

Pro workspaces and personal workspaces 

Content in Pro workspaces, Premium Per User workspaces, and My Workspaces is pinned to the home tenant region. It cannot be relocated by reassigning capacity because no capacity sits in front of it. If that content is material to the business or falls within a residency boundary, a tenant move may be the only practical option.

A small tenant with only supported items

Tenant size is a key factor in determining migration effort. A small tenant, for example one with fewer than fifty workspaces and mostly Power BI items well supported by the Admin APIs, is genuinely manageable. Many customers choose to migrate at this stage, before the estate grows and Fabric adoption accelerates.

As tenants grow—especially with increased Fabric adoption and shared dependencies—the effort and risk can increase significantly. If a migration is already on the horizon and the tenant is still small, moving sooner is often the more rational choice.

Fabric trial capacities in the home region 

Fabric trial capacities are created in the home tenant region and cannot be relocated. On their own, they rarely justify a tenant migration. If the content matters enough to preserve, it belongs on a paid capacity placed in the correct region from the outset.

M&A and divestment scenarios where co-existence is not viable 

In acquisitions and divestments, regulatory, branding, or operational constraints can make co-existence impractical. When the cost of running in parallel outweighs the migration effort, migration becomes the more practical path forward.

Next steps

If you have considered the alternatives, clarified the scenario, and decided that migration is the right move, use the official Microsoft Learn documentation — Power BI tenant migration patterns and strategies — for a full understanding of the process: discovery, user and security mapping, communications, target tenant readiness, pilot, execution order, validation, and cutover. Treat it as the backbone of your runbook.

 

 Figure: End-to-end steps for performing a tenant migration.