Microsoft retires Project Online on 30 September 2026. As I write this, that is just over eight weeks away. New Project Online-only SKUs stopped selling on 1 October 2025, so nobody has been sold this platform for nearly a year.
Most of the advice circulating is migration advice: export your data, pick a destination, move. That is the small problem. The big one is that a lot of PMOs never decided what Project Online was for, and a forced move is the first time in a decade anyone has had to answer.
Answer that first. The tool choice falls out of it in about an hour.
1. What actually retires, and what does not
Precision matters here, because a lot of published advice blurs four different products into one panic.
Retiring 30 September 2026:
- Project Online: the Project Web App (PWA) sites, the enterprise resource pool, portfolio analysis, timesheets, workflows, and the OData reporting feed that sits under everyone’s Power BI dashboards.
Already gone:
- Project for the web, and the Project and Roadmap apps in Microsoft Teams, retired in August 2025. That engine did not die. It became Planner. If you were on Project for the web, you are already on Planner premium plans.
Not affected by this retirement:
- Project desktop, the client on your machine.
- Project Server on-premises. Project Server Subscription Edition rides the SharePoint Subscription Edition lifecycle and is supported well past this date. Project Server 2016 and 2019 run on a separate clock: extended support ended on 14 July 2026, which is now behind us.
- Planner itself, in either tier.
So the honest framing is narrower than the headlines. One hosted service is being switched off, and its on-premises sibling is not. That matters, because “stay on the Microsoft schedule engine” is still a real option. It just stops being a SaaS one.
2. The question to answer before you look at a single vendor
Project Online did five distinct jobs. Almost no PMO used all five well. Go through the list and mark each one honestly:
- Scheduling. Critical path, dependencies, baselines, resource-levelled plans that someone actually re-plans when reality moves.
- Resource management. A central pool, capacity vs. demand, named assignments across projects.
- Timesheets. Actuals captured against tasks, usually for capitalisation or client billing rather than for schedule health.
- Portfolio selection. Prioritisation against business drivers, scenario modelling, funding decisions.
- Reporting. The OData feed, and whatever grew on top of it.
Now mark each one: load-bearing, ceremonial, or dead. Load-bearing means a decision or a payment depends on it. Ceremonial means it is produced and filed. Dead means the field exists and nobody has looked at it since the implementation partner left.
In my experience the common result is that reporting and timesheets are load-bearing, scheduling is ceremonial above the programme level, and portfolio selection was never switched on. If that is your result, you are not replacing a PPM platform. You are replacing a reporting feed and a time capture tool, and you have been paying for a schedule engine to host them.
That is the decision. Everything below is consequence.
3. What Planner premium is, with the real numbers
Microsoft’s own path is Planner, with premium plans providing the project-management layer: timeline and Gantt view, critical path, dependencies, custom fields, sprints, People view, goals, and the Planner Agent.
It is a genuine product and it is not Project Online. The published limits are worth reading before anyone commits, because they are hard per-project ceilings rather than soft guidance. From Microsoft’s own documentation for the premium engine:
| Boundary | Limit |
|---|---|
| Tasks per project | 3,000 |
| Custom fields per project | 10 |
| Resources per project | 300 |
| Successor links per project | 2,000 |
| Links per task (predecessor + successor) | 20 |
| Hierarchy depth | 10 levels |
| Goals per project | 10 |
| Project duration | 3,650 days |
Basic plans are a different set again: 3,000 active tasks and 9,000 total per plan, across a maximum of 200 buckets.
Ten custom fields is the number that breaks most migrations. A long-lived PWA instance usually carries dozens of enterprise custom fields, most of them dead and a handful genuinely driving a report. If you cannot get your list down to ten, you have not finished the exercise in section 2.
Then check the gaps against Microsoft’s published list of what premium plans add. That list runs to fifteen capabilities: goals, People view, sprints, timeline, critical path, milestones, advanced dependencies, custom calendars, assignments view, custom fields, task history, task chat, conditional colouring, summary tasks, and the agent. Four things are not on it, and each one is a Project Online job from section 2:
- Timesheets. No actuals capture. Time will need a separate tool, and it will not flow back into schedule health on its own.
- An enterprise resource pool of the Project Online kind. There is per-project resourcing and an assignments view. There is not a central pool spanning the portfolio.
- Portfolio analysis. No driver prioritisation, no scenario modelling.
- An OData reporting feed. Cross-project reporting means rebuilding on the Dataverse connector in Power BI. That is achievable, and it is not a like-for-like swap of an existing dataset.
None of this makes Planner the wrong answer. It makes it the wrong answer for whoever needs items 2, 3 and 4 from the list above to be load-bearing.
4. The four honest destinations
Planner premium. Correct when scheduling is light, the estate is inside Microsoft 365, and reporting can be rebuilt on Dataverse. Lowest friction, lowest cost, real ceilings. Choose it when your section-2 answer was mostly “ceremonial.”
Project Server Subscription Edition. Correct when the schedule engine is genuinely load-bearing, as in capital projects, construction, or regulated programmes with contractual baselines, and when you can run infrastructure. You keep the model and the muscle memory. You take on servers and a SharePoint dependency, having just spent a decade escaping both.
A dedicated PPM or SPM platform. Planview, Smartsheet, ServiceNow SPM, Celoxis and others compete here on portfolio depth, financial governance and resource optimisation. Correct when portfolio selection and capacity planning are the load-bearing parts. Budget honestly: procurement, data migration, stakeholder alignment and training do not fit in eight weeks. If this is your answer, your near-term job is a bridge, not the destination.
Wherever delivery already lives. For a software portfolio this is usually Jira, Azure DevOps or Linear plus a reporting layer. Correct when the PMO’s real product is a roll-up of work that is already tracked somewhere else, in which case Project Online was a parallel universe maintained by hand.
The one option I would rule out is a same-shape replacement chosen to avoid having the conversation. A tool bought to reproduce ceremonial artefacts will reproduce them faithfully, and you will do this again in four years.
5. The R&D view, which is worth hearing
Take this to your engineering leadership and the reaction is usually a shrug. Nobody in product development has planned work in a Gantt chart for years. Their objection is not aesthetic, and it is stronger than “we prefer agile”:
- A dependency-linked schedule assumes the work is decomposable in advance. For research and product work, the decomposition is the work.
- Baselines assume variance from plan is the signal. In discovery, variance from plan is the point.
- A resource pool assumes people are interchangeable at the skill level the pool models. Engineering teams are not staffed that way.
Where they are wrong is in concluding that governance is therefore theatre. Somebody still has to answer what was committed, what it costs, and what happens if it is late. “The board is our plan” is not an answer a regulator, an auditor or a CFO accepts.
The synthesis I would defend: schedule at the level where commitments are external, and iterate at every level below it. A launch date, a regulatory gate, a contractual milestone and a vendor cutover are commitments to people outside the team, and they deserve a real dependency model. Sprint contents are not, and modelling them in a Gantt produces expensive fiction.
That principle, not the vendor comparison, tells you how much schedule engine you are actually buying.
6. An eight-week plan
There are roughly eight weeks left. This fits, if the decision does not drift.
Weeks 1 to 2: inventory and honest marking. Export the full Project Online estate: projects, custom fields, resource pool, timesheet history, workflows, and every Power BI report bound to the OData feed. Mark each of the five jobs load-bearing, ceremonial or dead. Get the custom field list down to what genuinely drives a report. Name the owner of each surviving item.
Week 3: decide. One session, one destination, written down with the trade-off you accepted and the capability you knowingly gave up. If the answer is a full PPM platform, decide the bridge here too, which usually means Planner or a spreadsheet for a quarter while procurement runs.
Weeks 4 to 6: build and dual-run. Stand up the destination. Rebuild the reports first. They are the load-bearing part and the one thing nobody can improvise. Run both systems on live data for at least two reporting cycles. A report that has not produced a month-end in anger has not been tested.
Week 7: archive. This is the step people skip. After 30 September the PWA sites and their data go away. Decide now what has to survive as a record: closed project baselines, timesheet history with a retention obligation, decision logs, approvals. Export it to something you control, in a format that opens without the platform. Then confirm someone has actually opened the archive.
Week 8: cut over, with the buffer intact. Switch, keep the archive, and hold the last week as slack rather than plan.
7. What I would write down
Two paragraphs, in the governance record, before any tool is bought:
Project Online was performing X, Y and Z. Of those, X and Y are load-bearing and Z was ceremonial. We are moving X and Y to destination, retiring Z, and accepting the loss of capability because reason.
And:
Our schedule model is authoritative at this level and indicative below it.
Retirements are unpleasant, and they are also the only moment anyone will fund this conversation. A forced migration that ends with a shorter, honest toolchain is a better outcome than the platform you were quietly not using.
The date does not move. The decision can, and that is the risk worth managing.