Rebuilding Project Online Power BI Reports After Migration: A Practical Guide

Here's a test. Pull up the Power BI workspace your PMO uses for Monday morning status reports. Open the semantic model that drives it. Look at the data source. If that source URL contains _api/ProjectData, you have a Project Online Power BI time bomb. That data source stops working on September 30, 2026.

Most teams know this in abstract. Fewer have inventoried which specific reports depend on the Project Online OData feed, classified which of those reports are mission-critical, and built a rebuilding sequence that doesn't land on one overworked Power BI developer the week before cut-over. The gap between knowing "our reports will break" and knowing "these specific datasets need to be re-pointed by August 15" is precisely where migrations slip.

This post is the practical guide: how the Project Online OData reporting model works, which KPIs survive a field-mapping exercise, which need redesign, and what order to do the work in so the Monday morning dashboard is live on the new data source before the OData feed goes dark.

Context: this post is one piece of the wider 2026 retirement landscape, the consolidated reference covering all three Microsoft Project ecosystem retirements happening in 2026.

TL;DR: Project Online Power BI reports run on a proprietary OData schema unique to PWA. Tables like Projects, Tasks, Assignments, and Timesheets won't exist in your new tool's export API under the same names or structure. Some KPIs, including budget vs. actual and schedule variance by project, rebuild cleanly with field mapping. Others, including time-phased actuals and OData-computed measures, need redesign. Run a report inventory now, triage by business criticality, and rebuild in order: connector, then semantic model, then visuals.

How Project Online Power BI connections actually work

Project Online exposes its data through an OData v3 endpoint at /_api/ProjectData/[ProjectWebAppUrl]/. This is a read-only reporting feed. Power BI connects using the built-in OData connector, authenticates with Office 365 credentials, and pulls from named entity sets: Projects, Tasks, Assignments, Resources, Timesheets, Baselines, Issues, Risks, and about 40 others.

Each entity set becomes a table in Power Query. The report developer joins those tables, applies business logic in DAX measures, and builds the visuals. The result is a report that refreshes on schedule, pulling live data from Project Online every time it runs.

This architecture has one critical dependency: the OData endpoint must be online and authenticated. When Project Online retires, the endpoint goes dark. Every Power BI dataset with a connection to that endpoint fails to refresh from that point forward. Historical data already loaded into the dataset stays readable until someone deletes the dataset, but no new data comes in. Any report with a rolling time window, a "last refreshed" filter, or a date-relative measure starts showing stale or broken numbers immediately.

The failure mode is not "reports show old data and people notice." The failure mode is "the dataset refresh fails with an authentication error, Power BI marks the report as failed, and executives see a broken dashboard Monday morning during the highest-scrutiny week of the migration."

The OData entity sets your reports most likely depend on

In most Project Online Power BI implementations, five entity sets carry the majority of the reporting load. Knowing exactly which ones your reports depend on tells you the scope of the field-mapping work ahead.

Projects: Project-level fields including status, finish date, budget, schedule performance, and custom enterprise fields tagged as "project-level." This table is the spine of most PMO dashboards.

Tasks: Task-level data for all tasks published through the Project Desktop client or via API. Includes duration, start, finish, percent complete, critical path flag, baseline fields, and constraint types. Note that tasks in personal MPP files outside the PWA scope do not appear here.

Assignments: Resource assignment data, including who is assigned to which task, at what units, with what planned work, actual work, and remaining work. The source for utilization reports, capacity heatmaps, and workload analysis.

Timesheets: Actuals reported by resources through the PWA timesheet system. Includes the reporting period, hours by task, approval status, and submitted-vs-approved delta. Most finance-facing actuals reports depend on this table.

Baselines: Project-level and task-level baseline snapshots including baseline start, finish, work, and cost. The source for schedule-variance and cost-variance reporting against the original approved plan.

Every one of these tables is Project Online-specific. No modern PM tool exposes an OData endpoint with the same schema, the same entity names, or the same grain. After migration, you need new data sources for every report that touches any of them.

Triaging your report inventory before you start rebuilding

Not every report is worth rebuilding. Running an inventory and triage pass before writing a single line of new DAX saves significant rework.

Pull the dataset usage report from the Power BI admin portal. It shows the last-accessed date for every report and semantic model in your workspace. Sort by last-accessed date. Any report not opened in 90 days is a strong archive-or-retire candidate; any report opened in the last 30 days is a rebuild-now priority.

Classify each report into one of three buckets:

Rebuild before cut-over: Reports with active executive consumers, reports tied to operational decisions (resource allocation, budget approval, project status), and reports referenced from other dashboards or embedded in SharePoint pages.

Rebuild in the first 30 days after cut-over: Reports used monthly or quarterly, reports whose consumers can tolerate a manual export as a bridge, and reports that can be partially replaced by built-in dashboards in the new PM tool.

Archive or retire: Reports built for a one-off analysis that has since been answered, duplicate reports that cover the same data as a higher-priority rebuild, and reports that the new PM tool's built-in reporting fully replaces.

Build a spreadsheet with one row per dataset: dataset name, workspace, last-accessed date, business owner, tier (rebuild now / rebuild later / archive), and assigned developer. This spreadsheet becomes the tracking artifact for the entire reporting migration.

What rebuilds cleanly and what needs redesign

Understanding this distinction before you start saves weeks of surprises during the semantic model rebuild.

The diagram below shows the data flow from Project Online's OData source to reports, and what that path looks like after migration to a modern PM tool with a REST or webhook API.

What rebuilds cleanly (field mapping is enough):

• Project status, phase, and health fields: every modern PM tool exposes these as first-class project attributes.
• Budget vs. actual at project level: standard financial fields present in all enterprise PM tools, just with different column names.
• Schedule variance: baseline finish minus current finish, by project. Universally available once you have baseline data migrated.
• Resource assignment totals and utilization rates: assignment count and assignment hours are available in all tools; column names change but the data is there.
• Issue and risk counts per project: standard metrics any PM tool exposes via its API.

What needs redesign:

• Time-phased actuals: Project Online's OData exposes timesheet data by period, allowing charts that show hours worked per week per resource or per project. Most modern PM tools expose only summary totals, not period-by-period breakdowns at the task level. Recreating time-phased charts requires either a different data model or a warehouse layer between the PM tool and Power BI.
• OData-computed columns: Project Online's OData schema includes columns that are computed server-side based on field logic defined in PWA. These don't exist in the destination tool's API. Recreate the computation in DAX or Power Query.
• Cross-project portfolio aggregations using Project Online's portfolio analyzer entities: no universal replacement; depends on whether the destination tool exposes portfolio-level entities in its API.

The rebuilding sequence that avoids rework

Rebuild in this order: connector first, then semantic model, then visuals. Inverting this sequence produces expensive rework.

Step 1: Build and validate the new connector. Your destination PM tool exposes an API, REST endpoint, or export mechanism. Authenticate in Power BI, pull the raw tables, and verify that the data shapes match your expectations. This is pure data engineering; no DAX, no visuals. At this stage, confirm that every entity set you plan to report on is actually exposed by the new tool's API with the granularity you need.

Step 2: Rebuild the semantic model. Map source columns from the new connector to the column names expected by your existing DAX measures. Where columns are missing, build computed columns in Power Query. Where the grain differs (time-phased vs. summary), rebuild the table structure at the correct grain. Do not build or modify any visuals until this step is validated.

Step 3: Validate the model against the source. While Project Online is still live, run both the old OData-based report and the new semantic model against the same period. Compare key metrics. Any KPI difference greater than five percent warrants investigation before cut-over. This validation step is the one most teams skip because the cut-over date is close; skipping it is how discrepancies get discovered by executives, not by the migration team.

Step 4: Update or rebuild visuals. Once the model is validated, update visual field references in the Power BI canvas. For reports being redesigned rather than just re-pointed, this step may involve adding new visuals or consolidating existing ones.

Start connector work 8 to 10 weeks before your target cut-over date. The semantic model step consistently takes longer than estimated once real field-mapping gaps emerge from actual data. The visual rebuild is usually the fastest step once the model is solid.

Managing reporting continuity during the cut-over window

For the two to four weeks when you're running Project Online and the new tool in parallel, you'll have two data sources and a question of which one is authoritative.

Keep the old OData-based reports authoritative until the moment of cut-over. Run the new reports in shadow mode: built, validated against the old source, but not published to the executive audience. On cut-over day, flip the Power BI gateway authentication from the OData endpoint to the new tool's API, verify the report loads with live data, and send the updated workspace link to report consumers.

For reports that aren't ready at cut-over, communicate a managed gap rather than leaving an unexplained blank dashboard. "This report is being rebuilt for the new system and will be available [date]" is far better than a silent failure that generates support escalations during the migration's highest-scrutiny period.

Review the full project online migration checklist for where Power BI reporting fits into the broader pre-migration inventory, and check the 90-day migration plan for the recommended timeline for report rebuilding relative to data migration and cut-over.

Microsoft's July 2024 retirement announcement confirmed September 30, 2026 as the final service date with no extensions. That is the hard stop for the OData feed. Report rebuilding is a bounded problem, but only if you start it far enough in advance to validate before cut-over.

Run the free Migration Preview Upload a sample .mpp file and see which data elements survive the tool boundary before you start planning your Power BI connector rebuild. No signup required. → Open Migration Preview

Microsoft Project Online™ is a trademark of Microsoft Corporation. Onplana is not affiliated with Microsoft.