How Do You Connect Microsoft Project to Power BI?

How Do You Connect Microsoft Project to Power BI?

If you searched for this a year ago, every guide gave you the same answer: point Power BI at your Project Web App OData feed and you are done. That answer is now wrong, and following it will waste an afternoon.

Project Online retired on 30 September 2026. The OData reporting endpoint that nearly every published tutorial still describes went with it. Meanwhile "Microsoft Project" now means at least three different things depending on what your organisation actually bought, and each one reaches Power BI by a different route.

This guide covers the routes that still work in 2026, the exact steps for each, which one to pick for your situation, and the reporting limitations nobody mentions until you are three hours into building a dashboard.

What Is the Short Answer?

There is no single Microsoft Project connector in Power BI, and there has not been one for desktop files at any point. What you do depends on where your schedule data lives:

• If you are on Microsoft Planner with premium capabilities (the product that replaced Project for the web and absorbed Project Online's customers), connect Power BI to Dataverse, because that is where Planner Premium stores its data.
• If your schedules are .mpp files on someone's laptop, export them to Excel or CSV from Project desktop and import that file into Power BI.
• If you are on Project Server Subscription Edition on-premises, the classic OData reporting endpoint still exists on your own server.
• If you were on Project Online, the OData route is gone as of 30 September 2026 and you need one of the above instead.

The rest of this guide walks each of those through properly.

Not sure your reporting stack is actually earning its licence cost? Get a free SEO and analytics audit at https://www.seo-stuff.com/free-audit and find out what your data is really telling you.

Why Did This Get Harder in 2026?

Because the product underneath moved, and the documentation did not move with it.

Project Online has retired

Microsoft retired Project Online on 30 September 2026. The milestones ran roughly as follows: new-customer sales of Project Online-only subscriptions ended on 1 October 2025, existing customers lost the ability to stand up new Project Online tenants around April 2026, and the service itself reached end of life at the end of September 2026.

Commentators described it as a hard stop rather than a phased sunset, which matters for reporting: the OData feed at the Project Web App site was not deprecated gradually with warnings in Power BI. If your refresh started failing and you assumed it was a credentials problem, it may not have been. Confirm your own tenant's status with Microsoft rather than assuming, because migration timelines varied by agreement.

Microsoft Project desktop did not retire

This is the part people get wrong in both directions. Project desktop — the Windows application that opens .mpp files — continues to be supported, and Planner Premium licence holders generally have access to it. So "Microsoft Project is gone" is false. What went away is the hosted web service and its reporting endpoint, not the scheduling application.

The replacement stores data somewhere completely different

Project Online kept its reporting data in a SharePoint-hosted Project Web App database exposed as an OData feed. Planner Premium keeps its data in Microsoft Dataverse, the Power Platform data layer. Different store, different connector, different table names, and critically, no drop-in content pack to replace the one Project Online shipped with.

How Do You Connect Power BI to Planner Premium?

This is the route most organisations now need. It works, but it is a build rather than a click.

Step 1: Confirm your data is in Dataverse and find your environment

Sign in to Power Apps and select the environment your plans live in. Open the Tables area and look for the Project tables. You are looking for names beginning msdyn_ — these are the Project Operations schema tables that Planner Premium writes to.

If you cannot see them, you are either in the wrong environment or your account lacks the security role to read them. Sort that out before opening Power BI; it is much harder to diagnose from the other end.

Step 2: Identify the tables you actually need

The ones that carry the schedule are:

• msdyn_project — the projects themselves
• msdyn_projecttask — individual tasks, with their dates and completion state
• msdyn_resourceassignment — who is assigned to what
• msdyn_projecttasktolabel — the link between tasks and labels, if you use them

You will usually need at least the first three to build anything resembling a project dashboard.

Step 3: Connect from Power BI Desktop

In Power BI Desktop, choose Get data, then Dataverse. Sign in with your work or school account, pick the environment, and select the tables from the list. Load them, then start relating them in the model view — typically project to task, and task to resource assignment.

The Dataverse connector is a first-party connector and handles authentication through your organisational account, so there is no connection string to construct by hand.

Step 4: Build the relationships and measures yourself

This is the step that surprises people migrating from Project Online. There is no built-in content pack that populates a dashboard for you. You relate the tables, then write your own measures: tasks completed as a percentage of total, tasks past their finish date, assignment load per resource, and so on.

Microsoft has published Power BI templates for Project for the web on GitHub, and those are worth starting from rather than building from a blank canvas. They are applied manually — you download the template and point it at your environment.

Spending more time wiring dashboards than reading them? Get a free audit at https://www.seo-stuff.com/free-audit and see which of your reports anyone actually opens.

Step 5: If Dataverse is not available to you

Some tenants have Planner Premium without the Dataverse access a report author needs. The documented workaround is Power Automate: build a flow that reads plan and task data and writes it somewhere Power BI can read, such as a SharePoint list, a Dataverse table you do control, or a file in OneDrive. It is more moving parts, but it keeps the refresh automatic.

How Do You Get a .mpp File Into Power BI?

If your schedules are standalone Project desktop files, there is no connector for them. The route is an export.

From Microsoft Project desktop:

1. Open the .mpp file.
2. Go to File > Export and choose Save Project as File.
3. Under Other File Types, pick an Excel workbook or a CSV, and save.
4. Step through the Export Wizard and confirm the data format.
5. Choose New map, and select the data types you want — Tasks and Resources are the usual pair.
6. On the Map tab, pair each Project field with a column header. Include the ID and Unique ID fields, because you will need them to build relationships once the data is in Power BI.
7. Save the map so you can reuse it next time, then finish the export.

Then in Power BI Desktop, choose Get data, select Excel workbook or Text/CSV, pick the exported file, choose the right table in the Navigator, and click Transform data to clean it up in Power Query.

The thing to understand about this route: it is manual and it stays manual. The export is a snapshot. Every time you want current numbers, somebody re-exports and the file is replaced. Saving the field map makes that less painful, and putting the exported file in a synced OneDrive or SharePoint folder means a scheduled refresh can at least pick up the new version without anyone touching Power BI.

Which Route Should You Use?

Pick by where the data lives and how fresh it needs to be.

• Planner Premium plus Dataverse is the right answer if you are reporting across more than one project and you need the numbers to refresh on a schedule. It is the only route here with a genuine live connection to a managed store.
• Export from Project desktop is right for a one-off: a board pack, a single programme review, a schedule that is finished and will not change. Do not build a standing dashboard on it unless you have accepted that someone owns the re-export.
• Project Server Subscription Edition is right if you are already on-premises for compliance reasons. The classic OData reporting endpoint pattern still applies against your own server rather than a Microsoft-hosted one.
• Power Automate into an intermediate store is right when you cannot get Dataverse access but still need automation. Treat it as a workaround, not an architecture.

One general rule: if more than two people are going to look at the report, do not base it on a manual export. The failure mode is not a broken dashboard, it is a dashboard quietly showing last quarter's dates while everyone makes decisions on it.

Picked a route and want a second opinion on the reporting itself? Get a free audit at https://www.seo-stuff.com/free-audit and find out which numbers are worth putting on the dashboard.

What Are the Limitations Worth Knowing?

Four of them will cost you time if you do not know them up front.

Custom fields are not straightforwardly queryable. Planner Premium stores custom field data in the Project tables as a binary blob rather than as ordinary columns. That means your bespoke fields will not appear as something you can filter, group or chart in Power BI the way the built-in columns do. If your reporting depends on custom fields, validate that early, because it may change your whole approach.

Microsoft Graph does not cover premium plans. The Graph Planner endpoints for plans and tasks only address classic Planner. They do not expose Planner Premium's dependencies, resource assignments or custom fields. If a developer on your team suggests "just use Graph," this is why it will not work for premium data.

The Dataverse schema for Planner Premium is thinly documented. The table names are discoverable and the common ones are listed above, but the full relational model is not documented the way Project Online's reporting schema was. Expect some exploration in Power Apps before you get the joins right.

There is no replacement content pack. The single biggest practical difference from Project Online is that the quick path to a working dashboard no longer exists. Budget real build time, or start from the published templates.

Reporting stack held together with exports and good intentions? A free audit at https://www.seo-stuff.com/free-audit will show you where the gaps are before someone else finds them.

How Does This Compare to the Alternatives?

If the Dataverse build looks like more work than the reporting is worth, there are reasonable alternatives — and sometimes they are the honest answer.

Build the schedule where the reporting already is. If the only reason you need Project is a timeline, a Gantt chart built directly in Excel will reach Power BI with no export dance at all, and it costs nothing extra. For single-project schedules this is frequently the better engineering decision, not a compromise.

Use Dynamics 365 Project Operations. If you are a project-based business that needs schedules tied to billing, resourcing and revenue recognition, Project Operations sits on the same Dataverse foundation and the reporting story is considerably richer. It is a much larger commitment.

Use a third-party project tool with a native connector. Several project platforms ship a supported Power BI connector and a prebuilt dashboard. If you are migrating off Project Online anyway, that is a legitimate moment to ask whether staying in the Microsoft stack is actually buying you anything.

Query Dataverse directly. For developers, the Dataverse Web API is OData v4, and there is a Tabular Data Stream endpoint for SQL-style queries. If you want a warehouse rather than a dashboard, pull from those rather than from Power BI.

Final Thoughts

The practical answer to "how do you connect Microsoft Project to Power BI" in 2026 is: find out which Microsoft Project you are actually on, then use Dataverse if you are on Planner Premium and an Excel export if you are on desktop files. The OData feed that every older tutorial recommends retired with Project Online on 30 September 2026.

The deeper lesson is one that applies well beyond project reporting. The connector you build on is a dependency, and dependencies get retired. When a vendor moves a product's data layer, every dashboard downstream of it becomes a maintenance job — which is a good argument for keeping the number of hand-built connections small and the documentation of them current.

If you are reworking your reporting anyway, it is worth checking whether the reports you are rebuilding are the ones anyone reads. Our guide to building a project management dashboard in Power BI covers which measures actually earn their place on a project dashboard, which is a better starting point than porting your old layout across unchanged.