Project Online Retires: 3 Things to Export First

Project Online retires on 30 September 2026. Not “goes into read-only,” not “loses support” – the service and the data in it become permanently unreachable, with no recovery path and no extension. If you have a PWA site collection in your tenant, you have weeks, not months.

There are three things to deal with before the date, and most rescue efforts only cover the first: the PWA reporting data (projects, tasks, assignments, timesheets), the SharePoint project-site content (documents, risks, issues, deliverables), and any flows or apps built on the Project Online connector, which stop working regardless of what you exported.

The first two matter most, and they are genuinely separate jobs. Run only Microsoft’s export guidance and you end up with schedules, tasks and timesheets, but none of the documents, risks, issues or deliverables that explain what those schedules actually meant.

In this post: Prerequisites · The dates that actually matter · The two preservation jobs · What survives and what doesn’t · Pulling the data out with OData · The pagination limits that catch people · What else breaks besides the data · Where to actually land · When would you actually use this? · Related reading

Prerequisites

The “Manage Users and Groups” permission on the PWA site, or higher. This is the one that catches people mid-export: a standard project manager account authenticating against the reporting endpoint only returns the projects that account can see. Run the export as a project manager and you’ll get a clean-looking file that is quietly missing most of the portfolio.
Site Collection Administrator on the PWA site collection if you also intend to pull the SharePoint side (project site documents, risks, issues lists), which is a separate exercise from the reporting export.
Somewhere to put it. Decide the destination before you start extracting, not after – a pile of loose .mpp files and CSVs with no structure is only marginally better than losing them.

The dates that actually matter

Announced: 5 September 2025, so this has been public for a year.
1 October 2025: sales of new Project Online-only SKUs ended.
1 April 2026: creation of new Project Web App sites blocked. If you were planning to spin up a fresh PWA to stage anything, that door is already shut.
30 September 2026: retirement. Access to Project Online and its data ends.

Worth being precise about scope, since this causes unnecessary panic: this affects Project Online specifically. Project desktop, Project Server (the on-premises product), and Planner are not retiring. If your organisation runs Project Professional against a Project Server farm, none of this applies to you.

Exporting the Project Online data and preserving the SharePoint project sites are two separate jobs. Do only the first and you get an archive of schedules with none of the documents that explain them.

The two preservation jobs

Project Online is two things stitched together, and the retirement treats them differently. There’s the PWA reporting data – projects, tasks, assignments, resources, custom fields, timesheets, baselines – which lives in the Project Online service. And there’s the SharePoint project site content – the document libraries, risks lists, issues lists, deliverables, and whatever else each project team built on their own site.

Microsoft’s export guidance covers the first thoroughly. It separately identifies the second as your responsibility, and that’s where archives quietly go wrong. The project-site content often includes contributions from people who were never registered as PWA users at all – a stakeholder who only ever uploaded documents to a project site, a subject matter expert who logged risks. None of that appears in a reporting export, because none of it was ever reporting data.

Treat these as two tracked workstreams with two separate completion checks. An archive that has every schedule and no supporting documentation will not answer the question someone asks you in eighteen months.

What survives and what doesn’t

This distinction is genuinely confusing and worth stating plainly:

Anything under /sites/pwa should be treated as lost unless you extract it first. The PWA site and its associated Project Online data go away.
Ordinary SharePoint Online content persists as SharePoint content. Lists, libraries, content types and the sites themselves aren’t deleted by a Project Online retirement – they’re SharePoint objects, and SharePoint isn’t going anywhere.
The structured project data becomes unreachable regardless of where its shell lives, because the service that interprets it is gone.

The practical read: don’t assume a project site “will still be there” and skip auditing it, and equally don’t assume everything in your tenant with the word Project on it is about to vanish. Walk the list of project sites explicitly and decide, site by site, what needs preserving.

Pulling the data out with OData

Project Online exposes a reporting endpoint at /_api/ProjectData. Worth knowing up front that this is the reporting schema, not the full PWA administrative schema – it’s the right tool for extracting portfolio data, not for reconstructing your PWA configuration.

$pwa = "https://yourtenant.sharepoint.com/sites/pwa"
$cred = Get-Credential

# Projects, with their enterprise custom fields expanded inline
$url = "$pwa/_api/ProjectData/Projects?`$expand=ProjectCustomFields"

$headers = @{ "Accept" = "application/json;odata=nometadata" }
$resp = Invoke-RestMethod -Uri $url -Credential $cred -Headers $headers

$resp.value | Select-Object ProjectName, ProjectStartDate, ProjectFinishDate, ProjectPercentCompleted |
    Export-Csv "C:\PWAArchive\projects.csv" -NoTypeInformation

The resource pool is worth pulling the same way, since resource records carry custom field values that don’t appear anywhere in an .mpp export:

$url = "$pwa/_api/ProjectData/Resources?`$expand=ResourceCustomFields"
$resp = Invoke-RestMethod -Uri $url -Credential $cred -Headers $headers
$resp.value | Export-Csv "C:\PWAArchive\resources.csv" -NoTypeInformation

For the schedules themselves as openable files, the practical route is CSOM rather than OData: authenticate, enumerate the project list, and download each .mpp programmatically instead of opening several hundred projects by hand in Project desktop.

The pagination limits that catch people

Every query against the Project Online OData API is paged, and the per-entity limits are lower than most people expect:

Entity	Maximum returned per page
Projects	300
Tasks	300
Assignments	1000

This is the single most likely way to produce an export that looks successful and is silently incomplete. A tenant with 400 projects returns 300 and a continuation link, and a script that ignores the link exports 300 projects, writes a CSV, and exits cleanly with no error at all. Follow the @odata.nextLink until it stops coming back:

$all = @()
$next = "$pwa/_api/ProjectData/Projects"

while ($next) {
    $page = Invoke-RestMethod -Uri $next -Credential $cred -Headers $headers
    $all += $page.value
    $next = $page.'@odata.nextLink'
    Write-Host "Retrieved $($all.Count) so far..."
}

Write-Host "Total projects exported: $($all.Count)"
$all | Export-Csv "C:\PWAArchive\projects-full.csv" -NoTypeInformation

Worth reconciling the final count against what the Project Center shows in the browser before calling the export done. If the numbers don’t match, you paged wrong or you’re authenticating as an account that can’t see the whole portfolio.

What else breaks besides the data

Worth auditing before the date rather than discovering afterwards: any Power Automate flow or Power App that references the Project Online connector stops working. Flows and apps that happen to live in the same environment but don’t touch Project Online functionality carry on unaffected – the breakage is specific to the connector, not to the environment.

Worth searching your tenant for these specifically rather than assuming you’d remember building them. A status-report flow somebody set up three years ago and forgot about is exactly the kind of thing that surfaces as a mystery failure in October.

Where to actually land

Microsoft points at three destinations, and the honest framing is that none of them has an automatic migration path from PWA. There is no wizard. Whichever you pick, the data movement is manual or tooled by a third party.

Planner with premium capabilities – the intended successor for most Project Online customers. Existing Project Plan 3 and Plan 5 licences already grant the premium features (portfolios, baselines, dependencies, Gantt views), so for many organisations the licence investment carries across without a new purchase.
Project Server Subscription Edition – the closest functional match to Project Online, at the cost of running the infrastructure yourself. Worth considering specifically if you depend on PWA features that Planner doesn’t reproduce.
Dynamics 365 Project Operations – the right answer when project management is genuinely tied to billing, resourcing and finance rather than scheduling alone.

Pick the destination before the export, not after. What you need to extract, and in what shape, depends entirely on where it’s going.

When would you actually use this?

You have a /sites/pwa site collection in the tenant and nobody has confirmed in writing whether anything still depends on it – start with the audit, because the deadline doesn’t move.
Someone already ran an export and declared it done, but only the reporting data was pulled – the project-site documents, risks and issues are the second job, and they’re the half that usually gets missed.
Your export script finished without errors and the project count looks suspiciously round – check for a 300-row ceiling before trusting it.
You’re being asked whether Project desktop or Project Server is affected – they aren’t, and it’s worth saying so clearly rather than letting a retirement notice trigger a migration project nobody needs.

Exploring SharePoint REST API Endpoints – the OData query options ($select, $filter, $expand) used in the export scripts above, covered properly.
SharePoint Archiving: Options, Best Practices, and Approaches – worth reading before deciding where the extracted archive actually lives.
How to Migrate SharePoint Online Content to Another Tenant – the broader migration tooling picture, if the project sites are moving rather than just being archived.

The schedules are the easy part. It’s the project sites, the forgotten flows, and the 300-row pagination ceiling that turn a “we exported everything” into a gap somebody finds much later, with no way left to go back for it.

If you’re running this export against a large portfolio, I’d genuinely like to hear how the reconciliation went – drop a note in the comments.