PBIP and PBIR Explained: Is Power BI Finally Becoming a Modern Software Platform?

The same report, saved two ways. As a single package, a change is invisible until someone opens the file. As a project, it's a readable line-by-line change. (Simplified: real projects contain a few more files.)

What happens when your most important Power BI report becomes impossible to properly version, review or safely change?

Picture the monthly board pack. Your finance lead asks why the gross margin figure moved since last month. Someone edited a measure. Which one? Who changed it, and when? Did anyone check it before the board saw it?

In many organisations, the honest answer is: we'd have to open two copies of the report side by side and click through them.

That isn't a people problem. It's a packaging problem. For most of Power BI's life, a report has been managed as a single .pbix file. A PBIX is like handing your team an entire application in one sealed box. Everything is in there: pages, visuals, filters, measures, relationships and, for imported data, the data itself. But to see what's changed, someone has to open the box and look.

Microsoft's newer approach, Power BI Projects and the PBIR report format, unpacks that box onto labelled shelves. Which raises a question worth following through this article: is Power BI finally becoming more like a modern software development platform?

The Problem With One Big File

Software teams solved this years ago: code lives in plain-text files, Git records every change line by line, and nothing reaches production without review. Teams working with PBIX files mostly can't work that way.

Imagine two developers changing the same Power BI report in the same week. Git, or SharePoint version history, can tell you that the file changed. It can't tell you that a filter on page three was removed, or that a "Net Revenue" measure was rewritten. Finding out means opening both versions and hunting for differences.

As an estate grows, that one limitation becomes several business problems:

None of this shows with five reports and one developer. It shows at fifty reports and ten developers, just when Power BI has become business-critical. Governance, collaboration, testing and controlled deployment all get harder exactly when they start to matter most.

What Is a Power BI Project (.pbip)?

A Power BI Project answers one question: "How do I package and manage my Power BI solution as a project?"

When you use File > Save as and choose Power BI Project, Power BI Desktop saves the report and semantic model definitions as individual plain-text files in a folder structure, rather than inside one packaged file. According to Microsoft's documentation, the result looks like this:

SalesPerformance/
├── SalesPerformance.Report/          the report
│   ├── definition.pbir               entry point + link to the model
│   └── definition/                   pages and visuals (PBIR format)
├── SalesPerformance.SemanticModel/   the semantic model
│   ├── definition.pbism
│   ├── definition/                   tables, measures, roles (TMDL format)
│   └── .pbi/cache.abf                local data cache, ignored by Git
├── .gitignore
└── SalesPerformance.pbip             shortcut that opens the project

A simplified Power BI Project. Depending on the report, the folders can hold a few more files, such as custom visuals or registered resources.

What each part is for, in business terms:

• The .Report folder holds how the report looks and behaves: pages, visuals, filters and formatting.
• The .SemanticModel folder holds the business logic: tables, relationships, measures and security roles, stored in TMDL, a readable text format with one file per table, role and perspective. (New to semantic models? See our plain-English guide.)
• The .pbip file is just a pointer that opens the report and its model in Power BI Desktop. Microsoft describes it as optional.
• The .gitignore file tells Git what not to track. By default it excludes cache.abf, the local cached copy of the model's data, so your business data isn't pushed into the repository.

A project isn't a one-way door either. Power BI Desktop can save a PBIX as a PBIP and a PBIP back as a PBIX, so teams can trial the approach on a copy of an existing report.

What Is PBIR, and Why Isn't It "the New PBIX"?

PBIP and PBIR are often mentioned together and assumed to be the same thing. They're not. If PBIP answers "how do I manage this as a project?", PBIR answers a narrower question: "How is the report itself represented inside that project?"

The name turns up in two places, which is where the confusion starts:

• The definition.pbir file is the report's entry point. It holds core settings and which semantic model the report uses: a model folder in the same project, or a model already published in a Fabric workspace.
• The PBIR format, which Microsoft calls the Power BI enhanced report format, is how the report's contents are stored in the definition/ folder. It replaces PBIR-Legacy, where the whole report sat in one report.json file that isn't supported for editing outside Power BI.

In the PBIR format, the report is broken into small, predictable pieces:

definition/
├── report.json               report-level settings and filters
├── version.json
├── reportExtensions.json     report-level measures
├── pages/
│   ├── pages.json            page order and active page
│   └── [page]/
│       ├── page.json         page filters and formatting
│       └── visuals/
│           └── [visual]/
│               └── visual.json   position, formatting, query
└── bookmarks/
    ├── bookmarks.json
    └── [name].bookmark.json

The PBIR folder structure, as documented by Microsoft. Folders in square brackets are named after each page, visual or bookmark.

Three properties make this structure valuable:

• Every page, visual and bookmark is its own file. Microsoft says this "greatly improves change tracking and merge conflict resolution." Two developers editing different pages are editing different files.
• It's publicly documented. Each file declares a public JSON schema, so code editors such as Visual Studio Code can validate edits as you type.
• Editing outside Power BI is supported. Unlike PBIR-Legacy, PBIR supports modification by other applications, provided the files follow the schema.

That turns hours of clicking into minutes. Microsoft's own examples: copying pages, visuals or bookmarks between reports, find-and-replace across many reports, and scripting one change across every visual.

PBIX vs PBIP vs PBIR at a Glance

The simplest way to hold all three in your head: PBIX and PBIP are two ways to save a Power BI solution. PBIR is the format of the report inside either one.

Why Business Leaders Should Care

File formats rarely deserve a leadership conversation. This one does, because it changes how safely and how quickly your reporting can evolve. For each capability, the useful question is: so what does this mean for the business?

Taken together, these shift Power BI from a collection of dashboard files toward something closer to an engineered product: versioned, reviewed and released on purpose.

A Realistic Scenario: 20 Developers, 100+ Reports

Take an illustrative but typical organisation: a central BI team of 20 developers, more than 100 reports, separate development, test and production workspaces, weekly changes, and an IT department that already runs its other applications in Git with Azure DevOps.

With a PBIX-centric workflow

• Files named Sales_v7_FINAL_revised.pbix sit in shared folders, and "don't touch it, I'm editing" is agreed over Teams.
• A hotfix goes straight to production but never back into the development file, so the next release quietly undoes it.
• An auditor asks when a KPI definition changed, and someone opens archived copies one by one.

With a PBIP and PBIR workflow

• Reports and models live in Git, and developers work on their own branches.
• A pull request shows exactly what changed (say, one measure in Sales.tmdl and one visual.json) and a colleague approves it.
• Approved changes move to test and production through a defined pipeline, and the history answers the auditor in minutes.

What doesn't change: a poorly designed model stays poorly designed, two people editing the same visual still conflict, and none of it works without agreed rules on who reviews and who releases. PBIP makes good practice possible, not automatic.

What a Modern Power BI Development Workflow Looks Like

Here's how the pieces fit together in a mature setup. PBIP and PBIR are the foundation, not the whole building.

1. 1
   Developer

   Builds in Power BI Desktop, and can edit project files in a code editor such as Visual Studio Code.

2. 2
   Power BI ProjectPBIP

   Saved as text: the report in PBIR, the semantic model in TMDL.

3. 3
   Git

   Committed to Azure DevOps or GitHub, with a full history of who changed what.

4. 4
   Pull request and review

   A teammate approves the exact changes before they merge.

5. 5
   Validation and testing

   A build pipeline runs the automated checks your team defines.

6. 6
   DeploymentCI/CD

   Dev to test to production via Fabric Git integration, deployment pipelines, or Fabric APIs and Microsoft's fabric-cicd library.

7. 7
   Power BI / Microsoft Fabric

   Business users get versioned, reviewed, tested content.

Microsoft documents several ways to build the deployment half, from Git-driven releases to low-code deployment pipelines, and notes that many organisations combine them.

So, back to our question: is Power BI becoming a modern software development platform? The building blocks are now in place: readable files, Git, reviews and automated deployment. Whether your environment works that way is a decision about process and people, not a file format.

Should Your Organisation Start Using PBIP?

Not every team needs to move now. Here's a practical way to judge it.

What to do today if you run a large Power BI environment

1. Map your critical reports: who edits them, how often, and how changes reach production.
2. Pilot one important report as a Power BI Project in Git, with two or three developers.
3. Agree the ground rules: branching, reviewers, and who approves production releases.
4. Keep a copy before converting. Upgrading to PBIR can't be undone from the interface, though Power BI Desktop keeps a 30-day backup.
5. Test key reports in PBIR now, since Microsoft intends it to become the only supported report format.

Does This Mean PBIX Is Obsolete?

No, and plenty of commentary gets this wrong. In its June 2026 update, Microsoft said directly: "PBIR is not replacing PBIX. PBIX remains the primary file format for Power BI developers."

What changes is inside the file: PBIX will store reports in PBIR instead of the older PBIR-Legacy format, a silent upgrade that aligns PBIX and PBIP.

The format on its way out is PBIR-Legacy. Microsoft has said that at general availability, PBIR will become the only supported report format. The road there hasn't been straight: the default-on rollout was paused after issues surfaced and resumed in June 2026, with general availability for PBIR and PBIP to follow once it proves stable.

The takeaway: PBIX remains a sound choice for many teams. Moving to PBIP is a decision about development maturity and business need, not a forced migration.

What PBIP and PBIR Don't Solve

Before committing, weigh these honestly:

• They're still in preview. Behaviour can change before general availability.
• Source control isn't governance. Git records changes; it doesn't define ownership, permissions or data quality standards.
• Your team needs new skills. Branching, pull requests and merge conflicts are new to many report developers.
• Conflicts don't disappear. Two people editing the same visual or measure still have to reconcile.
• Not every file is safe to hand-edit. Invalid edits can stop Power BI Desktop opening a project, and some files aren't supported for outside editing during preview.
• Feature gaps remain. Sensitivity labels aren't supported with Power BI Projects, nor is Power BI Desktop for Report Server, and projects can't be saved directly to OneDrive or SharePoint.
• Practical limits apply. Windows' default 260-character path limit can break saves when names get long.
• Some data can appear in the files. Report metadata can store values, such as a filter set to a particular customer, so commits still deserve review.
• The wider tooling is evolving too. Fabric Git integration and deployment pipelines for Power BI reports and semantic models are also in preview, with some exceptions.

FAQ

Is PBIP the same thing as PBIR?

No. PBIP is how a whole Power BI solution is saved and managed, as a report folder plus a semantic model folder. PBIR is the format of the report inside it. The semantic model uses TMDL.

Is PBIX going away?

No. Microsoft says PBIX remains the primary file format for Power BI developers. PBIX files will simply store their reports in PBIR instead of PBIR-Legacy.

Do we need Microsoft Fabric to use Power BI Projects?

Saving as a Power BI Project is a Power BI Desktop feature, and the files can live in any Git repository, such as Azure DevOps or GitHub. Connecting a workspace directly to Git through Fabric Git integration is a separate capability with its own requirements.

Does putting a Power BI Project in Git put our data in Git?

Not by default: the .gitignore Power BI Desktop creates excludes cache.abf, the local data cache. But report metadata can hold some data values, such as filter selections, so review what you commit.

Can we switch back if PBIP doesn't suit us?

Yes. Power BI Desktop can save a PBIP as a PBIX and vice versa. Upgrading a report to PBIR is the exception: it can't be reverted from the interface, though Desktop keeps a 30-day backup.

Not sure whether your reports are ready for PBIR? We can review a representative sample and flag anything that needs attention.

The Bigger Shift

PBIP and PBIR are not simply new file formats. They're part of a broader shift toward treating Power BI solutions as engineered, manageable and scalable data products: built in the open, changed deliberately and released with the same discipline as any other business-critical software. The organisations that benefit most won't be the ones that convert every file first. They'll be the ones that pair the new formats with clear ownership, review and release practices.

Sources & Further Reading

1. Power BI Desktop projects (PBIP), Microsoft Learn
2. Power BI Desktop project report folder (including the PBIR format), Microsoft Learn
3. Power BI Desktop project semantic model folder, Microsoft Learn
4. Tabular Model Definition Language (TMDL), Microsoft Learn
5. Overview of Fabric Git integration, Microsoft Learn
6. Overview of Fabric deployment pipelines, Microsoft Learn
7. CI/CD workflow options in Fabric, Microsoft Learn
8. Azure DevOps integration with Power BI Desktop projects, Microsoft Learn
9. PBIR will become the default Power BI Report Format: Get Ready for the Transition, Microsoft Power BI Blog
10. Power BI June 2026 Feature Summary (PBIR default-on update), Microsoft Fabric Community
11. JSON schemas for Fabric and Power BI project files, Microsoft on GitHub

Power BI Projects and PBIR are still moving from preview to general availability, and Microsoft has adjusted the rollout timeline more than once. Confirm the current status and limitations in Microsoft's documentation before planning a migration around any specific detail here.