When planning a Power BI tenant-to-tenant migration, most teams focus on moving workspaces, reports, datasets, and dashboards.
But in real projects, that is only part of the story.
Some Power BI artifacts do not move automatically because they depend on tenant-specific settings, connections, capacities, security groups, gateways, or live endpoints.
Common examples include:
- Power BI dataflows
- Embedded and premium capacities
- Paginated reports
- Power BI Apps
- Scorecards
- Streaming datasets
If these items are not planned properly, reports may fail after migration, refreshes may break, and business users may lose access to important analytics experiences.
This article explains what typically does not migrate automatically and how to prepare for it.
1. Power BI Dataflows
Power BI dataflows are often difficult to migrate automatically because they are tightly connected to the source tenant environment.
A dataflow may depend on:
- Power Query M logic
- On-premises or cloud data gateways
- Stored credentials
- Parameters
- Custom functions
- Data source permissions
- Refresh schedules
- Downstream datasets and reports
Because of these dependencies, simply copying a dataflow to another tenant is usually not enough. The dataflow may open successfully but fail during refresh because credentials, gateways, or source references are no longer valid.
How to handle dataflow migration
A safer approach is to rebuild and validate dataflows in the target tenant.
Recommended steps:
- List all workspaces that contain dataflows.
- Identify business-critical dataflows first.
- Document each dataflow owner, data source, refresh schedule, gateway, and dependency.
- Export or copy the Power Query M logic from the source tenant.
- Configure equivalent gateways, credentials, and data source permissions in the target tenant.
- Recreate the dataflows in the target workspace.
- Run test refreshes.
- Compare row counts, sample outputs, and key measures with the source tenant.
- Reconnect dependent datasets and reports to the new dataflows.
- Keep the old dataflows until business users confirm that the new setup works correctly.
Dataflows should be migrated in small waves rather than all at once. This reduces risk and makes troubleshooting easier.
2. Embedded and Premium Capacity
Power BI embedded and premium capacity migration is not just about moving content. It also involves architecture, licensing, cost, performance, and governance.
During migration, capacity-related details usually change, such as:
- Capacity assignment
- Capacity region
- SKU selection
- Premium Per User usage
- Premium Per Capacity usage
- Fabric capacity decisions
- Service principal access
- Embedded application configuration
- API permissions
If your organization uses embedded analytics, the migration may also affect application authentication, workspace binding, and capacity assignment.
How to plan capacity migration
Treat capacity migration as a separate workstream.
A practical checklist:
- Map each workspace to its current capacity.
- Identify workspace owners and business criticality.
- Decide the target capacity model.
- Review whether Premium Per User, Premium Per Capacity, or Fabric capacity is the best fit.
- Plan for a coexistence period where both source and target tenants may run in parallel.
- Rebind workspaces to the correct target capacity.
- Validate embedded apps, service principals, APIs, and permissions.
- Monitor performance after each migration wave.
- Adjust capacity size or workload placement if required.
Capacity planning should happen early because it can affect both migration timelines and licensing cost.
3. Paginated Reports
Paginated reports require special attention because they are built differently from standard Power BI reports.
They are based on RDL files and are often used for:
- Pixel-perfect reporting
- Financial statements
- Invoices
- Operational reports
- Export-ready PDF or Excel reports
These reports may depend on specific data sources, credentials, parameters, page layouts, and export settings.
Because of this, paginated reports are usually not migrated automatically as part of a normal Power BI content migration.
How to migrate paginated reports
Use a controlled manual process:
- Create an inventory of all paginated reports.
- Note each report owner, workspace, data source, and usage frequency.
- Export the RDL files from the source environment or retrieve them from source control.
- Configure matching data sources in the target tenant.
- Update credentials and connection strings.
- Upload or republish the reports into the target workspace.
- Test parameters, filters, page layout, exports, and totals.
- Ask business users to validate the final output.
For paginated reports, visual accuracy matters. Always validate exports such as PDF, Excel, and printed layouts before completing the migration.
4. Power BI Apps
Power BI Apps are curated experiences that package reports, dashboards, and navigation for a specific audience.
They usually include:
- Audience targeting
- Navigation structure
- Report grouping
- Permissions
- Security groups
- Workspace connections
During tenant migration, the audience configuration and security groups usually change. Because of this, Power BI Apps generally need to be recreated and republished in the target tenant.
How to recreate Power BI Apps
Before migration:
- Capture the current app layout.
- Document included reports and dashboards.
- Note navigation order and sections.
- Map source security groups to target Microsoft Entra ID groups.
- Identify app owners and publishers.
After migration:
- Recreate the app in the target tenant.
- Rebuild audience settings.
- Validate permissions.
- Publish the app to a pilot group.
- Roll it out to all users after confirmation.
This helps avoid broken access after migration.
5. Scorecards
Power BI scorecards are used to track metrics and business goals. They may depend on linked datasets, owners, thresholds, check-ins, and alerts.
These dependencies are usually tenant-specific, so scorecards may not migrate cleanly through automated tools.
How to handle scorecards
Recommended approach:
- Document all scorecards before migration.
- Capture metric definitions, owners, thresholds, and status rules.
- Identify linked datasets and reports.
- Recreate scorecards in the target tenant.
- Reconnect them to the correct datasets.
- Reconfigure alerts and permissions.
- Ask business users to validate the metrics.
Scorecards should be reviewed with business owners because they often represent executive or operational KPIs.
6. Streaming Datasets
Streaming datasets are another area that requires careful planning.
They may receive data from:
- IoT devices
- Custom applications
- Power Automate flows
- APIs
- Event-driven pipelines
- Real-time monitoring systems
During migration, streaming dataset endpoints and connection strings usually change. If producers continue sending data to the old endpoint, the new reports will not receive live data.
How to migrate streaming datasets
To reduce downtime:
- List all streaming datasets.
- Identify the systems or applications that send data to them.
- Recreate streaming datasets in the target tenant.
- Generate new endpoints or connection details.
- Update producers, APIs, applications, or pipelines.
- Test live data ingestion.
- Confirm dashboard visuals are updating correctly.
- Retire the old endpoints only after validation.
For real-time dashboards, plan a cutover window and communicate it clearly to users.
Summary Checklist
Here is a quick checklist for Power BI migration gaps:
| Artifact | Migration Concern | Recommended Action |
|---|---|---|
| Dataflows | Gateways, credentials, Power Query logic | Rebuild and validate in target tenant |
| Embedded/Premium Capacity | Capacity, licensing, region, APIs | Plan as a separate workstream |
| Paginated Reports | RDL files, layouts, data sources | Export, republish, and test manually |
| Apps | Audiences, permissions, navigation | Recreate and republish |
| Scorecards | Metrics, owners, alerts, linked datasets | Document and recreate |
| Streaming Datasets | Live endpoints and producers | Recreate endpoints and update producers |
Final Thoughts
A successful Power BI tenant-to-tenant migration is not only about moving reports and datasets.
Dataflows, paginated reports, apps, scorecards, streaming datasets, and capacity configurations all need specific planning. These items often fail because they depend on settings that are unique to the source tenant.
The best approach is to identify these gaps early, create a migration checklist, test each artifact type separately, and involve business owners before final cutover.
By treating these items as dedicated migration workstreams, you can reduce downtime, avoid broken reports, and give users a smoother Power BI experience in the new tenant.
