The Export Deadline, and What If You Missed It

If you attempted a Project Online export after the deadline: the safe window closed August 31, 2026, and the service itself stopped on September 30. A recovery export in September was possible but rough. The .mpp path came first (it's faster per project and less exposed to server load), then OData for whatever .mpp couldn't capture, with throttling, partial failures, and no guarantee the full dataset came across in time. What was recoverable and the order to attempt it are covered below.

The most dangerous misconception in every Project Online migration plan is a simple one: that September 30, 2026 (the headline date in the full retirement timeline) was the Project Online data export deadline. It wasn't. September 30 was the date the service retired. The effective window to export your data reliably (at predictable speed, without server-side throttling, and with time to validate and re-run) closed a month earlier, on August 31.

The teams that set August 31 as their internal export deadline finished migrations calmly. The teams still exporting in September faced throttling risk, batch failures they might not recover before the cutover, and no time to validate that what they pulled actually matched the source system. Both situations are covered in this post: what a clean export looked like before August 31, and what a recovery export looked like in September. Either way, the work now is bringing in what you exported.

Pillar reference: Project Online Data: Import What You Exported covers bringing your exported data in; this post zooms in on one aspect.

The diagram below shows the effective export window versus the official retirement date, and where the high-risk zone begins.

The 30-day gap between August 31 and September 30 was not extra export time. It was the buffer for validating that your export matched the source, re-running any batches that throttled or failed, and confirming your destination platform had everything before the cutover.

Why the Effective Project Online Data Export Deadline Was August

The official retirement date and the practical export deadline were not the same thing, and treating them as equivalent was one of the most reliable ways to end up with a crisis migration in September 2026.

Here is the concrete math. A mid-size PMO with 100 to 200 active projects, a 150-field enterprise custom field schema, a resource pool with 400 named resources, and three years of timesheet history takes approximately 3 to 5 days of elapsed time to export via OData under normal operating conditions. That assumes batched requests, proper pagination, authenticated access, and a team member monitoring for throttled responses and re-queuing them.

That 3-to-5 day window assumes normal server load. The risk in September 2026 was concurrent load: every organization that had not yet migrated would try to export in the final weeks before the retirement. OData requests that responded in 2 seconds in June might time out or be throttled to 429 responses in September. Batch jobs that completed overnight in July might take 72 hours in September, if they completed without partial failures.

The final two weeks of September were the highest-risk period for export jobs. Not because the API had stopped working, but because the queue of concurrent requests from thousands of tenants could overwhelm the system's capacity to respond in time. You don't know your export failed until you try to import the data and discover the last 40% of your resource pool is missing.

Finishing the export by August 31 removed this risk. It meant full API access, predictable response times, and a month to validate before the retirement date.

Your Two Main Export Paths: .mpp Files and OData

Project Online provided two primary mechanisms for getting your data out, and they captured different things. Most PMOs needed both.

The .mpp export path worked through the Project Online Desktop Client. You opened each project in the client, used the "Save As" dialog to save a local .mpp copy, and repeated for every project in your tenant. A .mpp file preserves: task hierarchy, task names and durations, dependencies (all four types), baselines (up to 11 per project if used), resource assignments with hours, and the project calendar.

What the .mpp file does not preserve: timesheet history, the enterprise custom field values stored at the project level but not embedded in the schedule, portfolio metadata (EPTs, stage gate status), lookup table definitions, and resource cost rates from the ERP. A .mpp export is a schedule file: it gives you the scheduling data but not the project management infrastructure around it.

The OData path was more comprehensive but required more technical setup. The OData API at /_api/ProjectData exposed the full Project Online data model: projects, tasks, assignments, resources, time sheets, custom fields and their values, lookup tables, baselines, enterprise project types, stage gates, and portfolio metadata. With the right query set, you could pull everything that lived in Project Online's database.

The OData path required authentication (SharePoint Online / Entra ID credentials with the right permissions), paginated requests for large datasets, and handling of OData throttling (429 responses with Retry-After headers). PowerShell, Python, or any HTTP client could do this. The OData output is your archive and your reference; Onplana does not import it. The migration preview tool works on the exported .mpp and Project XML files instead.

The practical recommendation was to run the OData export first for a complete structured backup of everything, then use .mpp exports as a validation layer for the most critical active schedules.

OData Throttling: The Hidden Constraint That Slows Bulk Exports

OData throttling was the technical constraint that converted a "we have until September 30" plan into a missed deadline.

Project Online's OData endpoint used SharePoint's throttling framework. When your application sent requests faster than the server was configured to handle, it returned HTTP 429 (Too Many Requests) with a Retry-After header indicating how many seconds to wait before retrying. Microsoft documents SharePoint Online throttling behavior and retry guidance for developers building against these APIs. A well-behaved client respects this header and backs off. A poorly-written export script ignores it and keeps hammering, accumulating request failures and incomplete data.

Three specific throttling behaviors shaped every bulk export:

Per-user request limits. Project Online's OData endpoint imposed limits on concurrent requests per user identity. Exporting with a single service account limited you to that account's request quota. Distributing the export across multiple service accounts (one per portfolio or department) could significantly increase effective throughput.

Large dataset pagination. OData responses are paginated at 100 to 200 items by default. Exporting 10,000 timesheet entries requires 50 to 100 paginated requests. Each page request counts against your quota. Batching requests using $batch endpoint calls reduces the number of round trips but adds implementation complexity.

TimePhasedData endpoints. Timesheet actual hours and resource-assigned work-phased data are stored in separate TimePhasedData collections. These are often the most throttle-prone entities in the schema because of the row volume: a 3-year timesheet history for 400 resources can contain millions of rows. They exported best in tight time windows (e.g., one year per batch) rather than as a single full-history query.

A practical export sequence that worked well for mid-size tenants: projects and tasks first (fast), then custom field values (medium), then resource pool and assignments (medium), then timesheet TimePhasedData (slow, run in nightly batch windows over several days). The Project Online migration checklist has a section on OData inventory that covers which entities to query in which order.

To spot-check an exported .mpp without a Project licence, open it in Onplana Schedule, free for Windows and Mac.

.mpp Export Limits and What They Don't Capture

Even if you exported every project as a .mpp file, you are missing significant categories of data. This is not a deficiency of the .mpp format; it's a format designed to capture scheduling data, not the full project management system that PWA builds on top of it.

Baseline history is partially preserved. Project Online stored up to 11 baselines per project (Baseline, Baseline 1 through Baseline 10). The .mpp export preserved whichever baselines were saved in the project file, but only if the Desktop Client had loaded them from the server. Projects that hadn't been opened recently in the Desktop Client may have produced stale local copies that don't reflect the server-side baseline data. Check the baselines in each exported file before you rely on them.

Enterprise custom field values at task level are included; project-level ECF values may not be. Task-level custom fields that are directly embedded in the task schedule (like custom cost or duration fields used in schedule calculations) round-trip through .mpp cleanly. Project-level custom fields used for portfolio metadata (risk tier, strategic alignment, budget category) were typically stored in Project Online's database, not in the .mpp structure. Those needed an OData export.

Resource pool connection is lost. When you open a .mpp file locally, it retains the resource names and assignments but disconnects from the enterprise resource pool. Cost rates, calendar exceptions, and generic resource definitions that exist only in the ERP won't round-trip into a local .mpp. That data needed a separate OData export.

Project site links break. The association between a .mpp file and its SharePoint project site (the risk register, issues list, document library) exists as a metadata relationship in Project Online. That relationship doesn't travel in the .mpp export. In your destination platform, you'll need to re-establish those links or consolidate project-related SharePoint content through a separate migration track.

The Data With No Supported Export Path

Some Project Online data had no official API export mechanism. It needed manual documentation before the retirement date. If you captured it, rebuild from those notes.

PWA view definitions. The column layouts, groupings, filters, and saved views that your team has configured inside Project Center, Resource Center, and the task grid are stored in PWA configuration tables. There was no API that returned a structured export of these view definitions. If you screenshotted each custom view and documented its filter and grouping logic, treat each as a rebuild task in your destination platform.

Workflow process history. Stage gate approvals, decision logs, and reviewer comments accumulated through Project Online's governance workflows are stored in workflow history tables. These tables were not exposed through the OData public API. If your audit requirements include documented project governance decisions (who approved a gate, on what date, with what comment), that record had to come from SharePoint workflow history lists (which may have captured some of it) or manual review of PWA before the cutover.

SharePoint 2013 workflow audit trails. Organizations that built governance workflows using SharePoint Designer's 2013 workflow engine have workflow audit logs stored in SharePoint list history. These don't export cleanly from the OData endpoint. If your compliance scope includes workflow audit trails, they needed exporting through SharePoint's list export mechanisms before Project Online retired on September 30, 2026.

The Export Plan That Worked

A practical export plan treated data differently based on migration priority, risk, and export complexity. Use it now as a yardstick for what your own exports captured.

Phase 1: Insurance snapshot (first). A complete OData pull of the active project catalog (just the project and task entities, not TimePhasedData), saved to a location you control. This was the backup: even if everything else went wrong, you had the project structure data. It took 2 to 4 hours for most mid-size tenants and one person with SharePoint admin rights and a PowerShell script.

Phase 2: Full structured export (June to July). The complete export: all OData entities including resources, assignments, custom field values, and timephased actuals, run in batches by portfolio or department over 2 to 3 weeks, and validated against source counts (project count, task count, resource count, timesheet row count).

Phase 3: .mpp exports for active migration projects (rolling, May to August). A fresh .mpp export of each project on the day it migrated. This gave the most current schedule state at migration time and a rollback file if the import had issues.

Phase 4: Final validation export (August 15 to August 31). One final full OData export, compared against Phase 2 to find projects that changed significantly in the interim, plus fresh .mpp files for projects with active scheduling work between June and August.

This four-phase structure gave three complete copies of the data at different points in time, the minimum for a defensible audit record. If you have fewer, note the gaps before you import.

The Project Online inventory checklist tool includes export tracking fields for each asset category, so you can record what your exports actually captured. With your exports in hand, the migration preview tool lets you validate that your exported data maps cleanly to the destination platform before the full load.

Project Online Export After Deadline: What Was Recoverable

Between August 31 and September 30, a late export was still possible, but without margin. The service accepted requests until it retired on September 30, 2026. What changed was reliability: the same OData query that returned in 2 seconds in June might throttle, time out, or return a partial page in September, because every tenant that didn't finish in August was hitting the same endpoints in the same final weeks.

The order a late export followed:

1. .mpp exports of any project still open in the Desktop Client. This was the fastest path per project and the least exposed to bulk-endpoint throttling, since it was a single-project pull rather than a tenant-wide query. Highest-priority active schedules came first.
2. OData for projects and tasks (not TimePhasedData yet). The lightest bulk query, and the one most likely to complete even under heavy load. It got the schedule skeleton even if the heavier collections below failed partway through.
3. OData for resources, assignments, and custom field values. Medium weight. Small batches (by portfolio or department) worked better than one tenant-wide call, since a single large request was more likely to throttle to nothing than several small ones were to all fail.
4. TimePhasedData (timesheet actuals). The heaviest and most throttle-prone collection, covered above. If something was lost to a failed export, this was the most likely candidate, so it went last and in the smallest batches possible.

Not in your export: anything in the four categories above you didn't manage to pull, plus the categories that never had a supported export path at all (PWA view definitions, workflow process history, SharePoint 2013 workflow audit trails), which needed manual documentation before the cutover. Anything that read Project Online live stopped with it; anything already exported or imported did not. What actually happened after Project Online retired covers the read-only window, if any, and what a fully decommissioned tenant does and doesn't still expose. For data you did manage to export before the cutover but need to work with later, accessing archived Project Online data after retirement covers the format-by-format reality of what still opens without a live tenant behind it.

The practical takeaway now: work from what you exported. Check what your files contain, preview the mapping with the migration preview tool, and bring it into your migration. Project Online Data: Import What You Exported covers the import.

After the Export: Validating and Archiving Your Data

Exported data that you haven't validated is not a backup; it's an untested file you hope contains what you think it contains.

Validation means comparing record counts between source and export. Your OData query for projects returned 147 rows: did your Project Online tenant have 147 active and archived projects? Compare against the counts you recorded in PWA before September 30. Your resource pool query returned 312 named resources: does the ERP show 312? Your timesheet export for FY2025 returned 284,000 rows: does that match the row volume PWA timesheet reporting showed for that period?

Record count validation catches truncation failures, pagination errors, and authentication timeouts that caused partial exports. It doesn't catch data corruption within individual records, but that's a second-order risk compared to missing large categories of data entirely.

Archiving your exports: structured formats last longer than application-specific formats. A CSV or Parquet export of your timesheet data will be readable in 10 years. An .mpp file requires a specific version of Microsoft Project to open. For compliance retention, archive the raw OData output (which is JSON or XML) alongside a derived CSV version for human readability. Store both in a location with documented access controls and a documented retention policy.

The Project Online migration checklist has specific guidance on what to validate in each of the six inventory categories. Run through that list against your exports to confirm what you captured before you import.

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