Most Project Online migration plans account for schedules, tasks, and resources. The item that quietly breaks, and rarely appears on the checklist, is the reporting layer. Project Online stores its data in SharePoint Online, while its successor Planner Premium stores data in Dataverse. That single architecture change is why every Power BI dashboard built on the ProjectData OData feed stops working after migration, and why re-pointing a connection string will not fix it.
For PMO and BI leads, this is the risk with the longest tail. A board dashboard or a compliance report that has run reliably for years is tightly coupled to a data model that ceases to exist on September 30, 2026. The schedules migrate. The reports do not.
Why reporting is the overlooked casualty of the migration
Reporting breaks because it depends on a data model, not just a data set. Project Online dashboards read from OData feeds and OLAP cubes tied to the SharePoint-based ProjectData schema. When the underlying platform moves to Dataverse, that schema disappears, and anything built on top of it loses its source.
The organizations most exposed are the ones with the most mature reporting. Enterprise PMOs commonly run 30 to 50 custom fields per project for governance metadata, feeding executive dashboards that leadership relies on monthly. The more sophisticated the reporting, the more work it takes to rebuild, because none of it survives the platform change on its own. ​Microsoft’s lifecycle documentation confirms the September 30, 2026 retirement and that data becomes inaccessible after that date, which is why protecting this layer requires the ​enterprise architecture and data integration discipline that treats reporting as a first-class migration workstream, not a downstream afterthought.
What actually breaks, and what is recoverable
Not every asset carries the same risk. Sorting them by recoverability is what separates a controlled migration from a scramble.
Power BI dashboards and power automate flows
Dashboards and flows are the highest-risk items because they are tightly coupled to the PWA data model and not recoverable in any meaningful sense. Dashboards must be re-pointed at the new platform’s API, and flows re-authored against new triggers. Budget three to ten days per dashboard depending on complexity, and inventory every report before assuming it can be rebuilt quickly. Rebuilding on a modern ​analytics and reporting foundation is often the better path than replicating the old dashboards field for field.
Custom fields, formulas, and resource logic
The painful losses look like configuration rather than data: enterprise custom fields with their lookup tables and formulas, resource cost rates refined over years, and the segmentation that reflects your actual reporting hierarchy. Institutional logic like this took months to build and does not export on its own, so it needs to be documented and rebuilt deliberately as part of a structured ​work and operations management transition.
Timesheet history
Timesheet records are recoverable via OData while the service is live, and they matter more than most teams expect. Finance often relies on them quietly for capitalization reporting, billing, and revenue recognition. Organizations subject to SOX or government contracting requirements need this history captured in a records management system before retirement.
SharePoint document libraries
Attachments, status reports, and project site content stored in SharePoint remain recoverable through standard export tools, and on a slightly longer timeline than the service itself. Even so, inventory which libraries must stay searchable after retirement and archive them into your target document store deliberately.
How to protect your reporting before the deadline
The teams that avoid a reporting gap treat it as a distinct workstream that starts early, not a task discovered during cutover.
Begin by inventorying by dependency, not by product name. List every Power BI dataset, OData feed, Excel workbook, scheduled refresh, and downstream integration, then identify which ones feed the board deck or a compliance filing. A PWA admin knows what is configured, but only a business owner can say whether a given report drives a monthly executive decision. Get sign-off from the PMO director, IT, records manager, and integration owners on what must be preserved.
Next, rebuild the critical reports first on the new platform, validating each against the numbers the old dashboard produced for the same period. Connecting the rebuild to disciplined ​data migration practices ensures the historical baseline transfers intact rather than resetting to zero on the new system.
Protect the reports that drive your decisions
The Project Online retirement will not announce which of your reports are about to break. The dashboards keep working right up until the platform is gone, which is exactly why the reporting risk is so easy to miss until it is too late to fix cleanly. The PMOs that come through this without a gap are the ones treating historical reporting as a migration priority now, while the source system is still live and the data is still exportable.
If your organization is planning a move off Project Online, ​connect with Advaiya’s team. With deep Microsoft data platform expertise and OnePlan migration experience, Advaiya helps PMOs preserve their historical reporting, rebuild executive dashboards, and protect the governance data that leadership depends on before the deadline arrives.
Frequently asked questions
Project Online stores data in SharePoint Online, while its successor Planner Premium stores data in Dataverse. Power BI dashboards built on the Project Online OData feed depend on the SharePoint-based data model, which disappears in the migration. The reports cannot be fixed by changing a connection string and must be re-authored against the new platform's API.
Power BI dashboards and Power Automate flows are not recoverable in any meaningful sense because they are tightly coupled to the PWA data model. Custom field formulas, refined resource cost rates, and reporting hierarchy logic also do not export on their own and must be documented and rebuilt deliberately.
Rebuilding a Power BI dashboard typically takes three to ten days per dashboard depending on complexity, since each must be re-pointed at the new platform's API and validated against historical numbers. Inventorying every report early is essential to estimate the total effort accurately.
Timesheet history is often relied upon by finance for capitalization reporting, billing, and revenue recognition. Organizations subject to SOX or government contracting requirements need these records preserved in a records management system before retirement, as they are only recoverable via OData while the service is live.
Inventory by dependency, not by product name. List every Power BI dataset, OData feed, Excel workbook, scheduled refresh, and downstream integration, then identify which feed board decks or compliance filings. Business owners, not just admins, should confirm which reports drive real decisions and must be preserved.
Reporting migration should begin well before the September 30, 2026 deadline, while the source system is live and data is still exportable. Because rebuilding dashboards and re-authoring flows takes days per report, starting early prevents a reporting gap during the transition to the new platform.
