Microsoft has confirmed that Project Online (POL) will retire on 30 September 2026. Organisations running portfolio-grade schedules, baselines and resource plans in POL must now choose a replacement that preserves (and improves) delivery maturity, well before the deadline.

Microsoft’s strategic direction consolidates Project for the web into the new Planner experience with Teams and optional Power Platform extensions. This is effective for task and team work, but it typically lacks the enterprise-level scheduling depth and portfolio controls that many POL environments depend on, unless you undertake significant custom build.

Bottom line: If you rely on POL-level scheduling maturity, governance and portfolio analytics, moving to a dedicated PPM platform is the most direct, lowest-risk path.

Why a dedicated PPM platform protects you from vendor “direction changes”

Microsoft remains committed to project and work management within its collaboration ecosystem. However, broad productivity suites understandably evolve their priorities over time. Selecting a specialist, dedicated PPM platform keeps your roadmap anchored to PMO outcomes - rather than to the shifting emphasis of a generic toolset. In short: you won’t need to worry about a generalist provider changing direction on your product because the platform is purpose-built for PPM.

Why choose Fluid as your POL successor

Fluid is an all-in-one PPM platform that unifies scheduling, portfolio governance, resource and financial management, and reporting, removing the need to stitch together multiple products.

• Planning & scheduling with dependencies, milestones and portfolio-level visibility.
• Portfolio & pipeline for intake, prioritisation and governance in one system of record.
• Resource & financial management covering capacity, timesheets, rate cards, forecasting and variance.
• Reporting & analytics with real-time dashboards, RAG status and drill-downs across schedule, cost, resources and risk.
• Collaboration at the core including meeting and action tracking, kanban and stakeholder governance, so data isn’t fragmented across tools.

Hybrid delivery needs connected reporting-out of the box

Modern delivery is hybrid by default: governed projects with formal schedules run alongside agile teams working in Jira and Azure DevOps. Senior stakeholders need one version of the truth without forcing teams to change their tools.

Fluid provides out-of-the-box (OOTB) integrations with Jira and Azure DevOps at no extra cost so you can connect agile boards to portfolio schedules, instantly.

What this enables:

• Two-way synchronisation of key items (e.g., epics/features ↔ programme work packages; stories/tasks ↔ schedule activities).
• Automated status roll-ups from agile tools into portfolio dashboards - progress, blockers, risks, and target dates.
• Connected financials and capacity -align actuals and timesheets with sprints/iterations and forecast impacts on the master schedule.
• Unified reporting - portfolio, programme and project views that surface delivery health across both plan-driven and agile teams.
• Governance without friction - teams remain in Jira/Azure DevOps; PMOs retain critical path, dependencies and baselines in Fluid.

Result: hybrid delivery clarity. Your executives see complete, connected performance; your teams keep the tools they love.

The fastest safe path: a 3 month migration plan (POL → Fluid)

A focused programme for a typical mid-sized portfolio completes in 3–6 months. Heavily customised or multi-product routes (for example, broad Power Platform builds plus governance layers) frequently drift toward ~12 months, risking proximity to the 30 September 2026 deadline.

Phase 0 : Mobilise (Weeks 0–2)

• Inventory POL usage (projects, templates, custom fields, reports, integrations, resource pools).
• Define the target operating model in Fluid (roles, governance, workflows) and the data-retention approach.
• Confirm the tooling landscape for hybrid delivery (Jira, Azure DevOps, BI).
• Secure budget and sponsorship; issue the programme charter.
  Gate: Steering Committee approval.

Phase 1 : Design & Data Mapping (Weeks 2–4)

• Map POL constructs (schedules, resources, costs, baselines) to Fluid configuration.
• Define migration scope (active vs archive) and rationalise templates.
• Integration design: connect Jira/Azure DevOps to Fluid and define sync rules (objects, fields, cadence).
• Plan reporting and BI alignment for connected portfolio views.
  Gate: Design sign-off; pilot communications to the PM community.

Phase 2 : Pilot (Weeks 4–6)

• Configure Fluid; migrate 5–10 representative projects.
• Establish Jira/Azure DevOps connectors and validate two-way updates on a sample backlog/schedule.
• Validate schedules, resource plans, cost data and dashboards; refine workflows and templates.
• Deliver targeted training and operate a feedback loop.
  Gate: Pilot acceptance; readiness update.

Phase 3 : Wave Migration & Parallel Run (Weeks 6–10)

• Migrate remaining active projects in waves (by business unit, geography or project type).
• Set POL to read-only during waves and maintain fall-back.
• Expand Jira/ADO connections to all in-scope teams; stabilise integrated reports.
• Provide role-based training; stabilise integrations and BI.
  Gate: Wave go/no-go and cut-over communications.

Phase 4 : Decommission & Optimise (Weeks 10–12)

• Archive historical POL data; retire licences and legacy workflows.
• Conduct a post-implementation review; optimise dashboards, governance and performance.
• Track benefits (reporting cycle time, schedule adherence, resource utilisation).
  Gate: Final decommission approval; executive close-out.

Communications plan (what to say and when)

• Kick-off (T-24 weeks): Announce the POL retirement programme and the move to Fluid; set expectations, training windows and how hybrid integrations will work.
• Pilot start: Explain what’s changing, where to get help and how to provide feedback; showcase the connected Jira/ADO → Fluid reporting.
• Each migration wave: Issue go-live notices, confirm POL read-only status, and explain how to access historical data.
• Close-out: Confirm POL is decommissioned; reiterate support channels, archive access and integrated reporting locations.

Frequently asked questions

What is the Project Online retirement date?
30 September 2026. Plan to complete migration and stabilisation well in advance.

Is Microsoft stepping away from project and portfolio management?
No. Microsoft remains committed to project and work management within Microsoft 365. The focus, however, is on collaboration and task-centric work (Planner, Teams, Power Platform) rather than deep, specialist PPM functionality.

Why choose a dedicated PPM platform instead of building on Power Platform and Planner?
Dedicated PPM gives you enterprise scheduling, governance, resource/cost controls and portfolio analytics out of the box - without lengthy custom development. It also insulates you from product-direction changes in generic toolsets.

Can’t we re-create POL with Power Apps?
You can, but it often becomes a significant opex cost with the build - covering environments, governance, performance, BI, lifecycle and support. For many PMOs, this leads to longer timelines (often around 12 months) compared with a 3–6-month transition to a specialist platform.

How does Fluid integrate with Jira and Azure DevOps?
Fluid includes out-of-the-box connectors to both Jira and Azure DevOps at no extra cost. You can synchronise epics/features and stories/tasks with programme and project schedules, roll up status automatically, and surface unified reporting across portfolios.

What reporting do executives get in a hybrid environment?
Connected dashboards combine schedule milestones and dependencies with agile delivery data (iterations, velocity, burn-down, blockers). Leaders see consistent RAG, forecast and benefit views across all work types.

What migration duration should we plan for?
For a mid-sized portfolio with standard complexity, plan for 3–6 months. Highly customised, multi-product approaches commonly extend towards 12 months, which can push close to the retirement date.

How do we protect scheduling maturity when leaving POL?
Select a platform that supports critical path, robust dependencies, baselining, resource capacity management and portfolio-level governance natively. Validate these during the pilot phase before full cut-over.

What should our first steps be?

1. Run a two-week assessment to inventory POL usage and define the target operating model.
2. Approve the migration plan and pilot scope (including Jira/ADO integration).
3. Execute wave migration with a short parallel-run period, then decommission POL.

Next steps

• Book a short discovery to baseline your POL estate and confirm a 3–6-month plan.
• Run a targeted pilot (5–10 projects) to validate schedules, resources, reporting and Jira/ADO synchronisation.
• Execute wave migration with structured communications and measurable benefits.

‍