---
title: "Project Online Retires Sept 2026: 3 Migration Paths Compared"
slug: project-online-retires-sept-2026-3-migration-paths-compared
date: 2026-05-21
author: Raaj
categories: [General]
excerpt: "Project Online retires Sept 30, 2026. Compare Project Server SE, Planner Premium, and third-party PPMs — with real technical trade-offs for enterprise PMOs."
tldr: "Project Online dies September 30, 2026 — but SharePoint workflows break in April. No one-click migration exists. Compare three paths by custom fields, resources, and long-term viability."
canonical: https://clonepartner.com/blog/project-online-retires-sept-2026-3-migration-paths-compared/
---
# Project Online Retires Sept 2026: 3 Migration Paths Compared
**Microsoft Project Online shuts down permanently on September 30, 2026.** After that date, your projects, baselines, resource pools, custom fields, and every Power BI report tied to the PWA OData feed become inaccessible. No read-only mode. No grace period. No recovery.
The real pain starts earlier. SharePoint 2013 workflows — the engine behind Project Online's stage-gate governance, demand management, and approval routing — die on **April 2, 2026**. If your PMO relies on workflow-driven project types, those processes break six months before the platform goes dark.
This is not a simple platform swap. Migrating enterprise project data — baselines, cross-project dependencies, shared resource pools, and connected SharePoint document libraries — is a complex relational data problem. Microsoft's native export tools strip out critical enterprise metadata, and there is no one-click migration path that preserves the full Project Online data model.
There are three real migration paths: Project Server Subscription Edition, Planner Premium with Power Platform, or a third-party PPM. Each fits a different org profile. None is a one-click swap. This guide compares all three on the dimensions that actually matter to enterprise PMOs: custom fields, lookup tables, resource pools, integrations, and long-term viability.
For a deeper dive on the retirement timeline, risks, and what breaks first, see our companion piece: [Microsoft Project Online Retiring Sept 2026: Timeline, Risks & Migration](https://clonepartner.com/blog/blog/microsoft-project-online-retiring-sept-2026-timeline-risks-migration/).
## The September 2026 Deadline: What Project Online End of Life Actually Means
**"End of life" for Project Online means total data loss, not degraded service.** Microsoft's language is unambiguous. This is not a case where the servers keep running but support ends. The service retirement means you lose access to the application and the data stored inside it. If your migration plan assumes a long read-only period after September 2026, that assumption is not in Microsoft's published guidance.
Here is the phased shutdown timeline:
| Date | What Happens |
|---|---|
| **October 1, 2025** | End of sale for Project Online-only SKUs to new customers |
| **April 1, 2026** | Existing customers can no longer create new PWA site collections or tenants |
| **April 2, 2026** | SharePoint 2013 workflows fully retired — stage-gate automation, EPT workflows, and approval routing stop working |
| **September 30, 2026** | Project Online is permanently retired — all data inaccessible |
After Project Online is retired in September 2026, you will no longer be able to access your projects or any associated data within the service. To avoid disruption and potential data loss, it is essential that you back up your data/projects and complete your transition to either Planner or Project Server Subscription Edition before the retirement date.
The April 1 date catches many teams off guard. Starting that day, Microsoft blocks creation of new PWA site collections and locks out tenants that don't contain at least one project. If you're planning to spin up test environments for migration validation, do it before this date.
This update is exclusive to Project Online and does not affect Project desktop, Project Server, or Planner. Project Online has served organizations well, but its legacy architecture limits innovation and integration that enhance today's collaborative work environments. With certain SharePoint Online workflow design tools deprecating in 2026, Microsoft is prioritizing innovation within Planner, Microsoft 365 Copilot, and the Project Manager agent.
Project Online's backend relies heavily on the SharePoint 2013 workflow engine to drive demand management, stage-gate approvals, and portfolio governance. The related retirements of SharePoint Add-ins and SharePoint 2013 workflows compound the risk. If your PMO also relies on custom SharePoint solutions built against Project Online's PWA sites, those are on the same timeline. See our [SharePoint Add-ins Retirement guide](https://clonepartner.com/blog/blog/sharepoint-add-ins-retirement-the-april-2026-migration-guide/) for the full picture.
> [!CAUTION]
> **Do not wait for a Microsoft-native migration tool.** Microsoft has provided successor products and a retirement date, but there is no automated, one-click migration path that preserves the full Project Online data model — custom fields, lookup tables, workflows, and resource pools.
## Path 1: Project Server Subscription Edition (The Lift-and-Shift Illusion)
**Project Server Subscription Edition (PSSE)** is the closest like-for-like replacement for Project Online. It preserves the Project Web App (PWA) interface, supports Project Professional Desktop, and offers enterprise-grade scheduling, resource management, and portfolio analysis.
### Why teams choose this path
- Project Server Subscription Edition is designed for organizations needing advanced project and portfolio management (PPM) or a close match to the feature set of Project Online. It provides comprehensive planning, scheduling, and resource management tools, built on the latest SharePoint Server technology.
- Project Server Subscription Edition provides significant deployment flexibility. Organizations can choose a traditional on-premises deployment for maximum direct control over their infrastructure. Azure-hosted VMs and hybrid configurations are also supported.
- Microsoft has set an Earliest Possible End of Support (EoS) Date of December 31, 2031. This means the product will be supported at least through that date, and any official end-of-support timeline will be announced later under Microsoft's lifecycle guidelines. Support may extend beyond 2031, but it will not end before then.
### Where the lift-and-shift breaks down
The label "lift and shift" is misleading. There is no direct Microsoft migration path from Project Online to SE. Manual rebuild of workflows, custom fields, resource pools, and enterprise configurations is required.
Microsoft's supported **upgrade** path to Project Server SE is from Project Server 2016 or 2019 databases into a new SharePoint Server SE farm. For Project Online customers, Microsoft does **not** provide a migration tool and recommends working with a qualified partner. That means you are building a new destination and migrating data and configuration into it, not converting a cloud tenant. ([learn.microsoft.com](https://learn.microsoft.com/en-us/project/plan-upgrade-project-server-subscription-edition?utm_source=openai))
Specific limitations when migrating via API-based tools (like FluentPro FluentBooks, the most widely used tool for this path):
- Migration of workflows and solutions developed in Visual Studio is not supported. All stage-gate and governance workflows must be rebuilt.
- Data is downloaded via API from a Source PWA and uploaded to a Destination PWA via API. During data upload, system read-only fields like Created, Last Published, and Last Modified are set to the date of migration and will not be the same as in the Source PWA.
- By default, Resource GUIDs are not preserved. This breaks any downstream reporting that joins on resource identifiers unless you explicitly configure GUID preservation.
- Your Project Online app admin will need to configure the Project Server SE application to match the configuration of the Project Online application, including configuring items such as enterprise custom fields, enterprise calendars, enterprise views, and the Enterprise Resource Pool. Then someone from your organization will need to manually migrate every project.
There is also a critical reporting change: Microsoft removed the **OData reporting service** in Project Server Subscription Edition. If your current PMO reporting stack pulls from the Project Online `/_api/ProjectData` endpoint into Power BI, Excel, or middleware, a move to Project Server SE is already a reporting redesign — not a no-op. ([learn.microsoft.com](https://learn.microsoft.com/en-us/project/project-server-subscription-edition-architecture))
### Who this path fits
Organizations with heavy investments in Project Professional Desktop, complex Enterprise Project Types (EPTs), deep custom field hierarchies, and regulatory requirements around data sovereignty. PSSE gives you 5+ years of runway, but it is not a permanent destination — plan for another migration eventually.
**Bad fit:** teams expecting a cloud-managed future or assuming existing OData-based reporting will carry over unchanged.
> [!WARNING]
> **Infrastructure cost is real.** PSSE requires SharePoint Server Subscription Edition, a dedicated SQL Server, and in-house DBAs. Budget for Azure VM hosting if you don't want to maintain physical servers.
## Path 2: Planner Premium & Power Platform (The Cloud-Native Microsoft Path)
**Planner Premium** (formerly Project for the Web) is Microsoft's recommended successor. It is built on Dataverse, integrates with Microsoft Teams, and supports Copilot. Planner premium plans reside within the Microsoft Power Platform, making them extensible with model-driven Power Apps, automations with Power Automate, and Power BI reporting connecting to the backend Dataverse database platform, which is much faster than the OData-based reporting in Project Online.
For organizations that used Project Online for basic scheduling and team-level task management, Planner Premium is a reasonable fit. For enterprise PMOs with governance workflows, it is a significant downscope.
### The feature gaps that matter
| Capability | Project Online | Planner Premium (Native) |
|---|---|---|
| Custom fields per project | Hundreds of enterprise custom fields | **10 per project** |
| Task limit per project | Thousands | **3,000** |
| Enterprise Resource Pool | Cross-project, centralized | Per-project only |
| Stage-gate governance | Native via EPT workflows | Must be rebuilt in Power Automate |
| Timesheets | Built-in (clunky but functional) | **None natively** |
| Portfolio-level resource heatmap | Native | **Not available** |
| Baselines (graphical) | Full support | Limited — no graphical representation |
| Master/subproject hierarchy | Supported | **Not supported** |
Only 10 task custom fields can be created per project in Planner Premium due to the Planner Premium limitation. For a PMO running 30+ enterprise custom fields — common in construction, pharma, and government — this is a non-starter without building a custom Dataverse layer.
In Project Online, you could look across 50 projects and know exactly who was over-allocated. In the standard Microsoft Planner Premium, resource management is largely confined to the individual project level. You can see a "People View" for one project, but seeing a Global Heatmap of your entire workforce's capacity is a significant challenge.
Microsoft Planner Premium does not contain a central project time tracking system. By default, it is only possible to manually set the Effort completed field in each task. However, this only reflects the total actual effort and no daily posting is possible.
There is a critical reporting limitation: Local custom fields are stored in a binary format within Project tables in Dataverse. These fields aren't available for reporting. If your PMO depends on slicing Power BI dashboards by custom field values, this changes your reporting architecture.
Microsoft has also replaced **Roadmaps** with **Portfolios** in Planner, and the new Portfolios feature does **not** connect to Azure DevOps or Project Online projects. Importing `.mpp` files is not available in the standard Planner experience; that import can only be done through the Planner Power App. If your executives depend on cross-tool roadmap views or you expected a simple desktop-to-web import, check those assumptions early. ([support.microsoft.com](https://support.microsoft.com/en-us/office/frequently-asked-questions-about-microsoft-planner-d1a2d4e6-a4d7-408c-a48a-31caaa267de5))
### The migration itself is painful
You can manually import a Microsoft Project plan as an .mpp file via the Planner Power App. Up to 10 custom fields can be imported. Resources are removed because local names in the .mpp file cannot be automatically mapped to Entra ID user accounts. Historical baselines are often not transferred. Formulas and graphical indicators from MS Project are not migrated. As a result, migrating from MS Project to Planner Premium involves data loss.
Each plan must be migrated one by one. For a PMO with hundreds of active projects, this is weeks of manual labor — or custom scripting against the Dataverse API, which has its own service protection limits.
Microsoft does recommend a **side-by-side transition** for many customers: finish existing work in Project Online while starting new work in Planner as it meets your needs. For many PMOs, that is the least disruptive Microsoft path — new demand goes to Planner, old schedules close out in Project Online, and only the active or strategically important portfolio moves. ([support.microsoft.com](https://support.microsoft.com/en-us/project/project-for-the-web-and-project-online))
### Who this path fits
Smaller PMOs (under 50 active projects) with limited custom field usage, no timesheet requirements, and teams already embedded in Microsoft Teams. You will also need Power Platform licenses and likely a partner-built accelerator to replace PWA governance.
**Bad fit:** PMOs that need full PWA parity, very large schedules, or dozens of enterprise custom fields per project.
> [!NOTE]
> Do not budget Planner Premium as just another Microsoft license. The technical migration often includes Dataverse environment design, security role mapping, Power Automate rebuilds, Power Apps customization, and report rewiring. Architecture work belongs in the estimate from day one.
## Path 3: Third-Party Enterprise PPMs (Smartsheet, Planview, Asana)
Leaving the Microsoft PPM ecosystem entirely is a legitimate option — especially for organizations whose needs outgrew Project Online years ago.
### Smartsheet
Highly flexible, spreadsheet-like interface that appeals to PMOs wanting to own their process design. Smartsheet positions its portfolio layer around standardizing execution from intake to delivery, with Control Center, governance, automated blueprints, and portfolio reporting. ([smartsheet.com](https://www.smartsheet.com/platform/portfolio-management))
But you are **rebuilding from scratch** — there is no import path that preserves Project Online's enterprise custom field structure, lookup tables, or resource pool logic. Smartsheet also has its own row limits (20,000 per sheet) and cell-link limits (100,000 inbound per sheet) that can surprise large portfolios.
### Planview
Purpose-built for enterprise portfolio management, strategic alignment, and value stream delivery. Mature PMOs in financial services, pharma, and government often land here. Planview positions itself around enterprise-wide strategic portfolio management: business and technology planning, capacity balancing, investment prioritization, dependencies, risks, and executive decision support. ([planview.com](https://www.planview.com/products-solutions/solutions/strategic-portfolio-management/))
But Planview's implementation cycle is measured in months, its learning curve is steep, and migration complexity is high because you are mapping a SharePoint-based data model to a fundamentally different proprietary architecture.
### Asana / Monday.com
Better suited for team-level work management than enterprise PPM. They offer strong UX and fast adoption, but lack native resource capacity planning, earned value management, and the kind of portfolio governance that enterprise PMOs require. Consider these for a subset of your portfolio, not the whole thing.
### The common thread across all third-party paths
Every third-party migration is a **data extraction and re-architecture project**. You are not moving data between compatible schemas. You are extracting relational data from a SharePoint-based system — custom fields referenced by internal GUIDs, lookup tables, resource pools — and mapping it into a completely different data model.
Project Online structures data relationally. A single project might have thousands of tasks, each assigned to resources from a centralized Enterprise Resource Pool, governed by multiple enterprise custom fields linked to hierarchical lookup tables. Target systems like Smartsheet treat data more like interconnected spreadsheets. Planview has its own rigid data model. The custom fields, lookup table hierarchies, and cross-project dependencies do not transfer — they must be re-engineered, typically through custom API middleware.
### Who this path fits
Organizations that have already outgrown Project Online's capabilities and want a modern UX with native strategic portfolio management. Be prepared for a 3–6 month implementation cycle and significant change management.
## The Migration Audit: What to Inventory Before You Pick a Path
Before you decide on a path, you need a full inventory of what you actually have. Most organizations underestimate their Project Online footprint. The fastest way to overspend is to migrate every project and every field just because it exists.
### What to catalog
- **Active projects vs. archived projects.** How many are genuinely in-flight? How many are historical but still referenced in reports? Archive aggressively — every project you carry forward increases migration complexity.
- **Enterprise Custom Fields.** Count them. Document their types (text, cost, date, flag, lookup). Identify which are used in formulas or graphical indicators. Capture internal names or GUIDs — report and integration bindings depend on these. Custom fields and lookup tables are often dozens, often interconnected.
- **Lookup Tables.** Map every lookup table, its values, and which custom fields reference it. Multi-level hierarchies (e.g., Department > Region > Cost Center) must be rebuilt exactly in the target — or your data becomes meaningless.
- **Enterprise Resource Pool.** Document resources, generic resources, cost rate tables, calendars, and the RBS (Resource Breakdown Structure) hierarchy. Large PMOs use a shared Enterprise Resource Pool to manage capacity across hundreds of projects. Migrating projects one by one duplicates resources. The target system must be seeded with the resource pool first, and then every task assignment must be mapped to the new resource ID during the migration payload.
- **Workflows and EPTs.** Which Enterprise Project Types use governance workflows? Which stage-gate configurations are active? These cannot be migrated to any target — they must be rebuilt.
- **Power BI reports and OData connections.** Reports do not migrate themselves. Power BI reports that read from the Project Online OData feed will break the day the tenant goes dark. Rebuild them against the target platform's API early, not late.
- **Connected SharePoint Sites.** Every project in Project Online provisions an associated SharePoint Workspace for document management, risks, and issues. Moving the project schedule is only half the job; you must also migrate the linked document libraries and remap the URLs in the new PPM system.
- **Integrations.** Anything that talked to Project Online over CSOM or REST will need to be repointed or rewritten. Allocate developer hours.
- **Timesheet history.** If you track time in Project Online, decide now: does historical timesheet data migrate, get archived to a data warehouse, or get discarded?
A simple inventory file is usually enough to expose the hard work early:
```csv
object_type,object_name,scope,internal_name_or_guid,used_by,target_decision,owner
CustomField,CostCenter,Project,Custom_xxxxx,Power BI Portfolio Dashboard,Rebuild exactly,PMO Ops
LookupTable,ProjectType,Enterprise,LT_xxxxx,Intake workflow,Simplify,PMO Ops
Workflow,Capital Intake,Portfolio,StageGate_v3,Approvals + emails,Rebuild in Power Automate,PMO + IT
Integration,ERP Sync,Project,svc-project-sync,Finance actuals,Replace,IT Integration
```
### The GUID problem
This is the technical issue that blindsides most teams. Every enterprise custom field, lookup table value, and resource in Project Online has an internal GUID. When you recreate these objects in a new PWA instance or a different platform, they get **new GUIDs**. Every Power BI report, Power Automate flow, or custom integration that references the old GUIDs breaks silently — columns mismatch, filters return empty, dashboards show blanks instead of data.
The GUID for an object that already exists in the Destination PWA cannot be updated. Project Server and Project Online do not allow duplicates — Projects, Custom Fields, and Resources with identical Names or GUIDs. FluentBooks ensures data integrity by matching by Name or GUID.
This means your Power BI rebuild is not optional. It is a required workstream with its own timeline.
### Cleanup as a migration forcing function
Migrations are the best opportunity to shed years of accumulated cruft:
- **Archive completed projects** — don't migrate what you don't need
- **Retire unused custom fields** — most orgs use 30% of what they've created
- **Consolidate lookup table values** — merge duplicates before migration
- **Document undocumented workflows** — if nobody knows what a workflow does, it probably doesn't need to exist in the target
If you are moving to Planner or a third-party PPM, simplify the model before you translate it. If you are moving to Project Server SE, use cleanup to reduce the volume of manual recreation work.
### Authentication and identity
PSSE requires **modern authentication** and integrates with **Microsoft Entra ID** (formerly Azure AD). Modern Authentication is mandatory for tighter security. Native Compatibility with Microsoft Entra ID. SharePoint Server Subscription Edition supports OIDC with Microsoft Entra ID, but that is an architecture decision you must configure in the destination farm.
For Planner Premium, identity is handled through Microsoft 365's standard Entra ID integration — but resource assignments in migrated plans require that .mpp resource names map to actual Entra ID accounts, which rarely happens automatically.
Do not treat auth as a post-cutover task. It affects service accounts, guest access, automation, and every validation script you plan to run.
For more context on how legacy SharePoint dependencies complicate these moves, review our [SharePoint Add-ins Retirement: The April 2026 Migration Guide](https://clonepartner.com/blog/blog/sharepoint-add-ins-retirement-the-april-2026-migration-guide/).
## Why DIY Project Online Migrations Fail at Scale
The most common approach: export .mpp files from Project Online, import them one by one into the target platform, and manually recreate the PWA configuration.
This works for 10 projects. It falls apart at 100. Here's why:
- **Manual .mpp exports lose relational data.** Cross-project dependencies, shared resource pool references, and enterprise custom field values tied to lookup tables do not survive a round-trip through .mpp files.
- **One-by-one imports don't scale.** Each import requires manual field mapping, resource reassignment, and validation. At 100+ projects, you are looking at weeks of repetitive manual work with high error rates.
- **Custom field structures must exist in the target before import.** If you import an .mpp file before the target environment's custom fields and lookup tables are configured, values either get dropped or mapped incorrectly.
- **No delta sync.** Projects keep changing while you migrate. Without a mechanism for incremental updates, you face a growing gap between source and target that widens every day.
- **API throttling.** Basic API scripts hit throttling limits when trying to extract time-phased baseline data across thousands of tasks. Project Online's API does not easily expose the underlying logic of Enterprise Global templates.
Microsoft's own manual migration guidance is telling: save project plans to `.mpp`, reopen them, publish them, and manually recreate needed PWA configuration such as custom fields or enterprise calendars. That is manageable for a small, standard environment. It is not a serious enterprise strategy when you have hundreds of active schedules, custom workflows, project sites, executive reports, and integrations. ([learn.microsoft.com](https://learn.microsoft.com/en-us/projectonline/migrate-to-project-online-from-project-server?utm_source=openai))
For more on why scripted and AI-assisted migration approaches fail on complex relational data, see [The Data Migration Risk Model: Why DIY AI Scripts Fail](https://clonepartner.com/blog/blog/why-ai-migration-scripts-fail/).
> [!NOTE]
> **Typical enterprise migration timeline:** Depending on complexity, migrations typically take 3–6 months, including discovery, configuration, migration and testing. Start now. Not next quarter.
## Executing a Zero-Downtime PPM Migration
The organizations that get this right treat the Project Online retirement as a **data migration project**, not a platform swap. That means:
1. **Extract via API, not .mpp exports.** API extraction preserves the relational structure — subtask hierarchies, dependency chains, resource assignments, custom field values, and their GUID references.
2. **Rebuild the target PWA configuration first.** Enterprise custom fields, lookup tables, enterprise calendars, views, and EPTs must exist in the target before any project data moves.
3. **Migrate in waves.** Start with a pilot batch. Validate data integrity. Fix mapping issues. Then scale.
4. **Run parallel environments.** Keep Project Online operational while validating the target. Do not decommission Project Online access until you've confirmed data integrity in the target. Migrate in controlled waves, keep the final delta window small, and finish extraction before September 30, 2026.
5. **Rebuild Power BI reports against the new data source.** This is a separate workstream that should start the moment your target environment's custom field schema is finalized.
At ClonePartner, we treat PPM migrations as a data engineering discipline. We extract the full relational model from Project Online's legacy architecture and map it directly into Dataverse, Project Server SE, or your chosen third-party PPM. The custom fields, lookup tables, and cross-project dependency mapping is where most internal teams hit the wall — and it's where our engineering team spends the most time ensuring nothing gets lost.
Read more about our parallel execution methodology in [Zero Downtime Guaranteed: Why You Won't Have to 'Pause' Your Business](https://clonepartner.com/blog/blog/zero-downtime-data-migration/).
## Picking the Right Path: Decision Matrix
| Factor | Project Server SE | Planner Premium + Power Platform | Third-Party PPM |
|---|---|---|---|
| **Best for** | Heavy PWA users, regulated industries | Smaller PMOs, Teams-first orgs | Orgs that outgrew Project Online |
| **Custom field support** | Full (enterprise custom fields) | 10 per project | Varies (typically unlimited) |
| **Migration complexity** | High (manual config rebuild) | High (feature gaps + data loss) | Very high (schema re-architecture) |
| **Infrastructure** | Self-managed (on-prem or Azure VMs) | Microsoft-managed (Dataverse) | Vendor-managed (SaaS) |
| **OData reporting** | **Removed** — must redesign reporting | Dataverse-backed (faster) | Platform-specific |
| **Long-term viability** | Supported through at least 2031 | Active Microsoft investment | Depends on vendor |
| **Timeline to production** | 3–6 months | 2–4 months (with accelerator) | 4–8 months |
| **Total cost of ownership** | Moderate (infra + licensing) | Lower (but Power Platform add-ons) | Higher (new vendor licensing) |
## What to Do This Month
1. **Inventory your Project Online environment.** Count active projects, custom fields, lookup tables, workflows, and integrations.
2. **Identify your April 2026 exposure.** If you rely on SharePoint 2013 workflows for governance, those break first — before the platform itself retires.
3. **Spin up test environments now** — before the April 1, 2026 lockout on new PWA site creation.
4. **Pick your path.** Use the decision matrix above. If you're unsure, start with a paid discovery engagement — not a vendor demo.
5. **Start extraction before summer 2026.** The final delta window should be days, not weeks.
"Most organizations underestimate how long modernization takes. Highly customized Project Online environments can take months to assess, plan, and transition. The biggest risk today is waiting, because early planning gives organizations control instead of chaos."
> Facing the Project Online retirement? Our engineers specialize in complex PPM data migrations — custom fields, lookup tables, resource pools, and the Power BI rewiring that comes with them. Book a free 30-minute technical call to scope your migration.
>
> [Talk to us](https://cal.com/clonepartner/meet?duration=30)
## Frequently asked questions
### When does Microsoft Project Online officially retire?
Project Online officially retires on September 30, 2026. After that date, all projects and data become permanently inaccessible — no grace period, no read-only mode. Sales to new customers ended October 1, 2025, and existing customers can't create new tenants after April 1, 2026.
### What is the best replacement for Project Online for enterprise PMOs?
It depends on your org profile. Project Server Subscription Edition is the closest like-for-like replacement (supported through at least 2031) but puts you back on self-managed infrastructure. Planner Premium is Microsoft's recommended cloud-native path but caps custom fields at 10 per project and lacks native timesheets and portfolio governance. Third-party PPMs like Planview or Smartsheet work for orgs that have outgrown Project Online and are willing to redesign their PPM processes.
### Can I migrate Project Online custom fields and lookup tables automatically?
Not fully. Tools like FluentPro FluentBooks can automate parts of the migration, but workflows, Visual Studio solutions, and certain SharePoint entities cannot be migrated programmatically. Custom fields can be transferred, but GUID mismatches between source and target environments will break existing Power BI reports — those must be rebuilt.
### Does Planner Premium support enterprise custom fields like Project Online?
No. Planner Premium supports a maximum of 10 custom fields per project, compared to hundreds of enterprise custom fields in Project Online. Local custom fields in Planner Premium are stored in a binary format within Dataverse and are not available for reporting. Enterprise PMOs with complex custom field structures will need Power Platform extensions or a different target.
### How long does a Project Online migration typically take?
Enterprise Project Online migrations typically take 3–6 months including discovery, configuration rebuild, data migration, testing, and cutover. Organizations with hundreds of active projects, complex custom fields, and Power BI integrations should start planning immediately to avoid a compressed timeline.