Microsoft Project Online retires September 30, 2026, migrate to a modern platform before it's too late.Start migration
Back to Blog
Migration

Project Online Retirement Countdown: A 90-Day Migration Plan for PMOs

Microsoft Project Online retires September 30, 2026. A concrete 12-week, six-phase migration plan for IT and PMO leaders, with weekly checklists, exit criteria for each gate, and the failure mode that catches most teams (Pilot skip).

Onplana TeamApril 27, 202611 min read

Project Online Retirement Countdown: A 90-Day Migration Plan

Microsoft Project Online retires on September 30, 2026. That sentence has been repeated enough that it's lost its bite, but the calendar doesn't care. By the time you read this, every PMO running on Project Online has fewer than 160 days to migrate.

This post isn't another "what to know" piece. The internet has plenty of those (including our own). This is the operational counterpart: a concrete 12-week plan, six phases, with explicit exit criteria for each gate and the one failure mode that catches most teams.

If your migration hasn't started yet, today is week one.

The 30-Second Summary

  • 12 weeks, six phases: Inventory → Evaluate → Pilot → Prep → Cutover → Stabilise.
  • Don't skip Phase 3. A 2-week pilot on 3–5 representative projects is the difference between a clean go-live and a hypercare nightmare.
  • Sep 30, 2026 is the final cutover. Migrating by Aug 1 leaves a buffer; migrating after Sep 30 puts you in data-recovery territory.
  • Cost ramps non-linearly toward the deadline. Q2 migration runs ~3× cheaper than a Q3 panic-cutover.
  • Exit criteria, not dates. Every phase has a gate. If the gate doesn't clear, don't move on.

Twelve-week, six-phase migration timeline from Microsoft Project Online: Inventory, Evaluate, Pilot: Prep, Cutover, Stabilise

Why the Timing Matters More Than the Tool

Most posts focus on which tool to migrate to. That's the wrong starting question. The harder question, the one that determines whether the project succeeds, is when you migrate, not what you migrate to.

Cost and risk curves over time before the September 30, 2026 deadline, both rise non-linearly, with a danger zone after the cutover when Microsoft archives data

Two things rise non-linearly as you approach the deadline:

  • Risk, vendor support windows tighten, consultants get booked, and your own team's stress levels reduce decision quality. A migration scheduled for July is fundamentally different from the same migration scheduled for September.
  • Cost, by Q3, every PMO consultant in your region is double-booked. Day rates rise. Hypercare overtime stacks up. Integration vendors push back on bookings.

Past Sep 30, you enter the data-recovery zone. Microsoft archives the data, restoration requires a support ticket, and the response window is finite. Teams that delay past the deadline are paying twice, once for the migration, once for the recovery.

The sweet spot is migrating to a usable state by August 1, 2026, which gives you 60 days of buffer for hypercare, training, and the inevitable surprises. Working backward from Aug 1, that means starting the 12-week clock no later than the second week of May 2026.

Phase 1, Inventory (Weeks 1–2)

Exit criteria: documented project list, integration map, user roster, and a quantified data-volume estimate.

You can't plan what you don't measure. Most PMOs underestimate their Project Online footprint by 30–50%, usually because nobody has counted the orphan projects, the OData feeds wired to Power BI, or the SharePoint document libraries linked to Project Web App. The free Project Online Inventory Checklist walks the 35 items most tenants miss in this phase, with notes/owners per item and a PDF export for the steering committee.

Week 1 checklist

  • Pull the full project list from Project Online (active + archived). Tag each project with status, owner, last-modified date, and approximate task count.
  • Identify all OData consumers, Power BI dashboards, custom .NET reports, Excel data connections.
  • Map every integration: timesheet system, financials, identity provider, document libraries, Power Automate flows.
  • Roster every Project Online user, by role, by license tier, by time-zone.

Week 2 checklist

  • Categorise projects: active (will migrate), archived (will export to read-only storage), retire (won't migrate at all).
  • Document custom fields. Project Online's "Enterprise Custom Fields" with calculated formulas and lookup tables are the most common migration trip-wire.
  • Measure data volume, total tasks, total assignments, total custom-field values. This drives the import-tool selection in Phase 2.
  • Confirm sponsor + executive owner. The migration is going to surface organizational debt; have someone authorised to make decisions when it does.

Don't skip: the integration map. Migrations fail more often because of an unknown OData consumer than because of the project data itself.

Phase 2, Evaluate (Weeks 3–4)

Exit criteria: shortlisted tool, data-fidelity spike completed against your real export, security/compliance sign-off.

Two weeks. No more. Many PMOs get stuck here for months running parallel evaluations on tools that fundamentally don't fit. Get to a shortlist of three by end of week 3.

Week 3, Shortlist

Use the alternatives roundup as a starting filter. Apply your hard requirements:

  • Does it support all four dependency types (FS/SS/FF/SF) with lag? Most "modern" tools don't, they only do FS without lag.
  • Does it ingest .mpp files natively or via XML? Direct .mpp parse is rare; XML is universal.
  • Does it support baselines and critical-path analysis?
  • Does it offer SSO + SCIM at the tier you need?
  • Does it match your data-residency requirements?

If a tool fails any hard requirement, it's out. Keep three.

Week 4, Data-fidelity spike

Pick three real, complex projects from your inventory. Export them. Import them into each shortlisted tool. Compare against the original side-by-side.

What you're testing: not whether the tool can import .mpp, but whether your projects round-trip with their critical path intact, dependency lag preserved, baselines surviving, and custom field types mapping correctly. This is the moment that disqualifies tools, and it's much cheaper to find out in week 4 than in week 11.

Don't skip: the security review. Your security team will ask for SOC 2 docs: SSO configuration, audit-log capability, and data-retention policies. Get those answers documented before you commit. (Onplana publishes a full security & compliance overview for exactly this reason.)

Don't skip the budget either. End of week 4 is when finance starts asking for a 3-year number. Run the inventory you built in Phase 1 through the free Migration Cost Calculator — it produces low/mid/high scenarios across the six cost categories (license delta, data-migration labor, training, parallel operation, integration rework, cleanup) and exports a CFO-ready PDF. Defensible numbers beat round numbers when the steering committee asks.

Phase 3, Pilot (Weeks 5–6)

Exit criteria: 3–5 projects migrated, validated, and running in production on the new tool. UAT sign-off from project owners. Documented gap list with mitigations.

This is the phase teams skip. Don't.

The pilot is where you discover that one custom field type doesn't translate cleanly, that the OData feed your CFO uses for monthly reporting needs a workaround, that your power users have hotkey muscle memory you didn't plan training for. Each of these is cheap to fix in week 5; expensive in week 11.

Pilot project selection

Pick projects that collectively cover your portfolio's complexity:

  • One large schedule-driven project (1,000+ tasks, multiple baselines)
  • One agile/hybrid project (sprints + milestones)
  • One small simple project (the "easy win" sanity check)
  • One project with all four dependency types
  • One project with significant resource leveling

If a project owner won't cooperate, swap it. Volunteers > conscripts.

What "validated" actually means

Walk each pilot project against its Project Online twin, line by line, with the project owner. Confirm:

  • All tasks present, with correct dates
  • All dependencies (especially SS/FF/SF and lag) intact
  • Baselines preserve historical variance
  • Custom fields populated and computed correctly
  • Resources assigned with the same allocation percentages
  • Critical path matches (or, common, the new tool surfaces a better critical path because Project Online had a bug)

Document any gap. Decide: fix in tool, fix in import script, fix in process, or accept.

Phase 4, Cutover Prep (Weeks 7–9)

Exit criteria: bulk export verified, mapping rules documented, training delivered, rollback plan signed off, integration cutover plan agreed with vendors.

By now you've migrated five projects manually. Phase 4 is industrialising that for the rest.

Week 7, Mapping and scripts

Your pilot taught you the mapping rules: which custom fields go where, how lag values translate, how to handle resource pool migration. Codify these into the import script your migration partner (or your team) will run for the bulk cutover.

Week 8, Training

PMs need 90 minutes hands-on. Stakeholders need 30. Executives need a 15-minute walkthrough of the dashboard. Schedule them now while everyone has bandwidth, three weeks before cutover, not three days.

Week 9, Integration coordination

Every Power BI dashboard, OData consumer, and timesheet hook needs a cutover window. Get those windows agreed with the consuming teams. Don't assume Power BI will "just keep working", it won't, because the OData URL is different.

Don't skip: the rollback plan. It should be one page. If we fail to validate by Sunday 18:00, revert to Project Online (still live in read-only mode), reschedule cutover to weekend N+1, communicate via the standing comm channel. Sponsors love a written rollback plan; they trust the team that has one.

Phase 5, Cutover (Weeks 10–11)

Exit criteria: all active projects migrated, all integrations wired up, validation team sign-off, hypercare team in place.

This is the visible phase. Done right, it's anticlimactic. Done wrong, it's a Monday morning all-hands.

The 60-hour window

Friday 17:00   Freeze writes on Project Online (admin-only mode)
Friday 18:00   Bulk export from Project Online begins
Friday 22:00   Bulk import to new tool begins
Saturday all   Validation team walks each project, flags variance
Sunday all     Hypercare team monitors audit log + integration health
Monday 06:00   PMs log in to the new tool; migration war-room on standby

Keep the window under 60 hours. Past that, fatigue corrupts decisions and small mistakes compound.

The validation pass

Two-person teams, each project: one person on the new tool, one on the (read-only) Project Online view. Spot-check task dates, dependency arrows, critical path, custom-field values. A two-person team can validate ~30 projects/day. Plan capacity accordingly.

Communications

Status updates every 4 hours during the window: Slack channel, email digest, or whatever your org uses. The opposite of a successful migration weekend isn't a failed one; it's a successful one where leadership doesn't know it succeeded until Monday afternoon.

Phase 6, Stabilise (Week 12)

Exit criteria: hypercare ticket queue cleared, retrospective held, Project Online tenant archived for compliance, lessons documented.

The first week post-cutover is hypercare. Expect 3–10× normal support load. Staff for it.

Hypercare priorities

  • Critical: anything blocking a project owner from updating their schedule. Resolve same-day.
  • High: dashboard / report regressions. Fix within 48 hours.
  • Medium: cosmetic differences vs Project Online. Document and triage.
  • Low: feature requests. Park for the post-migration backlog.

Archive Project Online

Once the new tool is the source of truth, lock Project Online for read-only. Schedule the tenant deactivation per your data-retention policy, typically 90 days post-cutover, but check the retention preset that matches your obligation.

Retrospective

Hold it within 7 days while memory is fresh. Two questions:

  • What worked that we should keep?
  • What didn't, that the next migration (or the next vendor migration in 5 years) should avoid?

Publish both internally. Migration debt stays paid down only if it's documented.

Common Variations

Below 50 projects: Compress to 6 weeks. Phases 1+2 collapse to one week. Phase 3 (Pilot) stays at 2 weeks, don't skip. Phase 5 (Cutover) is a single weekend.

Above 1,000 projects: Extend to 16 weeks. Phase 3 (Pilot) doubles to 4 weeks with two pilot waves. Phase 5 (Cutover) splits across two weekends, half the portfolio per weekend.

Multi-region PMO: Each region runs its own Phase 5; centralise Phase 6 (Stabilise) and the retro. Phase 1–4 stays unified.

What to Do This Week

If you haven't started:

  1. Today: Schedule the kickoff for Monday morning. 60 minutes. Sponsor + PMO lead + IT lead.
  2. Tomorrow: Pull the project list. Send to the kickoff invitees as the pre-read.
  3. End of week: Inventory complete. Phase 2 begins Monday.

If you've started but lost momentum:

  1. Today: Audit your phase. Are exit criteria met for the previous phase? If not, you're behind your own definition. Don't paper over it, go back.
  2. This week: Re-baseline the timeline against Sep 30. If you can't make the deadline with current scope, descope the projects that can wait or hire help. Both are cheaper than missing the deadline.

The Honest Disclaimer

Some PMOs will not make Sep 30. The calendar is the calendar; ambition isn't velocity.

If you find yourself in week 4 and your shortlist still has 7 tools, your phase 3 (Pilot) hasn't started, and Aug 1 is no longer reachable: scope down. Migrate the active portfolio first. Send the archived portfolio to read-only storage and migrate those projects post-deadline. Better a clean cutover on a smaller scope than a chaotic one on the full one.

The goal isn't moving every project. It's preserving the schedule integrity of the projects that matter, and giving your PMO a tool worth using for the next decade.


Two free tools to anchor Phase 1 and Phase 2 Inventory the scope, then build the budget. No signup, runs on your real data, both export PDFs you can hand to the steering committee. → Project Online Inventory Checklist · Migration Cost Calculator

Onplana is purpose-built for PMOs migrating off Project Online, native .mpp + Project XML import, all four dependency types with lag, baseline shadows on the Gantt, and a free starter tier so you can run Phase 2 (Evaluate) without a procurement cycle. Start a free evaluation or book a migration walkthrough.

Related: Microsoft Project Online End-of-Life: What You Need to Know · How to Migrate from Microsoft Project Online · Best Microsoft Project Alternatives in 2026 · Cost of Migrating from MS Project Online · Why Most Project Online Migrations Fail

Microsoft 365 integration paths (if some teams keep working in the new Microsoft surfaces): Migrate Microsoft Planner to Onplana with optional live sync · Import Project for the Web Premium from Dataverse · Microsoft To Do bi-directional sync

Microsoft Project OnlineProject Online End of LifeMigrationPMOIT StrategyProject Management2026Migration ChecklistMicrosoft Project Alternative

Ready to make the switch?

Start your free Onplana account and import your existing projects in minutes.