Part one, Project Online retires on 30 September. What happens to your Power BI reports?, covered what the 30 September retirement does to Power BI reporting: the OData endpoint and its time-phased datasets become unavailable with the service, and Planner Premium cannot reproduce them through the standard reporting path because it has no cost model and exposes only a single planned-work field where the fuller time-phased picture would be.
This piece takes the next question: what to move to. It compares the four Microsoft paths in full, then the credible options outside Microsoft, on the dimensions that matter to anyone running resource-loaded, cost-loaded schedules rather than task lists, resource pools, cost models, time-phased data, and how each one reaches a BI layer.
It can be read on its own. If you only want the bottom line, the comparison table below and the decision table at the end will get you there.
A note on what changed recently. Microsoft consolidated Project for the web, the original Planner and To Do into a unified Microsoft Planner around August 2025. What used to be Project Plan 1/3/5 is now Planner Plan 1 and Planner and Project Plan 3/5, and the premium web capabilities, still widely called Planner Premium, now sit in Dataverse rather than SharePoint. Plan 5 reached end of sale on 1 May 2026, so Plan 3 is now the relevant current purchase tier that includes the desktop client, not a formal Microsoft designation, just the practical consequence of Plan 5 no longer being available to new buyers.
The four Microsoft options
Columns run left to right in ascending scheduling capability: task board, web scheduler, desktop scheduler, then desktop plus server.
| Dimension | Planner (Basic) | Planner Premium | Project desktop (.mpp) | Project Online + desktop (retiring) |
|---|---|---|---|---|
| Scheduling engine | None, lists and boards | Auto-schedule, critical path, milestones, Gantt. No manual scheduling mode | Full engine, constraints, calendars, effort-driven, manual and auto | Full engine, constraints, calendars, effort-driven, manual and auto |
| Scheduling modes fixed duration / fixed effort / fixed units, Microsoft's term is "scheduling modes," commonly called task types | No concept of scheduling mode | All three modes exist, but the mode is set once at project level on creation and applies to every task. Cannot vary task by task | Set per task, changeable any time, effort-driven toggled independently | Set per task, changeable any time, effort-driven toggled independently |
| Dependency types and lag | None | All four types with lead and lag, enterable as 3FS+10d. Creating SS, FF and SF needs Plan 3 or 5; Plan 1 can view only. Capped at 20 links per task, 2,000 per project | All four with lead and lag, no practical cap, plus cross-file links | All four with lead and lag, plus server-side cross-project dependencies |
| Multi-level WBS | Buckets and checklists only | Summary tasks and subtasks to a maximum of 10 levels. No WBS codes or outline numbering; hierarchy is visual only | Multi-level outline, commonly documented at 10 levels, plus outline numbering and custom WBS code masks | As desktop, plus consolidation across a master project |
| Calendars | None | Project and resource calendar support via templates, with an override checkbox for which one scheduling follows. Not the full task-calendar and exception model Project desktop has | Base, project, resource and task calendars, with full exception handling | As desktop, plus enterprise calendars shared server-wide |
| Baselines and variance | No | Single baseline, variance side pane | Multiple baselines plus variance | Multiple baselines plus variance |
| Time-phased work and cost | No | No; the underlying model has actual, remaining and total work contours, but the standard Dataverse route into Power BI exposes only a single planned-work field | Task and Resource Usage views give work and cost by period | Full time-phased work, cost and availability |
| Actuals capture | Completed flag and checklist progress. No actual work or cost | Percent complete, and effort split completed vs remaining. No actual cost; there is no cost model. The fuller work history exists in the product's data model but is not confirmed reachable through the standard reporting connector | Actual work, actual cost, actual start and finish, remaining work, percent and physical percent complete, with per-period actuals in Usage views | All desktop actuals plus server rollup, timesheet-fed actuals, and protected actuals |
| Timesheets | No | No native timesheets | None; actuals are keyed in by the scheduler | PWA timesheets with submission and approval |
| Resource management | Assign group members only | Bookable resources, 300 per project and 20 per task. No enterprise pool, no levelling, no cost rates | Local pool, levelling, generic resources. No server-wide pool | Enterprise pool, levelling, capacity, generic resources, engagements |
| Cost, budget, cost resources | No | No cost, rate or budget model in the product | Cost resources, rate tables, budgets | Cost resources, rate tables, budgets |
| Custom fields and formulas | Labels only | 10 per project across 5 types, no formulas, stored as a blob | ~30 fields, formulas, indicators, all local | Enterprise fields, lookup tables, formulas, indicators |
| Master projects, cross-project links | No | No | Local master and subprojects | Server master projects and cross-project dependencies |
| Portfolio rollup | No | Portfolios feature, basic rollup | No, single-file tool | Portfolio analysis and optimiser |
| Reporting and BI access | Graph API, basic plans only | Dataverse connector, TDS, Synapse or Fabric Link, no time-phased or cost data | Save as XML, Visual Reports, Excel, VBA, CData | Native OData feed, Power BI content pack, scheduled refresh |
| MCP connector | No dedicated server. CData publishes a read-only Planner MCP server needing their licensed JDBC driver | Has a first-party remote Dataverse MCP server at /api/mcp, supporting Claude, Copilot Studio and VS Code. Enabled per environment, inherits Dataverse security. Billable since Dec 2025 for agents outside Copilot Studio. Still bounded by the schema gaps above; an agent can't query cost or true time-phased data any more than a human can | No first-party server. A custom one over MPXJ or COM is feasible but DIY | None. Wrapping OData is moot after September |
| Collaboration | Deep Teams, co-authoring, web | Teams, web, co-authoring, Copilot agent | Desktop, co-authoring via SharePoint or OneDrive | PWA web plus desktop, limited co-authoring |
| Offline | No | No | Fully offline | Server no, desktop yes |
| Cost (AUD, excl. GST) | Included in M365 | AU$15.00–AU$44.90 per user per month | Perpetual AU$1,149–AU$2,299, or via Plan 3 | Plan 3 or 5, retiring |
Planner Premium's hard limits
These are documented by Microsoft on its own limits and boundaries page, which is worth reading before accepting any vendor's summary of what the product can do.
| Tasks per project | 3,000 |
| Resources per project | 300 |
| Successor links per project | 2,000 |
| Custom fields per project | 10 |
| Hierarchy levels | 10 |
| Links per task | 20 |
| Resources per task | 20 |
| Project duration | 3,650 days |
| Leaf task duration | 1,250 days |
| Supported dates | 1 Jan 2000 – 31 Dec 2149 |
The 3,000-task ceiling itself is documented on Microsoft's own limits and boundaries page. What happens beyond it is less firmly sourced: FluentPro, a migration tooling vendor, documents that its own migration process skips tasks past the limit without raising an error; I have not found Microsoft's own documentation of that behaviour for a general import. Treat it as a real risk rather than a confirmed silent failure, and count your tasks before you migrate a large program schedule, so you find out on your terms rather than downstream when a number stops reconciling.
Keeping Power BI alive
Four patterns are worth knowing, in descending order of how much they preserve.
Project Server Subscription Edition
Worth a correction here, because an earlier draft of this got it wrong: the OData reporting feed is not retained on Project Server SE. Microsoft removed it. The documented replacement is the pjrep reporting schema in SQL Server, accessed through database snapshots or SQL Server Integration Services rather than a REST connector, so an existing Power BI model built on the old OData feed cannot simply be repointed. It needs rebuilding against the SQL schema instead.
That is more work than a connection change, but it is not a dead end. The pjrep schema is the same reporting warehouse that fed the old OData service; it predates it, in fact, going back to Project Server's earliest reporting architecture, and it is a normal relational SQL Server database with documented views and table-valued functions. Power BI's native SQL Server connector reaches it directly, with scheduled refresh through an on-premises data gateway. The SQL Server Analysis Services cube layer, including a specific time-phased setting, is also confirmed present and configurable in Subscription Edition, so a cube-based reporting model is a second viable route in. What is genuinely gone is the one-step, cloud-friendly access that made this the easy option; what survives is the underlying data and a database-native way to get at it.
Project desktop plus a scheduled extract
Keep scheduling in the desktop client and run a scheduled job that pulls time-phased data into
SQL Server or a Fabric Lakehouse, which Power BI then refreshes from. Two routes work. VBA against
the TimeScaledData method extracts hours by period directly. Alternatively
MPXJ, an open-source library with Java, .NET and Python bindings, reads .mpp files
natively, along with Primavera XER, Asta and MSPDI XML. Neither can run inside the Power BI
Service, so both need a VM, gateway machine or Azure Function to host them. This preserves work
and cost, and needs one database rather than a server farm.
Planner Premium via Dataverse
Cloud to cloud, scheduled refresh, no gateway, and a documented connector, genuinely the easiest to stand up. Fabric Link will sync Dataverse tables to OneLake without ETL if volume justifies it. Suitable for task and assignment reporting, and not for forecasting, for the reasons covered in the companion piece.
Native exports, for completeness
Project desktop can Save As XML, which is machine-readable and includes time-phased data, and Visual Reports will build an OLAP cube into Excel. Both are viable for periodic reporting. Neither schedules itself, which is usually the point.
Replacing the resource pool
The enterprise resource pool has no direct successor. Dataverse bookable resources give a resource list without levelling. Dynamics 365 Project Operations has a full resource and cost model but is an ERP-scale commitment. A maintained resource master in SQL or Dataverse, joined in Power BI, covers reporting but not scheduling. OnePlan, Planview and Tempus Resource all offer purpose-built pools.
Project Server SE: cost and hosting
Microsoft publishes no list price. It sells through Volume Licensing and Enterprise Agreements, so the figures below are reseller rates and third-party estimates rather than official ones.
Licensing is server plus per-user CAL, but the stack underneath drives the cost. Project Server runs as a service application under SharePoint Server Subscription Edition, with Windows Server and SQL Server beneath that. SQL Server Analysis Services matters specifically: it powers the Cube Building Service, which is what produces time-phased reporting.
| Component | Indicative cost |
|---|---|
| Server licence | Several thousand USD one-off (third-party estimate) |
| Hosted CAL | ~$20.95 per user per month (reseller rate) |
| Hosted bundles | $395/mo to 10 users · $645 to 50 · $865 to 75 · $1,095 for 100+ |
| Implementation | $5,000–$20,000 SMB · $50,000+ enterprise |
| SharePoint SE, Windows Server, SQL Server | Additional, not included above |
Per Microsoft Q&A, users who already hold Planner Plan 1, 3 or 5 are covered and do not need a standalone Project Server CAL. Since Plan 3 is the tier that includes the desktop client, schedulers are typically licensed already, leaving CALs to buy only for view-only or approval-only users. On a small PMO this changes the arithmetic considerably. Treat this as a starting point for the conversation, not a procurement authority, confirm it against the current Product Terms and your own licensing agreement before it goes into a budget.
Can it run on a VM?
Yes, and it normally does. "On-premises" describes the licensing and deployment model, software you install and administer, not a physical location. SharePoint Server SE is supported on Hyper-V and any hypervisor in the Server Virtualization Validation Program, and Microsoft supports production farms on Azure VMs, not only dev and test. Licences move across via License Mobility with Software Assurance, or an SPLA through a hosting partner. Azure Australia East and Southeast keep the estate onshore, which matters for government work.
Three constraints to design around. The farm requires Active Directory, so budget for a domain
controller alongside the SharePoint and SQL servers. Dynamic or ballooning memory is unsupported,
and snapshots require shutting down every SharePoint and SQL server in the farm first, with restores
covering all of them; snapshots are not a casual backup mechanism. And hosting in Azure does not
change the reporting architecture: whichever route you take into the pjrep schema or
the Analysis Services cube, the Power BI Service still reaches it through a gateway, which is
another VM to run.
The honest summary is that Project Server SE is infrastructure ownership rather than a licence purchase, and the reporting layer needs rebuilding against SQL Server rather than a URL change, correcting an overstatement in an earlier draft of this page. Against an extract pipeline needing one SQL instance and some code, the two options now sit closer together than they first appear: both end with Power BI reading a SQL Server database, the difference being whether Microsoft maintains that database for you or you build and maintain it yourself. Get a real quote for the farm before ruling it out on cost; it may still be the better trade for an organisation that also wants PWA and timesheets back.
Outside Microsoft
Worth considering seriously where the scheduling requirement justifies a change anyway, and particularly where a real reporting database matters more than ecosystem fit.
This table is a landscape view, not a procurement spec. Primavera P6's and OnePlan's rows have been checked against current vendor and Oracle documentation; the rest is compiled to a lighter standard. Before treating any row as a basis for a purchase, verify the specific Power BI mechanism, refresh behaviour, and Australian hosting terms directly with the vendor.
| Platform | Scheduling | Resource pool | Time-phased cost | Power BI route | Typical fit |
|---|---|---|---|---|---|
| Primavera P6 / Oracle Primavera Cloud | Very deep CPM | Enterprise pool, levelling | Full | SQL reporting DB or P6 REST; third-party ETL to SQL Server is common, as Oracle hosting complicates direct connection | Construction, engineering, government |
| OnePlan | Deep; integrates MS Project | Enterprise resource and financials | Yes | Native Power BI, runs in your own tenant | Microsoft-aligned PMOs |
| Planview | Deep | Capacity planning | Yes | Power BI content pack, daily refresh | Large enterprise PPM |
| Deltek (Open Plan, Cobra, Acumen) | Very deep, EVM | Yes | EVM cost and time-phased | Database or ODBC | Defence, aerospace, government |
| Asta Powerproject | Deep CPM | Yes | Yes | Asta Vision BI, or via partners; MPXJ reads .pp files | Construction |
| Safran Project | Deep, EVM and risk | Yes | Yes | Database or API | Energy, defence, construction |
| Planisware | Deep | Yes | Yes | REST or DB export | R&D, pharma, engineering |
| Clarity PPM | Deep | Yes | Yes | JDBC or data warehouse | Large IT PMOs |
| Tempus Resource | Not a scheduler | Best-in-class forecasting and what-if | Resource-side | REST API | Pairs with an existing scheduler |
| Smartsheet | Moderate | Add-on module | Limited | Native template app | Mid-market, flexible PM |
| Runn / Float / Silverbucket | Light | Capacity and bench forecasting | Rate-based, not CPM cost | REST API | Consultancies and services teams |
For government work, prioritise vendors with Australian data residency and IRAP-assessed hosting, and confirm it contractually rather than from a marketing page. Oracle, Azure Australia regions and the larger PPM vendors all offer AU regions. Where the compliance posture is already settled, OnePlan running in your own tenant and a self-hosted Project Server SE both keep data inside it.
Choosing
| If the priority is | The path | Why, and when to reconsider |
|---|---|---|
| Time-phased forecasting | Project Server SE, a non-Microsoft PPM, or desktop plus a scripted extract | Planner Premium cannot do this. Only revisit if losing time-phased cost is acceptable |
| An enterprise resource pool | Project Server SE, OnePlan, Planview or Tempus Resource | Bookable resources are a list, not a levelling pool |
| Lowest cost | Planner Premium, if Plan 3 is already held | Make the forecasting trade explicitly rather than discovering it later |
| Least change | Project Server Subscription Edition | Keeps PWA, the resource pool and timesheets. Reporting moves from OData to a SQL Server schema, a rebuild, not a reconnection, at the cost of running a farm |
| Microsoft ecosystem plus real BI | OnePlan, or desktop plus a Fabric pipeline | OnePlan is a separate vendor but Microsoft-recommended for this migration |
For most organisations running capital programs in MS Project with a Power BI layer on top, I would start by evaluating the extract pipeline; it keeps the scheduling practice unchanged and needs no server farm. But get a genuine quote for Project Server SE before deciding against it: once the reporting mechanism is corrected, the two options end up architecturally close, and Microsoft maintaining the database for you is worth something against building and maintaining an extract yourself.
Export Project Online data before 30 September. Microsoft has not documented a post-retirement recovery window for the scheduling database, resource pool, rates and time-phased history, and its retirement guidance points to partner migration solutions rather than a first-party migration utility. Whatever you choose, the backup is the part that cannot wait.
On sources
Much of the readily available migration commentary comes from vendors offering migration or consulting services, and their accounts of the successor product are not reliably accurate in either direction. One widely-cited post states that Planner Premium supports finish-to-start dependencies only, with no lag. Microsoft's own Project blog documents all four dependency types with lead and lag, subject to Plan 3 or 5 for the advanced ones.
A more consequential correction: an earlier draft of this page and its companion piece stated
that Project Server Subscription Edition keeps the OData reporting feed. It does not; Microsoft
removed it, and the supported route is the pjrep SQL Server schema rather than a
connector reconnection. That changes the effort involved without changing the conclusion that
Project Server SE remains one of the stronger ways to keep time-phased reporting alive; the
comparison and the decision framework above reflect the correction.
Where this page states a limit, it comes from Microsoft's published limits and boundaries page or its support documentation. Where it states a price, it is a reseller rate or estimate and is flagged as such. Verify before committing, including verifying this page.
Weighing the options?
If you are working through this for a capital program and want a second opinion on where it lands, including the possibility that the simplest option is the right one, I'm happy to talk it through. No pitch required.
Get in touch