Project Online Migration: The Complete Guide

Project Online launched in 2013 as the cloud-hosted version of Microsoft Project Server, built on top of SharePoint Online. For its first decade it was Microsoft's flagship PMO product: enterprise-grade scheduling, full custom-field engine, formal portfolio analytics, time-sheeting against a costed resource pool, and an OData feed that any BI tool could ingest. The thing it was bad at, by modern standards, was usability — the ribbon-driven UI, the dependency on Internet Explorer for the ActiveX components, and the deep coupling to the Project Web App SharePoint site collection all aged poorly after the 2018 SharePoint UX modernization push.

In April 2024 Microsoft announced that Project Online would be replaced by Project for the Web (now branded as Microsoft Planner Premium) and that the existing service would be retired on September 30, 2026. The replacement is built on Microsoft's Dataverse / Power Platform stack rather than SharePoint, which means a clean modern UI but also a fundamentally different data model. Migration is not in-place; every customer needs to extract their data, transform it, and load it into whichever successor system they pick.

The strategic context: Microsoft is consolidating its PM tooling around the same Dataverse + Power Platform substrate that Dynamics 365 sits on. That gives them a single stack to invest in across CRM, ERP, and PM, and lets them ship Power Apps + Power BI + Power Automate integrations once instead of three times. For Microsoft this is a rational move. For PMOs that built deep customizations on Project Online — formula fields, custom workflows in SharePoint Designer, OData-driven dashboards — it means rebuilding those customizations in whichever platform you migrate to. The retirement isn't about killing PMO software; it's about consolidating the underlying infrastructure and forcing customers off the SharePoint-coupled architecture.

Two implications follow that PMOs should plan around. First, this is a forcing function: any organization that has deferred PMO modernization on the assumption that Project Online "still works fine" is now on a clock. Second, the replacement product is a Microsoft-shop continuity decision more than it is a PMO-tooling decision — Project for the Web / Planner Premium will keep evolving, but its design centre is smaller teams using Microsoft 365 Groups and Planner-style boards, not enterprise PMOs managing 200-project portfolios. Organizations that need the latter should evaluate third parties seriously rather than default to the Microsoft successor.

One more piece of context worth knowing: there is no "Project Online 2.0." Microsoft isn't holding back a v2 that keeps the depth. The decision tree is binary — accept the Planner-class replacement and either trim PMO ambitions or bolt on third-party tools, or migrate the whole PMO surface to a platform that was designed for PMO depth from the start. Every guide that frames this as "wait and see" is misreading the announcement. The deadline is real and the depth gap is real.

The retirement isn't a single date — it's a sequence of milestones, several of which come months before the final shutdown. Plan backwards from the dates you cannot move:

What actually breaks first depends on how integrated Project Online is with your downstream systems. If you have Power BI dashboards reading the OData feed, those break at retirement, not before — but they'll fail silently overnight, surfacing in monthly PMO reporting cycles. If you have Power Automate flows triggered by SharePoint list changes in the PWA, those stop firing the moment PWA goes offline. The pre-migration checklist below catches both classes.

Recommended target completion date: August 15, 2026 — gives you 6 weeks of stable parallel operation before retirement removes the rollback option.

The honest answer to "what if we just don't?" is: you lose all live access to your PMO data, and most of it isn't recoverable after retirement. The categories, ranked by recovery difficulty:

• Active project schedules. Recoverable as one-off .mpp file exports if you do them before Sep 30. Otherwise gone — there is no Microsoft-provided archive recovery for retired Project Online tenants.
• Resource pool + capacity data. Recoverable via OData export before retirement. After Sep 30 the OData endpoint is gone; Microsoft Support cannot reconstruct it.
• Custom field definitions and formulas. Recoverable via the Project Server SOAP API or by inspecting individual project files. Formulas need to be rewritten on the target platform; the metadata (field names, types, lookup tables) transfers cleanly to most modern platforms.
• Timesheet history. Recoverable via OData while the service is live. Critical to capture for audit, billing, and revenue-recognition purposes — organizations subject to SOX or government contracting requirements need this in their records management system before retirement.
• Power BI dashboards + Power Automate flows. Not recoverable in any meaningful sense; they're tightly coupled to PWA's data model. Dashboards need to be re-pointed at the new platform's API. Flows need to be re-authored against the new triggers. Budget 3–10 days per dashboard depending on complexity.
• SharePoint document libraries (attachments, status reports).Recoverable until December 31, 2026. Use the standard SharePoint export tools, then archive into your target document store.

The compounding factor is that institutional knowledge in a Project Online tenant isn't just data — it's the formula logic that took someone six months to refine, the resource pool segmentation that reflects actual reporting hierarchy, the Project Web App custom views that the PMO trained on for years. None of that is in the .mpp export. Without a migration that captures intent, you ship the next year's projects with a worse tool than you had.

The undocumented dependencies that bite

Even teams that run a careful inventory routinely miss the same three classes of undocumented dependency. First: SharePoint workflows configured in SharePoint Designer that fire on PWA list events — these are invisible until they stop firing in production. Second: Excel workbooks with live OData connections that someone in finance built four years ago and now monthly close depends on. Third: third-party integrations someone set up via Zapier or Logic Apps that nobody on the current PMO team installed.

The mitigation is a 30-day shadow period before retirement: write a script that taps the Project Online audit log and records every external system that hits OData, the Project Server SOAP API, or the SharePoint REST API for the PWA site. Anything that shows up in that log is a downstream consumer that needs migration planning. The list is almost always longer than what your team thought existed.

There are five real options for getting off Project Online. The right one depends on your portfolio shape, your appetite for vendor lock-in, and how much of Project Online's PMO depth you actually used.

The Microsoft path has the strongest M365-license argument: if you're already paying for E3/E5, Planner Premium / Project for the Web is bundled or close to it. The trade-off is platform depth — Planner Premium ships fewer scheduling primitives than Project Online had (no proper resource pool, custom fields are limited, no formal portfolio analytics dashboard), and it's still maturing as a PMO tool. For PMOs that did real PMO work in Project Online (multi-project resource leveling, costed timesheets driving billing, formal stage-gate workflows), the depth gap is meaningful.

Onplana sits in the gap: PMO-grade scheduling (full critical path, four dependency types with lag, baselines, custom fields with formulas), native .mpp/MSPDI import that preserves the dependency graph and resource assignments, formal governance workflows (proposal pipeline, stage gates, change control board), and AI overlays for risk detection and what-if analysis. Per-seat pricing starts at $7/seat/month, well below the third-party PPM tier. The honest comparison vs Microsoft Planner Premium is on our Planner comparison page, and the head-to-head with the other dedicated Project Online replacement vendor is on our OnePlan comparison; for the broader landscape see our MS Project alternative page.

For the migration-cost dimension specifically: the seat-cost difference between options can be dwarfed by the migration tooling rebuild (custom field rewrites, dashboard rebuild, training) when you pick a platform that handles imports poorly. Run the migration cost calculator before you assume the cheapest license is the cheapest migration.

Honest gotchas, by path

The trade-off table is the headline; the gotchas are the detail that determines how your migration actually goes. The five most-underestimated risks, one per path:

• Microsoft Planner Premium — the Power BI semantic model is different from Project Online's OData. Existing dashboards don't translate; they get rewritten against the Dataverse data model. Plan a 2–4 week BI rebuild for any team that depended on PMO dashboards.
• Project for the Web — same product as Planner Premium under a different SKU label, with the same depth gaps. The PMO branding can mislead buyers into expecting Project Online parity. It isn't there.
• OnePlan — the other dedicated Project Online replacement vendor. Strong on enterprise PPM features and Microsoft-ecosystem integration, but per-seat pricing and the closed data model differ meaningfully from Onplana's approach. The head-to-head covers the specific differences PMOs care about.
• Onplana — newer to market means smaller third-party ecosystem (fewer consultancies, fewer pre-built connectors). Compensated by direct vendor support and native .mpp/MSPDI import that preserves the dependency graph 1:1, but worth being honest about.
• Smartsheet / Workfront / generic third-party PPM — per-seat pricing looks comparable to Project Online's bundled cost until you add the resource pool module, the portfolio analytics module, and the timesheet module as separate SKUs. Pull the all-in TCO before signing.
• Custom build — sounds cheap when the engineer pitches it ("we just need an Airtable + a Power Automate flow"), expensive over 3 years when you discover you've also built timesheet validation, resource leveling, and audit trails from scratch. Treat this option as "I'm becoming a PM software vendor."

The right path for a given PMO usually shakes out from two questions: (1) how much of Project Online's depth do you actually use day-to-day, and (2) how strategically committed are you to the Microsoft ecosystem? A PMO that lightly used Project Online and is committed to Microsoft can probably live with Planner Premium. A PMO that relied on costed timesheets, multi-project resource leveling, and formal stage gates either needs a peer-class platform like Onplana, or accepts a step-down in capabilities.

Before you start moving data, build a complete picture of your current Project Online tenant. The pre-migration inventory is what separates a clean migration from a three-month surprise tour. Six categories matter:

1. Project inventory. Enumerate every active and recently-closed project, with owner, last-saved date, dependency-graph density, and custom-field usage. The Project Online Inventory Checklist tool walks the 35 items you should capture before retirement.
2. Custom field definitions. Export the full custom field metadata (name, type, default value, formula if any, lookup-table associations). Project Online's custom fields engine is more permissive than most successor platforms; you'll find fields you forgot existed.
3. Resource pool. Export the enterprise resource pool with calendars, standard rates, max-units, and group memberships. Note any resources defined as "generic" (placeholder roles like "Senior Developer") vs named individuals — generics need re-mapping in the target platform. The full resource-model migration playbook (RBS, costed timesheets, capacity views, validation) lives in the dedicated Resource Capacity Planning After Project Online pillar.
4. Integrations. List every system that reads from or writes to Project Online: Power BI dashboards (with the OData query strings), Power Automate flows (with their triggers), custom .NET / SharePoint apps, third-party connectors. Each of these will need to be re-pointed or re-authored.
5. Permissions and roles. Export the security categories, project permissions, and PWA permission groups. Project Online has a fairly elaborate permissions model; not all of it survives migration verbatim, but you need the source of truth before you can reproduce intent.
6. Document libraries and attachments. List the SharePoint document libraries inside the PWA site, with file counts and total size. These need to migrate to your target document store (could be the new platform, could be a separate SharePoint site, could be M365 / OneDrive).

The output of the pre-migration checklist is a single document — call it a Migration Readiness Report — that lists every Project Online artifact, where it currently lives, where it's going, and who's responsible for the move. A team that skips this step is the team that discovers in week 6 that nobody owns the resource-pool migration. Don't be that team.

To get a sense of how clean your migration will be before you commit, run a sample schedule through the Migration Preview tool — upload a representative .mpp and see exactly which custom fields, dependencies, and resource assignments transfer cleanly versus need attention. Pick a representative schedule for the test, not the cleanest one — running the preview against a project that has the messy dependency graph, the formula custom fields, and the historical baseline gives you signal that generalises to the rest of your portfolio.

Run the migration as five sequential phases. Each phase has a clear deliverable and a go/no-go gate before the next phase starts. Skipping the gates is the failure mode that turns 8-week migrations into 16-week migrations.

Phase 1: Inventory & decisions (1–2 weeks)

Complete the pre-migration checklist from the section above, then make three platform decisions: which platform, which projects move, and which resources move. Document each decision with rationale; the rationale matters six weeks later when somebody asks why archived projects from 2019 weren't migrated.

• Run the inventory tool against your tenant
• Pick target platform (use the migration paths section above)
• Decide active vs archive split — recommend last 12 months active
• Identify the 3–5 representative projects you'll use as the migration test bed
• Sign off the Migration Readiness Report with the PMO sponsor

Gate: Migration Readiness Report signed by PMO sponsor and IT leadership.

Phase 2: Test bed migration (2–3 weeks)

Migrate the 3–5 test-bed projects into the target platform. This is where you learn what actually breaks. Don't try to migrate everything yet; resist the temptation to parallelize before you've validated the import quality.

• Set up the target platform tenant and authentication
• Migrate the resource pool
• Import the test-bed projects
• Validate critical path, dependencies, custom fields, baselines
• Re-author one Power BI dashboard against the new API
• Re-author one Power Automate flow against the new triggers

Gate: All 3–5 test-bed projects validate cleanly; one BI dashboard and one flow proven against the new platform.

Phase 3: Bulk migration (2–3 weeks)

Migrate the remaining active and recent-closed projects in waves. Group projects by owner team so each PMO subgroup can validate their own portfolio. Run the import tooling against backup .mpp files exported from Project Online; never run it against live PWA while users are editing.

• Export full backup snapshot from Project Online
• Migrate in 4–6 waves of 10–25 projects each, by team
• After each wave, the receiving team validates within 48 hours
• Roll forward only after validation; defer any "weird" projects for individual review
• Migrate all remaining BI dashboards and Power Automate flows

Gate: All in-scope projects in the target platform; team-level validation signoff.

Phase 4: Parallel operation (2 weeks minimum)

Run both platforms simultaneously for at least two weeks. Project owners update both systems during this window. The goal is to surface differences between source and target in a low-stakes environment — if the new platform's calculated finish date differs from Project Online's, you find out now, not at retirement.

• Project owners maintain both systems
• Daily diff reports comparing key fields (% complete, finish date, resource allocation)
• Investigate every diff > 5%
• Document workarounds for anything the target platform genuinely doesn't support
• Train users on the target platform UI

Gate: Daily diff reports show no unexplained variance for 5 consecutive working days.

Phase 5: Cutover & decommission (1–2 weeks)

Cut over: Project Online becomes read-only, the target platform becomes the source of truth. Then archive Project Online's content while the service is still live. Don't wait for retirement — the SharePoint document library export takes longer than people remember.

• Announce the cutover date 5 business days in advance
• Set Project Online to read-only via PWA permissions
• Switch all user-facing dashboards and reports to the new platform
• Export SharePoint document libraries to your target document store
• Archive timesheet history to your records management system
• Document any open items / known limitations in a post-migration runbook

Gate: Target platform is the documented source of truth; Project Online content archived; runbook published to PMO.

The five failure modes we see most often, with the prevention each one needs:

The pattern across all five: each one is a "we'll figure it out later" decision that looked cheap at the time. The migration cost calculator weights training, dashboard rebuild, and parallel operation explicitly because those are the categories most underestimated in initial migration budgets.

Migration cost has six components. License delta is the most visible but rarely the largest. The order below reflects the typical relative weights for a 100-project PMO migrating from Project Online to a modern alternative:

1. Training (largest non-license cost). 4–8 hours per active user, plus PMO-specific training for the new portfolio analytics surface. For a 200-user PMO, that's 1,000–1,600 person-hours of internal time, or roughly $50K–$120K in fully-loaded labor.
2. Integration rework. Re-pointing or re-authoring Power BI dashboards, Power Automate flows, custom .NET integrations. Highly variable: $20K for a basic shop, $200K+ for a heavily-integrated enterprise.
3. Data migration tooling. Either an automated import tool (typical cost: free to $30K depending on platform) or a custom-scripted migration ($40K–$120K for engineering time).
4. Parallel operation overhead. Project owners maintain both systems for 2 weeks. For 50 active projects, that's roughly 200–400 person-hours of double entry.
5. Cleanup + archival. SharePoint library exports, timesheet archiving to records management, end-of-service decommissioning checklist. 40–80 hours of IT time.
6. License delta. Difference between Project Online seat cost and the target platform's seat cost, multiplied by the seat count, multiplied by the amortization window. Often a wash or net positive when moving from Project Online (which is bundled in expensive E5+Project plans) to a flat per-seat platform.

For a calibrated estimate against your specific situation (org band, project count, dashboard count, integration complexity), the migration cost calculator produces a 3-year range with a sensitivity analysis. The output is in a format designed for inclusion in a CFO business case — six categories, low/middle/high estimates, and the assumptions that drive each.

Worked example: 200-user PMO, 100 active projects

To make the categories concrete, here's a mid-band estimate for a typical mid-market PMO. Numbers are USD, fully-loaded labor at $80/hour internal, $180/hour for external integration consultants. Figures are illustrative, not contractual:

Two takeaways from the worked example. First, license delta is genuinely a net positive when moving off Project Plan 3 to a flat-priced modern platform — the seat savings cover roughly a third of the migration spend over 3 years. Second, training and integration rework dominate; both are heavily underestimated by spreadsheets built on optimistic assumptions, so plan for the upper end and treat any underrun as good news.

After cutover, validate that what shipped actually works. Three checks, each with a specific evidence artifact:

1. Schedule integrity check. Run a critical-path comparison between the last Project Online snapshot and the new platform's view of the same projects. The Schedule Health Check tool surfaces dependency anomalies, baseline variance, and constraint violations across all migrated schedules at once. Evidence: a per-project health report.
2. Resource allocation reconciliation. For the top 25 resources by allocated hours, compare allocation in the source vs target across the next 90 days. Tolerance: ±5%. Larger variance flags either a resource pool mapping issue or a generic-vs-named-resource translation problem.
3. Reporting parity. Pick the three most-used PMO reports (typically: portfolio status, resource utilization heatmap, schedule variance). Reproduce them in the new platform and side-by-side compare against the last Project Online run. Evidence: side-by-side screenshots with calculated diff.

The validation phase should produce a single Migration Outcome Report — what was migrated, what wasn't, what's open. File it with the original Migration Readiness Report; together they're the audit trail of how your PMO handled the retirement.

The questions PMOs ask us most often, with direct answers. The full FAQPage schema is embedded in this article's structured data so these surface in Google's "People Also Ask" feature.