Project Online Data Export Deadline: How Long You Actually Have

The most dangerous misconception in every Project Online migration plan is a simple one: that September 30, 2026 is the Project Online data export deadline. It isn't. September 30 is the date the service stops. The effective window to export your data reliably—at predictable speed, without server-side throttling, and with time to validate and re-run—closes about a month earlier.

The teams that set August 31 as their internal export deadline finish migrations calmly. The teams that plan for September exports discover throttled APIs, batch failures they can't recover from before the cutover, and no time to validate that what they pulled actually matches what was in the source system.

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 is not extra export time. It's the buffer you need to validate that your export matched the source, re-run any batches that throttled or failed, and confirm your destination platform has everything before you commit to the cutover.

Why the Effective Project Online Data Export Deadline Is August, Not September

The official retirement date and the practical export deadline are not the same thing, and treating them as equivalent is one of the most reliable ways to have 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. In September 2026, Microsoft's Project Online infrastructure will be under the heaviest concurrent read load it has ever seen. Every organization that has not yet migrated—and that will be a substantial number—will attempt to export in the final weeks of September. OData requests that respond in 2 seconds in June might time out or be throttled to 429 responses in September. Batch jobs that complete overnight in July might take 72 hours in September, if they complete without partial failures.

The final two weeks of September are when export jobs fail. Not because the API stops working, but because the queue of concurrent requests from thousands of tenants overwhelms 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 your export by August 31 eliminates this risk entirely. You have 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 provides two primary mechanisms for getting your data out, and they capture different things. Most PMOs need both.

The .mpp export path works through the Project Online Desktop Client. You open each project in the client, use the "Save As" dialog to save a local .mpp copy, and repeat 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 is more comprehensive but requires more technical setup. The OData API at /_api/ProjectData exposes 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 can pull everything that lives in Project Online's database.

The OData path requires 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 can do this. The migration preview tool can pull a sample of your OData data to validate field mappings before you run a full export.

The practical recommendation: run the OData export first to get 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 is the technical constraint that converts a "we have until September 30" plan into a missed deadline.

Project Online's OData endpoint uses SharePoint's throttling framework. When your application sends requests faster than the server is configured to handle, it returns 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 to understand before you start:

Per-user request limits. Project Online's OData endpoint imposes limits on concurrent requests per user identity. If you're exporting with a single service account, you're limited to that account's request quota. Distributing the export across multiple service accounts (one per portfolio or department) can significantly increase your 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. Export these collections in tight time windows (e.g., one year per batch) rather than attempting a single full-history query.

A practical export sequence that works 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, do this 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.

.mpp Export Limits and What They Don't Capture

Even if you export every project as a .mpp file, you will be 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 stores up to 11 baselines per project (Baseline, Baseline 1 through Baseline 10). The .mpp export preserves whichever baselines are saved in the project file, but only if the Desktop Client has loaded them from the server. Projects that haven't been opened recently in the Desktop Client may have stale local copies that don't reflect the server-side baseline data. Always check a project out from the server, allow it to fully sync, and then save the local copy.

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—are typically stored in Project Online's database, not in the .mpp structure. You need OData to capture those.

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. This is data you need to export via OData separately.

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 has no official API export mechanism. You need to document or capture it manually before the retirement date.

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 is no API that returns a structured export of these view definitions. Screenshot each custom view, document its filter and grouping logic, and 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 are 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—you need to export this data via SharePoint workflow history lists (which may capture some of this) or document it manually by reviewing 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, export them through SharePoint's list export mechanisms before the PWA site collection is decommissioned.

Building an Export Plan That Actually Works

A practical export plan treats data differently based on migration priority, risk, and export complexity.

Phase 1: Insurance snapshot (do this this week). Run a complete OData pull of your active project catalog—just the project and task entities, not TimePhasedData—and save it to a location you control. This is your backup. Even if everything else in your migration goes wrong, you have the project structure data. It takes 2 to 4 hours for most mid-size tenants and can be done by a single person with SharePoint admin rights and a PowerShell script.

Phase 2: Full structured export (June to July). Execute the complete export: all OData entities including resources, assignments, custom field values, and timephased actuals. Run this in batches, by portfolio or department, over 2 to 3 weeks. Validate the output against source counts—project count, task count, resource count, timesheet row count—before moving on.

Phase 3: .mpp exports for active migration projects (rolling, May to August). As each project migrates to your destination platform, pull a fresh .mpp export of that project from Project Online on the day you migrate it. This gives you the most current schedule state at migration time and a rollback file if the import has issues.

Phase 4: Final validation export (August 15 to August 31). Re-run the full OData export one final time. Compare against Phase 2 to identify projects that changed significantly in the interim. Re-export any .mpp files for projects that had active scheduling work between June and August.

This four-phase structure gives you three complete copies of the data at different points in time, which is the minimum for a defensible audit record and a realistic chance of catching any export failure before you're on the clock.

The Project Online inventory checklist tool includes export tracking fields for each asset category so you can monitor export completion status as you work through the phases. After your exports are complete, the migration preview tool lets you validate that your exported data maps cleanly to the destination platform before the full load.

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—does your Project Online tenant have 147 active and archived projects? Run the count in PWA and confirm. Your resource pool query returned 312 named resources—does the ERP show 312? Your timesheet export for FY2025 returned 284,000 rows—does the PWA timesheet reporting show that row volume 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 after your Phase 2 export to confirm you've captured everything before committing to a retirement date.

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