Microsoft Project Online retires September 2026: planning the migration

Microsoft Project Online retires on September 30, 2026. From the date on this post, that gives most PMOs we work with under five months to plan, scope, and execute the move. Some are well into the work. Many are not. Teams that started planning last fall are finishing now. Teams starting today have less time than they think.

This is the playbook we hand to clients when they ask where to begin. It is not a product pitch. It is the work that needs to happen between now and the deadline.

What is actually changing

Project Online is being retired. The PWA front end, the integration with SharePoint, the custom Project Web App sites — all of it goes away. Microsoft’s communicated successor is Microsoft Project for the web, which has a meaningfully smaller feature surface. Custom solutions built on top of Project Online (custom fields, JS Grid customizations, server-side workflows) do not migrate.

For most enterprise PMOs, “move to Project for the web” is not a one-to-one replacement. It is a downscope. Some features go to Microsoft Planner, some to Power BI, some need to be rebuilt outside the Microsoft stack entirely.

What needs to be migrated

A complete Project Online tenant has more in it than most teams realize. At minimum, the migration scope includes:

• Project plans. The .mpp files, dependencies, baselines, custom calculations.
• Resource pool. Enterprise resources, generic resources, cost rate tables, calendars, RBS hierarchy.
• Custom fields and lookup tables. Often dozens, often interconnected.
• Timesheet history if you track time. Historical actuals are often the hardest piece to preserve.
• Reports. Power BI or Excel-based reports that read from the Project Online OData feed.
• Integrations. Hooks into ERP, HRIS, Azure DevOps, custom dashboards.
• Custom code. Client-side or server-side customizations on the Project Web App.

Inventory that list against what your team actually built. The volume is usually a surprise.

A realistic timeline for what is left

For a mid-sized PMO starting now, with the September deadline, the runway looks roughly like this:

Weeks 1 to 3: Inventory and assessment. Catalog what is in the tenant. Identify what is in active use versus retired-but-still-there. Decide what migrates, what gets archived, and what gets retired.

Weeks 4 to 8: Target platform decisions. Pick the destination for each piece. Plans go to one place. Resources another. Reports a third. The decisions are easier to revisit on paper than after migration.

Weeks 9 to 14: Export and stage. Pull data out of Project Online into a format the target platforms can ingest. Onplana publishes a thorough technical export guide covering the eleven categories of Project Online data and the formats each comes out in: see Exporting Project Online data before September 2026 for the path-by-path details we point clients to.

Weeks 15 to 18: Migrate, validate, and run in parallel. Stand up the target platforms with the migrated data. Run the new and old in parallel for a few weeks, comparing reports and resource allocations against tolerance bands.

Weeks 19 to 20: Cutover. Stop writing to Project Online, complete final exports for archival, switch business processes to the new platforms.

That is roughly twenty weeks of work, and there are about twenty-two weeks left at the time of this post. The math is not generous.

What you cannot do at the last minute

A few things we have learned from prior platform retirements:

• The data export takes longer than expected. Most teams underestimate the time to validate that an export is actually complete. Plan for at least a week per major data category.
• Reports do not migrate themselves. Power BI reports that read from the Project Online OData feed will break the day the tenant goes dark. Rebuild them against the target platform’s API early, not late.
• Historical timesheet data is the painful piece. Treat it as its own workstream. Decide what you are keeping, where, and in what format.
• Custom integrations need code review. Anything that talked to Project Online over CSOM or REST will need to be repointed or rewritten. Allocate developer hours.

Where the destination platforms fit

The destination is not one platform. It is usually a set, depending on what your PMO actually does:

• For team-level work: Microsoft Planner or Microsoft Project for the web. Lightweight, native to Microsoft 365.
• For cross-portfolio resource and capacity planning: the gap Microsoft is leaving open. Some clients move to dedicated PPM tools here, including Onplana, which we built specifically as an alternative to Project Online with capacity planning, resource models, and AI-assisted plan generation. Other clients move to incumbent enterprise PPM platforms, or to a combination of Microsoft tools plus Power BI.
• For reporting and analytics: Power BI against whatever data source replaces the OData feed.
• For custom-built workflows: Power Platform or a custom .NET application. We do this work for clients regularly.

The right answer is rarely “one tool replaces everything.” It is “we replace each piece with the best fit.”

What we tell clients

Start the inventory this month. Pick the destinations for each data category by end of next month. Run the export, migration, and parallel period through the summer. Be in cutover by mid-September.

If you have not started, you have not started. The platform shuts down on the deadline. Recovery options after that point exist but are expensive and slow.

If you want help planning or executing the migration, that is the work we do.