How to export your data from Power BI

Export your Power BI content before the renewal decides for you

A team leaving Power BI Pro, Premium Per User, Fabric capacity or Power BI Report Server needs its reports and semantic models out of the service before the license lapses. The documented export path is the .pbix download, which workspace Contributors can run from the Power BI service, and several model types and sizes block it entirely. Direct Lake models, models with incremental refresh, models with automatic aggregations enabled and models migrated from Azure Analysis Services cannot be downloaded as .pbix files, and data models above 50 GB cannot be downloaded with their data. Everything else in that group has to be rebuilt or extracted by other means. Start with an inventory rather than a download. For each workspace, confirm who holds Contributor access, whether an administrator has turned off the download option (in which case the .pbix option does not appear at all), and which reports depend on local Excel or CSV uploads, OneDrive-imported semantic models or Template Apps, since those cannot be downloaded either. Record the model size and refresh settings for every semantic model, because those two facts decide which of the three download modes is even available. Confirm the exact limits with the current Microsoft Learn guidance on downloading reports to Power BI Desktop, since Microsoft updates these rules over time. The inventory also shows what must be extracted separately. Report layouts and visuals can be recovered from .pbix files, but the DAX measures, Power Query logic and source connection details sit in the model layer and need documenting before the subscription ends. Plan for that work early, because it usually takes longer than the download itself.

What Power BI exports, in which format, and with which limits

This table lists the three .pbix download modes, the access and tenant conditions that gate them, and the model types that block a download with data. Read it as a checklist: confirm each row against your own workspaces before planning an export, because one blocked model can stall a whole migration batch.

Item	What it allows or requires	What to confirm or plan for
Report with data	Downloads a copy of the report and its data as a .pbix file	Only available when the model is within the offline size limit and not on a blocked model type
Live connection	Downloads a copy of the report that stays connected to the semantic model in the service	Use this for models above 50 GB, since data cannot be downloaded with them
Empty report with dataset only	Downloads a report without data, keeping the model definition	Rebuild data connections in the target platform before relying on the file
Minimum workspace access	Contributor role or higher in the workspace	Ask which users hold Contributor access, since Viewers and Members rules can differ from your expectation
Tenant download setting	If an administrator turns off data download, the .pbix option does not appear	Check the tenant setting with your Power BI administrator before the export window
Size limit for data downloads	Data downloads are not supported above 50 GB	Confirm each model's size against the capacity's maximum offline semantic model size
Blocked model types	Incremental refresh, Direct Lake, automatic aggregations and models migrated from Azure Analysis Services cannot download to .pbix	Plan a separate extraction path for these models, such as exporting the underlying data and metadata
Local uploads and template apps	Reports based on Excel or CSV uploads, OneDrive imports or Template Apps cannot be downloaded	Recover source files and the original definitions from their owners
Metadata via XMLA endpoint	Not confirmed in the supplied sources	Ask your Power BI administrator and vendor whether the documented XMLA route covers your models before relying on it

Which reports and models cannot be downloaded with data

Microsoft blocks a .pbix download with data for several model types and sources, and the blocked cases are not all about size. Each card below names one case, the workaround that usually replaces the download, and the check to run before you rely on it.

Incremental refresh models

Semantic models that use incremental refresh cannot be downloaded to a .pbix file. The partition logic and the refresh policy live in the service, so a local copy would not reproduce how history is kept. Rebuild the model in your target tool from its upstream database, with the same date filters and a full history load, and confirm that the source system still holds every period the refresh policy kept.

Direct Lake models

Direct Lake models read Delta tables in OneLake directly and cannot be downloaded to a .pbix file. The data stays in the lakehouse, so the practical route is to re-point the new tool at the same tables through a SQL endpoint or export them as files. Confirm which tables and columns the reports depend on and whether the target database can read the table format.

Models with automatic aggregations

A model with automatic aggregations enabled cannot be downloaded to a .pbix file. The aggregation tables are maintained by the service, so a download would not carry them correctly. Turn the setting off only after you confirm the detailed queries still perform acceptably, then rebuild the summary logic as views or SQL metrics in the target database.

Models migrated from Azure Analysis Services

Models moved from Azure Analysis Services to the Power BI service cannot be downloaded to a .pbix file. The model definition may still be recoverable through the service's tooling, but it is not a .pbix download. Ask your Power BI administrator to confirm the model's origin, then rebuild its tables and measures from the upstream source system.

Local Excel, CSV and OneDrive sources

Reports built on local Excel or CSV uploads cannot be downloaded, and neither can semantic models imported from OneDrive for work or school. The data lives in a file, not a database, so the file itself is the export. Locate the original spreadsheets, confirm who owns them and their version history, and move the data into a database table before rebuilding the report.

Template App and models above 50 GB

Template App reports cannot be downloaded, and a model above 50 GB cannot be downloaded with its data, only in live connected mode. Template App content should be rebuilt from its source connections. For larger models, export the tables from the source system in partitions rather than relying on a single download, and confirm the export size and time with your database team before you plan the cutover.

How to run a complete export from Power BI in order

This sequence moves a Power BI estate out of the service in an order that shows which items can be downloaded with data, which need a live connection, and which must be rebuilt from their source databases. The result is a verified set of files and a record of what each one depends on.

Inventory workspaces and confirm Contributor access
Start by listing every workspace, report and semantic model that the export must cover, and note who owns each one. Confirm that the person running the export holds at least Contributor access to each workspace, because a download is not available to lower roles. Record any workspace where access is missing so an administrator can grant it before you continue. The step is done when you have a complete inventory with an access status for every workspace.
Check each item against the blocked list
For every report and semantic model in the inventory, check whether it uses incremental refresh, Direct Lake, automatic aggregations, or a migrated Azure Analysis Services model, since these cannot be downloaded to a .pbix file. Also flag reports built on local Excel or CSV uploads, semantic models imported from OneDrive for work or school, and Template App reports, which cannot be downloaded either. Confirm with your Power BI administrator whether the download setting is enabled in your tenant, because without it the .pbix option does not appear. The output is a classification sheet that sorts each item into downloadable with data, live connection only, or rebuild from source.
Download eligible reports in the correct mode
For each item that can be downloaded, choose the mode that matches the goal: a copy of the report and data, a copy of the report with a live connection to the semantic model in the service, or an empty report that carries only the dataset. Items whose data model is larger than 50 GB can only be downloaded in live connected mode, so plan those separately. Save each file to a controlled location with a name that includes the workspace and date. The step is done when every eligible item has a saved file and a matching line in your log.
Confirm each file opens in Power BI Desktop
Open every downloaded .pbix in Power BI Desktop and check that the report loads, the visuals render, and the data model opens without errors. A file that opens in live connected mode will show the connection to the service rather than local data, so note that difference in your log. Where a file fails to open, record the error and the item name for follow-up with the report owner. The step is done when each file has a pass or fail result and every failure has a named owner.
Record source connections and refresh settings
For each report and semantic model, document the data sources it connects to, the credentials type used, the refresh schedule, and any parameters or gateway bindings. Export the list of data source names and connection strings from Power BI Desktop where they are visible, and note the on-premises data gateway, if one is used. This record is what lets you rebuild refresh and access later, because a .pbix file does not carry the scheduled refresh settings from the service. The step is done when each item has a source inventory that a second person can read.
Export the underlying data from source databases
For items that cannot be downloaded with data, and for any model where you need the full history, export the data directly from the source systems. Work with the database owners to extract tables or views with an agreed scope, keep the extract queries in version control, and store the output in a location you control. Ask the database owners to confirm the extract covers the same date range and filters that the Power BI model uses. The step is done when each source has an extract file and a query that produced it.
Verify row counts and key measure totals
Compare each exported dataset against the source for row counts, and compare the totals of the key measures that the business uses, such as revenue or active users, against values shown in the original report. Use the same filters and date range on both sides, and record any difference with its cause. Where a measure is defined in DAX and cannot be reproduced from the extract, document the gap rather than forcing a match. The step is done when every key figure has a recorded comparison and every difference has an explanation signed off by the report owner.

Which parts of the model leave with the file and which must be rebuilt

A .pbix file carries the report, the semantic model and, when the download mode and size limits allow it, the imported data. What it does not give you is a neutral specification. The DAX measures, calculated columns and relationships sit in the model, so they travel with the file, but they are written in DAX and only make sense to a target that can evaluate DAX. The Power Query steps that shape the data are also inside the file, and they are the transformations that produced your tables, so they need to be read and written down as logic, not just preserved as a binary. Row-level security roles are defined in the model too, and they must be exported as documented rules with their DAX filter expressions and the groups they map to, because a self-hosted platform will not enforce them automatically.

Treat the file as a source to read, not a package to move. Open the model in Power BI Desktop and list every measure, every Power Query step, every RLS role and every relationship, then record which ones your target platform can express. Measures that depend on DAX functions, time intelligence or Power Query transformations that happen only in the model will need to be rebuilt as SQL, metrics or upstream pipeline logic. Sign-in rules also do not travel: a Microsoft Entra ID group that gates a role must be mapped to a group in the new identity provider before anyone is cut over. Ask your target team to confirm, in writing, which of these items it will rebuild and who owns each one. A live-connected download is different from a copy. In that mode the report points back to the semantic model in the Power BI service, so the data stays where it was and the file is only an entry point, not an independent archive. Deleting the workspace or the model after a live-connected download removes the data and the logic you still depend on. Before you delete anything in Power BI, confirm what your target needs: a copy of the model and data, the query logic, the RLS definitions and the refresh schedule. Keep the source workspace and the download under retention until the target has reproduced every figure you check against, and confirm the retention period with your records owner.

Choosing the right download mode for each report

Choose this mode when you need a self-contained copy of the report and its data that can be opened in Power BI Desktop and used as a starting point for a rebuild. The file is a snapshot of the data at the time of download, so it does not refresh on its own in any new system. Microsoft documents the download steps in Download a report from the Power BI service to Power BI Desktop.

Who can run it: Workspace Contributors or higher. If the download option does not appear, an administrator may have turned off data downloads.
Size ceiling: Downloads with data are limited by the capacity's maximum offline semantic model size and are not supported above 50 GB.
Model types that block it: Direct Lake models, models with incremental refresh, models with automatic aggregations and models migrated from Azure Analysis Services cannot be downloaded to a .pbix file.
Source types that block it: Reports built on local Excel or CSV uploads, semantic models imported from OneDrive for work or school, and Template App reports cannot be downloaded.
What you must rebuild: Refresh schedules, workspace permissions and source connections belong to the service, so plan to recreate them in the target system.

Check the model type, size and sources in the workspace settings before you commit a migration plan to this mode.

How to verify an export is complete

A .pbix file that opens is not proof that the export is complete. The four checks below cover the file itself, the data inside it, the report structure and the audit trail, so that a gap found during migration is traced to a known export rather than discovered by a business user later. Run them in order and record the results against each report.

Confirm the file opens cleanly

Open each downloaded .pbix in a Power BI Desktop version that Microsoft supports for your environment, and confirm the model loads without errors, the data source settings resolve and the report renders on first open. Test the file in a clean Desktop session, not on the machine where it was downloaded, because cached credentials and local settings can hide problems. Confirm the supported Power BI Desktop version with Microsoft before you rely on this check, since the supported build changes over time. Record the Desktop version used with the test result.

Reconcile row counts and key totals

For each fact table and each measure that finance or operations relies on, compare the row count and a total of a key numeric column between the source system, the semantic model in the service and the exported file. Differences usually point to a filter, a relative date that resolved on a different day, or a table excluded from the download. Keep a short list of reconciled tables so that the next person can repeat the same comparison without guessing which numbers matter.

Check every page and visual

Compare the page list, visual count and slicer settings of the exported report against the original in the workspace. Check bookmarks, drill-through pages, tooltips and report-level filters, because these are the elements most often lost or altered in a round trip. Also verify that row-level security roles are present in the model and that the role membership is recorded separately, since the file does not show who was assigned to each role in the service.

Log each export against its source

Keep a register that ties every exported file to its source workspace, report or semantic model name, download mode, export date, the account that performed the download and the checksum of the file. The register is what lets you answer which version of a report a stakeholder was using on a given day, and it shows which content was left out because of the download limits. Store the register in the same controlled location as the exports, with access limited to the migration team.

What to plan before the Power BI contract ends

Start by writing down the end date of every Power BI entitlement your organization holds: Pro seats, Premium Per User, the Fabric or Premium capacity that hosts your workspaces, and any Power BI Report Server product key. Confirm each date with your Microsoft account team or licensing contact rather than relying on the renewal notice you remember. The export window closes when the access behind it closes, so the export must run while the workspace is still reachable with Contributor rights. Because a download is only possible for certain models and sizes, inventory which semantic models fall into the blocked cases before the date, not after it.

Plan for what remains after the license ends. Source databases and warehouses behind your semantic models usually sit under their own contracts, so keep a read account on them long enough to rebuild the data layer in the new platform, and confirm who owns those credentials. Report Server deployments raise a separate question: the product key and any capacity terms that let you keep running it must be checked with the vendor, since the rights attached to an existing installation can differ from what a renewal form suggests.

Finally, check what stops working and what silently breaks. Shared links, subscriptions and scheduled refreshes depend on the workspace and capacity, so list every dashboard that business users open from a bookmark or email and every refresh that feeds it. Record the owner of each item and the recipients of each subscription, then decide which ones move to the new platform and which are retired. Doing this inventory early gives you a dated cutover plan with a rollback path, instead of discovering on the last day that a critical report no longer loads.

Export questions buyers ask before hiring outside help

What drives the cost of exporting Power BI content?

The main drivers are how many workspaces hold content, how many semantic models fall into a blocked category, how complex the source systems behind each model are, and how much data each model holds relative to the 50 GB line. Reports that download as eligible .pbix files with data are the cheapest to handle. Models with incremental refresh, Direct Lake, automatic aggregations or Azure Analysis Services origins need a different approach, usually rebuilding the logic against a database. Ask any provider to break the quote down by workspace and by blocked versus eligible models, and to state which items are one-time work and which recur if you keep running the stack.

How long does a Power BI export project take?

The duration depends on the same factors as cost: the number of workspaces, the count of blocked models, the source databases and the data volume. No general figure is reliable without an inventory of your tenant. A useful first step is a listing of every workspace, report and semantic model with its refresh type, size, source and owner, because that inventory turns a vague estimate into a timeline the written scope can commit to. Ask for the timeline to be tied to that inventory and to milestones you can check.

What access and information must our team provide?

Downloads require at least Contributor access to each workspace, so someone with that role must be available for every workspace in scope. Expect to provide credentials or read access for the source databases behind the semantic models, since the replacement queries and connections depend on them. Report owners should be able to confirm what each report is for, which users rely on it and which pages matter, because a download is only useful if the intent behind it is known. Agree in advance who signs off on each report's acceptance.

Can our own team export Power BI reports without a consultant?

Yes, for eligible reports. Power BI can download a .pbix with data for reports that are not blocked, provided the user has Contributor access and the model is under the size limit. Your team can also download a live-connected copy or an empty report with the dataset only. Blocked cases are harder: Direct Lake models, incremental refresh, automatic aggregations, Azure Analysis Services migrations, local Excel or CSV uploads, OneDrive-imported models and Template App reports need the logic rebuilt from its sources, which usually means reviewing DAX, Power Query and the upstream databases. Your team can start with the eligible reports and decide afterwards whether the blocked ones justify outside help.

What does a fixed-scope Power BI export engagement cover?

A fixed-scope engagement sets out, in writing before work starts, which workspaces, reports and semantic models are included, what each deliverable is and the timeline. For an export project, typical deliverables are a tenant inventory, a classification of each item as downloadable with data, live-connected only, or needing rebuild, the exported .pbix files for eligible items, and a documented plan for the blocked ones. DeployOpen plans, implements, documents and supports self-hosted open-source BI platforms in your own infrastructure, and most engagements are fixed-scope. Ask that the written scope name the exclusions, such as models you have not yet confirmed, so the boundary is clear.

Why do some Power BI models refuse a download with data?

Microsoft blocks the .pbix download with data for several model types. The main ones are Direct Lake models, models with incremental refresh, models with automatic aggregations enabled, and models migrated from Azure Analysis Services. Models above 50 GB cannot be downloaded with data either and are limited to live-connected mode. Also blocked are reports built on local Excel or CSV uploads, models imported from OneDrive for work or school, and Template App reports. If a Power BI administrator has turned off the download option, the .pbix option does not appear at all, so check the tenant settings before planning.

What should we check before we start an export?

Check four things first. Confirm the Contributor role on every workspace, because a Viewer or Member role will not show the download. Confirm with a Power BI administrator that the download-data setting is on for the tenant. List each semantic model with its size, refresh type and source, which determines whether a download with data is possible. Finally, record which owner will confirm the intended use of each report and who will approve the replacement. Keeping a copy of the source database credentials and the model's refresh schedule also avoids delays later.

How DeployOpen works on this

DeployOpen starts by inventorying which Power BI semantic models and reports can and cannot be downloaded with their data, then agrees a written scope before any export work begins. The work runs inside your own infrastructure, with each blocked case tracked and given a documented route forward.

How we scope

Inventory every workspace, report and semantic model, flagging incremental refresh, Direct Lake, aggregations and models over 50 GB.
Confirm which Contributor accounts and workspace roles are available for the download work.
Agree in writing which of the three download modes applies to each asset and which cases need a different route.

How we build

Export .pbix files where the service allows it and record the mode used for each asset.
Capture report definitions, measures and data source connections for assets that cannot be downloaded with data.
Test each exported item against a copy of the source data before any cutover decision is made.

How we hand over

Deliver an export register listing every asset, its download mode, its status and any manual steps still open.
Document the blocked cases, the workaround used for each and the owner who confirmed it.
Hand over runbooks and access records so your team can repeat or audit the export without DeployOpen.

How we support

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Ask for a written quote that lists each export task, the blocked cases covered and the handover documents included.