Microsoft Project Online Retiring Sept 2026: Timeline, Risks & Migration

Microsoft Project Online officially retires on September 30, 2026. After that date, all projects and associated data within the service become permanently inaccessible. No grace period, no read-only mode, no extension. (techcommunity.microsoft.com)

But the platform breaks well before that. Project Online's governance, approvals, and stage-gate automation run on SharePoint 2013 workflows — and Microsoft is killing those on April 2, 2026. If your PMO depends on workflow-driven project types, demand management, or approval routing, those processes stop working six months before the lights go out.

This is not a simple platform swap. Migrating enterprise project data — baselines, cross-project dependencies, resource pools, connected SharePoint document libraries — is a complex relational data problem. Microsoft's recommended successor, Planner Premium, imposes hard limits that break enterprise portfolios. The native export tools destroy historical data. And there is no one-click migration path that preserves the full Project Online model.

Here is exactly what the retirement means, where the alternatives fall short, and how to engineer a migration that preserves your project history.

For a broader view of Microsoft product retirements converging in 2026 — including SharePoint Server 2016/2019, Exchange 2016, and SharePoint Add-ins — see our Microsoft 2026 End-of-Support Timeline.

The Project Online Retirement Timeline (2025–2026)

Microsoft first signaled this direction in 2018 when it announced Project for the Web as the successor platform. The shutdown is now a phased execution tied to Microsoft's broader deprecation of legacy SharePoint architecture. (techcommunity.microsoft.com)

Here are the hard dates:

The April 1 date catches teams off guard too. Starting that day, Microsoft blocks creation of new PWA site collections and locks out tenants that don't contain at least one project. If you're planning to spin up test environments for migration validation, do it before this date.

For a deep dive on the SharePoint workflow retirement and its downstream effects, see our SharePoint Add-ins Retirement guide.

What is NOT affected: Project Desktop (Standard and Professional), Project Server Subscription Edition (PSSE), and Microsoft Planner are not part of this retirement. Existing Project Online environments stay fully supported until the September 30, 2026 cutoff. (techcommunity.microsoft.com)

What Project Online Is Used For (And What You Stand to Lose)

Project Online is not a glorified task list. It's an enterprise-grade Project Portfolio Management (PPM) platform built on SharePoint that organizations have used for over a decade to manage complex, cross-functional execution. (learn.microsoft.com)

Enterprise PMOs rely on it because it handles the realities of large-scale program delivery:

• Cross-project dependency tracking — linking tasks across multiple projects with finish-to-start, start-to-start, finish-to-finish, and start-to-finish relationships
• Baselines and earned value — storing up to 11 schedule snapshots for variance tracking, EVM, and executive reporting
• Resource capacity planning — centralized enterprise resource pools with demand/capacity analysis across the entire portfolio
• Connected SharePoint document libraries — every project site has associated SharePoint content (documents, lists, issues, risks) linked to the PWA instance
• OLAP cubes and OData reporting — ProjectData OData feeds and SQL Server Analysis Services cubes power Power BI dashboards and executive reports
• Custom fields at scale — Project Online supports 435+ built-in fields; enterprise PMOs commonly use 30–50 custom fields per project for governance metadata
• EPT workflows and stage gates — SharePoint Designer workflows that enforce governance, approvals, and phase transitions

The blast radius extends well beyond project managers. PMO directors, resource managers, BI teams building Power BI dashboards on _api/ProjectData, Microsoft 365 admins managing PWA site collections, and any third-party system (Jira, ServiceNow, SAP) pulling from Project Online APIs — all are affected. When Project Online goes away, all of it goes with it: the data, the reporting connections, the SharePoint document associations, the workflow logic. There is no archive mode.

Why Planner Premium Is a Downgrade for Enterprise PMOs

Planner Premium (formerly Project for the Web) is Microsoft's recommended cloud-native replacement. It's built on Dataverse and integrated into the unified Planner experience in Microsoft Teams and the web. One source of naming confusion: Project for the Web is not a separate product anymore. Microsoft has been rolling those capabilities into Planner, and the premium planning experience in Planner is the Dataverse-backed continuation of that line. (support.microsoft.com)

For light project management — team-level task tracking, basic Gantt charts, simple dependencies — Planner Premium is a capable tool. For enterprise PMOs migrating from Project Online, the hard limits are disqualifying.

Planner Premium Hard Limits

These are not soft limits. They are hard boundaries documented in Microsoft's official limits and boundaries page.

A pharmaceutical program with 5,000 tasks, or an engineering portfolio with 40+ custom tracking fields, simply cannot fit into Planner Premium without being split, restructured, or fundamentally reduced.

What Else Is Missing

• No master/sub-project hierarchy. Every project in Planner Premium is standalone. There are no parent-child relationships between projects. For organizations managing programs as linked master plans, this is a structural gap with no workaround.
• No centralized timesheets. No daily postings, no timesheet approvals, no resource utilization reports. You can manually set "Effort completed" per task, but there is no enterprise time-tracking system.
• No OLAP cubes. The OData reporting feed that powers Project Online's analytics layer does not exist in Planner Premium. Reporting goes through Dataverse and Power BI, which means rebuilding your entire reporting stack.
• No in-card comments in premium plans. Premium plan tasks redirect comments to Microsoft Teams channel conversations, adding friction for teams used to inline task discussions.
• Portfolios do not connect to Project Online. Microsoft's Planner Portfolios feature replaces Roadmaps, but it only connects to Planner Premium plans — not Project Online projects or Azure DevOps projects. There is no native hybrid portfolio layer that spans old PWA schedules and new premium plans during a phased migration. (support.microsoft.com)

Alternative Upgrade Paths: Dynamics 365, Project Server SE, or Third-Party PPMs

Because Planner Premium falls short for enterprise use, organizations are forced to evaluate heavier alternatives. Microsoft offers three official paths, each with significant trade-offs.

Dynamics 365 Project Operations (Enterprise, High Cost)

Best for: Professional services firms and project-driven organizations that need project financials (revenue recognition, cost tracking, billing) integrated with their ERP.

Licensing: Full user licenses start at $135/user/month (after the October 2024 price increase). Team Member licenses are $8/user/month for lightweight access (time entry, approvals). Microsoft requires a minimum of 20 licenses. Implementation costs for mid-sized firms typically run $150K–$500K+ depending on complexity.

Key limitation: Dynamics 365 Project Operations uses a completely different data model from Project Online. There is no direct migration path — every project, resource assignment, and custom field must be mapped through a dedicated ETL process. The scheduling engine shares the same Dataverse-based limits as Planner Premium (3,000 tasks, 10 custom fields per project), because both tools use the same underlying Project schedule service.

For architecture details and cost analysis, see our Dynamics 365 Migration Handbook.

Project Server Subscription Edition (On-Premises)

Best for: Organizations that need to retain the full PWA experience — enterprise resource pools, OLAP cubes, custom workflows — and have the infrastructure to host on-premises.

This is the closest functional match to Project Online, but it reverses the move to cloud that many organizations made in the first place. You're taking on server procurement, patching, backup infrastructure, and ongoing maintenance. If your goal is continuity with the least business-process change, this is the Microsoft-supported path. If your goal is to modernize, it's a holding pattern.

Third-Party PPM Tools (Jira, Smartsheet, Planisware, etc.)

Some enterprises are using this forced migration as an opportunity to leave the Microsoft PPM ecosystem entirely. Jira (for Agile-heavy portfolios), Smartsheet (for collaborative planning), Planisware (for enterprise R&D), and Asana Enterprise are common alternatives.

Limitation: Migration from Project Online to any of these platforms is a fully custom effort. There are no pre-built connectors. Enterprise resources, PWA workflows, OData reports, baselines, and SharePoint project artifacts do not map 1:1 into most modern work-management products. You need to extract data via API, translate the data model, and validate every dependency, baseline, and resource assignment. That doesn't make the move wrong — it means the migration needs engineering, not just export rights. (learn.microsoft.com)

Data Migration Challenges: Why Native Exports and DIY Scripts Fail

This is where most migration plans break down. The data inside Project Online is deeply relational — tasks link to resources, resources link to assignments, assignments link to timephased data, and everything connects to SharePoint content. Getting it out cleanly is harder than it looks.

The .mpp Import Problem

Microsoft's recommended path to Planner Premium is to export projects as .mpp files from Project Desktop and then import them via the Planner Power App — not the main Planner UI. The import function was removed from the standard Planner interface and now runs through a separate Power App that may not be visible in all tenants by default. Many organizations report that IT must explicitly provision it in the Power Platform admin center's Default environment. (support.microsoft.com)

What the .mpp import preserves:

• Task names and hierarchy (WBS structure)
• Finish-to-start dependencies
• Start and finish dates

What the .mpp import drops:

• Resource assignments — must be manually reassigned after import
• Baselines — historical schedule snapshots are not transferred
• Formulas and graphical indicators — calculated fields and traffic-light status indicators are lost
• Custom fields beyond 10 — only 10 custom fields are supported in the target
• Non-finish-to-start dependencies — SS, FF, and SF links may be silently removed depending on license tier
• Subprojects and cross-project links — master/sub-project relationships are not supported

The import process is slow (a 275-row project can take 5–10 minutes) and must be done one project at a time. For a portfolio of 200+ projects, this is weeks of manual work before you even start the validation pass.

The CSV/Excel Export Problem

Exporting Project Online data to Excel or CSV flattens the relational database. Subtask hierarchies become flat rows. Cross-project links disappear. Resource assignment relationships are lost. CSV-based hierarchy reconstruction relies on Outline Level and row order — you're not carrying the live scheduling model forward, you're attempting to rebuild it from a flat file. (learn.microsoft.com)

For a deeper analysis of why flat-file migrations fail for relational data, see Using CSVs for SaaS Data Migrations: Pros and Cons.

The OData API: The Real Extraction Path

Project Online exposes a ProjectData OData endpoint at /_api/ProjectData on every PWA site collection. This is a read-only REST API that provides structured access to:

• Projects, tasks, and assignments
• Resource pools and allocations
• Custom field values
• Timephased data (actual work, remaining work by period)
• Risks, issues, and deliverables

The OData feed preserves relational structure — you can query Tasks joined to Assignments joined to Resources and maintain the foreign key relationships that flat exports destroy.

GET https://{tenant}.sharepoint.com/sites/pwa/_api/ProjectData/Projects
  ?$select=ProjectId,ProjectName,ProjectStartDate,ProjectFinishDate
  &$expand=Tasks($select=TaskId,TaskName,TaskStartDate,TaskFinishDate,TaskParentId)

The OData API has constraints you need to account for:

• Read-only — extraction only, no write-back
• Baseline gaps — baseline snapshots are not fully exposed through the standard OData feed; use CSOM/PSI APIs to supplement
• Pagination — large datasets require proper $skip and $top handling
• Authentication — requires Azure AD app registration with OAuth 2.0 bearer tokens (certificate-based auth or ROPC flow)

For enterprise-scale extraction, teams typically use SSIS, Azure Data Factory, or custom scripts to pull from the OData endpoint, land the data in a staging database, and then transform it for the target system. (learn.microsoft.com)

Third-Party Migration Tools

FluentPro FluentBooks is the most widely referenced tool for Project Online migrations. It uses Microsoft's public APIs (PSI, CSOM, OData, SharePoint Foundation RPC) to download project data locally and re-upload to a destination PWA.

What FluentBooks cannot migrate:

• OLAP cubes and reporting configurations
• SharePoint workflows and Visual Studio solutions
• System read-only fields (Created Date, Last Modified — these reset to migration date)
• Status reports, approvals, and timesheet data (available only as a paid service)
• Power BI report connections (must be manually reconfigured)

Off-the-shelf tools handle basic task lists well, but they typically drop the artifacts that make enterprise PMO data valuable. Use them, but validate on your most complex project before trusting them with the full portfolio.

For a realistic look at why generic migration scripts fail in production, see The Data Migration Risk Model: Why DIY AI Scripts Fail.

Step-by-Step Transition: How to Migrate Without Disrupting Active Projects

Step 1: Audit Your Project Online Environment (Now)

Before choosing a target platform, document what you actually have:

• Project count and size distribution — How many projects? How many tasks per project? Any exceeding 3,000 tasks?
• Custom field inventory — Every custom field, its type, and which projects use it. Flag any project using more than 10.
• Workflow dependencies — All EPT workflows, stage gates, and approval processes built on SharePoint 2013 workflows. These break April 2, 2026.
• SharePoint content — Map which project sites have linked document libraries, issues lists, and risk registers.
• Reporting connections — All Power BI dashboards, Excel reports, and SSRS reports connected to the OData feed or OLAP cubes.
• Integration points — Any third-party systems (Jira, ServiceNow, SAP) pulling data from Project Online APIs.

Capture separately:
- Schedules, tasks, assignments, dependencies, baselines
- Enterprise resources, timesheets, approvals
- Custom fields and lookup tables
- OData / Power BI reports
- SharePoint project sites, lists, libraries, permissions
- Workflows, Power Automate flows, and external integrations

Inventory by dependency, not by product name. Do not just inventory Project Online — inventory every object that depends on it.

Step 2: Choose Your Target Platform (By Q1 2026)

Use the audit results to match your needs:

• < 3,000 tasks per project, < 10 custom fields, no master planning → Planner Premium
• Need project financials, billing, resource costing → Dynamics 365 Project Operations
• Need full PWA feature parity, can host on-prem → Project Server Subscription Edition
• Leaving the Microsoft ecosystem → Third-party PPM (Jira, Smartsheet, Planisware)

Licensing note: If you already hold Project Plan 3 ($23.10/user/month) or Plan 5 ($42.30/user/month) licenses, you likely already have Planner Premium access. Dynamics 365 Project Operations starts at $135/user/month with a 20-license minimum and typical implementation costs of $150K–$500K+.

Step 3: Extract Your Data via API (Not .mpp, Not CSV)

For any migration path that needs to preserve relational integrity:

1. Register an Azure AD application with appropriate permissions for your PWA site
2. Authenticate using OAuth 2.0 and obtain a bearer token
3. Query the ProjectData OData endpoint for each entity: Projects, Tasks, Assignments, Resources, TaskBaselines (where available via CSOM)
4. Land the data in a staging database (SQL Server, PostgreSQL) with foreign keys intact
5. Use CSOM/PSI APIs for data not exposed through OData (baseline data, certain custom field configurations) (learn.microsoft.com)

Step 4: Map and Transform

Build your field mapping between the source (Project Online data model) and target system. Pay special attention to:

• Subtask hierarchy — Maintain TaskParentId relationships to reconstruct the WBS
• Dependencies — Map predecessor/successor links with their types (FS, SS, FF, SF) and lag values
• Resource assignments — Link resources to tasks with effort and allocation percentages
• Custom field values — Decide which fields map to the target's limited field set, and which need to be archived or restructured
• Target limits — If migrating to a capped system like Planner Premium, you may need to break massive multi-year projects into smaller linked portfolios to stay within the target API's boundaries

Map unsupported features before the pilot, not during cutover weekend. For every gap — baselines, cross-project dependencies, deadlines, status reports, workflow states — decide explicitly: preserve, rebuild differently, archive, or intentionally drop.

Step 5: Migrate SharePoint Content Separately

Project Online's connected SharePoint sites (documents, issues, risks) live in standard SharePoint site collections. These must be migrated as a separate workstream using SharePoint migration tools or API-based scripts.

Maintain the association between project records and their SharePoint content — this is the link that breaks most often in rushed migrations. None of the schedule-only import paths cover project-site documents, metadata, or permissions.

For guidance on SharePoint data exports, see How to Export Data from SharePoint.

Step 6: Rebuild Reporting and Automations in Parallel

Do not wait until after task migration to think about dashboards. If your PMO consumes _api/ProjectData today and Dataverse tomorrow, the reporting redesign belongs on the same migration plan. Power BI models, Excel reports, downstream integrations, and Power Automate flows all need schema remapping when the underlying data store changes from SharePoint to Dataverse. (learn.microsoft.com)

Step 7: Pilot on Your Worst Projects

Your pilot set should include at least one schedule with deep hierarchy, one with a heavy project site, one with reporting dependencies, one with workflow-driven governance, and one with extensive resource/timesheet data. Clean demo projects tell you nothing about production risk. Prove your migration on the ugliest data you have before trusting it on the full portfolio.

Step 8: Validate and Cut Over

Run parallel operations for at least 2–4 weeks:

• Verify task counts match between source and target
• Confirm dependency chains produce correct schedule calculations
• Validate resource assignments and allocation totals
• Spot-check baseline data (if preserved)
• Test reporting connections against the new data source
• Confirm SharePoint document links are functional

Only cut over after validation is complete. Do not decommission Project Online access until you've confirmed data integrity in the target. Migrate in controlled waves, keep the final delta window small, and finish extraction before September 30, 2026. After that date, Microsoft has confirmed that project data in the service will no longer be accessible. (techcommunity.microsoft.com)

Plan the Cutover Before Microsoft Plans It for You

The common failure mode is waiting for a perfect Microsoft-native migration path that does not exist. Microsoft has provided a retirement date and a set of successor products, but it has not provided a one-click path that preserves the full Project Online data model.

The key risks if you wait too long:

1. Losing historical baselines and earned value data that took years to build
2. Breaking cross-project dependencies that govern program-level scheduling
3. Disconnecting SharePoint documents from their associated project records
4. Destroying reporting pipelines that executive teams depend on for portfolio visibility
5. Missing the April 2, 2026 workflow cutoff and losing PMO governance months early

DIY scripts and manual .mpp imports don't address these risks at scale. The organizations that handle this well are the ones that treat it as a data migration project, not a platform swap.

At ClonePartner, we extract complete relational datasets via API — preserving subtask hierarchies, dependency chains, resource assignments, and connected SharePoint metadata that native export tools drop. We build custom integrations to map Project Online's data model to your target system, whether that's Dynamics 365, Jira, or a custom architecture.

If your PMO is facing the September 2026 deadline and you need a migration partner who understands the data model — not just the project management workflow — we're here to help.