Project Online retires on 30 September.
What happens to your Power BI reports?

Most of the commentary on the Project Online retirement has been written for PMO managers, and it reads like a licensing decision. For anyone who owns a data pipeline, it is something else entirely: a dated, unavoidable break in a source system, with a replacement that silently drops the most valuable part of the payload.

If you maintain a Power BI model that reads scheduling data, this is the short version. The OData endpoint becomes unavailable with the service. The datasets that carried work and cost by period become unavailable with it. And the successor product cannot reproduce them, because it does not hold the underlying data in a form you can query.

Why I looked at this

I have a soft spot for program scheduling and control. It goes back to a stretch of World Bank-financed programs where I sat in the project management consultancy group and had to learn MS Project properly, not the Gantt-chart-for-a-status-pack version, but resource loading, cost accrual and time-phased forecasting under real reporting obligations. I have followed the tooling since.

More recently the interest went the other way: getting that data into Power BI so program analytics reach the people making decisions, instead of living inside a scheduler's desktop. Together with Rouhi Mobtadi, a friend and former colleague who is a seasoned project planning and control professional, we built a full project and program progress monitoring dashboard on exactly this stack. Project schedules published to Project Online, time-phased data pulled through to Power BI, refreshing on its own. It was implemented and used across multiple programs with state government and private sector clients.

So this is not a hypothetical pipeline to me. It is one I have built, handed over, and watched people come to rely on, which is also how I know what the failure mode looks like. Nobody notices a forecasting dataset quietly losing its cost dimension until a number stops reconciling and the reason is three layers down.

That seam is where this retirement does its damage, and it is why the impact gets understated. Schedulers can see that a product is going away. BI people can see that a connector is going away. The part that gets missed is that the specific thing making the integration worth building is the part with no successor.

What actually breaks

Project Online exposed an OData reporting endpoint at /_api/ProjectData. Underneath it sat a set of genuinely time-phased datasets; TaskTimephasedDataSet, AssignmentTimephasedDataSet, ResourceDemandTimephasedDataSet and their baseline variants; with configurable daily, weekly, monthly and fiscal rollup.

That is what made resource and cost forecasting reportable. Not the task list; the distribution of work and money across periods. It is the difference between "this task costs $40,000" and "this task draws $6,000 in March, $22,000 in April and $12,000 in May", which is the only version finance can use.

On 30 September that endpoint stops answering. The enterprise resource pool, enterprise custom fields, timesheets, portfolio analysis and server-side master projects go with it. Microsoft's retirement guidance points customers to partner migration solutions rather than providing a first-party migration utility, and there is no guaranteed read-only period.

Why Planner Premium does not fill the gap

Microsoft's recommended path is Planner Premium, which stores its data in Dataverse. As a BI source that sounds like an upgrade; a documented connector, cloud-to-cloud scheduled refresh, no gateway. For task and assignment reporting it genuinely is.

Two things make it unsuitable as a replacement for forecasting.

There is no native cost model. Not a limited Project-style one. Planner Premium itself has no resource cost rates, no cost resources, and no native budget or financials engine; you can add a custom field and call it "Budget," but nothing in the product calculates, rolls up, or forecasts from it. Microsoft's own support responses (as recently as April 2026) confirm there is no dedicated financials or budgeting module in the product. Oddly, Microsoft's commercial plan-comparison pages have at times listed "project financials, budgeting, and costing" among Plan 3's features; that appears to be marketing language describing the plan tier, not a claim about what the interface actually does, and it's the likely source if you've seen this capability asserted elsewhere. (Microsoft does have a real cost and rate engine elsewhere in the stack, in Dynamics 365 Project Operations, but that is a separate, ERP-scale product, not something a Planner Premium licence gets you.)

Time-phased work is not reachable the way you need it. The underlying data model does include actual and total work broken down by period, not only remaining work; Microsoft's own export schema documents actualWorkContour and totalWorkContour alongside remainingWorkContour at the assignment level. But the standard route into Power BI is the Dataverse connector reading the msdyn_resourceassignment table, and Microsoft's own API documentation for updating that data states the contour operation "solely updates a single field", msdyn_plannedwork, on that table. On Microsoft's own Tech Community forum, developers who reverse-engineered that field for reporting purposes found it holds only remaining work and is overwritten as tasks progress; I have not found a first-party Microsoft statement confirming that behaviour formally, so treat it as well-corroborated rather than documented. Either way, the fuller picture exists somewhere in the product; it does not appear to be exposed as queryable columns through the connector a BI person would actually use.

The practical consequence: percent complete and remaining effort survive the move through the standard connector. Actual cost, and a reliable trend of forecast against outturn, do not, the cost side because the model has none, the work side because the data that would support it is not exposed where Power BI can reach it.

That task cap deserves a note of its own. The 3,000-per-project ceiling itself is documented on Microsoft's own limits and boundaries page. What happens to tasks beyond it is less firmly sourced: FluentPro, a migration tooling vendor, documents that its own migration process skips tasks past the limit without raising an error; I have not found Microsoft's own documentation describing that behaviour for a general import. Treat it as a real risk to plan around rather than a confirmed silent failure: a large program schedule approaching the limit is worth checking carefully before you rely on it having migrated in full.

What survives, in order of how much it preserves

There are three realistic ways to keep time-phased data flowing into a refreshing Power BI model, and one that is cheaper but concedes the forecasting.

1. Project Server Subscription Edition. Worth a correction here: the OData reporting feed is not retained on this product. Microsoft removed it; the documented replacement is the pjrep reporting schema in SQL Server, accessed via database snapshots or SSIS rather than a REST connector. That still keeps time-phased reporting alive; the same SQL Server Analysis Services cube layer that fed the old OData service is present and configurable in Subscription Edition, including a specific time-phased setting, but an existing Power BI model has to be rebuilt against SQL views rather than repointed at a URL. Real effort, not a connection-string change, and the product is on-premises infrastructure, SharePoint, SQL and Windows Server, which can run on Azure VMs including in Australian regions, but is infrastructure ownership rather than a licence purchase.
2. Project desktop plus a scheduled extract. Keep scheduling in the desktop client, and run a scheduled job that pulls the time-phased data out into SQL Server or Fabric, which Power BI then refreshes from. Two routes work: VBA against the TimeScaledData method, or the open-source MPXJ library, which reads .mpp directly from Python or .NET. This preserves both work and cost, and needs one database and a runner machine rather than a farm. Note that this now lands in roughly the same place architecturally as the option above; both end with Power BI reading a SQL Server database, so the real choice is between Microsoft maintaining that database for you (Project Server SE) or you building and maintaining the extract yourself.
3. A non-Microsoft platform with a real reporting database. Primavera P6, Planview, OnePlan and others expose time-phased data properly. Appropriate where the scheduling requirement justifies the change anyway.
4. Planner Premium, accepting the loss. Legitimate if what you actually need is schedule and assignment reporting with Teams collaboration. Just make that trade explicitly rather than discovering it in October.

For most organisations running capital programs in MS Project with a Power BI layer on top, I would start by evaluating option two; it needs no server farm, and the scheduling practice stays unchanged. But option one deserves a proper look before you rule it out: Microsoft maintains that reporting database for you, which is worth something against building and maintaining your own extract. Get both quoted before you decide.

One thing worth checking yourself

While researching this I found a widely-cited vendor post stating that Planner Premium supports finish-to-start dependencies only, with no lag. That is wrong. Microsoft's own Project blog documents all four dependency types with lead and lag, with the caveat that creating the advanced types requires Plan 3 or 5 while Plan 1 users can view but not create them.

One item in this piece I'd flag as not fully nailed down: Project Server SE's SQL Server reporting schema and OLAP cube layer clearly retain rich reporting capability, including a distinct time-phased setting, but I have not found a named, first-party-documented view or table that exposes time-phased assignment data the same way the old OData feed did. The architecture supports it; I have not pinned down the exact query. If you're building against this, confirm it on your own instance or with a partner who has, rather than taking that part on the strength of this article alone.

A lot of the available commentary on this retirement is published by vendors selling the migration, and their accounts of the successor product's gaps are not always accurate in either direction. The underlying limits here are documented first-party, on Microsoft's own limits and boundaries page and its Project Server documentation. Worth reading before accepting anyone's summary of it, including this one.