How to export Project Online data
before September 2026

What can vs cannot be exported

Before you start exporting anything, build an inventory. Project Online has at least eleven distinct data classes, and each one has its own export path, format, and set of edge cases. The matrix below is the honest version, including the parts that do not export cleanly.

Two thirds of the categories are exportable, but the “partial” rows are where most of the rework lives. Plan for them now, not in week eight.

Step-by-step: exporting project plans

Project plans are the largest single export and the one most teams start with. Three methods cover the realistic paths: the PWA UI for one-off projects, PowerShell with the Project CSOM module for bulk export, and a third-party extractor when the tenant has hundreds of plans and you want a single CLI invocation. Pick based on volume.

Method 1, PWA UI (for <20 projects)

1. Sign in to your Project Online tenant as a user with Open Project permission for the projects you want to export.
2. Open Project Center. Confirm the project list is the full set, filtering by department or owner if needed.
3. Click into each project to open it in the browser editor, then choose File → Save As → Save As File. Pick Microsoft Project File (*.mpp).
4. If your browser prompts to open in Project Professional rather than save, that is fine, save from Project Pro’s File → Save As menu instead.
5. Repeat per project. Name files <project-id>-<short-name>.mpp so the source GUID is preserved in the filename.
6. For each saved file, also export a parallel MSPDI XML via File → Save As → XML Format (*.xml). The XML version is your insurance against any future binary-format compatibility issue.

Gotcha: the browser editor cannot save .mpp directly in some tenant configurations. If the menu item is greyed out, you must open the project in Project Professional (the desktop app) first, which then routes the save through the desktop client.

Method 2, PowerShell + CSOM (for 20–500 projects)

Microsoft ships a Client-Side Object Model (CSOM) DLL for Project Online. Combined with PowerShell and a service account, this is the standard bulk export path.

1. Install the latest Project Online CSOM NuGet package on your jump box. Reference the Microsoft.ProjectServer.Client assembly from PowerShell.
2. Create a service account with Manage Users and Groups + Open Project permissions. Use modern auth (OAuth) only, basic auth is fully retired.
3. Author a script that connects to https://<tenant>.sharepoint.com/sites/pwa, enumerates ProjectContext.Projects, and for each project calls Project.Draft.SaveProjectAs(localPath). Iterate with a Throttle of 1 request every 1.5 s to stay under tenant rate limits.
4. For each project, also call the OData export endpoint /_api/ProjectData/Projects('<guid>')?$expand=Tasks,Assignments,Resources to capture the relational view alongside the .mpp.
5. Capture a per-project log line: { projectId, guid, lastModified, taskCount, assignmentCount, fileBytes, sha256 }. This is your auditable manifest later.
6. Run the script in a maintenance window. A 200-project tenant typically takes 4–8 hours end-to-end at safe throttle.

Method 3, Third-party extractor (for 500+ projects, or low-touch)

Several vendors ship Project Online extractors that wrap the OData + CSOM APIs in a single CLI or GUI. The trade-off is licence cost vs engineering time. For a tenant with 500+ projects, an extractor typically pays for itself in the script-authoring time it saves. Vet the tool against your security team before granting tenant-admin credentials, and confirm it can produce both .mpp and MSPDI XML outputs (some only do one).

Whichever method you use, validate by opening 5% of exported files in a clean Project Professional install and comparing the task count, finish date, and total work to the source. Deviations >1% mean the export configuration needs revisiting.

Step-by-step: exporting the resource pool

The enterprise resource pool is one of the most under-appreciated assets in Project Online. Years of resource definitions, custom resource fields, calendar exceptions, and cost rates often live nowhere else. Export it in two passes: a structural pass via PWA, then a data pass via OData.

1. In PWA, open Resources. Filter by Generic, Active, Inactive separately; export each filter as CSV using the built-in Export to Excel button. This gives you the resource roster in three clean slices.
2. For each resource, capture the calendar exceptions: open the resource → Resource Information → Change Working Time. Export the exception list to CSV manually (PWA does not bulk-export exceptions).
3. Pull the OData feed at /_api/ProjectData/Resources?$expand=ResourceCustomFields. This returns every resource with all their enterprise custom field values in a single relational shape. Save as JSON or convert to CSV per resource.
4. Cost rates: open each resource that has cost rate tables → Costs tab. Capture the five rate tables (A through E) and their effective dates. PWA has no bulk cost-rate export, so this is manual or via CSOM EnterpriseResource.CostRateTables.
5. Validate: total resource count from CSV exports should match OData resource count exactly. Any drift indicates a permission or filter issue with the OData service account.

Export the resource pool BEFORE the project plans. If you do project plans first and discover a resource permission issue when you get to the resource step, you may need to re-export plans to pick up resource GUIDs that resolve correctly in the destination.

Once exported, the re-modelling and capacity-view migration into the target platform have their own playbook. See the Resource Capacity Planning After Project Online pillar for the platform-by-platform model coverage, the five-phase migration process, and post-migration validation checks.

Step-by-step: exporting reporting & timesheet data

Reporting and timesheets are the most likely categories to be needed years after the tenant goes dark, for audits, for capitalisation reviews, for HR queries. Export them with that retention horizon in mind.

OData reporting feed

1. Identify the OData entities you depend on. The full set is documented at ReportData OData reference. Common picks: Projects, Tasks, Assignments, Resources, TimeSet, TimesheetLines, IssuesAndRisks.
2. Use $top=5000 + $skiptoken paging for each entity. The OData service throttles at the tenant level, plan for one entity at a time and do not run more than two endpoints concurrently.
3. Save each entity as JSON (lossless) AND as CSV (for human + Excel access). Two formats double your storage but cuts your future regret in half.
4. Capture the OData metadata document at /_api/ProjectData/$metadata. This XML schema is your decode ring for any future re-import attempt.

Timesheet history

1. Identify the time period you need to retain. Most regulators require 7 years; finance often wants 10. Default to longest of the applicable retention requirements.
2. Pull /_api/ProjectData/TimesheetPeriods?$expand=Timesheets($expand=Lines) in monthly batches. This is the only path that gives you the line-item time entries with project + task + resource GUIDs intact.
3. Save per-period as a single JSON file plus a flattened CSV. Hash each file (SHA-256) and store the hash alongside the file in a separate manifest.
4. If you have a Reporting Database (on-prem Project Server only), additionally back up the MSP_TimesheetHistory_* tables via SSMS → Tasks → Generate Scripts (Schema and Data). Useful when the OData TimeSet entity has been thinned out by tenant retention policy.

Status reports + Power BI

1. Status reports stored in PWA have no bulk export. Either save each report to PDF manually, or query the underlying tables via OData if your tenant exposes them, or accept the loss and recreate the reporting cadence in your destination tool.
2. For Power BI dashboards built on the Project Online OData feed, download the .pbix file from Power BI Service → ... → Download this report. The connection string inside the .pbix points at your old tenant and will need rewiring after migration, but the visuals, measures, and bookmarks all survive.
3. Document the dashboard inventory: report name, owner, last refresh date, OData endpoints it consumes. This is what you hand to whoever rebuilds the reports in the destination.

Storage & retention: where to keep exports

Exports are static, infrequently read, and need to outlive the tools that produced them. That points at cold object storage, not a SharePoint library. The right answer for most PMOs is a tiered approach: a hot copy for the first 6–12 months (active migration window), an archive copy for the regulatory retention horizon.

• Hot tier (active migration): the storage attached to your destination tool, plus a working copy on a managed file share or shared drive your migration team can read.
• Archive tier (long retention): Azure Blob (cool/archive), AWS S3 Glacier, or your existing on-prem records management system. All three give you 7+ year retention at pennies per GB-month.
• Geographic redundancy: at least one copy in a different region from your primary. Cheap insurance against a regional outage when you need the records years from now.
• Manifest + checksums: alongside the exports, store a CSV manifest of every file, its source project ID, last-modified date, and SHA-256 hash. This is what an auditor will ask for.
• Encryption + access control: exports contain proprietary PMO data. Enforce server-side encryption at rest and restrict read access to a documented role.

Two patterns to avoid: keeping the only copy on a single team member’s laptop (one stolen device away from a permanent loss), and storing exports inside the same SharePoint or OneDrive tenant the source data lived in (creates a coupling between the records you need to retain and the platform you are decommissioning, which is exactly the situation that motivated the export in the first place). Cold object storage in a separately-billed account is the boring, correct answer. If your organisation already operates a records-retention platform with legal hold support, push the exports through that channel rather than spinning up a new bucket, the documented chain-of-custody is what auditors care about, not the storage tier.

Plan to revisit the archive once a year, even after migration is complete. Run a spot-check restore against 1% of the manifest, confirm files are still readable, confirm hashes still match. This is cheap to do and catches silent storage-tier corruption (rare but documented in long-tail Glacier and Blob archive incidents) before a real audit makes it expensive.

FAQ