Project Online Retirement: An SMB Migration Checklist

Microsoft Project Online retires on September 30, 2026. Microsoft says customers will lose access to projects and associated data inside the service after retirement. This is a service shutdown, not simply an end to updates. A working Project Web App (PWA) site today is not a continuity plan for October. See Microsoft's retirement announcement.

For a small or midsize business, the urgent question is not just where a project schedule will move. It is whether staff can still approve time, assign resources, explain a budget variance, and retrieve the records behind a customer commitment. A replacement that displays tasks but loses those workflows is not a finished migration.

ITECS recommends three priorities: preserve independently readable records, test real workflows in the proposed destination, and approve a cutover with a fallback that does not rely on Project Online staying available. The checklist below is practical planning guidance, not a promise that every feature or historical record can be transferred.

First, identify which Microsoft Project product you use

The names are similar, but the products and migration implications are different:

• Project Online: the hosted project and portfolio service being retired, commonly used through PWA for centralized project work.
• Project desktop: the Windows scheduling application. It is not being retired by this announcement. A desktop installation does not, however, keep its connection to a retired Online service working.
• Project Server: a separately operated server product. Microsoft identifies Project Server Subscription Edition as an alternative; it is not an automatic conversion of your Online tenant.
• Microsoft Planner: Microsoft's work-management experience with basic and premium capabilities. Its consolidation of Project for the web is different from migrating Project Online.

Microsoft's Planner FAQ explains these transitions. Confirm the exact product, version, subscription, and PWA address with your administrator rather than relying on an application icon or a license's familiar name.

1. Build one inventory with business owners, not just site URLs

Ask the Microsoft 365 administrator and the person who runs project operations to work together. Inventory every relevant tenant and PWA site, including sites inherited through an acquisition or maintained by an outside consultant. Do not assume one administrator's recent-project list represents the whole business.

For each site, record:

• Work: active, proposed, closed, master, and linked projects; schedules; baselines; calendars; resource plans; and task assignments.
• Business records: submitted and approved timesheets, approvals, cost information, project documents, risks, issues, and records needed for billing or reporting.
• Configuration: enterprise custom fields, lookup values, formulas, views, templates, security groups, permission rules, and approval steps.
• Dependencies: Power BI or Excel reports, OData feeds, scripts, workflows, add-ins, service accounts, and connections to finance or line-of-business systems.
• Accountability: business owner, technical owner, replacement destination, archive location, cutover date, and acceptance evidence.

Ask each department what would stop working if PWA disappeared tomorrow. “Our Monday report” or “the approved hours used for invoices” is often a better starting point than a technical integration list. Assign an owner to every answer.

2. Separate an archive from a migration

An archive preserves evidence; a migration makes work usable in another system. A spreadsheet, PDF, or project file may serve one purpose without serving the other. Plan both, especially for closed projects that do not need to become editable plans again.

Microsoft provides a user-content export procedure, but it is user-scoped, not a complete tenant-backup guarantee. Master and inserted projects can have different coverage. Microsoft also states that saving the MPP files produced by that procedure back into Project Online or Project Server is unsupported. Do not confuse those files with a tested restoration method.

Have an authorized administrator choose and test the extraction approach for each record type. Preserve machine-readable data where practical and readable reference copies of essential reports. Capture field definitions and lookup meanings as well as values. Inventory related SharePoint documents and permissions separately; a project export alone should not be accepted as proof that the document estate is preserved.

Microsoft's export object definitions expose an important limitation: some configuration-related outputs describe items checked out by a user rather than a full configuration library. File names such as CustomFields or LookupTables do not establish completeness.

For each archive, record the source, extraction time, exporter version, filters, project identifiers, file counts, checksums, access owner, and exceptions. Open representative files using the tools that will remain available after retirement. Store sensitive schedules, rates, and timesheets in controlled storage with an independently recoverable copy. Have the appropriate records owner set retention and access rules; do not invent one retention period for every business.

3. Choose the destination by workflow fit

Start with must-have business operations, then compare products. A familiar Microsoft name is not evidence of feature parity.

Planner: test the required plan and license

Evaluate Planner when your target is collaborative planning inside Microsoft 365. Verify the capabilities available to project managers, contributors, reviewers, and guests in your tenant. Premium features and licensing differ; use Microsoft's current plan comparison, not an old procurement spreadsheet.

Microsoft documents migration options and partner assistance in its Planner FAQ. That does not establish automatic tenant-wide migration or preservation of every PWA workflow. Require a demonstration using your calendars, dependencies, custom fields, approval needs, timesheet process, and reporting—not a vendor's simplest demo plan.

Project Server Subscription Edition: account for operating responsibility

Evaluate this path when centralized project-management requirements justify a separately managed platform. It brings infrastructure, administration, security, backup, patching, licensing, and support decisions. Microsoft's installation requirements belong in the technical feasibility review.

The Planner FAQ states that Microsoft does not provide a tool to migrate Project Online projects and settings to Project Server and recommends experienced partner assistance. Do not treat a server installation or an exported MPP file as proof that migration is solved.

Other tools or a split approach: make the tradeoff explicit

A fit-for-purpose project platform, a supported desktop scheduling workflow, or a combination of active-project tooling and a searchable archive may be appropriate. Compare resource allocation, time approval, reporting, integration support, access controls, data portability, and ongoing ownership. Desktop files alone are not a substitute for a shared timesheet or portfolio process unless the business has approved another way to perform it.

Budget for migration effort, report rebuilding, integration changes, archive access, training, and support—not just subscription seats. Do not purchase a long-term destination until the essential workflow has passed a representative pilot.

4. Pilot the difficult projects, not only the clean ones

Select a small sample that reflects how your organization actually works: a live customer project, a resource-heavy schedule, a project with custom fields and dependencies, and a closed project with historical reporting. Include a master/subproject relationship if you use one.

Give the pilot explicit pass/fail checks:

• Scheduling: task relationships, calendars, milestones, baselines, assignments, and dates remain understandable; explain any recalculation or unsupported behavior.
• Resources and time: named and generic resources map correctly; availability and approved hours reconcile; the next time-entry and approval cycle works.
• Reporting: owners can reproduce an agreed historical period and explain differences in hours, costs, status, or totals.
• Permissions: a project manager can manage, a contributor can update only the intended work, and a restricted or guest user cannot see unauthorized projects or sensitive rates.
• Integrations: each required read, update, notification, and report refresh works with the intended identity and permissions.

A populated dashboard is not sufficient evidence: check its last refresh and source. Test without relying on the old PWA connection in a controlled pilot. Have business owners sign off on results, not just administrators confirm that an import completed.

5. Keep a “cannot transfer” register

Every gap needs a disposition. For each field, history record, workflow, attachment, or integration that does not transfer, record:

1. What is missing or behaves differently, and which business process needs it.
2. Where the original evidence will remain readable.
3. Whether to rebuild, replace, handle manually, archive only, or retire it.
4. The responsible owner, acceptance decision, and completion date.

Illustrative example: a historical time-approval record may be retained in a restricted archive while new approvals move to another system. Finance must confirm that the archived evidence is sufficient for its needs and that the new process works. Calling both systems “timesheets” does not establish equivalent records.

Do not silently convert an unrecognized lookup value into free text or drop a field because a tool labels it unsupported. Make the loss visible before the business accepts it.

6. Set a cutover and a realistic fallback

Choose a cutover before September 30 with room to investigate defects. Publish a single schedule stating when users stop changing PWA, when the final extraction occurs, who reconciles changes since the pilot, and when the new system becomes authoritative.

Before switching, require the final export, reconciliation, permission tests, reporting checks, archive readback, and owner sign-off. Avoid uncontrolled dual entry: if temporary parallel operation is necessary, define which system owns each record and how updates are reconciled.

Rollback has a deadline. Before retirement, returning work to Project Online is an option only if its availability, your change window, and a tested recovery method permit it. After retirement, the plan cannot depend on reactivating the service. An export is not a promise that Microsoft can restore access.

Prepare an independent continuity procedure for critical scheduling, time collection, approvals, and customer reporting. Specify who activates it, where changes are logged, who approves exceptions, and how those changes later enter the destination. Do not delete the source records or retire supporting access as a shortcut before preservation and acceptance are complete.

7. Train users and complete the handoff

Give each role a short guide covering its first real task: finding a project, updating progress, entering time, approving work, locating historical evidence, or refreshing a report. Replace old bookmarks and documentation after acceptance, and identify a support contact and escalation owner.

Tell staff what changed, what did not move, where archives live, and which workarounds are temporary. Recheck the first reporting and time-approval cycle after cutover. Retire old integration identities and connections only after their dependencies and retention obligations are resolved through the normal change process.

If the migration cannot finish before retirement

Escalate now rather than treating the deadline as negotiable. Prioritize readable records and a workable business-continuity process, then complete the more complex replacement work against that preserved evidence. Do not assume a grace period, an extension, or access after September 30.

The minimum leadership review should answer five questions: Can we retrieve our records? Can people perform tomorrow's critical work? Are permissions correct? Does the owner understand every remaining gap? Is there a documented fallback independent of Project Online?

If any answer is no, name the blocker and its owner. ITECS can help frame the technology and dependency review through Microsoft 365 consulting. Contact ITECS to discuss your environment, remaining workflows, and migration-readiness priorities; scope and timing require an environment-specific review.

---

Microsoft documentation checked September 18, 2026. Prepared with AI assistance for the ITECS Team. Product facts are linked to Microsoft sources; the checklists and acceptance recommendations are ITECS planning guidance. Confirm current tenant capabilities, licensing, and migration-tool behavior before making changes.