Project Online Archive Strategy: Three Approaches Before Read-Only Mode

Most migration plans have a cutover section. Very few have a Project Online archive section. These are two different operations, and conflating them is how PMOs end up three years after the retirement date unable to answer a compliance request.

Migration moves your active, in-flight projects to a new platform. The work continues; only the tool changes. An archive is a different operation entirely: it preserves your completed and historical Project Online data in a durable, queryable format after the service is gone. The question of what archive strategy fits your PMO depends on your compliance requirements, your IT infrastructure, and how often you realistically expect to query that historical data.

Get this wrong and a 2029 audit request produces either a helpdesk scramble for data that was never extracted, or a file system full of .mpp files that nobody can query without opening each one manually.

What a Project Online Archive Actually Contains

Before choosing a strategy, clarify what "the archive" needs to contain. The answer varies by PMO, but four data types are almost always in scope.

Project schedules and task data. This is the core: the full set of .mpp files plus the reporting-schema OData snapshot of tasks, assignments, durations, dependencies, and baseline history. For most PMOs, this is the layer that audit requests reference when someone asks "what was the plan at project kickoff?" or "when did the scope change?"

Timesheet and resource data. Completed timesheet periods, resource assignments, and actual-hours records. Finance and HR teams need this for multi-year audit trails. Define your retention period before extracting: most compliance frameworks require five to seven years.

Enterprise configuration. Custom field definitions, lookup tables, calendar configurations, and the enterprise resource pool. These aren't project data per se, but they define the context that makes the project data interpretable. A custom field called "Risk Level" with lookup values "High / Medium / Low" needs its definition archived alongside the project records that used it.

Governance and reporting. Report definitions, Power BI connection strings, Power Automate flow configurations. Less critical from a data-retention standpoint, but valuable as institutional memory for whoever builds reporting on the destination platform.

The Project Online Inventory Checklist walks through each of these data types systematically and generates an export plan with item counts and priority rankings. Run it before deciding which archive strategy to use: the inventory output determines which strategy is realistic for your tenant size.

What a Project Online Archive Does Not Preserve

Equally important: know what you're not getting, regardless of which strategy you choose.

Live PWA functionality does not archive. After September 30, 2026, Project Web App stops serving pages. Any reporting or workflow that depended on live PWA data (real-time resource availability, dynamic portfolio rollups, active project status) is gone. The archive captures a point-in-time snapshot, not a live service.

SharePoint project sites are technically unaffected by the Project Online retirement, but their connection to PWA-specific data (custom views built on OData, web parts that queried PWA) breaks. The SharePoint sites themselves remain accessible, but they lose their Project Online data context.

Tenant-specific OData schema customizations are not portable. If your PMO added custom OData fields or modified the default reporting schema, the archive captures the data but not the schema configuration. Document the customizations separately.

For more detail on the technical shutdown sequence, the Project Online data export deadline post covers what stops working and when during the final weeks before retirement.

Strategy 1: Full Export to Azure Blob Storage

The highest-fidelity approach: export every data type from Project Online and store it in Azure Blob Storage with versioning and access controls.

What goes into the archive: the complete OData entity set (Projects, Tasks, Assignments, Resources, Baselines, Timesheets, CustomFields, LookupTables), .mpp exports for every project, timesheet history as CSV or Parquet, report definitions, and the enterprise resource pool data.

How it works: OData is throttled at approximately 100 requests per minute. A tenant with 100 projects, each with several hundred tasks and assignments, requires 4 to 8 hours for a complete OData snapshot. Run this during off-peak hours and store the output in a dated folder structure (e.g., pwa-archive/2026-09-01/). The .mpp exports can be scripted using the Project CSOM API.

When this strategy makes sense: regulated industries (defense, healthcare, financial services) where audit requests may require line-item task history, and where the legal hold requirement is seven years or more. Also appropriate for any PMO planning to rebuild historical reporting dashboards in a new BI tool: the raw OData data is the source.

Infrastructure cost: Azure Blob Storage is inexpensive for cold-tier storage. A typical 100-project tenant archive occupies 50 to 200 GB. The cost to store that in Azure Cool Tier for seven years is modest compared to any per-seat licensing cost. The real cost is the engineering time to script and validate the export.

The risk: this strategy has no value if the extraction fails or the data is never validated. Treat the archive as done only after you open a sample .mpp, run a query against the OData export, and confirm readable timesheet records.

Strategy 2: Summary Extraction to a BI Warehouse

A queryable historical layer rather than raw file storage: extract key metrics and relationships from Project Online into a structured data warehouse (Azure Synapse, Databricks, Fabric, or your existing BI infrastructure) and build a read-only historical reporting layer on top of it.

What goes into the archive: not the raw OData entities, but a curated set of summary tables: project-level rollups (planned vs. actual start/finish/cost), milestone history, resource utilization by period, and baseline variance over time. Custom field values for any fields used in portfolio-level reporting.

How it works: design the summary schema first based on what questions you actually need the archive to answer. Then write extraction queries against the Project Online OData feed that populate those summary tables. Run the extraction, validate the data, and freeze the schema. After September 30, the tables are read-only historical data.

When this strategy makes sense: PMOs that rely heavily on portfolio-level Power BI reporting and want to preserve the ability to answer "how did our portfolio perform in 2024 and 2025?" without opening individual .mpp files. Also appropriate when the raw OData export volume is impractical (large tenants with thousands of projects) and you need a subset of curated data rather than everything.

The limitation: this strategy loses task-level granularity. If a compliance request asks for the complete task history of a specific project, a BI warehouse summary may not have enough detail. Combine with a spot .mpp export for high-priority or sensitive projects.

Strategy 3: Project-by-Project PDF Report Bundle

The lowest-infrastructure approach: generate a standardized report for every project in the tenant (schedule summary, resource assignment table, milestone list, baseline vs. actual comparison) and store the PDFs in a SharePoint document library or file share.

What goes into the archive: one PDF report per project, generated from PWA's existing report library or a custom report template. For tenants with 50 to 200 projects, this is a half-day task if you have a consistent report template and someone to run it.

When this strategy makes sense: small to mid-size PMOs without compliance requirements that mandate structured data access, and where the historical archive is primarily for internal reference ("what was the status of Project X at completion in 2025?"). Also the right fallback for any project that doesn't have a complete OData export for technical reasons.

The limitation: PDFs are not queryable. You cannot answer cross-portfolio questions ("which projects were over budget in Q2 2025?") from a PDF archive without manual review of each file. This is the minimum viable archive, not the complete one.

Which Project Online Archive Strategy Fits Your Compliance Requirements

The right strategy depends on what you're actually trying to preserve access to.

The diagram below compares the three strategies across the dimensions that matter for compliance-driven decisions.

How to Structure the Archive Before Read-Only Mode

Regardless of which strategy you choose, the archive needs to be done before September 1, 2026, not September 30. OData throttling is the practical reason: the endpoint is rate-limited at approximately 100 requests per minute. A tenant with 150 projects can take 8 to 12 hours for a complete OData snapshot under normal conditions. In the final two weeks of September, as every other organization tries to run the same exports simultaneously, service degradation is predictable.

September 1 is the practical safe deadline for completing any extraction that depends on the OData API. Plan accordingly.

The Project Online migration checklist includes the archive as a phase alongside the cutover: the export runs during the same window as the data validation for the destination platform. Running both in parallel means you catch OData issues before the deadline, not on September 29.

The structure of your archive storage matters as much as the data. Date-stamp everything. Use a folder hierarchy that makes the source obvious: pwa-archive/tenant-name/2026-09-01/projects/ rather than a flat file dump. Name .mpp files with project IDs, not just project names (project names change; IDs don't). Include a README in the archive root explaining what each folder contains and when the extraction ran.

Microsoft's documentation on exporting user data from Project Online covers the PowerShell-based export process for individual users, which is the same CSOM infrastructure underlying any bulk extraction. The export script package it references is a useful starting point for building your own archive pipeline.

What Happens If You Wait Until After September 30

The retirement date is a hard cutover. After September 30, 2026, the OData endpoint returns 410 Gone and the .mpp export options in PWA stop functioning. Microsoft retains the tenant data internally, but self-service access ends.

Recovery after the deadline requires a Microsoft support ticket. Response time, data completeness, and the cost of the recovery process are all uncertain. Organizations that have been through this scenario with other Microsoft service retirements (Skype for Business, SharePoint Designer workflows) describe the post-deadline recovery as expensive, slow, and incomplete.

The security and compliance posture for your PMO addresses the broader retention and data-sovereignty requirements that make a complete pre-retirement archive mandatory rather than optional for regulated organizations.

The safe position: treat September 30, 2026 as the date when access is gone, not as the export deadline. Every day before that date is time you can use to make the archive reliable. Every day after is time you spend hoping the data is still recoverable.

Run the free Project Online Inventory Checklist Walk through your tenant in about 10 minutes and get a structured export plan covering projects, custom fields, resource pool, and timesheet history. No signup required. → Open the checklist

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