Power BI tenant migrations are not conventional lift-and-shift projects. Workspaces cannot be moved directly between tenants, user and group object IDs change, gateways must be reconfigured, credentials must be re-established, apps and dashboards can require recreation, and Fabric item support varies. Definitions can move without data, and a report can open while pointing to the wrong source or missing a downstream consumer.
Microsoft states that tenant migrations carry significant risk and extensive manual effort and does not provide direct support for moving content between tenants. Datrick uses supervised AI to classify inventory, map dependencies, compare source and target evidence, and draft exception and validation records. AI cannot select content for migration, map identities, approve data transfer, create credentials, deploy artifacts, grant access, switch users, or decommission the source without deterministic controls and accountable owners.
Is a merger, divestiture, tenant consolidation, or regional requirement putting Power BI continuity at risk? Datrick can run discovery, classify migration complexity, and prove the path with one representative workspace.
Confirm that full migration is necessary
Classify the scenario first. A side-by-side migration consolidates separate Microsoft 365 tenants, commonly after an acquisition. A tenant split carves selected business content and users into an independent tenant during a divestiture or spin-off. A tenant remap deletes and recreates the Power BI tenant in a different home region while preserving the Microsoft 365 tenant identity. These scenarios have different identity, coexistence, downtime, and recovery requirements.
Evaluate alternatives. Multi-geo capacity can satisfy many latency and data-residency needs without relocating the tenant. Cross-tenant or guest access, content sharing, capacity relocation within supported boundaries, or managed coexistence can reduce migration scope. A full remap is justified only when requirements include tenant metadata and Microsoft 365 identity residency that capacity placement cannot satisfy.
Build an inventory and migration evidence contract
| Migration layer | Required evidence | Decision supported |
|---|---|---|
| Tenant and capacity | Tenant IDs, home and capacity regions, capacities, SKUs, settings, domains, labels, governance, administrators, and target readiness. | Define boundary, residency, capacity, policy, and platform prerequisites. |
| Workspace and content | Workspaces, item types, definitions, data, size, owner, environment, app, activity, criticality, supported migration path, and complexity. | Select migrate, rebuild, consolidate, archive, retire, or defer. |
| Dependencies | Sources, gateways, credentials, semantic models, reports, dataflows, Fabric items, cross-workspace models, links, APIs, subscriptions, and embedded use. | Determine safe sequence and reveal dependencies that cross the migration boundary. |
| Identity and access | Source and target user and group object IDs, licenses, workspace roles, item permissions, RLS, sharing, service principals, contacts, and owners. | Map least-privilege target access and prevent orphaned content. |
| Validation | Source refresh, row counts, aggregates, DAX controls, report interactions, performance, capacity, security tests, user scenarios, and acceptance owners. | Prove technical and business equivalence in the target. |
| Cutover and recovery | Wave, freeze, delta, coexistence, target release, link changes, communication, rollback, source retention, decommissioning, and evidence. | Control user transition, service continuity, recovery, and closure. |
Use Power BI and Fabric admin APIs, metadata scanning, activity logs, capacity evidence, identity data, and manual documentation for unsupported metadata. Capture tenant settings through an approved method. Inventory My workspaces, external users, service principals, large semantic models, dataflow storage, embedded applications, SharePoint pages, Power Apps, Power Automate, exports, subscriptions, and Excel live connections. Unknown relationships become migration risks.
Assign an artifact-specific migration path
| Artifact | Typical migration treatment | Critical validation |
|---|---|---|
| Workspaces | Recreate in target, assign capacity, settings, roles, contacts, domain, tags, and environment pattern. | Ownership, least privilege, capacity, policy, naming, and target readiness. |
| Gateways and sources | Install or register target gateways, recreate clusters and sources, map identities, and enter approved credentials. | Connectivity, HA, region, permissions, refresh, DirectQuery, and failure recovery. |
| Semantic models | Definition export/import or supported backup and restore; reconnect sources and perform target refresh. | Schema, partitions, data, measures, RLS, refresh, size, performance, and downstream reports. |
| Reports and paginated reports | PBIX or definition export/import; RDL for paginated reports; rebind to target semantic models and sources. | Visuals, filters, bookmarks, RLS, links, exports, performance, and subscriptions. |
| Dataflows | Export and import supported definitions, then configure storage, connections, credentials, destinations, and schedules. | Query logic, outputs, lineage, refresh, incremental behavior, and consumers. |
| Fabric items | Use supported Git or definition paths; recreate unsupported items; migrate or reload data separately. | Item support, dependencies, data state, connections, execution, security, and capacity. |
| Dashboards and apps | Plan manual recreation where no direct path exists; rebuild audiences, navigation, tiles, links, and distribution. | Content binding, permissions, user entry points, subscriptions, and adoption. |
| External references | Update embedded URLs, SharePoint, Power Apps, Power Automate, APIs, bookmarks, documentation, and service desk records. | No source-tenant references remain after cutover except approved coexistence. |
Recreate upstream foundations before downstream artifacts. Establish capacities, workspaces, identities, gateways, sources, and connections; then data and Fabric foundations, dataflows and semantic models, reports and dashboards, apps and external integrations. Skipping dependency order creates broken references and repeated rework. A Git sync can remove target items not represented in the repository, so use clean, controlled workspaces and explicit scope.
Map identities, permissions, and licenses
In cross-tenant migration and tenant splits, source and target users and groups have different object IDs. Build a controlled mapping from each source identity to a target identity or approved disposition. Include workspace roles, item permissions, Build, RLS groups, app audiences, subscriptions, ownership, contacts, external users, service principals, and licenses. Unmapped identities block cutover; silent substitution creates access risk.
Target users and groups must exist before permission restoration. Prefer managed groups to recreating thousands of direct grants. Reassess access against the target operating model rather than copying known excess privilege. Preserve the source permission record and target effective-access result for audit.
Operate migration as a controlled evidence pipeline
- Discover: collect tenant, workspace, item, source, identity, permission, activity, capacity, and dependency evidence.
- Decide: assign owner, criticality, migration wave, target architecture, artifact path, identity mapping, test scope, and disposition.
- Prepare: configure target tenant settings, capacities, domains, workspaces, identities, gateways, connections, secrets, and monitoring.
- Extract and protect: export definitions or backups, record checksums and versions, capture source controls, and log unsupported items.
- Deploy in order: create upstream foundations, migrate definitions and data, bind dependencies, configure schedules, and restore access.
- Validate: compare inventory, data, calculations, security, refresh, reports, integrations, performance, capacity, and business scenarios.
- Cut over: freeze or control changes, run delta steps, update links and apps, grant users, communicate, monitor, and retain recovery options.
- Stabilize and close: resolve defects, transfer ownership, document operations, remove approved source access, and decommission only after sign-off.
Every migration record should contain source and target IDs, artifact version, dependency map, method, status, attempt, error, validation result, owner, approver, and exception. AI can summarize failures and suggest likely shared causes. It must cite the source evidence and leave the migration state machine under deterministic control.
Validate business continuity, not only artifact counts
Definitions do not include all operational state or data. Microsoft explicitly notes that imported semantic model definitions require at least one refresh in the target tenant. Validate source and gateway connections, credentials, row and partition counts, key aggregates, DAX controls, data freshness, RLS, report interactions, exports, subscriptions, apps, embedded scenarios, API calls, and external links.
Measure performance and capacity under representative concurrency. A migration can be functionally correct and operationally unstable because target capacity is undersized or many validation refreshes run together. Temporarily increasing validation capacity can be appropriate, but size steady state from measured workloads.
Design coexistence, freeze, cutover, and rollback
Large migrations use waves. Define whether source and target can coexist, how changes are frozen or synchronized, which tenant is authoritative, how users distinguish environments, and how long source access remains. A side-by-side period reduces immediate cutover risk but creates drift and duplicate-support risk.
Rollback depends on the wave and external references. Preserve source artifacts and access until the target passes acceptance. Record which identity, link, app, automation, or data changes are reversible. Do not promise zero downtime without proving every dependency. Communicate last source change, target URL, access instructions, known differences, support path, and decision owner.
Measure migration quality and stabilization
- Coverage: inventoried, assigned, migrated, validated, deferred, retired, unknown, and ownerless artifacts and dependencies.
- Quality: definition match, data reconciliation, refresh success, DAX controls, report tests, link validation, and business acceptance.
- Security: mapped identities, least privilege, RLS equivalence, external access, orphaned owners, credential handling, and audit evidence.
- Service: availability, freshness, performance, capacity headroom, user access, incidents, support volume, and recurrence.
- Delivery: wave throughput, manual effort, retry, defect escape, cutover duration, rollback, blocked dependencies, and schedule variance.
- Control: unapproved data transfer, missing artifact, wrong source, excessive access, premature source deletion, and unsupported automated action.
Prove the migration with one representative workspace
- Select an actively used but noncritical workspace containing realistic reports, a semantic model, refresh, permissions, RLS, and at least one relevant Fabric or integration dependency.
- Complete source and target discovery, identity mapping, dependency analysis, classification, backup, and acceptance criteria.
- Prepare target capacity, workspace, gateway, connections, identities, monitoring, support, and migration evidence store.
- Execute the artifact-specific migration in dependency order and record every manual and scripted step.
- Refresh and reconcile data, test security, reports, subscriptions, links, performance, capacity, and business scenarios.
- Run a controlled user cutover, observe operation, exercise rollback or recovery, and capture support findings.
- Update the factory pattern, effort model, risk classes, scripts, runbooks, test suite, and wave plan from pilot evidence.
Discovery and a representative pilot commonly take four to eight weeks. Full duration depends on tenant size and complexity, but large programs should not begin with bulk movement. The pilot must expose unsupported items, manual work, identity gaps, validation cost, cutover behavior, and the operating model required after migration.
Frequently asked questions
Can Power BI workspaces be migrated directly between tenants?
Microsoft documents no direct workspace migration path between tenants. Target workspaces must be recreated, and each supported artifact needs an appropriate export, definition, backup-and-restore, Git, API, or manual recreation path. Gateways, apps, dashboards, identities, credentials, permissions, links, and unsupported Fabric items require separate handling.
What triggers a Power BI tenant-to-tenant migration?
Common triggers include mergers and acquisitions, tenant consolidation, divestitures and spin-offs, corporate reorganization, managed-service transition, and strict regional or data-residency requirements. Before migrating, evaluate whether multi-geo capacity, cross-tenant access, or another architecture can meet the requirement with lower risk.
What must be inventoried before a Power BI or Fabric tenant migration?
Inventory workspaces, capacities, reports, semantic models, dataflows, dashboards, apps, paginated reports, Fabric items, sources, gateways, credentials, schedules, identities, licenses, permissions, RLS, labels, tenant settings, lineage, embedded URLs, SharePoint links, Power Apps and Power Automate references, APIs, usage, criticality, and owners.
How do you validate a Power BI tenant migration?
Validate artifact counts and definitions, dependencies, source and gateway bindings, credentials, refresh, row counts, key aggregates, DAX results, RLS and permissions, apps, links, embedded scenarios, subscriptions, exports, report interactions, performance, capacity headroom, audit evidence, and business-owner acceptance. Each imported semantic model needs a target-tenant refresh because definitions don't include underlying data.
How long does a Power BI tenant migration take?
A discovery and pilot commonly take four to eight weeks. Full duration depends on workspace and item count, Fabric item support, identity readiness, data volume, gateways, shared dependencies, manual recreation, security approvals, business validation, coexistence, cutover windows, and decommissioning. Large or complex tenants are usually migrated in controlled waves.
Official implementation references
- Microsoft Power BI tenant migration patterns and strategies
- Microsoft Power BI tenant-level workspace planning
- Microsoft Power BI semantic model backup and restore
- Microsoft Fabric Git integration
- Microsoft Power BI cross-workspace semantic models
Start with discovery and one representative workspace. Datrick can build the migration factory, execute under your brand, and stabilize target operations after cutover.