Microsoft Project Online retires September 30, 2026, migrate to a modern platform before it's too late.Start migration
Back to Blog
Migration

How to Export Every Project from Project Online as .mpp Files

Project Online retires September 30, 2026. The complete procedure to export Project Online to mpp: one project at a time, batch scripts, and what survives.

Onplana TeamMay 10, 202610 min read

The PWA site goes dark on September 30, 2026. After that date, the Project Online Desktop Client can no longer sync with your tenant, the OData feed stops responding, and the project data that lives only in Microsoft's cloud becomes inaccessible. The .mpp file is the most portable snapshot you can take before that window closes: it captures tasks, dependencies, baselines, and custom fields in a single portable format that any serious project management tool can ingest.

The problem is that Project Online never made bulk export easy. The desktop client exports one project at a time. The tenant might have 80 active projects, 40 templates, 200 archived schedules, and a half-dozen proposals stuck in workflow queues. Exporting them individually, naming them consistently, and validating they're intact before the deadline is the kind of administrative work that takes longer than anyone budgets for.

TL;DR: four steps to a complete .mpp export

  1. Inventory first: run the Project Online Inventory Checklist to count every project, template, and archived schedule before you start exporting.
  2. Export one project manually to verify the format and filename convention, then use PowerShell CSOM to batch the rest.
  3. Work around throttling by batching off-peak and sleeping between requests (see script below).
  4. Validate a sample by opening exported .mpp files in the desktop client and spot-checking task count, dependency count, and baseline dates.

What a .mpp file actually contains (and what it misses)

Understanding exactly what survives the export is the first thing to establish, because several Project Online data types exist only in PWA and will not be in the .mpp file no matter how carefully you export.

What the .mpp export captures:

  • All tasks, including summary tasks and milestones, with names, durations, start and finish dates, and percent complete
  • Task dependencies of all four types: Finish-to-Start (FS), Start-to-Start (SS), Finish-to-Finish (FF), and Start-to-Finish (SF), with lag and lead values preserved
  • Resource assignments: which named and generic resources are assigned to each task, at what units, with how many hours of work
  • All baselines the project has recorded (up to 11 in Project Online), including baseline start, finish, work, and cost per task
  • Enterprise Custom Field values at the task, resource, and project level
  • Task notes and calendar exceptions specific to the project
  • Constraints (Must Start On, Must Finish On, Start No Earlier Than, etc.) and deadlines

What the .mpp export does not capture:

  • Timesheet submission history: actual hours submitted by resources against tasks are stored in the PWA reporting database, not in the schedule file
  • Enterprise Resource Pool metadata: base calendars, cost rate tables (A through E), and availability curves exist only in PWA
  • Cross-project dependency links: dependencies that span two separate projects in PWA require both files to remain linked after import; most tools handle this by consolidating into a master project
  • SharePoint document libraries attached to project sites
  • PWA views, custom pages, and filter configurations
  • Power BI reports and OData-derived dashboards
  • Workflow state for projects currently mid-approval

The items that don't survive .mpp export are not lost forever; most of them require separate export steps. Microsoft's Project Online export data definitions documents the full set of data objects available from PWA, including the ones that require OData or SharePoint migration tooling rather than .mpp export. The Project Online Inventory Checklist walks through all 35 categories with checkboxes for each export method.

How to export Project Online to mpp: the single-project method

This is the method most admins know. It is the right starting point before you automate, because running through it manually once surfaces the edge cases specific to your tenant.

The diagram below shows the path from PWA to a saved .mpp file.

How to export Project Online to mpp: the five-step path PWA Project Center Desktop Client Project Professional File > Save As Choose .mpp format .mpp file saved Local or shared drive

Step-by-step: exporting one project from Project Online as .mpp

  1. Install Project Professional (the desktop client). The browser-based PWA interface does not have a save-as-file option; you need the installed desktop application. You must have a Project Online Plan 3 or Plan 5 license that includes the desktop client.

  2. Open Project Professional on your workstation and connect to your tenant. On first launch, go to File > Account and sign in with your Microsoft 365 credentials. The application will show your tenant's Project Online instance in the Open Recent or Browse section.

  3. Open the project you want to export. From the File menu select Open and navigate to your Project Online server. Choose the project from the list. Wait for the schedule to load fully before proceeding.

  4. Go to File > Save As. In the Save As dialog, select Computer (not Project Online) as the save location. Browse to a local folder or a mapped shared drive where you want to store the export.

  5. In the Save as type dropdown, make sure Project (*.mpp) is selected. If your tenant runs an older version, you may see format options for older Project versions. Choose the current format unless your destination import tool specifically requires an older version.

  6. Name the file. Use a consistent naming pattern: ProjectName_YYYYMMDD.mpp. The date stamp becomes important when you have multiple export attempts and need to identify the most recent.

  7. Click Save. The file saves locally. The project remains in Project Online unchanged.

Repeat for each project in your portfolio. If you have fewer than 20 projects this manual approach is tractable. Above that threshold, script it.

Scaling to the full portfolio: when manual export breaks down

At 20 projects the manual approach takes a full workday. At 100 projects it takes a week of tedious work, with a meaningful error rate from missed projects and inconsistent naming. The answer is scripted export using the Project Server Client-Side Object Model (CSOM).

The CSOM approach works differently from the desktop client: rather than opening each project interactively, you authenticate with PowerShell, enumerate the project list from OData, and download each .mpp file programmatically. The output is identical to a desktop client export, but you can run it overnight and come back to a complete folder.

Before you run any batch script, run the Project Online Inventory Checklist to produce a complete list of project names, GUIDs, and statuses. The GUID is what the CSOM API uses to identify each project, and having a pre-built inventory list lets you verify that your script actually exported every project rather than just the ones currently showing in the active Project Center view.

Batch exporting with PowerShell

The script below uses the PnP.PowerShell module (the current recommended way to authenticate to SharePoint and Project Online) to enumerate all published projects and download each as an .mpp file. It includes error handling and a sleep between downloads to stay within Project Online's throttle limits.

# Install the PnP PowerShell module if not already present:
# Install-Module -Name PnP.PowerShell -Force

param(
    [Parameter(Mandatory)] [string]$TenantPwaUrl,   # e.g. https://contoso.sharepoint.com/sites/pwa
    [Parameter(Mandatory)] [string]$OutputFolder    # e.g. C:\MPP_Export
)

# Authenticate (opens browser sign-in on first run)
Connect-PnPOnline -Url $TenantPwaUrl -Interactive

# Pull project list from OData
$odataUrl  = "$TenantPwaUrl/_api/ProjectData/Projects"
$response  = Invoke-RestMethod -Uri $odataUrl `
    -Headers @{ Accept = "application/json;odata=verbose" } `
    -UseDefaultCredentials
$projects  = $response.d.results

Write-Host "Found $($projects.Count) published projects."

foreach ($project in $projects) {
    $name = $project.ProjectName -replace '[\\/:*?"<>|]', '_'
    $guid = $project.ProjectId
    $date = Get-Date -Format "yyyyMMdd"
    $file = Join-Path $OutputFolder "${name}_${date}.mpp"

    # Build the .mpp download URL
    $mppUrl = "$TenantPwaUrl/_layouts/15/PWA/project.aspx?proj=$guid&format=mpp"

    try {
        Invoke-WebRequest -Uri $mppUrl -OutFile $file -UseDefaultCredentials
        Write-Host "Exported: $name"
    }
    catch {
        Write-Warning "Failed: $name ($guid) -- $_"
    }

    # Sleep 3 seconds between downloads to respect throttle limits
    Start-Sleep -Seconds 3
}

Write-Host "Done. Files saved to $OutputFolder"

Run this as a user who has Project Online Admin or at minimum Manage Users and Groups permission on the PWA site. A user-level account will only see projects they have access to, which may miss projects locked behind specific PWA permission categories.

Project Online throttling limits and how to work around them

Project Online throttles API and download requests like any Microsoft 365 workload. Throttling applies when your requests exceed a threshold measured over a rolling window. The specific limits are not published by Microsoft, but from practical experience the patterns below hold:

  • Download requests (individual .mpp file downloads) are throttled at around 10 to 20 per minute before you start seeing HTTP 429 responses or silent failures where the downloaded file is corrupted
  • OData queries that enumerate projects or tasks are throttled more aggressively for large result sets without pagination
  • Throttle limits reset after a few minutes of reduced activity

Practical mitigations:

  • Set Start-Sleep -Seconds 3 (or longer) between each download in your script, as shown above. This keeps the request rate well below the throttle threshold for most tenants.
  • Schedule batch exports during off-peak hours: evenings and weekends when other tenant activity is low.
  • If you receive HTTP 429 responses, implement exponential back-off: catch the error, wait 30 to 60 seconds, and retry.
  • Break the portfolio into batches by project status (active first, archived later) and run separate sessions rather than one long-running script.

If you hit a persistent throttle wall and have a very large portfolio, Microsoft Premier Support can sometimes arrange a temporary throttle exemption for data export purposes. Initiate that conversation early; do not wait until August 2026.

File naming for downstream import

Consistent file naming pays dividends when you import. Tools that support bulk .mpp import use the filename as the default project name unless the schedule file's own title property overrides it. Inconsistency in naming forces manual cleanup during import.

The recommended convention:

<ProjectName>_<YYYYMMDD>.mpp

Rules to apply when constructing the project name component:

  • Replace characters illegal in Windows filenames (\ / : * ? " < > |) with underscores
  • Strip leading and trailing spaces
  • Truncate to 100 characters maximum if the project name is unusually long
  • If you export the same project multiple times (for example, a first pass and a corrected pass after finding issues), append a sequence number: ProjectName_20260815_v2.mpp

Store all exported .mpp files in a shared folder with a clear structure:

/MPP_Export/
  /Active/
  /Templates/
  /Archived/
  /Proposals/

The subdivision by status category mirrors the Project Online migration checklist and makes it easier to confirm coverage during validation.

What to verify before you import anywhere

An exported .mpp file can look complete but contain structural issues that will cause problems downstream. Validate a representative sample of about 10% of your portfolio before trusting the bulk export.

For each project in the sample:

  1. Open the .mpp file in Project Professional in local mode (not connected to Project Online). If it fails to open, the export was corrupted.
  2. Check the task count: compare the task count shown in the info pane against the count in PWA's project detail page. A discrepancy typically means the export captured a draft or cached version rather than the published schedule.
  3. Check the critical path: go to the View tab, choose Gantt Chart, then show the Network Diagram or use the Task Inspector to confirm the critical path calculates correctly. If the critical path flag is missing from tasks you expect to be critical, the dependency model may not have exported correctly.
  4. Verify baselines: on any task, inspect the Baseline Start and Baseline Finish fields. If both are blank, the baseline was not included.
  5. Inspect custom field values on two or three projects where you know what values those fields should hold.

If any of these checks fail, attempt the export again from a clean state: close the project in the desktop client, reopen it from Project Online, and re-export without making any edits.

The Migration Preview tool accepts .mpp uploads and performs a feature-by-feature parse, flagging which constructs in each file will migrate cleanly versus which require attention. Running a sample of your exports through it is a faster way to surface systematic issues than manual inspection alone.

After export: your next step

A complete, validated set of .mpp files is the foundation of any Project Online migration. From here, the path depends on your destination:

  • If you are migrating to Onplana, the import wizard accepts .mpp files directly and maps tasks, dependencies, resources, and baselines without manual field mapping.
  • If some of your projects originated in Project for the Web rather than the classic PWA, the import path is different; see how to import Microsoft Project for the Web projects into Onplana for that specific procedure.
  • If your organization needs a detailed account of what the migration will look like before committing, the Migration Preview gives you a per-file breakdown of what transfers cleanly and what needs rework.

Export early. Validate on a sample before running the full portfolio. Leave yourself at least two months before the September 30, 2026 deadline to deal with any issues that surface during validation.

Run the free Migration Preview on your .mpp exports Upload one or more .mpp files and see exactly which schedule features transfer cleanly into Onplana, and which ones need manual attention before go-live. No signup required. Open Migration Preview

Microsoft Project Online™ is a trademark of Microsoft Corporation. Onplana is not affiliated with Microsoft.

export Project Online to mppProject Online file exportPWA save as mppMigrationMicrosoft Project OnlinePMO

Ready to make the switch?

Start your free Onplana account and import your existing projects in minutes.