Tenant-to-Tenant Power BI Migration

Tenant-to-tenant migrations are often needed as part of merger and acquisition (M&A) deals or divestitures, or to consolidate multiple tenants. While migrating some Microsoft 365 workloads, such as Exchange, is fairly straightforward, migrating Power BI is extremely complex — and there are no native or third-party tools to assist with planning and execution.

To help, we’ve developed a framework to guide a Power BI migration from one tenant to another. This blog provides a brief overview of the framework.

What is Power BI?

Power BI is an interactive data visualization solution that turns data into coherent business intelligence. Power BI lets teams easily connect to disparate data sources, discover and visualize what’s important, and share that with anyone. The insights and analytics provided by Power BI are often business-critical.

Components of Power BI include:

• Workspace — A container for dashboards, reports, workbooks, datasets, and dataflows
• Report — A set of charts, maps, and other visualizations, all of which come from a single dataset
• Dashboard – A  canvas that contains tiles and widgets
• Data source — Any of the numerous data repositories that the Power BI service can connect to
• Gateway — A bridge to provide quick and secure data transfer of on-premises data
• Dataset — A collection of data that you import or connect to
• Dataflow — Data prepared and staged for use by datasets
• Sensitivity labels — Labels from Microsoft Purview Information Protection (previously called Microsoft Information Protection) that tag sensitive content

Why is a tenant-to-tenant Power BI migration a challenge?

As you can see, Power BI is not just a set of static reports; it relies on data generated in external systems and imported through connectors and gateways. It is not feasible to simply move a report and all the associated components from one tenant to another in a single action.

Indeed, there are complexities in migrating all of the components listed above. Here are some of the top issues in a Power BI migration:

Data sources and gateways

Data that resides in the source tenant may need to be migrated to the target tenant and its location updated. For on-premises data sources, a new gateway must be configured in the target tenant. And if a gateway was created by a user, the migration team will need to help the user reconfigure it for the new tenant.

Reports

Power BI reports can typically be exported to .pibx files that can then be imported into the target tenant. But permissions updates are required to ensure continued access to reports. Getting an accurate mapping can be a challenge because Power BI has multiple layers of permissions, from the workspace level through to the datasets, and can even employ row-level data security.

Datasets

Sensitivity labels apply encryption to Power BI datasets and exported report content, so they can complicate dataset migration.

Dataflows

Dataflows have to be recorded and recreated in the target tenant.

Tips for a successful Power BI migration

• Move as little as possible. Work with business stakeholders to determine what is critical and what can be left out of the Power BI migration.
• Procure all required licenses and capacity in advance of any user or content migrations.
• Prepare data sources and gateways in advance of the first migration job.
• Start with small pilot migrations that can be reverted with minimal business impact.
• Overcommunicate with stakeholders throughout the process.
• Do not decommission the source until required.

A framework for Power BI migrations

We have created a framework as a guide for planning and executing a cross-tenant Power BI migration. It includes four phases: analysis, planning, migration, and remediation.

These phases comprise ten steps, as illustrated in Figure 1. Note that this workflow is not one-size-fits-all; in some situations, some steps might not be applicable or a step might span multiple phases.

Phase I. Analysis

Step 1: Inventory your Power BI data components.

Start by collecting an inventory of the data components that could be eligible for migration, along with their associated administrators, owners, and users. At a minimum, be sure to inventory all components listed earlier.

Step 2: Understand Power BI usage.

Determine how much is Power BI being used and who is using it. In addition, analyze the subscriptions of both tenants to ensure you have enough licensing and capacity to transition without interruptions or delays.

Step 3: Determine the criticality of each component.

Work with business stakeholders to determine which components are critical to business operations and which are not. Utilization reports do not tell the whole story. For example, a report that has been accessed a lot over the last 30 days might be obsolete by the time of the migration, or conditions of your M&A might require certain content to be deleted.

Phase II. Planning

Step 4: Scope the migration.

Flesh out the scope of your Power BI migration by digging deeper into the components flagged for migration. For example, if multiple reports rely on the same dataset, it is usually best to migrate the reports together.

Step 5: Determine migration paths.

When migrating traditional Microsoft workloads, you have three pathways: migrate, do not migrate, and archive. But those options aren’t sufficient for a Power BI migration. Accordingly, we developed the “6 R” classification shown in Figure 2.

Step 6: Batch the workspaces for migration.

Be sure not to move Power BI content until the accounts that use it are licensed to access the new tenant, and the source data will be accessible. Also, pay attention to workspace type; Shared workspaces can be batched together based on the accounts that access them, while personal workspaces are typically migrated with the user account that owns them.

Step 7: Schedule the migration jobs.

Keep the following tips in mind:

• Personal workspaces can only be moved after the accounts are licensed for Power BI in the new tenant.
• Shared workspaces can be moved before all associated accounts are migrated, but it is best to ensure that the administrators are active in the new tenant.
• The Power BI Service employs throttling on API use, which can cause delays in batch moves.

Phase III. Migration

Step 8: Communicate.

Let users know when their content is scheduled to be moved and inform them when it is available in the new tenant. Explain any steps they must complete, such as updating authentication to the source data, re-creating personal gateways to their workstations, refreshing their reports, or manually copying workbooks that could not be migrated.

Step 9: Move.

The Power BI migration itself involves creating shared and personal workspaces in the target tenant and assigning proper permissions; exporting the reports (and possibly their datasets) to a file, and importing the content into the new tenant. Then you may need to complete some additional tasks, such as updating permissions for shared datasets, rebinding reports to shared datasets, updating access permissions to shared and personal workspaces, and handling sensitivity labels.

Phase IV. Remediation

Step 10: Remediate

Finally, you need to ensure that the Power BI content is available to the appropriate users and that the reports are connected to their source data. Steps can include updating the source data connections, re-authentication for data sources, and refreshing report data.

Conclusion

Power BI is a business-critical workload, so ensuring it is moved accurately and securely is vital to the success of your tenant-to-tenant migration. There are no native or third-party tools to help with migrating Power BI, but the ten-step framework described above can guide your project and help you achieve your goals.