Power BI Migration: Complete Guide to Move Workspaces, Reports, and Models Without Losing Control (or Stopping the Business)

Quick summary: Power BI migration in 12 points (without unnecessary jargon)

1. Define the “why”: tenant change, workspace reorganization, moving to capacity (or changing it), reducing risk, or enabling proper governance.
2. It is not only content: the hard part is not reports, but permissions, refreshes, credentials, gateways, and owners.
3. Choose a strategy: “lift and adjust” (fast) vs “rebuild with order” (cleaner, less technical debt).
4. Real inventory: list of workspaces + who uses them + which refreshes fail + what is business critical.
5. Design the target: naming standards, domain/area structure, group-based roles, and sharing rules.
6. Licensing/capacity: validate what creators and consumers need (Pro/PPU/capacity) before moving anything.
7. Wave plan: representative pilot → area-based waves → final cutover.
8. Refreshes and gateways: prepare the data “bridge” (gateway, credentials, source permissions) before mass publishing.
9. Security: sensitivity labels, export/sharing rules, and auditing enabled from day one.
10. Business testing: UAT with real use cases (“what I do every Monday”), not only “open the report.”
11. Communication: explain what changes (links, apps, access) and provide a support channel for the first days.
12. Stabilization: measure incidents, performance, and refreshes; fix issues before retiring the old environment.

When do you need a Power BI migration?

Not every organization “needs” to migrate Power BI. In many cases, what you need is order and governance. But there are scenarios where a Power BI migration (full or partial) becomes the most reasonable path.

Common scenarios (the ones we see most in real life)

• Tenant change (tenant-to-tenant): mergers, carve-outs, rebranding, or reorganizations where identities and permissions are redefined.
• “Power BI got out of control”: too many workspaces, duplicated reports, owners who have left, and no one knows what is critical.
• Capacity/licensing changes: moving workspaces to dedicated capacity or changing the model to scale performance and consumption.
• Governance and security: auditing, sensitivity labels, control of exports, and external sharing because data requirements demand it.
• Data platform modernization: source systems change (for example, a new DWH), and you take the opportunity to clean models and reports.
• Cost optimization: remove redundancies and keep only what delivers value, with an operating model that can be sustained.

Introduction to Power BI migration

This guide is for IT teams, analytics teams, and business stakeholders who want to execute a Power BI migration with a clear head: continuity, security, and no first-month ticket avalanche.

We use “migration” in a broad sense: from moving workspaces into a new structure, to a full tenant move, to license/capacity transitions, or organizing the full content lifecycle (development → test → production).

You will see terms such as workspace, semantic model (what many used to call “dataset”), gateway (the bridge to on-prem or restricted data), and deployment pipelines (the clean way to move content across environments). We use them only where they add clarity, always with plain-language context.

Note: some capabilities and screens evolve over time, especially with Microsoft Fabric. That is why we include official resources at the end to validate the current state.

1. What gets migrated (and what should be redesigned)

In practice: what you “move” is usually the easy part; what you “rebuild properly” prevents years of pain.

1.1 Typical assets in a Power BI migration

1.2 What usually breaks without planning

• Refreshes: the report opens, but data is stale because credentials or gateway setup is missing.
• Permissions: users who “used to see it” no longer can—or the opposite (security risk).
• Ownership: critical content owned by nonexistent owners or personal accounts.
• External sharing: gets cut unintentionally or remains too open without governance.
• Exports: suddenly everyone can export to Excel/PDF (or no one can), causing friction.

1.3 What you should use migration to redesign

Migration is a great moment to make decisions that daily operations always postpone:

• Reduce duplicates: “this report exists 5 times” is more common than most teams think.
• Separate environments: development and production should not be the same room.
• Organize by business domains: finance, sales, operations… with clear owners.
• Define standards: naming, minimum description, who publishes, and who only consumes.

2. Migration strategies: fast vs clean (and how to choose)

In practice: choosing strategy is not ideology; it is balancing time, risk, and future debt.

2.1 Strategy A — “Lift and adjust” (when time is tight)

This works when the main objective is to move location (new tenant, new capacity, or new structure) within a fixed timeline. You migrate key content, reestablish refreshes and permissions, and fix issues as they appear.

• Pros: faster, less upfront debate, useful for hard deadlines.
• Cons: if the source was messy, you can “move the mess” and keep carrying it.

2.2 Strategy B — “Rebuild with order” (when you want a true reset)

Here you do not just migrate—you redesign. You build a clean target state and move only value-adding assets, adjusting models, permissions, and distribution as you go. This is usually better when technical debt is high.

• Pros: maintainable, more secure environment that scales better.
• Cons: requires more business engagement (decisions) and slightly more initial time.

2.3 Hybrid strategy (the most common)

In real projects, teams usually combine both: move critical assets fast for continuity while cleaning and professionalizing in parallel. Example: migrate the top 20 business-critical reports first, then filter the rest (archive, redesign, or retire).

3. Licensing and capacity: what to settle before the project

In practice: if licensing/capacity is unclear at the start, you will debate it when the business is already waiting for outcomes.

A Power BI migration often reveals an uncomfortable reality: the current model “works” thanks to exceptions, scattered licenses, and undocumented rules. Before migrating, define how content will be published, how it will be consumed, and who needs what.

3.1 Questions you must resolve (no exceptions)

• Who creates and publishes content? (creators) → typically need Power BI Pro (or PPU depending on use case).
• Who only consumes content? (consumers) → depends on whether content runs on capacity.
• Which workspaces go on capacity? and what that means for performance and cost.
• Any “premium” needs? (for example, broad distribution, stronger control, performance, advanced features).

3.2 Practical orientation (without overcomplicating)

As a starting point, these ideas help frame the discussion with leadership:

• If everyone is an author (many publishers) → a controlled per-user model (Pro/PPU) often makes sense.
• If you have many readers (hundreds or thousands) → capacity is often better to enable broad consumption without per-user licensing for every reader (depending on scale and requirements).
• If your organization is moving toward Fabric → align licensing/capacity decisions with that direction to avoid redesigning twice.

3.3 What usually becomes expensive later

• Migrating without defined capacity: content is published, works “sometimes,” and business concludes “Power BI is slow.”
• Licensing without governance: “give me a Pro license” becomes a reflex, without control over who truly publishes.
• Workspaces without owners: nobody owns content quality or operations, and everything becomes reactive.

4. Wave methodology and project governance

In practice: a calm Power BI migration looks like moving room by room, not emptying the whole house overnight.

The safest way to execute a Power BI migration is by waves: start with a representative pilot (not “the easiest one”), learn, adjust, and then scale.

4.1 Typical phases

1. Discovery: inventory + real usage + criticality.
2. Target-state design: structure, roles, settings, security, distribution.
3. Pilot: one or two areas with real use cases and feedback-ready users.
4. Waves: migrate by area/process, with windows and support.
5. Stabilization: performance, refreshes, permissions, final cleanup, and closure.

When working with a partner (like MSAdvance), the internal team does not “lose control”: it gains method, templates, and predictable pace while protecting day-to-day operations.

5. Assessment: inventory, real usage, and dependencies

In practice: an assessment answers “what we have,” “what is actually used,” and “what breaks if we change this.”

5.1 Minimum viable inventory (what to know before migrating)

• Workspaces: who administers, who publishes, who consumes.
• Assets: reports, dashboards, semantic models, dataflows.
• Refreshes: frequency, duration, recurring failures, dependencies.
• Data sources: cloud vs on-prem, gateway requirements, credentials.
• Security: RLS, external sharing, exports, labels.

5.2 How to do it with official tools (without reinventing the wheel)

For large-scale inventory, Power BI/Fabric provides APIs and logs to reveal the “real picture,” especially in large tenants:

• Metadata scanning (Admin APIs): extract metadata for workspaces and assets.
• Activity log: understand usage (who views what, what gets shared, what gets exported) and prioritize what matters.

5.3 Criticality-based prioritization (so you do not migrate blind)

A tactic that works: classify assets into 3 levels with business owners:

• Level 1 (critical): if it fails, operations or executive reporting is impacted.
• Level 2 (important): weekly value with temporary fallback options.
• Level 3 (long-tail): low usage, duplicate, or retirement candidate.

This simple classification makes migration governable: continuity first, optimization second.

6. Target-state design: workspaces, roles, sharing, and settings

In practice: a good target state reduces support load, avoids risk, and makes content easy to find without “send me the link.”

6.1 Workspace structure (a simple model that usually works)

A practical structure looks like:

• Business-domain workspaces (Finance, Sales, Operations…): clear ownership and stable content.
• Development/test workspaces: iterate without breaking production.
• Sandbox workspaces: exploration with clear rules and periodic cleanup.

6.2 Roles and permissions (less drama, more clarity)

The goal is to avoid one-off person-to-person permissions. The most maintainable model is:

• Assign permissions to groups (ideally Entra ID groups), not individual users.
• Separate who publishes from who consumes.
• Define who can share or export based on data sensitivity.

6.3 Tenant settings: export, sharing, publish… without blocking everyone

This is often delicate: security wants control, business wants agility. The answer is not “fully open” or “fully closed,” but group-scoped rules by use case.

Analyze in Excel (official): Create Excel workbooks with Power BI data.

7. Migrate content: reports, dashboards, and semantic models

In practice: migrating content is relatively straightforward; what matters is making it publishable, refreshable, and governable.

7.1 Three common ways to move content

7.2 “Content ready for migration” checklist

• Clean PBIX: clear parameters, consistent naming, documented data sources.
• Semantic model: understandable measures and relationships; avoid “magic” dependencies.
• RLS reviewed: roles validated with real users.
• Labels (if applicable): classification ready before large-scale publishing.

7.3 A detail that prevents future pain: “who owns what”

Before migration, assign real owners by domain. A report without an owner is not a report—it is a future incident. If there is no owner, decide: retire, archive, or reassign.

8. Refreshes, credentials, and gateways: the “critical point”

In practice: if refresh fails, the business considers the report “broken,” even if it looks great.

8.1 Refresh: what to review before cutover

• Frequency and windows: when each asset refreshes and whether refreshes compete with other workloads.
• Duration: long refreshes usually indicate model/source optimization needs.
• Recurring errors: timeouts, expired credentials, overloaded gateway.

8.2 Gateways: the bridge to data that is not openly reachable

If you have on-prem or restricted-network data, gateway is not a detail—it is the highway. In serious migrations, gateway is treated as a critical component with high availability, monitoring, and clear ownership.

8.3 How to avoid the classic “published, but it does not refresh”

1. Prepare service accounts/credentials (avoid personal accounts).
2. Create and test gateway data sources before mass migration.
3. Validate source-side permissions (SQL, files, APIs) from the service account perspective.
4. Test a small set first (pilot) and measure refresh times.

9. Dataflows and other assets: what usually hurts and how to do it right

In practice: dataflows often hide dependencies; if you do not document them, they will come back to bite you.

If your organization uses dataflows, treat them as “data products”: they include logic, connections, owners, and indirect consumers (models that depend on them).

9.1 What to review in dataflows

• Connections: source, credentials, gateway (if applicable).
• Dependencies: which models/reports depend on each dataflow.
• Performance: refresh duration and load peaks.
• Owners: who responds if it fails at 7:00 AM.

9.2 Practical recommendation

Instead of trying to “migrate everything at once,” it is usually safer to:

1. Migrate the parent dataflow first (the one feeding several downstream assets).
2. Validate refresh reliability and data consistency.
3. Then migrate dependent models/reports.

Note: the exact way to move dataflows can vary by type (and depending on Fabric capabilities in use). In every case, the principle is the same: clear dependencies, clear owners, real testing.

10. Apps, audiences, and user experience: make sure people can find “their” content

In practice: success looks like Monday morning with no one asking “where is the report?”

10.1 Apps: the cleanest way to distribute content

A well-built app reduces link chaos, adds structure, and supports audience segmentation. During migration, it also helps relocate users without forcing them to relearn where everything is.

10.2 What usually changes for users (and should be communicated)

• Links: old links may no longer point to new content.
• Access: when permissions are cleaned up, some people will lose access they had “by habit.”
• Exports: there may be new rules (for good reasons).

10.3 Simple communication plan (and effective)

1. Before: what is being migrated, when, and what users must do (if anything).
2. During: wave/cutover status and how to request help.
3. After: where the new app is, what changed, and a 5-minute quick guide.

11. Security and compliance: labels, exports, and auditing

In practice: security should not be “the brake”; it should be the seatbelt that lets you scale safely.

11.1 Sensitivity labels

If you handle sensitive data, labels help classify and protect content (reports, models, dashboards, and dataflows), and those protections can also travel with exported data.

11.2 RLS (row-level security): what to understand so you do not overtrust it

RLS is powerful, but nuanced. In the Power BI service, users with elevated workspace roles (admin, member, contributor) are not constrained by RLS the same way a viewer is. That is why separating administration from consumption roles is important.

Official: Row-level security (RLS) with Power BI.

11.3 Auditing: visibility for improvement (and peace of mind)

A well-executed migration leaves auditing enabled so you can answer questions like: “who exports?”, “who shares?”, “what is truly used?”, “what can we retire because nobody uses it?”

12. KPIs, UAT, and business validation

In practice: “the report opens” is not a test. The real test is “I can do my job with this.”

12.1 Useful KPIs (simple and actionable)

12.2 UAT with real scenarios

Ask business stakeholders for 5–10 “real stories”: month-end close, sales tracking, stock control, productivity monitoring… If those stories work in the new environment, you are close to success.

13. Operational checklists (pre, during, and post)

In practice: a simple checklist prevents the usual “who was supposed to check this?” moments.

13.1 Before migration

• Inventory completed (workspaces, owners, criticality, dependencies).
• Target structure created (workspaces, groups, roles).
• Licensing/capacity decisions agreed.
• Gateways ready (if applicable) and data sources tested.
• Export/sharing rules reviewed and approved.
• Wave communication and support plan ready.

13.2 During migration

• Migrate by batch/wave with a locked list.
• Validate access (key users) and refreshes (critical content).
• Log incidents and fix patterns (not isolated firefighting).
• Short and clear communication: what is done and where it lives.

13.3 After migration

• Measure usage and performance (first week and first month).
• Recertify access in sensitive workspaces.
• Retire or archive duplicated/obsolete content.
• Set old-environment shutdown date (if applicable), with contingency plan.

14. Frequent mistakes and mitigations

In practice: most issues are preventable if addressed early—not on cutover day.

15. Useful scripts and snippets (PowerShell / APIs) without overcomplicating

In practice: automating repeatable tasks saves time and reduces human error.

If your tenant is large, inventory and automation tools are worth it. You do not need to become an “API developer,” but knowing the basics helps for listing workspaces or reviewing activity.

# Requires Power BI Management module
# Conceptual example: extract events from activity log
Get-PowerBIActivityEvent -StartDateTime "2026-01-01T00:00:00" -EndDateTime "2026-01-07T00:00:00" | Export-Csv .\activity.csv -NoTypeInformation

Official: Access the Power BI activity log.

POST https://api.powerbi.com/v1.0/myorg/groups/{groupId}/imports?datasetDisplayName={datasetDisplayName}

Official: Post Import In Group.

16. Frequently asked questions (extended FAQ) about Power BI migration

17. Official resources and useful links for Power BI migration

• Deployment pipelines (Microsoft Fabric)
• Power BI REST API — Imports
• Admin APIs — Workspace metadata scanning
• Power BI activity log (guidance)
• Auditing (Power BI)
• Sensitivity labels (Power BI)
• Export & sharing tenant settings
• On-premises data gateway
• Licensing: features by type
• Official Power BI pricing

MSAdvance internal resources (related and useful)

• MSAdvance Blog
• Microsoft 365 tenant-to-tenant migration (guide)
• Entra ID migration (guide and checklist)
• MFA in Entra ID (complete guide)
• Azure Architecture (service)
• Security & Compliance (service)
• Licensing supply and sales (service)
• All services

18. Conclusion and next steps

A well-executed Power BI migration is recognizable by three outcomes: (1) the business finds its reports without chasing links, (2) refreshes run predictably, and (3) security improves without turning the platform into an obstacle.

If your next step is to start, the most practical path is:

• Build a real inventory (usage + criticality, not just a list).
• Design a simple, maintainable target state (workspaces, roles, distribution).
• Run a representative pilot and tune before scaling.