Quick Start
- Find every Project Web App site in the tenant. There are usually more than anyone remembers.
- Accept that the Microsoft export script runs per user, not per tenant, and budget the runs accordingly.
- Export the schedules to
.mpp,.xmland.jsonfor every user who owned projects. - Separately, save the SharePoint content sitting inside the PWA sites. The project export does not include it.
The step most plans miss is the fourth. See the SharePoint half of the problem.
Project Online is not a separate cloud product bolted on beside SharePoint. It runs on top of SharePoint Online, and every Project Web App instance is a SharePoint site collection in your tenant. That is why this retirement lands on the SharePoint administrator's desk even in organisations where IT never touched Project itself.
Step 1: Find every Project Web App site
Do this before anything else, because it sizes the whole job. PWA sites were frequently provisioned by project managers without involving IT, so the number in a mature tenant is routinely higher than the number anyone can name from memory.
Connect to the SharePoint Online Management Shell as a SharePoint administrator, then
filter the site list on the PWAEnabled property:
Connect-SPOService -URL https://yourtenant-admin.sharepoint.com
Get-SPOSite | ?{$_.PWAEnabled -eq "Enabled"} | ft -a Url,Owner
That gives you the URL and owner of every PWA site. Keep the list: you will need it for every step that follows, and the owner column tells you who to ask about which projects still matter.
Step 2: Know what the Microsoft export tool actually is
This is the part that derails schedules, so it is worth being clear before you start.
Microsoft publishes a Project Online User Content Export and Delete script
package, and the export script inside it is
ExportProjectUserContent.ps1. It was built to answer data subject requests.
It takes one user, identified by login name or resource ID, and exports
the projects that user owned, was assigned a task in, owned an assignment in, or was
status manager for.
Plan it as an inventory exercise first: from the site list in step 1, work out who owned projects in each site, then build the run list. The alternative, discovering the per-user constraint in the last fortnight of September, is how organisations end up exporting only the projects someone happened to remember.
Step 3: Export the schedules
Before the script will run, three prerequisites have to be true:
| Requirement | Detail |
|---|---|
| Licence | Project Online Premium or Project Online Professional, assigned to the account running the export. |
| Desktop client | The Project Online Desktop Client, installed and connected to the Project Online instance. It is included with either licence above. |
| Permissions | Site collection administrator on the PWA site. Alternatively, in Project permission mode, the Manage Users and Groups plus Access Project Server Reporting Service permissions; in SharePoint permission mode, SharePoint administrator. |
The scripts arrive blocked, because Windows blocks scripts downloaded from the internet by default. Unblock the zip before extracting it, through Properties on the file, or you will spend the first hour debugging the wrong problem.
Then run the export per user, per site:
.\ExportProjectUserContent.ps1 -Url https://contoso.sharepoint.com/sites/pwa1 -LoginName user@contoso.com -OutputDirectory C:\pwa1output
For each project the user was part of you get the schedule as both .mpp and
.xml, from the draft and published schemas separately, plus JSON for the
reporting data covering tasks, assignments, resources, baselines and timephased figures.
Alongside those you get up to 27 feature-level JSON files for things like timesheets,
custom fields, calendars, lookup tables and security. The -Options parameter
narrows that down if you only want one feature area.
Step 4: The SharePoint half of the problem
Here is the gap most export plans leave open. The project export covers project data. It does not cover the SharePoint content living inside the PWA site collections, and on a well-used Project Online deployment that content is substantial: project document libraries, risks, issues, deliverables, custom lists and whatever else teams built into their project sites over the years.
Those are ordinary SharePoint objects in ordinary SharePoint site collections. They go when the site collections go, and no amount of running the project export script will save them. Treat them as a separate workstream with the same deadline.
The practical approach is to inventory first and move second. Take the PWA site list from step 1, work out which sites actually hold content worth keeping, and copy those libraries and lists into a normal SharePoint site that is not going anywhere.
Report Master exports Excel reports covering the lists, libraries and storage in a site, which is a fast way to see which PWA sites are carrying real content and which are empty shells left over from an abandoned project. Clone Master then copies sites, lists and libraries to another site or another tenant, including views, fields and lookup columns, which is the mechanism for getting that content somewhere permanent.
Step 5: Decide where the work continues
Microsoft points at two destinations, and they suit different situations:
| Option | Who it suits |
|---|---|
| Project Server Subscription Edition | Organisations that want to keep the Project Web App interface and enterprise scheduling and reporting, and can run it on their own infrastructure. |
| Planner and its premium capabilities | Organisations moving to the modern cloud path. The premium tier is backed by Dataverse. |
Whichever way you go, the export still has to happen first. Neither destination reaches back into a retired service to collect your history for you.
What you cannot get out
- Project Home favourites and recently viewed lists. The Microsoft guidance is to log in and take a screenshot, because there is no export for it.
- Anything belonging to a user nobody runs the script for. The export is scoped to the user you name, so a project owned by someone who left the organisation is only captured if you deliberately include their account.
- A working service. The .mpp files cannot go back in, so what you are building is a readable archive plus a migration into whatever comes next.
Frequently Asked Questions
What happens to my Project Online data on 30 September 2026?
Access ends. Microsoft documentation states that after the retirement date Project Online and its data are no longer accessible. No read-only period has been published and the PWA site collections do not move into an archive tier, so treat anything not exported by that date as gone.
Can I export all Project Online projects at once?
Not with the Microsoft script. It takes a single user login name or resource ID and exports the projects that user was part of. Covering a whole PWA site means one run per project-holding user, and resource IDs differ per site for the same person, so plan a list of runs rather than one job.
Can I put the exported .mpp files back into Project Online or Project Server?
No. Microsoft documents that saving exported .mpp files back is not supported. You can open them in the Project desktop client to read and rebuild from, which makes the export an archive rather than a restore point.
How do I find how many Project Web App sites we actually have?
Connect to the SharePoint Online Management Shell as a SharePoint administrator and
filter Get-SPOSite on the PWAEnabled property, as in step 1.
Do it early: PWA sites were often created without IT involvement and the real number is
usually higher than expected.
Sources
- Export user data from Project Online, Microsoft Learn, for the script package, prerequisites, parameters and output files.
- Microsoft Project Online is retiring: what you need to know, Microsoft Tech Community, for the retirement timeline and successor products.
For the dated timeline and the wider SharePoint impact, see our alert on Project Online retiring on 30 September 2026.