Microsoft has set the retirement date for Project Online: September 30, 2026. After that, the service and all its data will become permanently inaccessible. For the thousands of organizations that still rely on it for portfolio and project management, the clock is now ticking—not just to export their schedules, but to preserve the full context of every project, including the documents, risks, and decisions scattered across linked SharePoint sites. The official export tool only captures what’s inside the Project Web App (PWA). Left behind are the SharePoint-based project sites that often hold the most critical evidence of why a project went the way it did, and missing them turns a migration into a data dump.

The Deadline Is Firm—And There’s No Gradual Fade-Out

Microsoft’s lifecycle policy is clear: Project Online leaves support on September 30, 2026, and after that date the service is taken offline entirely. There is no extended ‘read-only’ grace period and no opportunity to recover anything you forgot. The lifecycle page on Microsoft Learn is blunt: “Project Online and its associated data will no longer be accessible.”

That means every project schedule, portfolio artifact, resource plan, status report, and user setting living inside the PWA must be exported beforehand. But it also means the linked SharePoint infrastructure—project sites containing documents, issue lists, risk registers, deliverables, and permission structures—will vanish alongside it. For a PMO, this is not just a technical migration. It is an archival effort that demands understanding what you have, where it lives, and how to reassemble it into something usable outside the Microsoft ecosystem.

What the Built-in Export Actually Covers—And What It Misses

Microsoft provides an ExportProjectUserContent.ps1 script that can pull a substantial amount of data from Project Online. Run it with the right parameters, and you can save draft and published .mpp files, XML and JSON representations, reporting datasets, portfolio artifacts, status reports, resource plans, and user-view settings. The workflow is designed around a single user’s content, so administrators typically loop through a list of key project managers or resource IDs.

But the tool’s name is a giveaway: it’s built for user content, not for a complete tenant-wide archive. It does not reach into the SharePoint site collections that underpin every Project Online instance. Those sites hold the collaborative record of a project: documents uploaded by team members, issues logged during execution, risk assessments, deliverable tracking, and workflow histories. In many cases, the people who contributed to that content never had PWA licenses; they were pure SharePoint users, invisible to the export script. If you export only PWA artifacts, you end up with schedules stripped of the narrative and evidentiary material that explain them.

This gap has tripped up early movers. One large PMO reported that after a “successful” export of all project files, their test import into a new platform failed because the schedules referenced old SharePoint links that no longer resolved, and the absence of risk registers made it impossible to reconstruct approval chains. The export had terminated without errors, but the archive was incomplete.

Project Sites: The Hidden Iceberg Beneath Every Project

A schedule may show that a milestone slipped. The SharePoint site often contains the issue entry that explains why, the risk record that shows when the threat was identified, the deliverable used for acceptance, and the document containing the decision that changed the baseline. Those records are not duplicates of PWA data; they carry a different kind of value—narrative, contextual, and legal.

Microsoft’s own guidance separates the two worlds, emphasizing that project-site content must be reviewed and exported independently. The categories include:

  • Documents: reports, specifications, contracts, and meeting notes.
  • Issues: logged problems, tracking status, and resolution details.
  • Risks: probability and impact assessments, mitigation plans, and ownership.
  • Deliverables: formal work products accepted or rejected by stakeholders.
  • Permissions: who could read, edit, approve, or administer the content.
  • Workflows: the business logic that routed updates, approvals, and stage transitions.

If an organization simply exports the PWA and moves on, none of this comes along. And because SharePoint project sites can have permissions inherited or unique, a simple file copy via a migration tool won’t necessarily preserve ownership or security context. Future auditors or project teams attempting to open a document may find themselves blocked because the archive no longer knows who had access.

Step One: Inventory Everything Before You Export Anything

A successful retirement plan begins with discovery, not extraction. The first task is to list every PWA-enabled site in your tenant and assign an owner who understands its business content. SharePoint administrators can use the SharePoint Online Management Shell to enumerate these sites:

Connect-SPOService -URL <AdminSiteURL>
Get-SPOSite | ?{$_.PWAEnabled -eq "Enabled"} | ft -a Url, Owner

This gives you a list of URLs and registered owners, but that’s only a starting point. Next, you need to:

  • Identify which projects are active, completed, or abandoned, and which have retention obligations.
  • Map every project to its linked SharePoint site and list all libraries and lists used for project records.
  • Document the identities of all contributors—including those who never appeared in PWA—whose content must be preserved.
  • Record any workflows, business rules, or third-party integrations that depend on Project Online or SharePoint.

For large tenants with dozens of PWA sites and hundreds of projects, this inventory phase can take months. The clock is already running.

The Two-Track Export: PWA and SharePoint

Once you know what you have, you can execute a dual-track export.

Track 1: PWA artifacts
Use ExportProjectUserContent.ps1 for every active user and service account that has contributed to a project. Do not assume that exporting the top five project managers covers everything; resource managers, portfolio administrators, and even former employees may hold the only copy of certain schedules or views. The output should be validated by opening sample projects and confirming that draft, published, and reporting versions are all present.

Track 2: SharePoint project-site content
For each project site discovered during inventory, capture the content of document libraries, issue and risk lists, deliverable trackers, and any other custom lists. Preserve permissions and metadata. If your replacement platform cannot natively import SharePoint list structures, export them to a format that retains the data and can be re-imported later—for example, a collection of CSV files combined with a manifest of permissions.

Administrators must also watch for links. Any hyperlink in a project plan, report, or document that points back to https://<yourtenant>.sharepoint.com/sites/pwa/... will die after retirement. Validate that your exports do not rely on such links; if they do, you may need to embed or replace them with references to the new archive location.

Project Online retirement is not a free pass to delete everything. Different projects carry different retention obligations. A completed construction project may need to be kept for decades under regulatory rules; an abandoned R&D proposal might be disposable after two years; active projects must continue functioning in a new system. Legal holds may apply to specific projects, preventing data deletion.

Before any mass export or deletion, the PMO, legal, and records management teams must agree on the retention schedule for each category of content. This should be documented so that the archive arriving in a new platform or a cold storage repository is already classified. Otherwise, you risk either violating a legal hold or keeping terabytes of junk indefinitely.

How We Got Here

Microsoft launched Project Online in 2013 as a cloud companion to Project Server, offering a dedicated PWA for project and portfolio management within SharePoint Online. Over time, the company shifted its development energy toward newer tools: Project for the web, which is built on the Microsoft Power Platform, and Planner, a lighter-weight task management tool. In April 2023, Microsoft stopped adding new features to Project Online, and in early 2025, the official retirement announcement followed. The message is clear: investing in legacy project-management infrastructure is no longer part of the roadmap. For existing customers, the only path forward is migration.

What to Do Now: A Practical Timeline

If your organization hasn’t started planning, the next few months are critical. Here is a high-level timeline experts recommend:

  • Q2 2025–Q4 2025: Complete inventory of all PWA sites and linked SharePoint project sites. Assign owners, document retention requirements, and evaluate replacement platforms.
  • Q1 2026–Q2 2026: Execute initial exports of PWA content using the PowerShell script, and begin exporting SharePoint content. Validate the completeness of the archives by testing with representative projects.
  • Q3 2026: Migrate active projects to the new platform. Perform a final reconciliation of the archive—cross-check PWA exports, SharePoint exports, and destination maps. Confirm that all data required for legal or regulatory purposes is preserved.
  • September 30, 2026: The retirement day. By this point, all validation should be complete, and any required shutdown scripts should have been run. No further access is possible.

The most frequent mistake teams make is postponing validation until the last month. Testing whether an exported project can be reconstructed without Project Online is not a one-day exercise. It requires opening schedules, reading linked documents, tracing risk and issue histories, and confirming that permissions are intact. That takes time—and ideally involves people who were not part of the export process, to avoid blind spots.

Looking Ahead: Life After Project Online

Migration isn’t simply about moving files; it’s about choosing what comes next. Microsoft’s recommended successor, Project for the web, handles scheduling and task management differently, and it lacks many of the portfolio analysis and reporting features of Project Online. Some organizations are turning to third-party tools like Planisware, ServiceNow PPM, or even custom solutions built on Power Apps and Dataverse. Others are decoupling functions: sending schedules to desktop Project, reporting to Power BI, and collaboration to Teams and SharePoint Online.

The key is to base your choice on the artifact map you built during inventory. If your PMO relies heavily on portfolio modeling and resource optimization, a replacement that can only track tasks will leave a gap. If your governance processes depend on complicated approval workflows stored in SharePoint, ensure the new platform supports equivalent automation.

September 30, 2026, is both a deadline and a milestone. When it arrives, the organizations that treated the retirement as a data-migration project will be left with piles of files no one can use. The ones that treated it as a records-preservation and business-continuity challenge will have an archive that speaks for itself—and a new platform that actually works.