Moving a Power BI tenant from one Azure AD tenant to another — because of a merger, a rebrand, or a platform consolidation — sounds like a weekend project until someone asks what happens to the 40 live dashboards executives check every Monday morning. The steps below walk through a phased approach that keeps reporting live in 2026 while workspaces, datasets, and gateways move in the background.
- Migrating a Power BI tenant without downtime in 2026 means phased, workspace-by-workspace cutover, not a single weekend event.
- Gateway and credential remapping causes more outages than dataset migration itself — sequence it first, not last.
- Azure AD B2B guest access lets source and destination tenants run in parallel during the transition window.
- Budget 4-8 weeks per 100 workspaces depending on gateway count and row-level security complexity.
- KnackForge's Power BI migration services use pilot-group cutover to catch breakage before it hits the whole business.
Why this matters
A Power BI tenant holds more than reports — it holds workspace permissions, row-level security (RLS) rules, on-premises data gateway registrations, scheduled refresh credentials, and embedded links inside Teams, SharePoint, and custom apps. Move the tenant wrong and none of that comes with it automatically.
Most teams underestimate this because the Power BI service itself doesn't have a native "move tenant" button. Every workspace, dataset, and gateway connection has to be recreated or reassigned in the destination tenant, and if the sequence is wrong, refreshes silently fail for days before anyone notices a dashboard is stale. Power BI migration services exist mainly to catch that sequencing problem before it reaches production.
What you'll need
- Admin access to both the source and destination Azure AD tenants (Global Admin or Power Platform Admin role)
- A full workspace and dataset inventory from the source tenant (Power BI admin portal or the Power BI REST API)
- An on-premises data gateway inventory, including cluster membership and data source credentials
- A row-level security (RLS) audit for every dataset with restricted access
- A pilot group of 3-5 low-risk workspaces to test the migration sequence before the full move
- A rollback window of at least 48 hours per wave, in case a wave needs to be reversed
- A completed RFP scoped for the migration if the work is going to an outside vendor rather than an internal team
The steps
1. Audit the source tenant completely
You can't migrate what you haven't counted. Pull a full inventory of every workspace, dataset, dataflow, and app in the source tenant using the Power BI REST API or the admin portal's tenant settings export.
Flag every dataset that uses RLS, every workspace with external guest users, and every report embedded outside the Power BI service (Teams tabs, SharePoint pages, custom web apps). Missing even one embedded report here means a broken link discovered by an end user, not by you. Expected outcome: a spreadsheet-level map of every asset, its owner, and its downstream dependencies.
Common mistake: auditing only workspaces you know about. Shadow workspaces created by individual analysts routinely account for 15-20% of total assets in mid-size Power BI tenants.
2. Map identity and permissions between tenants
Every user, security group, and service account tied to a workspace in the source tenant needs an equivalent in the destination tenant before migration starts. This is the step most teams try to skip, and it's the one that breaks RLS silently.
Build a mapping table: source Azure AD object ID to destination Azure AD object ID, for every user and group referenced in RLS rules or workspace access. Expected outcome: a permissions map that lets you validate RLS post-migration instead of discovering broken access weeks later.
Common mistake: assuming email addresses carry over. Azure AD object IDs change even when the user's email stays identical, which breaks any RLS rule built on object ID rather than UPN.
3. Stand up destination tenant infrastructure first
Provision Power BI capacity (Premium or Fabric capacity, depending on your 2026 licensing model), register the destination tenant's on-premises data gateways, and recreate service accounts before a single workspace moves.
This step runs entirely in parallel with production — nothing in the source tenant changes yet, so there's zero risk of downtime here. Expected outcome: a fully functional, empty destination environment ready to receive workspaces.
Common mistake: reusing the source gateway cluster instead of standing up a new one. A shared gateway cluster across two tenants creates a single point of failure during cutover.
4. Run a parallel pilot migration
Migrate your 3-5 pilot workspaces using the Power BI REST API's workspace export/import or a third-party migration tool, then validate refreshes, RLS, and report rendering in the destination tenant while the originals still run live in the source tenant.
Let the pilot run for at least one full refresh cycle — daily datasets need a minimum of 3-4 days validated side by side. Expected outcome: a confirmed migration sequence with known timing per workspace, which you'll use to estimate the full rollout.
Common mistake: treating the pilot as a formality and rushing to the full migration after a single successful refresh. One clean cycle doesn't catch scheduled-refresh credential expiry, which often surfaces on the second or third run.
5. Migrate datasets and reports in waves
Group remaining workspaces by business unit or reporting cadence and migrate them in waves of 10-20 workspaces, never all at once. Each wave gets its own validation window before the next one starts.
During each wave, keep the source workspace live and read-only rather than deleting it immediately — this is what makes the migration "no downtime" instead of "brief downtime." Expected outcome: business units keep working off the source tenant until their specific wave is validated in the destination.
Common mistake: deleting source workspaces the moment the destination version looks correct. Give each wave a minimum 48-hour parallel-run window before decommissioning anything.
6. Cut over consumption and communicate the switch
Once a wave is validated, redirect the URLs users actually click — bookmarks, Teams tab embeds, SharePoint links, and email report subscriptions — to the destination tenant workspace.
Send a short notice to each business unit at cutover, not before, so support tickets map to the actual switch rather than a rumor. Expected outcome: users land on the destination tenant without noticing a functional difference in the report itself.
Common mistake: cutting over the backend but forgetting embedded Teams tabs, which cache the old workspace ID and keep pointing at the source tenant until manually re-added.
7. Decommission the source tenant in stages
Only after the full validation window closes — typically 2-4 weeks after the last wave cuts over — start removing workspaces, gateway registrations, and service accounts from the source tenant.
Keep a read-only export of the source tenant's dataset definitions and RLS rules for at least one full reporting cycle after decommission, in case an auditor or finance team asks for historical configuration. Expected outcome: a clean source tenant with zero orphaned Power BI assets and a documented, reversible migration trail.
Plan your Power BI tenant migration
Get a workspace-by-workspace migration plan scoped for zero downtime.
Troubleshooting
Row-level security stops filtering correctly after migration. This almost always traces back to RLS rules built on Azure AD object IDs that weren't remapped in step 2. Rebuild the identity mapping table and reapply RLS role assignments in the destination workspace.
Scheduled refreshes fail silently 2-3 days after cutover. Data source credentials stored against the old gateway cluster don't carry over automatically. Re-enter credentials against the destination gateway cluster for every dataset, not just the ones that failed first.
Embedded reports in Teams or SharePoint show "report not found." The embed still references the source workspace ID. Re-embed the report using the destination workspace's report ID rather than editing the existing embed URL.
Two workspaces end up with identical names, confusing users. This happens when source workspaces aren't renamed or archived during the parallel-run window. Append "(legacy)" to source workspace names the moment their wave cuts over.
Gateway cluster shows as offline in the destination tenant. Cluster membership doesn't transfer with a simple gateway reinstall — each machine in the cluster needs to be individually re-registered against the new tenant's gateway resource.
If a wave fails validation and needs a full reversal, that's the point of the parallel-run window — a documented disaster recovery plan for the migration itself, not just the destination environment, is what makes rollback a non-event instead of an emergency.
Tools and resources
- Power BI REST API and PowerShell cmdlets for bulk workspace export/import
- Power BI admin portal tenant settings export for the initial audit
- Azure AD B2B guest access to run both tenants in parallel during migration
- On-premises data gateway management console for cluster re-registration
- A managed services partner for multi-cloud enterprises if the destination tenant sits on infrastructure your internal team hasn't operated before
What to do next
Once the tenant migration itself is validated, the harder work is usually consolidating the data sources feeding those Power BI datasets — especially in M&A scenarios where two companies' data platforms need to become one before reporting can fully unify.
FAQ
What's the best way to migrate a Power BI tenant without downtime?
Migrate workspaces in waves of 10-20 while keeping the source tenant live and read-only during each wave's validation window. A single big-bang cutover is what causes downtime in the first place.
Is Azure AD B2B required for a Power BI tenant migration?
It's not strictly required, but Azure AD B2B guest access is what lets both tenants stay operational at the same time during the transition. Without it, you're forced into a harder cutover with a shorter validation window.
How long does a Power BI tenant migration take in 2026?
Plan on roughly 4-8 weeks per 100 workspaces, depending on gateway count and RLS complexity. Tenants with heavy on-premises gateway usage run toward the longer end of that range.
Can row-level security rules be migrated automatically?
No, RLS rules built on Azure AD object IDs need to be remapped manually because object IDs change between tenants even when usernames stay the same. This is the single most common cause of post-migration access errors.
What happens to scheduled refreshes during tenant migration?
Scheduled refreshes keep running in the source tenant until that workspace's wave cuts over, then need credentials re-entered against the destination gateway cluster. Skipping this step causes refreshes to fail 2-3 days after cutover, not immediately.
Do embedded Power BI reports in Teams or SharePoint break during migration?
Yes, unless they're re-embedded using the destination workspace's report ID after cutover. The old embed keeps pointing at the source workspace and shows a report-not-found error.
How much does a Power BI tenant migration cost in 2026?
Cost depends heavily on workspace count, gateway complexity, and whether the work is done internally or through a migration partner. Get a scoped estimate based on your specific workspace and gateway inventory rather than a flat industry number.
Is a big-bang cutover ever the right approach?
Only for very small tenants with a handful of workspaces and no on-premises gateways. Anything larger benefits from a phased, wave-based cutover that keeps reporting live throughout the move.
One last thing
The step teams skip most often isn't dataset migration — it's re-registering every machine in an on-premises data gateway cluster individually. A gateway reinstall alone doesn't transfer cluster membership to the new tenant, and that single gap is what causes refreshes to fail two or three days after everyone thinks the migration is done.
