Transitioning to the New Power BI Enhanced Report Format (PBIR) - What You Need to Know

Let me be clear: I really like and support the updates that Rui Romano has been pushing the last years!
In short, it brings:

• Better support for CI / CD and source control 
• Better integration for programmatic report updates, e.g. with LLM's
• More reliable merge outcomes with the PBIP and PBIR structures

With that being said, I do think some customers do not want to have preview features in production, so they will be cautious with the recent developments. Since the end of January, the PBIR format will be the default if you don't take action.
If you don't want to enable PBIR yet, or just want to know more about the transition, read on.

A little bit of background

Let's start with the basics, what is PBIP, TMDL and PBIR?

PBIP
PBIP turns Power BI into a real project instead of a single magic PBIX file. Files on disk, folders, source control that actually works. If you’ve ever tried to diff a PBIX and felt pain: PBIP is the fix.

TMDL
TMDL is the semantic model as text. Tables, measures, relationships: readable, reviewable, automatable. This is Microsoft finally saying “models are code”, not artifacts you click together and hope for the best.

PBIR
PBIR does the same, but for reports. Visuals, layout and interactions stored in a format that Git can understand. PBIX still exists, but the report inside it stops being a black box. That’s why PBIR becoming the default is a big deal.

So, PBIP is the structure, TMDL is the model, PBIR is the report.
Together, they move Power BI away from file-based BI and closer to proper software development, whether you asked for it or not. 😊
And to be clear, PBIX is still here and not moving away either, I will expand on that later.

Why This Matters Now

PBIR will become the default report format starting January 25th, 2026 in the Power BI Service, with Desktop adopting it in March 2026, but it will still be in preview.

This will affect developers using PBIP workflows, admins managing enterprise tenants, and teams relying on legacy formats.

Because a lot of clients don't want to use preview features, you can opt out during preview: let me explain how and why you might want to...

M365 Message center PBIR announcement

Legacy Format vs. Enhanced Report Format

The Legacy format is the older JSON-based metadata structure inside reports, which contains 1 big, unreadable JSON file for all things reports in your Power BI Desktop file, whether it's PBIX or PBIP.
This legacy format poses limitations on readability, CI/CD, automation, source-control and working with AI / LLM's. 

As I mentioned earlier, and Microsoft is also explicit about that, PBIX isn't going away. It will still be the primary developer format.

What will change is the metadata inside a PBIX file: from PBIR-Legacy to the new PBIR structure.

Official Timeline

Changes will hit the service first, and Power BI Desktop later.

Power BI Service, starting January 25:

• New reports in the service will default to PBIR
• Existing reports will auto-convert to PBIR when edited and saved in the service

Power BI Desktop, starting with the March 2026 release:

• Desktop switches to PBIR as the default for both PBIX and PBIP-files. Until then, PBIR must be explicitly enabled in the preview features

General Availability (GA) & Beyond:

• PBIR remains in Preview during the transition and becomes mandatory at GA (right now: expected in Q3 of 2026, check the roadmap for latest info)
• At GA, PBIR-Legacy will be removed and PBIR will be the only supported report format

What You Need To Do Today For Opting Out

In Power BI Desktop:

• Disable the PBIR preview features (under Options > Preview features).

In Power BI Service (Tenant Setting):

• Turn off Automatically convert and store reports using Power BI enhanced metadata format (PBIR).
• Important: this tenant setting already existed for quite a few weeks but only took effect in the end of January 2026

PBIR tenant setting to opt out before GA

What about rollback?

If a report is already converted to the new format, you can still go back, but you have to do it with a backup of your report. Backups are automatically created for you, both in Desktop and in the service, but they will only be available for a limited time window.

Desktop

In Desktop, a backup is automatically written to disk and kept for 30 days. Depending on which version you have, the location differs a little bit:

• Microsoft Store version:
  %USERPROFILE%\Microsoft\Power BI Desktop Store App\TempSaves\Backups
• Executable installer version:
  %USERPROFILE%\AppData\Local\Microsoft\Power BI Desktop\TempSaves\Backups

Service

When a report is automatically converted in the service, a backup in legacy format is retained for 28 days. You can restore it from the workspace in the report settings.

For both the desktop and service reverted versions, it won't prompt again to upgrade for that specific file.

Wrap-Up & Call-to-Action

While the transition to PBIP and PBIR in general is a good thing, and I'm already using it for most of my projects, there might be some clients that rather do not want to, or just aren't allowed to use preview features in production.

If you are in the last group, I suggest you:

• Check the Power BI Desktop preview settings
• Check the Tenant settings in the Fabric Admin portal

My Favorite Power BI Desktop February 2022 New Features

Last week it was that time of the month again! No not that time.
I mean time for the Power BI February 2022 Feature Summary blog post by Jeroen ter Heerdt of course.

Dynamic M Query Parameters

The new thing is that dynamic M Query Parameters now supports SQL Server (and more data sources). There are several use cases that come to mind and a few people have already blogged about this:

• Teo Lachev (@tlachev) talks about calling a Stored Procedure with a parameter, and the requirements you need to meet and consider to pull this off
• Chris Webb (@cwebb_bi) has a similar approach, but uses a T-SQL Table-Valued Function with 2 parameters

The high level steps to dynamic M query parameters are:

• The source (SP/TVF) has to be in DirectQuery mode
• Create a parameter(s) in PQ
• In the model view, bind that parameter(s) to the column in your datamodel
• And then use the parameter(s) in your source in PQ

If you want to read up on all the features, supported datasources, limitations and risks, go read the documentation on how to use dynamic M query parameters.

New mobile formatting options

If you're into mobile formatting for Power BI, you're going to love this update. There's a lot more you can configure, now also independently from the web version.

To enable the new mobile formatting pane, the blog post says you'll have to enable the preview feature under Options, but after my installation of the February update it was already enabled:

And more...

Of course there's a lot more in the February update, to mention a few:

If you haven't started using Goals, there are more updates to it, including:

• Teams notifications integration,
• Multiple owners for a single goal and 
• The ability to create scorecards in My Workspace

Deployment Pipelines enhancements: there's a (fairly) new Azure DevOps extension and multiple pipelines working together, for example for disconnected reports and datasets

Download .pbix improvements: starting with this release you can download a .pbix file in more scenario's. Specifically, if a report is connected to a dataset that is configured for large models, incremental refresh or has been modified using the XMLA endpoint, you are now able to download that (connected) report, so not the dataset itself 😉

Read up on all the gotcha's and limitations of this export to PBIX.

Now go download that new update and check it out ourself! 😀

My First Look at Read/Write XMLA Endpoints in Power BI Premium

Exactly 1 year ago Microsoft announced the public preview of PowerBI open-platform connectivity with XMLA endpoints. That allowed us to connect to Power BI Premium datasets with external tools, like SSDT, SSMS, SQL Server Profiler and DAX Studio.

On March 26, they took the next step and announced the public preview of read/write XMLA endpoints in Power BI Premium.

You can go to the link of the webinar to re-view the session given by Christian Wade last week.

Theory

If you just want to see read/write XMLA endpoints in action, skip to the Practice section of this post.

Otherwise, if you never heard of it or just wanna read up on the specifics, keep reading here and we'll get there eventually :-)

Preview Feature

To start with a side-note disclaimer:

XMLA Endpoint

If you're not familiar with XMLA, you can read all about it at the XML for Analysis (XMLA) Reference. Basically, it's the protocol for communicating between client applications and the engine that manages the workspaces and datasets.

These communications are through what are commonly referred to as XMLA endpoints. XMLA is the same communication protocol used by the Microsoft Analysis Services engine, which under the hood, runs Power BI's semantic modeling, governance, lifecycle, and data management.

Additional Functionality

Through these endpoints, Visual Studio and open source community tools like Tabular Editor are enabled to provide additional data modeling and deployment capabilities (supported by the Analysis Services engine, but not yet in Power BI Desktop), like:

• Calculation groups for calculation reusability and simplified consumption of complex models
• Metadata translations to support multi-language reports and datasets
• Perspectives to define focused, business-domain specific views of dataset metadata

Enable Read Write

Follow the steps outlined here to enable XMLA Read Write in the Power BI Admin Portal for your Premium capacity.

In Practice

To test the new read-write functionality I started with an existing Tabular project in Visual Studio (SSDT) and see if I can deploy this to a Power BI Premium workspace. This project currently has a compatibility level of SQL Server 2014 (1103).

One thing to remember is the current SSAS-version of my localhost, this is 1400. We'll come back to this later, as it seemed rather important…

Upgrade Existing Model

So I started with opening the model (.bim-file) to change it to SQL Server 2019 / Azure Analysis Services (1500).

That leaves me with the following error:

A bit strange at first, because I don't know why this wouldn't be possible. I tried upgrading one compat-level at a time. 1200 worked fine, as did 1400. But 1500 kept failing. Then it struck me that I set up the Workspace Server to my localhost, which is level 1400.

So to fix this, in the properties of the model, I changed the setting Integrated Workspace Mode to True. And after that I could change the compatibilitiy level to 1500.

If you haven't disabled the pop-up, you can also set this at the startup of your project:

Deploy to Premium Workspace

If you don't know yet how to connect to a workspace on a dedicated capacity read up on it here and then come back. In the properties of the project file you can set the Deployment Server to the Power BI URL of your workspace.

Security

In addition to the XMLA Endpoint property being enabled to read-write by the capacity admin, the tenant-level Export data setting in the Power BI Admin Portal, also required for Analyze in Excel, must be enabled.

Furthermore, it's good to know that when accessing workspaces through the XMLA endpoint, group memberships (workspace and app access rights) are still honored.

The highest access rights that are currently possible are equivalent to Analysis Services database admins. So anything that requires server admin permissions (server-level traces, certain DMVs) is not yet supported through XMLA endpoints.

Model Roles

When I started my deployment I ran the following error:

As stated in the docs, the following limitations apply when working with dataset roles through the XMLA endpoint:

• During the public preview, you cannot specify role membership for a dataset by using the XMLA endpoint. Instead, specify role members on the Row-Level Security page for a dataset in the Power BI service.
• The only permission for a role that can be set for Power BI datasets is the Read permission. Build permission for a dataset is required for read access through the XMLA endpoint, regardless of the existence of dataset roles. Use the Power BI security model to control permissions beyond RLS.
• Object-level security (OLS) rules are not currently supported in Power BI.

Obviously, I ran into the first point. And it turns out I had 3 XMLA-scripts for role assignments in my project, which are not supported yet in preview mode, as also explained here. I had to delete the defined roles in my model itself, as shown here:

Success (sort of)

After fixing the roles I tried to deploy again and I got myself a little cheer, because the metadata was successfully deployed! However, I was seeing some errors at the table level of the deployment.

Looking at the error details quickly showed me what is was, because I read that, again, in the docs:

When deployed the first time, a dataset is created in the workspace by using metadata from the model.bim. As part of the deployment operation, after the dataset has been created in the workspace from model metadata, processing to load data into the dataset from data sources will fail.

So looking at the Power BI workspace, we can already see the dataset appearing there!

The error is now with the credentials of the dataset. So configuring the dataset settings in the Power BI Service will solve this. Depending on the data source you can either:

• Set data source credentials
• Configure the dataset to use the data gateway

Downloading the PBIX file

There's one more thing I'd like to mention, which is also noted in the docs, but very important to know:

At this time, a write operation on a dataset authored in Power BI Desktop will prevent it from being downloaded back as a PBIX file. This will result in the following error in the Power BI Service:

Closing

I also did some tests with another project and got into some other errors. But this post is already getting very long, so I'm first going to investigate these errors and see if I can find an explanation for them to pop up.

Also remember once again, this feature is still in public preview, so it should not be used in a production environment. It is scheduled to be in GA in September 2020 according to the current release plan.

All-in all I think this is an awesome feature that will give us many more capabilities, especially regarding metadata of a dataset. And I only used SSDT and SSMS to connect to and deploy my dataset, but there are a lot of other options available that you can use.
The error messages I received could have been a bit more descriptive, but I heard (from a very good source) that the Power BI team is already working on that!

So to recapitulate, a few important points to notice in the end:

• Go read the documentation first 
• Enable Read Write for XMLA Endpoints at your Premium Capacity
• Enable the Export data setting in the Power BI Admin Portal
• Make sure your localhost is compat level 1500 or use the Integrated Workspace Mode
• Delete any role memberships in your model during the public preview
• A write operation on a dataset will prevent it from being downloaded back as a PBIX file
• Did I already mention it is still a preview feature? :-)

Did you already have a start with XMLA endpoints, being the recently released read and write feature, or the read-only feature? Please let me know what you think and also what things could be improved even further?

@NickyvV