What Happens After Project Online Retires: PWA, Data, and Permissions
After Project Online retires September 30, 2026, PWA stops and OData returns 410. Here is the exact sequence—read-only window, data fate, permissions.
Here is the scenario most PMO directors are quietly worried about: September 30, 2026 arrives and they're not fully migrated. What actually happens after Project Online retires on that date? Which services break first, and is there any window left to recover data?
Understanding the post-retirement sequence is not just useful for contingency planning—it shapes how you prioritize your migration work and which data types you move first. The answer matters whether you are 90% done or have barely started.
After Project Online retires, PWA goes dark, OData returns 410 Gone, and the enterprise resource pool becomes unreachable—simultaneously. An informal ~90-day read-only window may follow, but Microsoft has not guaranteed it. Your practical export deadline is August 31, 2026. SharePoint project sites survive. Everything inside Project Online's scheduling database does not, unless you extracted it first.
The diagram below shows the five phases of the post-retirement timeline—from the last days of full service through the point where all access is permanently gone.
The dashed segment between September 30 and the eventual permanent shutdown is the piece that trips up most migration plans. Teams see "~90 days of read-only access" mentioned in Microsoft documentation and mentally give themselves until December to finish. That reasoning is why migrations fail.
What "Retirement" Actually Means for an Enterprise SaaS Product
When Microsoft retires a SaaS product, the infrastructure that runs it stops being maintained and eventually stops being provisioned. It is not the same as end-of-support, where a product continues running but no longer receives updates. Retirement means the service literally stops.
For Project Online, that means the SharePoint framework component that hosts Project Web App, the SQL backend where your project data lives, the authentication broker for the OData API, and the workflow orchestration layer for timesheets all get decommissioned on the same date. Microsoft confirmed this scope in the Project Online service description retirement guidance published July 2024. There is no partial sunset where some features keep working while others are deprecated. The cutover is simultaneous.
The operational difference from a customer's perspective: one day your PMO directors log into PWA, check portfolio status, approve timesheets, and run OData-backed Power BI reports. The next day, all of that fails. There is no degraded mode, no read-limited mode, no warning banner. The service stops, and the question of what happens next is the one this post answers.
What Breaks First: The Day-One Impact After Project Online Retires
On September 30, 2026, the following stop working immediately and simultaneously.
PWA site collection access. Every user who navigates to your PWA URL—https://[tenant].sharepoint.com/sites/pwa or whatever alias you've configured—receives a service-unavailable or resource-not-found response. The PWA site collection is decommissioned, not just disabled.
OData API endpoint. The endpoint at /_api/ProjectData returns 410 Gone. This is the signal that the resource no longer exists and will not return. Power BI reports, Excel workbooks with OData connections, custom dashboards, and any application consuming this feed stop refreshing. If those reports drive executive steering meetings, those meetings start with broken data on day one unless you've rebuilt the reports against a different data source.
Project Online Desktop Client online features. The desktop application itself continues to function for locally saved .mpp files. What stops is everything that requires a live PWA connection: checking out a project from the server, publishing an updated schedule, syncing resource assignments from the enterprise resource pool, submitting work actuals. If your PMs habitually publish their schedules to Project Online, that publish button stops working.
Resource pool synchronization. Any project open in the Desktop Client that has resources assigned from the enterprise resource pool will no longer be able to update those resource assignments from the server. The local copy of the project retains the resource names, but the connection to the ERP is severed.
Timesheet system. The timesheet web application inside PWA stops. Active timesheet periods that have not been submitted, approved, and locked will be in an indeterminate state. Time entries accumulated up to September 30 but not yet approved are stuck. This is the category that causes the most immediate operational pain if not handled before the cutover.
Stage gates and governance workflows. Any projects in mid-approval—a PDP form submitted, a stage gate awaiting sponsor decision—will have their workflow suspended. The workflow engine that drives Project Online's governance features is decommissioned with the rest of the service.
The Read-Only Window: What It Covers and What It Doesn't
After the hard retirement date, Microsoft may—emphasis on may—maintain a limited read-only access window for data retrieval. Microsoft's historical behavior with SaaS retirements gives rough precedent for a 60 to 90 day window, but the important qualifier is that this is never formalized in the Project Online service agreement. It is not an SLA commitment.
During a read-only window, if Microsoft provides one, you would presumably be able to retrieve data via the OData API and possibly download .mpp files. You would not be able to make changes—no new projects, no timesheet submissions, no workflow actions.
Three reasons not to plan around this window:
Throttling. Even if the read-only API is available, every organization that missed the September export deadline hits it simultaneously. Microsoft's servers face enormous concurrent load. Exports that take three days in May will take two to three weeks in October, if they complete at all.
No guarantee on scope. Microsoft may provide read access to some data types but not others. Timesheet history, for example, might not be accessible even if project schedules are.
It delays everything else. A team waiting for the read-only window to "finish their export" is not finalizing their destination platform configuration, not training users, and not stabilizing processes. The migration gets pushed another three months while the new platform sits idle.
The Project Online retirement 90-day plan is built around a September 1 practical deadline specifically to avoid this trap.
What Happens to Historical Project Data Long-Term
Once the read-only window expires—whether that is 60 days, 90 days, or some other period—all access to Project Online's database ends permanently.
This is the part that is difficult to communicate to stakeholders who haven't managed a SaaS sunset before. The data is not deleted by Microsoft in the sense of being overwritten. It is simply no longer accessible. The servers are decommissioned, the databases are taken offline, and the authentication infrastructure that would allow any client to query them is shut down. There is no "request your data" path after that point, no backup restoration service, no support ticket that retrieves a deleted project. The data is effectively gone for any practical purpose.
For organizations with audit, compliance, or contractual requirements around project record retention—SOX controls, ISO 9001 quality records, government contract documentation, client billing evidence—this is a hard deadline, not a soft one. If those records need to exist in 2028, they need to be in a system you control before September 2026.
The practical implication: historical projects that your organization would normally archive rather than actively migrate still need to be exported and stored somewhere before the cutover. Archiving to Azure Blob Storage, S3, or an internal document management system in structured formats like CSV, Parquet, or XML is appropriate for this use case. You're not migrating those projects to a new PM tool—you're preserving the audit record.
Which Permissions and Integrations Break First
The sequence matters for organizations that are partially migrated when the retirement date arrives.
Power BI and Excel connections break day one, since they depend on the OData API. An organization that has migrated 80% of its active projects but still has reporting built on Project Online's OData feed will have broken dashboards from day one of retirement.
Power Automate flows using the Project Online connector stop. Flows that route timesheet approvals, trigger gateway notifications, or sync data to other systems will fail silently—they won't throw errors that propagate to users, they simply won't execute. Discovering broken flows weeks after retirement is a common post-mortem finding.
SharePoint permissions on PWA-derived sites remain intact, because those sites are SharePoint Online sites. Users who had contributor access to the PWA site collection will lose access when the site collection is decommissioned, but their permissions on the project-specific SharePoint sites—the ones that hosted issue lists and document libraries—are unaffected.
Azure AD / Entra ID app registrations that use the Project Online API scope will continue to exist but will receive 410 responses when they attempt to query the service. If you have service accounts or daemon applications polling Project Online for data, they will need their configurations updated or decommissioned.
M365 Group memberships associated with Project Online sites survive. The Groups themselves are not decommissioned with the PWA site collection, so users in those groups remain members. This is largely irrelevant after the PWA site is gone, but it does mean lingering licensing implications if those group memberships were tied to Project Online seats.
What the M365 Admin Sees on and After Retirement Day
From the M365 admin center perspective, the experience is clean from Microsoft's side. The Project Online service tile disappears from the admin center. The PWA site collection shows as decommissioned or simply absent from the SharePoint admin's site collection list. Provisioning scripts that reference Project Online APIs will throw errors.
License reclamation is a separate administrative action. Project Online Professional and Premium licenses attached to users in your tenant do not auto-reclaim when the service is retired. You need to manually remove those license assignments—typically via the M365 admin center, PowerShell, or your Microsoft licensing agreement terms—to avoid continuing to pay for license seats that serve no function. The Project Online licensing removal guide covers this in more detail.
SharePoint admin operations on PWA-derived site collections should be completed before the retirement date. Operations like content migration off those sites, changing permissions, or downloading site inventories should not wait until after September 30.
Planning Your Cutover Backward from the Retirement Date
The practical insight from this post is that after Project Online retires, you have limited options and no guaranteed recovery path. Planning a migration timeline backward from that reality:
September 30: Retirement date. Hard stop.
September 1: Practical export and cutover deadline. All project data exported. All active projects running on the destination platform. Project Online in read-only mode for reference only.
August 1: Active migration complete. No new projects being created in Project Online. Users fully trained on the destination platform.
June 1: Pilot complete, destination platform configured, staged migration underway. The largest wave of project migrations happening in June and July.
May 1 (today): Inventory complete or underway. Vendor decision either made or imminent. OData backup snapshot already taken.
The teams that hit September 1 calmly are the ones that started in April or earlier. The teams arriving at September 30 in crisis mode started in July. That gap—three months of elapsed calendar time—is not recoverable.
The Project Online end-of-life overview covers the full data impact in more detail. When you're ready to run your inventory before committing to a migration scope, the Project Online migration checklist covers all six asset categories that migrations consistently undercount. And the Project Online inventory checklist tool gives you an interactive version you can run on your actual tenant data today.
Microsoft Project Online™ is a trademark of Microsoft Corporation. Onplana is not affiliated with Microsoft.
Ready to make the switch?
Start your free Onplana account and import your existing projects in minutes.