Microsoft Project Online retires on September 30, 2026. After that date, Project Web App sites and the project data inside them are no longer available. Any PMO still running schedules, timesheets, or an enterprise resource pool in PWA has two jobs: export the data before the cutoff, and choose what replaces the platform. Those jobs have different deadlines. Treating them as one is how organizations end up signing a contract in a hurry to save data that an admin could have archived in a week.
Key takeaways
- Project Online retires on September 30, 2026. Sales to new customers ended October 1, 2025, and PWA sites with no projects were made inaccessible on April 1, 2026.
- Project desktop, Project Server, and Planner are not part of the retirement.
- Planner premium plans cover scheduling well: Microsoft lists portfolios, baselines, dependencies, and Gantt charts. The enterprise resource pool, timesheets, and portfolio analysis are not on that list.
- There are four realistic routes: Planner premium plans, Project Server Subscription Edition, a Microsoft 365 PMO layer from a partner, or a dedicated PPM platform.
- Full migrations commonly take 3 to 6 months. With weeks left, secure the data first and make the platform decision properly.
Last updated September 2026.
When does Project Online retire?
Project Online retires on September 30, 2026. Microsoft announced the retirement in September 2025, stopped selling Project Online-only plans to new customers on October 1, 2025, and on April 1, 2026 blocked the creation of new Project Web App sites and made existing PWA sites that held no projects inaccessible. Existing customers keep full support, including integrations and team member access, until the retirement date.
Each of those dates changed something for a PMO that stayed put, and the middle one catches people out. A PWA site kept around for testing or training, with no projects in it, may already be gone.
| Date | What changed | What it means for a PMO still on PWA |
|---|---|---|
| September 2025 | Microsoft announces the retirement | Any renewal signed after this point was for a service with a published end date |
| October 1, 2025 | End of sale for Project Online-only plans to new customers | Existing tenants continue, but nobody can start fresh on the platform |
| April 1, 2026 | New PWA site creation blocked; PWA sites with no projects made inaccessible | Sandbox, test, and training sites without projects may already be unreachable |
| September 30, 2026 | Project Online retires | PWA sites and the project data in them are no longer available |
Swipe to see more →
The retirement is narrower than the headlines suggest. Microsoft has said it does not affect Project desktop, Project Server, or Planner. The premium Planner features that grew out of Project for the web, which Microsoft describes as portfolios, baselines, dependencies, and Gantt charts, are sold through the Planner and Project Plan 3 and Plan 5 licenses.
What happens to Project Online data after September 30, 2026?
After September 30, 2026, Project Web App sites and the data in them are no longer available, and there is no published grace period you should plan around. Anything worth keeping, including closed projects, timesheet history, baselines, and the enterprise resource pool, has to be exported before the cutoff, because it lives inside the service rather than in files your organization already holds.
That last point is the one people underestimate. A project manager's schedule feels like a file, but in PWA it is a set of rows in Microsoft's database, published and checked in. The same is true of every approved timesheet and every resource's calendar. The two practical export routes are the OData reporting feed that most Power BI portfolio reports already read from, and opening individual schedules in Project desktop and saving them as .mpp files.
| Data | Export route | What you lose if it is skipped |
|---|---|---|
| Active project schedules | Open in Project desktop and save as .mpp; also available through the OData Tasks and Assignments data | The working plan for every project still in flight |
| Closed project history | OData Projects, Tasks, and Assignments data into a database you own | The actuals you estimate the next project from |
| Baselines | OData baseline data for projects, tasks, and assignments | Variance history, so every project restarts as if it had always been on plan |
| Timesheets and actual work | OData timesheet and timesheet line data | Effort history, and often the evidence finance relies on for capitalized labor |
| Enterprise resource pool | OData Resources data plus the timephased resource data | The capacity and skills model behind every allocation decision |
| Enterprise custom fields and lookup tables | Values come through OData; document the field definitions and hierarchies separately | The attributes your reports filter on, such as department, strategic theme, and stage |
| Risks, issues, and project documents | OData exposes risk and issue lists; documents are a SharePoint content decision for your tenant admin | The decision trail behind the projects |
Swipe to see more →
What Project Online did that Planner does not replace
Microsoft positions Planner as the successor, and for scheduling that is a fair description. The trouble is that many PMOs were not using PWA mainly as a scheduler. They were using it as the system of record for the portfolio: the place where resource managers approved assignments, timesheets were submitted, and projects moved through gated workflows. The table below compares those capabilities with what Microsoft lists for the premium Planner plans. Where a capability is not on Microsoft's list, the honest position is to test it in a trial rather than assume it is there.
| What a PMO relied on in PWA | Planner premium plans, as Microsoft describes them | What usually replaces it |
|---|---|---|
| Schedules with baselines, dependencies, and Gantt views | Listed as premium features | Planner premium plans, or Project desktop for the heaviest schedules |
| Grouping projects into portfolios for visibility | Portfolios are listed | Planner premium plans for visibility; a PPM platform where the portfolio must also be governed |
| Enterprise resource pool with capacity across all projects | Not on the list; test before assuming | A PPM platform, or Project Server Subscription Edition |
| Timesheets and approved actuals | Not on the list; test before assuming | A PPM platform with time capture, or Project Server Subscription Edition |
| Enterprise project types and workflows that gate intake and stages | Not on the list; test before assuming | A PPM intake module, a partner governance layer, or a Power Platform build |
| Portfolio analysis against business drivers and budget or resource constraints | Not on the list; test before assuming | A strategic portfolio management or PPM platform |
| The OData reporting feed behind Power BI | Premium plan data sits in Dataverse, a different data model | Reports rebuilt against the new platform's API or data store |
Swipe to see more →
The pattern is simple once it is laid out. If PWA was mostly a shared place to keep schedules, Planner is a real answer and probably the cheapest one. If PWA ran your project intake process and your capacity decisions, Planner is a scheduling answer to a portfolio problem, and the gap will reappear as spreadsheets within a quarter.
What are the alternatives to Project Online?
There are four realistic alternatives to Project Online: Planner premium plans, usually alongside Project desktop; Project Server Subscription Edition on your own servers; a PMO layer built on Microsoft 365 by a partner; or a dedicated project portfolio management platform. The right one depends on what PWA was actually doing for your organization, not on which vendor gives the most convincing demo.
| Alternative | Fits when | You keep | You give up | Watch for |
|---|---|---|---|---|
| Planner and Project Plan 3 or 5 | PWA mostly held schedules and few specialists were shared across projects | Microsoft 365 licensing, identity, and familiar scheduling | The resource pool, timesheets, and portfolio analysis as PWA ran them | Capacity planning drifting back into spreadsheets because nothing replaced the pool |
| Project Server Subscription Edition | Data must stay on premises, or the customization is too deep to rebuild this year | The PWA model: enterprise project types, timesheets, resource pool, OData | The cloud service; your team runs SharePoint Server and SQL Server again | Moving from Online to Server is still a migration, with its own infrastructure project |
| A Microsoft 365 PMO layer from a partner | You want to stay inside Microsoft 365 and add intake, governance, and reporting | Teams, SharePoint, Power BI, and Microsoft identity | A mainstream product roadmap; you now depend on one partner's | Who supports the build after go-live, and what happens when Microsoft changes the platform underneath it |
| A dedicated PPM platform | PWA was your portfolio system of record: pool, timesheets, intake, and selection | Portfolio capability, often deeper than PWA offered | The Microsoft-native feel; users learn a new tool and a new data model | Import fidelity for custom fields, calendars, and baselines |
Swipe to see more →
Several PPM vendors, Celoxis, Epicflow, and Planisware among them, now publish their own guides to replacing Microsoft's project tools. They are worth reading for the import details and worth discounting on the conclusion, since each one ends with its own product. If the fourth route is yours, the named platforms and the buyer situation each one suits are laid out in best PPM software by buyer situation. The requirements, RFP, and pilot work for a large estate belong in a proper enterprise project portfolio management software selection, which this page does not try to repeat.
Which Project Online alternative fits your PMO
The fastest way to choose a route is to look at how PWA was actually used, not at the license you paid for. Pull the last year of usage from your admin: who opened Resource Center, who submitted timesheets, which enterprise project types had workflows attached, and whether anyone ran a portfolio analysis. The answers point to a route more reliably than any feature checklist.
| What you find in your PWA estate | What it tells you | Route it points to |
|---|---|---|
| Schedules are the main artifact and almost nobody opens Resource Center | PWA was a shared scheduling tool | Planner premium plans with Project desktop |
| Timesheets feed finance for capitalization or chargeback | Time capture is a financial control, not a convenience | A PPM platform with time capture, or Project Server Subscription Edition |
| Resource managers approve assignments inside PWA | Your capacity process runs through the tool | A PPM platform, or Project Server Subscription Edition |
| Enterprise project types push projects through approval stages | Intake and governance are encoded in PWA workflows | A PPM platform, or a partner governance layer |
| Portfolio analyses were run for annual planning | PWA was doing portfolio selection | A strategic portfolio management or PPM platform |
| Security or residency rules rule out a new cloud vendor this year | The constraint is procurement, not capability | Project Server Subscription Edition as a bridge |
Swipe to see more →
Most estates show more than one signal. When they do, route by the most demanding row that is really in use. An estate where timesheets drive capitalization cannot move to a tool without time capture just because the schedules would fit there comfortably. If approval stages were doing real work, map them to a stage gate process before evaluating tools, so you are testing vendors against your process rather than theirs.
How long does a Project Online migration take?
A full Project Online migration usually takes months rather than weeks. Microsoft partners that run these projects, such as Wellingtone, put most of them at 3 to 6 months, depending on data complexity, governance requirements, and how much change adoption is involved. With the retirement date weeks away, that means securing the data first and running the platform decision on its own timeline.
The split works because the two jobs are different in kind. Archiving is mechanical: an administrator with access to the reporting feed can copy the history into a database, and project managers can save their live schedules, in a matter of days. Choosing a platform is organizational. It involves the resource managers, finance, the sponsors who approve projects, and a procurement cycle that does not speed up because a vendor's deadline is approaching.
A two-track plan for the weeks before September 30
Run the two tracks in parallel, with different owners. Track one has a hard end date. Track two should not be allowed to borrow that date as a reason to skip evaluation.
| Track | Step | Output | Owner |
|---|---|---|---|
| Data | 1. Inventory the estate: projects, custom fields, lookup tables, project types, workflows, and every report or integration that reads from PWA | A one-page estate inventory | PWA administrator |
| Data | 2. Export the history through the OData feed into a database you own | A queryable archive | PWA administrator with the BI or data team |
| Data | 3. Save every in-flight schedule from Project desktop as an .mpp file | Working plans that survive the cutoff | Project managers |
| Data | 4. Verify: compare row counts with PWA and rebuild one important report from the archive | Proof the archive can actually be used | PMO lead |
| Decision | 5. Classify the estate with the usage signals above | A chosen route | PMO lead and sponsor |
| Decision | 6. Give active projects an interim home, either Project desktop files or Planner premium plans | No in-flight project stalls | PMO |
| Decision | 7. Run the selection with an import test on your own exported data | A contract signed on evidence | PMO with procurement |
Swipe to see more →
Step four is the one that gets skipped, and it is the only one that tells you whether steps two and three worked. An archive nobody has queried is a hope, not a backup. If the history has to live inside the new platform rather than sit in an archive, a data integration tool that maps one system's API to another's can move it in one supervised pass once the destination is chosen, which is another reason the export should come first. The rebuilt reports themselves are worth designing properly rather than copying, and the layout choices are covered in the guide to the project portfolio dashboard.
Import tests to run before you sign
Every vendor in this market now says it can import Project Online data, and the claim is true at the level of a schedule. It gets less true as you move toward the portfolio data PWA was holding. Ask for each of these tests to be run on a sample of your own exported data during the pilot, not on a demonstration dataset.
| Test | A pass looks like | A red flag |
|---|---|---|
| Enterprise custom fields and lookup tables | Values and hierarchies arrive mapped to fields you can filter and report on | "We import the schedule now and map fields later" |
| Resource pool with calendars and rates | Named resources keep their calendars, cost rates, and attributes | Resources arrive as plain text names on tasks |
| Baselines | At least the current baseline carries over for in-flight projects | Only the current plan imports, so variance starts at zero |
| Dependencies between projects | Links across projects survive the import | Every project arrives as an island |
| Timesheet history | Actuals by resource and period arrive, or the vendor says plainly that they will not | No clear answer about actuals at all |
| Your three most used reports | Rebuilt on the vendor's data model during the pilot | "Our dashboards are better" with no rebuild shown |
Swipe to see more →
Resource data deserves the most suspicion. A pool that imports without calendars and availability looks complete in a demo and produces wrong capacity numbers on the first planning cycle, which is the moment your resource and capacity planning depends on it.
Can you still buy Project Online?
No. Microsoft ended sales of Project Online-only plans to new customers on October 1, 2025, and the service itself retires on September 30, 2026. Existing customers keep full support until the retirement date. Organizations buying Microsoft project tools today are pointed to the Planner and Project Plan 3 and Plan 5 licenses, which carry the premium Planner features.
Is Microsoft Project desktop being retired too?
No. Microsoft has said the retirement applies only to Project Online and does not affect Project desktop, Project Server, or Planner. Check the version you run, though, because each release has its own lifecycle. Project Server 2016 and 2019 reached the end of extended support on July 14, 2026, which leaves Subscription Edition as the only Project Server release still supported.
Is Project Server Subscription Edition a safe place to move?
It is a supported destination, but a narrow one. Project Server Subscription Edition follows Microsoft's Modern Lifecycle Policy and is listed as in support with no retirement date published as of September 2026. It keeps the PWA model intact, but it puts servers, SharePoint Server Subscription Edition, and SQL Server back on your team's list, which is the work most PMOs moved to Project Online to escape.
It makes the most sense as a bridge. An organization with deep workflow customization, or a residency rule that blocks a new cloud vendor this year, can keep working in a familiar model while it runs a proper selection. The risk is that the bridge becomes permanent, and in three years the PMO is running on-premises infrastructure it never wanted.
If you are reading this after September 30, 2026
Start with what still exists. Project managers often have .mpp copies on their own machines, and finance usually holds the approved actuals that timesheets fed. Check Power BI before anything else: a report built in import mode keeps the last data it successfully loaded from the OData feed, so export those tables before anyone republishes the report or rebuilds the dataset. Ask Microsoft support what, if anything, can be recovered, and document the answer. Then rebuild the portfolio baseline from those pieces rather than waiting for a perfect copy that may not come.
The deadline is for the data, not the decision
September 30 is a hard date for the history held in PWA and a soft one for everything else. Export the archive, verify it, give active projects a place to live, and then choose the platform the way you would have if Microsoft had not forced the question: by what the portfolio needs to do. For organizations running several PMOs on one PWA tenant, the choice is really an enterprise PMO software decision, and it deserves the same care as any other system of record.