Support Engineering Weekly
Episode 001
Microsoft Project Online is approaching its September 30, 2026 end-of-service date—but what comes next isn't as simple as clicking an upgrade button.
Transcript
Follow the episode as a written conversation. Transcript entries are synchronized with the audio player.
Announcer: This is Support Engineering Weekly from the Support Engineering Blog, technical conversations for engineers who
Announcer: troubleshoot, support, and operate Microsoft technologies.
Speaker 1: So, on September 30th, 2026, a whole decade of enterprise project data, custom workflows, and
Speaker 1: literally multi-million-dollar IT investments are going to effectively hit a brick wall.
Speaker 2: Yeah, a massive, unyielding brick wall.
Speaker 1: Right. Because Microsoft is officially pulling the plug on Project Online, and, you know, the
Speaker 1: most dangerous part of this entire transition we're looking at, most IT directors and enterprise
Speaker 1: architects currently think they can just, like, click an upgrade button to migrate their entire
Speaker 1: organization to the new system.
Speaker 2: Which is terrifying, honestly. Because they can't. I mean, that button simply does not exist.
Speaker 1: It does not exist at all.
Speaker 2: No, it is a really harsh awakening for a lot of these organizations. We are
Speaker 2: looking at a scenario where companies are going to try and map these legacy, deeply
Speaker 2: customized architectures onto a completely new cloud-native paradigm. And when those systems inevitably reject the
Speaker 2: transplant—and they will—the operational disruption is just going to be massive.
Speaker 1: Which is exactly why we are unpacking this today. If you are managing complex enterprise
Speaker 1: portfolios right now, or, you know, if you're the architect responsible for keeping the lights
Speaker 1: on when a major vendor forces a platform shift, you are staring down a transition
Speaker 1: landscape that is completely reshaping how organizations operate.
Speaker 2: Absolutely.
Speaker 1: So, we've gone through a massive stack of source material for this deep dive today,
Speaker 1: anchored pretty heavily by a really comprehensive engineering breakdown by Sadhan Chandra. And our mission
Speaker 1: here is to decode the actual mechanics of this retirement.
Speaker 2: Because there's a lot of noise out there right now.
Speaker 1: So much noise. We need to look at the immediate deadlines, some of which are
Speaker 1: going to hit way before 2026. And we have to dismantle this really pervasive myth
Speaker 1: that Planner Premium is just, you know, a reskinned version of Project Online.
Speaker 2: Right, the UI trap.
Speaker 1: Exactly. We have to open up the hood on Microsoft Dataverse to understand why legacy
Speaker 1: workflows are breaking, and then map out the three very specific, very different transition paths
Speaker 1: Microsoft has actually engineered for survival here.
Speaker 2: This isn't an optional software update where you can just, you know, cling to the
Speaker 2: old version for another five years while you figure it out.
Speaker 1: Oh, right. They are cutting the cord.
Speaker 2: They really are. Microsoft is fundamentally altering the underlying philosophy of work management. They're moving
Speaker 2: away from isolated, static project data and moving toward this integrated, AI-ready ecosystem. But to
Speaker 2: grasp the magnitude of where we actually have to go, we first have to understand
Speaker 2: the timeline that is actively constricting around legacy systems, like right now.
Speaker 1: Right. So let's get right into that ticking clock. The hard, final end-of-service date for
Speaker 1: Project Online is September 30, 2026. At that moment, the lights go out.
Speaker 2: Totally dark.
Speaker 1: The service is unsupported, and it's completely inaccessible. But if you're the IT architect listening
Speaker 1: to this deep dive right now, your immediate headache is not 2026. You have these
Speaker 1: severe constraints hitting much sooner, starting on October 1st, 2025.
Speaker 2: Yeah, October 2025 is really the first major choke point, because on that date, Project
Speaker 2: Online-only subscriptions will no longer be available for new customers.
Speaker 1: Wow.
Speaker 2: So if you have existing subscriptions, you know, your environment remains supported for another year.
Speaker 1: Yeah.
Speaker 2: But the gates to the legacy ecosystem are closed.
Speaker 1: Okay, so think about the real-world implications of that for a second. Let's say you
Speaker 1: are a global logistics company running absolutely everything on Project Online, and then in, say,
Speaker 1: November 2025, you acquire a mid-sized regional distributor...
Speaker 2: Which happens all the time.
Speaker 1: Right. And you want to onboard their 500 project managers into your existing Project Online
Speaker 1: environment just to, you know, maintain operational continuity while you figure out a long-term plan...
Speaker 2: You can't do it.
Speaker 1: You literally can't. You cannot buy the legacy licenses for that new subsidiary. You are
Speaker 1: legally and technically walled off from expanding your legacy footprint.
Speaker 2: Which forces you into this awful dual-operating environment. You suddenly have your core business on
Speaker 2: a dying legacy platform, and your newly acquired subsidiary has to operate on modern tools,
Speaker 2: and you have zero native bridge between them.
Speaker 1: That sounds like an integration nightmare.
Speaker 2: It is. The pressure to migrate just accelerates exponentially at that point. And then Microsoft
Speaker 2: tightens the vise again on April 1st, 2026.
Speaker 1: Right, the second milestone.
Speaker 2: Exactly. On that date, the creation of new Project Web App sites—what we call PWA
Speaker 2: sites—is completely blocked globally.
Speaker 1: So even if you have the licenses, like even if you were an existing customer
Speaker 1: paying your bills, as of April 1st, 2026, you cannot spin up a new PWA
Speaker 1: environment.
Speaker 2: No new sandboxes, no new departments coming online, nothing.
Speaker 1: And the source material actually notes that existing PWA sites that don't contain active projects
Speaker 1: are going to become inaccessible. So they are essentially freezing all new legacy deployments solid
Speaker 1: a full six months before the final shutdown.
Speaker 2: Yeah, it is a highly calculated throttling strategy. Because Microsoft knows that if they don't
Speaker 2: physically block the creation of new legacy environments, enterprise teams will just continue to spin
Speaker 2: them up right until the final hour.
Speaker 1: Because it's comfortable, it's what they know.
Speaker 2: Exactly. Human nature, right? So the April 2026 deadline is the point of no return
Speaker 2: for legacy infrastructure.
Speaker 1: Yeah.
Speaker 2: But, you know, while we are defining the parameters of this sunset, we really need
Speaker 2: to be incredibly precise about the naming conventions here.
Speaker 1: Oh man, the naming conventions are a total minefield.
Speaker 2: They really are. It has caused so much unnecessary panic in the market.
Speaker 1: So let's clarify exactly what is surviving this purge, based on the engineering documentation. Because
Speaker 1: it's not everything with the word "Project" in it.
Speaker 2: Right.
Speaker 1: Microsoft Project desktop, you know, the localized application you actually install on your physical machine,
Speaker 1: that is not retiring.
Speaker 2: Still safe.
Speaker 1: Project Server Subscription Edition, which is the massive on-premises heavyweight version, that is not retiring
Speaker 1: either. And Microsoft Planner is aggressively expanding.
Speaker 2: Oh, massively expanding.
Speaker 1: Right. The only thing being ripped out of the infrastructure is the cloud-based Project Online
Speaker 1: service.
Speaker 2: Which leads directly into the most dangerous misconception we found across all the source material.
Speaker 1: 1:1 myth.
Speaker 2: Yes. Microsoft has been highly visible in their campaign to consolidate Microsoft To Do, the
Speaker 2: basic Planner application, and Project for the web into a single, unified interface within Microsoft
Speaker 2: Teams.
Speaker 1: They merged all the menus together. You open Teams, you click the little Planner icon,
Speaker 1: and theoretically all your tasks are just sitting there in one clean, beautiful view.
Speaker 2: And from a user interface perspective, it is a brilliant piece of consolidation. It looks
Speaker 2: completely seamless. But because of this UI unification, there is this widespread assumption across IT
Speaker 2: departments that the new flagship product, which they call Planner Premium, is simply Project Online
Speaker 2: with a fresh coat of UI paint.
Speaker 1: They just think it's a rebrand.
Speaker 2: Exactly. They believe it is a one-to-one replacement.
Speaker 1: It is the ultimate trap of the graphical user interface. You see a Gantt chart
Speaker 1: in the old software, and then you see a Gantt chart in the new software,
Speaker 1: and you just assume the engine underneath them is identical.
Speaker 2: And it couldn't be further from the truth.
Speaker 1: But the source documentation makes a really harsh distinction here. Microsoft is actively divorcing collaborative
Speaker 1: project execution from what they call mature project portfolio management, or PPM.
Speaker 2: This is a huge philosophical shift. Historically, organizations used Project Online to do both of
Speaker 2: those things at the same time.
Speaker 1: Right, all in one bucket.
Speaker 2: Right. They used it to manage the daily, collaborative tasks of their teams, who's doing
Speaker 2: what on Tuesday, but they also used it to manage the complex, multi-year financial portfolios
Speaker 2: of the entire global enterprise.
Speaker 1: So high-level strategy and low-level task management all mixed together.
Speaker 2: Exactly. But the new architecture totally rejects that dual purpose. Planner Premium is engineered explicitly—and
Speaker 2: I mean exclusively—for collaborative project execution.
Speaker 1: Wow. So if you've spent the last 10 years customizing Project Online to handle your
Speaker 1: CapEx and OpEx amortization, mapping thousands of enterprise resources across global time zones, and running
Speaker 1: these really complex portfolio demand management scenarios...
Speaker 2: Which so many companies do.
Speaker 1: Right. And you think you are going to just port that operating model over to
Speaker 1: Planner Premium because the UI looks nice, the system is going to shatter.
Speaker 2: It will fail at the structural level. The functionality isn't just missing; it is fundamentally
Speaker 2: incompatible with the new philosophy.
Speaker 1: Okay, so to understand why an enterprise PMO cannot just transplant their legacy data into
Speaker 1: Planner Premium, we have to look past the user interface. We need to examine the
Speaker 1: underlying technical architecture, because the sources reveal this massive, often misunderstood divide between the architecture
Speaker 1: of basic Planner and Planner Premium.
Speaker 2: Yeah, this is where it gets really technical, but it's so important. To the end
Speaker 2: user, you know, Planner is just Planner. They have a Microsoft 365 E3 license, they
Speaker 2: open the app, and they just drag a task card from to-do to done.
Speaker 1: Smooth and easy.
Speaker 2: Super easy. But structurally, basic Planner is incredibly lightweight and highly distributed across the back
Speaker 2: end.
Speaker 1: It is essentially just a visual aggregation layer.
Speaker 2: Right, that's a great way to put it. When a user creates a task in
Speaker 2: basic Planner, the raw telemetry of that task—so the title, the due date, the assignee—that
Speaker 2: is written to an Azure database.
Speaker 1: Okay, Azure.
Speaker 2: But then, when that same user attaches a PDF specification document to that exact same
Speaker 2: task, the PDF does not go to Azure. It is routed to the connected SharePoint
Speaker 2: document library associated with that specific Microsoft 365 Group.
Speaker 1: And when the team starts arguing in the comments section of that task about, you
Speaker 1: know, why the deadline was missed, that conversation data isn't in Azure or SharePoint; it's
Speaker 1: being logged in an Exchange mailbox.
Speaker 2: Exactly. Basic Planner is basically an illusion of centralization. The visual layer is pulling from
Speaker 2: Azure, SharePoint, and Exchange simultaneously just to render a simple Kanban board on your screen.
Speaker 1: It's a patchwork quilt. But I mean, it's highly efficient for what it does. If
Speaker 1: you are a marketing team tracking collateral deliverables or like an HR team onboarding new
Speaker 1: hires, that distributed architecture is fast, it's super cheap for Microsoft to host, and it
Speaker 1: scales infinitely because the data is just flat records resting in these disparate silos. There
Speaker 1: is no heavy logic required to connect them.
Speaker 2: But you cannot run a $50 million engineering portfolio on a distributed illusion.
Speaker 1: No, definitely not.
Speaker 2: You cannot apply complex mathematical logic to task data in Azure if the metadata you
Speaker 2: need is stranded over in SharePoint. And this is exactly why Planner Premium abandons that
Speaker 2: distributed architecture entirely and relies on Microsoft Dataverse.
Speaker 1: Okay, Dataverse. We have to break this down, because it is thrown around in marketing
Speaker 1: materials constantly as a buzzword. For the architect trying to build a resilient system here,
Speaker 1: what is the actual mechanical reality of moving project data into Dataverse?
Speaker 2: Well, the trap is thinking of Dataverse as just another SQL database sitting in the
Speaker 2: cloud. It's not. It is a really comprehensive, highly secure data foundation and application platform
Speaker 2: all rolled into one.
Speaker 1: Okay.
Speaker 2: When you instantiate a project inside Dataverse, you are operating within unified, relational data models.
Speaker 1: Meaning the system inherently understands the relationship between things. Like it knows a task is
Speaker 1: connected to a human resource, and it knows the cost of that resource and the
Speaker 1: calendar availability of that resource, all at the core data layer rather than trying to
Speaker 1: calculate it way up in the application layer.
Speaker 2: Precisely. And that relational awareness is governed by strict role-based access control, or RBAC, built
Speaker 2: directly into the foundation itself. It provides this level of enterprise governance that basic Planner
Speaker 2: simply cannot mathematically support.
Speaker 1: Right, because it's scattered everywhere.
Speaker 2: Exactly. Because the data in Dataverse is structured and relational, Planner Premium can actually execute
Speaker 2: advanced scheduling algorithms. It can manage complex, multi-tiered task dependencies—you know, where Task C has
Speaker 2: a finish-to-start relationship with Task A, but it has a start-to-start relationship with Task B.
Speaker 1: It can handle the math.
Speaker 2: Yes. It can render interactive timelines and integrate completely seamlessly with the Power Platform, so
Speaker 2: Power BI for reporting and Power Automate for logic.
Speaker 1: Which makes total sense for an enterprise upgrade. You want that robust, relational integrity. But
Speaker 1: this leads us to what I think is the most counterintuitive technical reality in the
Speaker 1: whole stack of source material, and it's something that is going to give procurement officers
Speaker 1: a massive headache.
Speaker 2: Ah, the scale paradox.
Speaker 1: The scale paradox. We just established that Planner Premium is the heavy-duty, Dataverse-backed powerhouse, and
Speaker 1: basic Planner is the lightweight, scattershot tool for marketing teams. Yet the engineering blog explicitly
Speaker 1: notes that basic Planner can hold up to 9,000 tasks per plan, but Planner Premium
Speaker 1: imposes a hard limit of 3,000 tasks, 300 resources, and 2,000 successor links per project.
Speaker 2: It is such a brilliant paradox to explore, honestly, because it forces an understanding of
Speaker 2: computational complexity.
Speaker 1: Because how do you explain to a CFO that they need to pay a premium
Speaker 1: licensing fee for a system that basically has one-third the raw storage capacity of the
Speaker 1: free version? That sounds insane.
Speaker 2: You explain the difference between storage and processing. Think about the mechanical nature of a
Speaker 2: task in basic Planner. Like we said, it is a flat, isolated record. Storing 9,000
Speaker 2: disconnected flat records in Azure requires almost zero computational overhead. There's no heavy lifting involved
Speaker 2: in just rendering a visual list of 9,000 isolated items.
Speaker 1: It's like having a massive warehouse floor. You can dump 9,000 cardboard boxes on the
Speaker 1: floor; it holds a ton of volume, but the boxes don't interact with each other.
Speaker 1: Box number one doesn't care what is inside box 8,999.
Speaker 2: That's a perfect analogy. Now apply relational logic to that warehouse. Planner Premium is not
Speaker 2: just storing the boxes; it is mathematically linking them together with bungee cords. When you
Speaker 2: have 3,000 tasks in Planner Premium, they are bound tightly by dependencies, resource allocations, calendar
Speaker 2: exceptions, and lead and lag times.
Speaker 1: So if a project manager shifts the due date of task number 12 by, say,
Speaker 1: two weeks, the system doesn't just quietly update one record in a database.
Speaker 2: No, it has to instantly calculate the cascading impact on tasks 13 through 3,000. It
Speaker 2: has to check the calendar availability of the 300 resources assigned to those downstream tasks.
Speaker 2: It has to identify any resource over-allocations, recalculate the entire critical path of the whole
Speaker 2: project, and then redraw the Gantt chart in real time.
Speaker 1: That's a huge amount of math happening in milliseconds.
Speaker 2: The relational processing power required to maintain the structural integrity of 3,000 interconnected nodes, along
Speaker 2: with 2,000 specific successor links, inside a highly governed Dataverse environment is just immense. That
Speaker 2: is the premium.
Speaker 1: Right. That makes total sense.
Speaker 2: You are paying for the structural integrity of the relational logic and the APIs that
Speaker 2: allow you to query that logic securely. You are not just paying for flat storage
Speaker 2: space.
Speaker 1: And that structural integrity is also what allows the Power Platform to interact with the
Speaker 1: project data safely, right? Which is a massive operational shift, because the source material explicitly
Speaker 1: calls out the death of legacy automation, specifically SharePoint 2013 workflows.
Speaker 2: Yes. Microsoft has entirely deprecated SharePoint 2013 workflows. And for over a decade, these workflows
Speaker 2: basically functioned as the central nervous system for thousands of enterprise PMOs.
Speaker 1: Oh, yeah. Organizations built incredibly elaborate, deeply nested approval processes, stage-gate routing rules, custom email
Speaker 1: alerts—all of it inside Project Online using this legacy SharePoint engine.
Speaker 2: IT departments spent literal millions of dollars consulting with developers to write these custom SharePoint
Speaker 2: workflows. It was the duct tape that kept complex business logic attached to the project
Speaker 2: data.
Speaker 1: And now that duct tape is chemically degrading. It is completely unsupported.
Speaker 2: It's gone. When you migrate away from Project Online, those legacy workflows simply do not
Speaker 2: translate. You cannot just export a SharePoint 2013 workflow and import it into Planner Premium.
Speaker 2: The new architecture is completely alien to it. Organizations are being forced to modernize their
Speaker 2: automation via Power Automate and the project scheduling APIs within Dataverse.
Speaker 1: So let's talk about those project scheduling APIs, because they seem crucial to this whole
Speaker 1: modernization effort. In the old SharePoint days, a workflow might just, you know, brute-force a
Speaker 1: change to a list item, like just overwrite the cell. But in Dataverse, you can't
Speaker 1: just overwrite a date field on a task if that task is part of a
Speaker 1: complex dependency chain, right?
Speaker 2: Precisely. If a Power Automate flow tries to independently change the date of a task
Speaker 2: in Dataverse without respecting the underlying scheduling logic, it would instantly corrupt the critical path
Speaker 2: of the project.
Speaker 1: It would break the math.
Speaker 2: Exactly. That is why Microsoft mandates the use of the project scheduling APIs. The automation
Speaker 2: has to hand the request to the API, like knocking on a door. Then the
Speaker 2: API runs the calculation through the central scheduling engine, and only if the logic holds—if
Speaker 2: it doesn't break the rules—does the API write the change to the Dataverse tables.
Speaker 1: It is a highly, highly regulated transaction, which means IT departments aren't just moving data
Speaker 1: from server A to server B; they are entirely rewriting their business logic to interact
Speaker 1: with a highly structured API gateway.
Speaker 2: It's a fundamental rebuild. And because Dataverse and Planner Premium are so aggressively engineered for
Speaker 2: modern, collaborative execution and these regulated workflows, they simply cannot handle the sheer, unregulated sprawl
Speaker 2: of legacy portfolio management.
Speaker 1: Right. Microsoft realized that they could not build a single, magical cloud platform that accommodates
Speaker 1: both modern, lightweight collaborative work and the massive, heavy-duty, highly customized portfolio structures of these
Speaker 1: legacy enterprises.
Speaker 2: The architectures are just fundamentally at odds with each other.
Speaker 1: Which is why the source documentation lays out three very distinct transition paths. I mean,
Speaker 1: they aren't telling every single Project Online customer to just move to Planner Premium. They've
Speaker 1: engineered this enterprise decision framework to essentially force organizations to categorize their actual operational realities.
Speaker 2: And thank goodness they did.
Speaker 1: Yeah, so let's dig into these three paths, because making the wrong choice here is
Speaker 1: going to be a multi-million-dollar mistake for a lot of companies.
Speaker 2: The framework outlined in the engineering blog is actually very pragmatic. It guides decision-makers through
Speaker 2: a pretty logical flow.
Speaker 1: Okay, walk us through it.
Speaker 2: Well, the first step is assessing your overall business need and the complexity of your
Speaker 2: actual projects. Then, the second step evaluates the size and the distribution of your teams.
Speaker 2: But the third step—this is the critical fork in the road—is asking, "Does your organization
Speaker 2: require advanced resource and financial management?"
Speaker 1: Okay, so let's start with path one, which we've been circling around: Planner Premium. The
Speaker 1: source defines this path for organizations focused on collaborative, organization-wide project execution, real-time planning, and
Speaker 1: portfolio visibility. This feels like the path for agility.
Speaker 2: It is. If an organization's primary objective is coordinating tasks across departments, managing dependencies within
Speaker 2: cross-functional teams, visualizing work on a modern timeline, and just deeply integrating with the Microsoft
Speaker 2: Teams communication layer, Planner Premium is the absolute optimal destination.
Speaker 1: It's sleek.
Speaker 2: Very sleek. The engineering blog assesses Planner Premium's capability for task management and collaboration as
Speaker 2: excellent. They give it a 9 or 10 out of 10.
Speaker 1: It is the undisputed king of getting the actual work done efficiently. But you know,
Speaker 1: the source material is also brutally honest about its limitations. It analyzes the gaps. For
Speaker 1: resource management, Planner Premium is rated only as moderate, like a 4 to 5 out
Speaker 1: of 10. And for financial management, it drops all the way down to basic, a
Speaker 1: 2 to 3 out of 10.
Speaker 2: And this is exactly why the migration requires brutal self-awareness from leadership. If an enterprise
Speaker 2: PMO relies on Project Online to maintain a centralized global resource pool of, say, 5,000
Speaker 2: engineers, track their fractional utilization down to the quarter hour, forecast capacity bottlenecks six months
Speaker 2: in advance, and manage multi-million-dollar project budgets with strict CapEx and OpEx segregation...
Speaker 1: Yeah.
Speaker 2: Planner Premium, out of the box, simply lacks the mechanical depth to execute those functions.
Speaker 2: It will fall over.
Speaker 1: So what happens to that enterprise PMO? I mean, Microsoft can't just abandon their biggest
Speaker 1: clients. That is where path two comes into play: Project Server Subscription Edition.
Speaker 2: Right.
Speaker 1: Let's rethink our analogy here for a second. Rather than trains or warehouses, let's think
Speaker 1: about this transition like a massive update to a city's power grid. In the legacy
Speaker 1: Project Online days, every company essentially had its own localized gas generator.
Speaker 2: Oh, I like this.
Speaker 1: Yeah. It was messy, you could customize the pipes however you wanted, and you could
Speaker 1: bolt on all sorts of weird custom machinery to make it run your specific factory.
Speaker 1: Now, Planner Premium is like plugging into the new, modern, highly regulated commercial power grid.
Speaker 1: It's clean, it's super efficient, it runs your modern office building perfectly, but you cannot
Speaker 1: attach your old, leaky, custom gas pipes to it. The grid will reject you.
Speaker 2: It will short-circuit. And Project Server Subscription Edition, which is path two, is for the
Speaker 2: organization that realizes they cannot move their massive legacy industrial plant onto the commercial grid.
Speaker 1: Right.
Speaker 2: The source explicitly positions Project Server for on-premises control, proven enterprise-grade PPM, deep customization, and
Speaker 2: strict data residency.
Speaker 1: It is the heavy-duty, isolated bunker. But I have to ask the obvious question here:
Speaker 1: we are operating in an era where Microsoft's entire corporate messaging is obsessively focused on
Speaker 1: cloud-native architecture and artificial intelligence...
Speaker 2: Cloud-first, mobile-first.
Speaker 1: Right. So why is Microsoft offering an on-premises subscription edition where you actually have to
Speaker 1: install the software on your own local bare-metal servers? Doesn't that entirely contradict their strategic
Speaker 1: vision?
Speaker 2: Well, it contradicts the marketing vision, sure. But it acknowledges the immovable realities of enterprise
Speaker 2: IT. Microsoft understands that there are two massive, concrete roadblocks to cloud adoption for certain
Speaker 2: sectors.
Speaker 1: Okay, what's the first one?
Speaker 2: The first is non-negotiable data residency and compliance mandates.
Speaker 1: Ah. So we're talking defense contractors, federal agencies, big healthcare conglomerates.
Speaker 2: Correct. You have organizations operating under ITAR compliance or really strict FedRAMP regulations, whose core
Speaker 2: project portfolio data contains classified operational details, or proprietary defense schematics, or just heavily regulated
Speaker 2: financial models.
Speaker 1: Stuff that cannot leak.
Speaker 2: Right. Their governance frameworks legally prohibit that data from resting in a multi-tenant public cloud
Speaker 2: environment, no matter how secure Dataverse claims to be. They physically require isolated, on-premises control
Speaker 2: over their data layer. It's not a preference; it's the law.
Speaker 1: That makes total sense. And what's the second roadblock?
Speaker 2: Crushing legacy technical debt.
Speaker 1: Of course.
Speaker 2: Over the past 15 years, massive global enterprises have integrated Project Online deeply into sprawling
Speaker 2: on-premises ERP systems, like SAP or Oracle, and these totally bespoke financial engines.
Speaker 1: Oh, I've seen those. They're monsters.
Speaker 2: They are. And these integrations are the central nervous system of their revenue recognition. Untangling
Speaker 2: a global ERP integration just to move the project management module to the cloud could
Speaker 2: take five years and cost hundreds of millions of dollars.
Speaker 1: It would just paralyze the business operations. They'd freeze.
Speaker 2: Exactly. So Project Server Subscription Edition acts as the vital lifeline here. It allows these
Speaker 2: highly complex, heavily regulated organizations to maintain their bespoke on-premises integrations while still receiving modern
Speaker 2: security updates and support from Microsoft. It essentially prevents a catastrophic disruption of their core
Speaker 2: operating model.
Speaker 1: Okay, so if Planner Premium is the modern commercial grid for agile teams, and Project
Speaker 1: Server is the isolated heavyweight bunker for legacy and compliance, what is path three: Dynamics
Speaker 1: 365 Project Operations?
Speaker 2: Dynamics 365 represents the most comprehensive evolution of work management in the entire Microsoft ecosystem
Speaker 2: right now. The source highlights this path specifically for end-to-end, project-centric business management. This is
Speaker 2: designed for organizations where the project itself is the core revenue-generating product.
Speaker 1: Okay, so we are talking about professional services, like global consulting firms, large-scale engineering contractors,
Speaker 1: IT service providers, architecture firms...
Speaker 2: Exactly. For these organizations, a project isn't just an internal initiative to, you know, update
Speaker 2: a website or launch a marketing campaign. The project is what they sell to a
Speaker 2: client.
Speaker 1: Right, it's the product.
Speaker 2: So Dynamics 365 Project Operations bridges that entire lifecycle. It starts at the CRM level
Speaker 2: with sales quoting and pipeline management...
Speaker 1: So before the project even starts?
Speaker 2: Yes. Then it handles the complex resource staffing, mapping consultant skills against project demands. It
Speaker 2: manages the actual task delivery, tracking every single billable hour and expense incurred by the
Speaker 2: delivery team on the road. And crucially, it feeds all of that directly into the
Speaker 2: financial engine to generate client invoices, recognize revenue based on completion milestones, and provide real-time
Speaker 2: profit margin analytics.
Speaker 1: Wow. So it's essentially a full-scale ERP system explicitly built for project-based economies. You aren't
Speaker 1: just tracking when a task is due; you are tracking the exact financial impact of
Speaker 1: that task being late on the overall profitability of the client contract.
Speaker 2: Precisely. When you look back at the decision flowchart in the source documentation, the logic
Speaker 2: becomes really clear. If you answered yes to needing advanced resource and financial management, you
Speaker 2: lean away from Planner Premium immediately.
Speaker 1: Right.
Speaker 2: If you just need to maintain massive internal portfolios, you look at Project Server. But
Speaker 2: if you answer yes plus we need end-to-end project business operations and billable revenue tracking,
Speaker 2: you absolutely must migrate to Dynamics 365.
Speaker 1: And this really exposes why the whole upgrade button myth is so lethal. If a
Speaker 1: 2,000-person consulting firm tries to run its entire resource utilization and revenue recognition pipeline through
Speaker 1: Planner Premium simply because they both feature nice-looking Gantt charts, they will literally lose the
Speaker 1: ability to bill their clients accurately.
Speaker 2: They'd go bankrupt. The tools are mechanically engineered for entirely different operational realities.
Speaker 1: But you know, identifying the correct path is merely the theoretical phase. The true crisis
Speaker 1: for enterprise IT departments begins when they actually attempt to pack up a decade of
Speaker 1: legacy data and physically move it to the new architecture.
Speaker 2: Yeah, that's where the theory meets the road.
Speaker 1: Which brings us to the most labor-intensive part of this deep dive. The engineering blog
Speaker 1: makes it abundantly clear: there is no native, one-click migration path to convert a legacy
Speaker 1: Project Web App project into a Planner Premium plan or a Dynamics 365 environment. You
Speaker 1: cannot just right-click and hit "Export to modern platform."
Speaker 2: Because, as we detailed with Dataverse earlier, you are moving data from a flat, visually
Speaker 2: aggregated architecture into a highly structured relational database that enforces strict mathematical rules on every
Speaker 2: single entry.
Speaker 1: Right.
Speaker 2: The legacy data structures are just fundamentally incompatible with the modern schema without really rigorous
Speaker 2: transformation.
Speaker 1: The source material actually outlines an eight-stage migration journey, and it is a punishing, deeply
Speaker 1: technical process. The stages are: Current Environment Assessment, Assessment Analysis, Data Analysis, Governance Review, Platform
Speaker 1: Selection, Migration Planning, Adoption and Change Management, and finally, the Modernized Environment.
Speaker 2: Yeah.
Speaker 1: It sounds like standard, boring corporate methodology, right? But the reality of executing this is
Speaker 1: a minefield of technical debt. Let's look at stage two: Assessment. In the real world,
Speaker 1: what happens when an enterprise architect actually starts assessing a 10-year-old Project Online environment?
Speaker 2: Oh, it's a nightmare. They almost always uncover a staggering amount of shadow IT and
Speaker 2: broken logic. Because an environment assessment is not just a simple inventory of active projects...
Speaker 1: Like counting rows in a spreadsheet.
Speaker 2: Right, it's not that simple. It requires a forensic audit of the entire legacy ecosystem.
Speaker 2: Architects have to dissect the custom project templates. They have to analyze every single custom
Speaker 2: enterprise field, every lookup table, and every resource pool configuration.
Speaker 1: They're basically hunting for the ghosts in the machine.
Speaker 2: They are. They're looking for legacy dependencies that will critically fail the moment they touch
Speaker 2: Dataverse. For example, they have to audit every OData feed.
Speaker 1: Oh, tell me about the OData feeds.
Speaker 2: So, many organizations have built highly complex Power BI dashboards that ingest data directly from
Speaker 2: Project Online via OData feeds. If you just migrate the project data over to Dataverse,
Speaker 2: those legacy OData feeds will instantly break.
Speaker 1: The dashboard just goes dark for the executive.
Speaker 2: Completely dark. The architect must map every single API connection, every third-party application tied into
Speaker 2: the tenant, and every legacy SharePoint workflow we talked about. Because all of it—100% of
Speaker 2: it—must be completely rebuilt.
Speaker 1: And then they hit stages three and four: Data Analysis and Governance Review. This is
Speaker 1: where the translation really gets difficult, doesn't it? Moving from the way SharePoint handled permissions
Speaker 1: to the way Dataverse handles role-based access control.
Speaker 2: It is a massive conceptual leap.
Speaker 1: Yeah.
Speaker 2: In the legacy environment, security was often managed at the SharePoint site level.
Speaker 1: Right.
Speaker 2: If you had access to the site, you generally just had access to all the
Speaker 2: project data within it.
Speaker 1: Very broad strokes.
Speaker 2: Very broad. Dataverse, on the other hand, enforces security at the entity and row level
Speaker 2: within the database itself, governed by highly granular security roles and business units. So mapping
Speaker 2: messy, decentralized SharePoint permissions into strict Dataverse security models requires a complete overhaul of the
Speaker 2: organization's entire data governance strategy.
Speaker 1: And the source material flashes a massive warning sign over this entire process. They explicitly
Speaker 1: warn against the lift-and-shift mentality.
Speaker 2: Yes. The lift-and-shift is the single most expensive mistake an organization can make during this
Speaker 2: transition.
Speaker 1: And the psychological friction here is just immense. I mean, think about it: an IT
Speaker 1: department has spent countless budget cycles meticulously customizing Project Online to execute highly specific, often
Speaker 1: overly complicated business processes. When faced with a migration, the intense human urge is to
Speaker 1: demand that the new system replicate the old system perfectly.
Speaker 2: They do it all the time.
Speaker 1: Yeah.
Speaker 2: They tell the developers, "I want Planner Premium to look and act exactly like our
Speaker 2: customized Project Online environment."
Speaker 1: They want to bring all their legacy baggage into the modern architecture. It's like buying
Speaker 1: a state-of-the-art electric vehicle, but insisting the mechanics rip out the battery and install the
Speaker 1: leaky gas engine from your old sedan just because you were comfortable with how it
Speaker 1: idles.
Speaker 2: It's crazy.
Speaker 1: You completely destroy the efficiency of the new machine.
Speaker 2: You really do. It actively degrades the performance and stability of the Dataverse environment. Forcing
Speaker 2: modern cloud-native platforms to execute inefficient legacy business logic through complex workarounds just creates a
Speaker 2: fragile, unmaintainable architecture.
Speaker 1: Yeah.
Speaker 2: The engineering source is blunt about this: redesign reporting instead of rebuilding old dashboards. You
Speaker 2: must simplify the operating model to align with the strengths of the new platform. Don't
Speaker 2: fight the platform.
Speaker 1: But, okay, I'm putting myself in the shoes of the IT director who actually has
Speaker 1: to sell this to the executive board. Telling the C-suite that you need a massive
Speaker 1: budget allocation to redesign everything from scratch just to replace a software platform that is
Speaker 1: being forcibly retired by the vendor—that sounds like a catastrophic disruption. How does an IT
Speaker 1: leader justify completely re-engineering their core operational processes when the board thinks they are just
Speaker 1: buying a new tasks management app?
Speaker 2: The justification lies in the broader market research cited in the source material. This isn't
Speaker 2: just Microsoft being difficult with a software update; this is an aggressive, industry-wide pivot. The
Speaker 2: article references insights from Gartner and Forrester that contextualize why this painful redesign is absolutely
Speaker 2: mandatory.
Speaker 1: Right, the divergence of the market.
Speaker 2: Exactly. Forrester highlights that collaborative work management—which is what Planner Premium exemplifies—is rapidly maturing and
Speaker 2: diverging entirely from traditional project portfolio management.
Speaker 1: They are two different beasts now.
Speaker 2: They are. The market itself has split into distinct operational philosophies. Attempting to force an
Speaker 2: organization into a hybrid legacy model is just a dead end. So the IT director
Speaker 2: justifies the redesign by explaining to the board that they aren't just replacing a tool;
Speaker 2: they are deciding the future operational agility of the entire company.
Speaker 1: You tell the C-suite, "We have to modernize the architecture now because the old way
Speaker 1: of working is mathematically incapable of supporting the future."
Speaker 2: And you validate the massive expense of the redesign by focusing on the ultimate return
Speaker 2: on investment. The C-suite is not interested in the nuances of task management software. They
Speaker 2: are intensely focused on one thing right now: artificial intelligence.
Speaker 1: AI, of course.
Speaker 2: The IT director's core argument is this: you must undergo this painful data modernization and
Speaker 2: migration to Dataverse today, or you will be permanently locked out of the AI revolution
Speaker 2: tomorrow.
Speaker 1: Which brings us to the true endgame of this entire transition. Microsoft isn't retiring Project
Speaker 1: Online just to, you know, tidy up their product catalog.
Speaker 2: No, not at all.
Speaker 1: They are doing it to pave the highway for AI, specifically Copilot and the new
Speaker 1: Planner agent.
Speaker 2: Artificial intelligence is the driving force behind this entire architectural shift to Dataverse. The source
Speaker 2: documentation outlines three massive, overarching themes for the future of work management.
Speaker 1: Let's hear them.
Speaker 2: One: AI-assisted project management becomes the default standard. Two: unified, integrated platforms completely replace standalone,
Speaker 2: siloed applications. And three: strict data governance becomes the absolute non-negotiable foundation for AI deployment.
Speaker 1: So let's look at the mechanical capabilities of the Planner agent integrated with Microsoft 365
Speaker 1: Copilot. What is this AI actually doing that makes the pain of this migration worth
Speaker 1: it?
Speaker 2: We are witnessing a transition from a system of record to a system of action.
Speaker 2: In legacy platforms, the software just recorded what a human typed into it, right? It
Speaker 2: was passive.
Speaker 1: Just a digital filing cabinet.
Speaker 2: Yeah, exactly. Copilot operates as an active intelligence layer. It can ingest a rough project
Speaker 2: charter document and automatically generate a comprehensive work breakdown structure.
Speaker 1: Wow.
Speaker 2: It can continuously analyze the real-time state of a project plan, cross-reference it with resource
Speaker 2: availability across the tenant, and automatically produce nuanced status reports. And crucially, it can identify
Speaker 2: subtle scheduling risks—like, say, a critical path dependency slipping by two days long before a
Speaker 2: human project manager would even notice it—and recommend specific, actionable steps to mitigate that risk.
Speaker 1: It is shifting from historical reporting to predictive navigation. But here's the critical connection back
Speaker 1: to the architecture we're discussing: none of that predictive navigation is possible on the old
Speaker 1: Project Online architecture, right?
Speaker 2: It is technically impossible. Think back to our discussion about the difference between flat files
Speaker 2: in Azure and relational structures in Dataverse. For an AI agent to accurately read a
Speaker 2: project's health, identify risks, and suggest viable actions, it requires highly structured, governed, and mathematically
Speaker 2: interconnected data.
Speaker 1: Right. If your project data is siloed in legacy databases, or your metadata is scattered
Speaker 1: across loosely governed SharePoint sites, the AI cannot piece together the true context of the
Speaker 1: project. It's like asking a GPS to calculate a route from New York to LA,
Speaker 1: but instead of a digital map, you just hand the system a shoebox full of
Speaker 1: loose Polaroids of different street corners.
Speaker 2: That's a great image.
Speaker 1: It has no idea how the data connects. It can't route you.
Speaker 2: It can't. And honestly, the risk profile of deploying AI on ungoverned data goes far
Speaker 2: beyond it simply failing to work. If an organization's permissions and data governance aren't flawlessly
Speaker 2: structured—which Dataverse inherently enforces through RBAC—the AI becomes a massive security vulnerability.
Speaker 1: Because the AI will just surface whatever data the user technically has access to, even
Speaker 1: if they really shouldn't see it.
Speaker 2: Exactly. If you point Copilot at a legacy ungoverned SharePoint architecture, and say a junior
Speaker 2: developer asks the chatbot, "Hey, what is the biggest financial risk to the Q4 release?",
Speaker 2: the AI will scour the entire tenant.
Speaker 1: Uh-oh.
Speaker 2: And if a project manager accidentally left a confidential budget cuts spreadsheet in an open
Speaker 2: SharePoint folder two years ago...
Speaker 1: The AI finds it.
Speaker 2: Copilot might pull that unstructured document and casually inform the junior developer that the biggest
Speaker 2: risk to the project is that half their team is scheduled to be laid off
Speaker 2: in November.
Speaker 1: That is a catastrophic data breach executed by your own productivity tool.
Speaker 2: And that is precisely why the source material emphasizes over and over that strict data
Speaker 2: governance is the prerequisite for AI. You cannot deploy intelligent, secure AI without a strictly
Speaker 2: governed data foundation. Dataverse provides that foundation. Project Online's legacy architecture simply could not support
Speaker 2: the security, the relational logic, and the scale required to run enterprise AI safely.
Speaker 1: So this migration is truly a forced evolution. Microsoft is tearing down the old infrastructure
Speaker 1: because it is quite literally a hazard to the AI future they are building. And
Speaker 1: the market data backs up this aggressive pivot. The source quotes IDC forecasting that the
Speaker 1: project and portfolio management software market will reach $13.6 billion by 2029.
Speaker 2: Yeah, that represents a 12.8% compound annual growth rate. That financial forecast clearly indicates that
Speaker 2: this cloud-native, AI-driven, highly integrated approach to work management is an industry-wide inevitability.
Speaker 1: You can't hide from it.
Speaker 2: You can't. Organizations that resist modernizing their data architecture now, clinging to legacy on-premises workflows,
Speaker 2: will simply be outmaneuvered and outcompeted by organizations whose delivery teams are augmented by AI.
Speaker 2: It's that simple.
Speaker 1: But this massive injection of AI raises a very real existential question for the people
Speaker 1: actually doing the work. I mean, if Copilot is generating the work breakdown structure, assigning
Speaker 1: the tasks based on capacity, monitoring the critical path for slippage, and automatically producing the
Speaker 1: weekly status reports for the executive steering committee... what is the human project manager actually
Speaker 1: doing? Are they just sitting there clicking "Approve" on the AI's suggestions all day?
Speaker 2: It is a very valid anxiety, but I think it misinterprets the function of the
Speaker 2: role. The role of the project manager isn't disappearing; it's being aggressively elevated. The fundamental
Speaker 2: shift is moving away from data entry and chasing status updates towards strategic governance and
Speaker 2: human alignment.
Speaker 1: Think about the day-to-day reality of a traditional project manager right now. They spend an
Speaker 1: absurd amount of their week just nagging developers for status updates on Slack, manually dragging
Speaker 1: bars on a Gantt chart when someone calls in sick, and, you know, formatting PowerPoint
Speaker 1: slides so the font sizes match for the Friday steering committee meeting.
Speaker 2: It's exhausting. And that is all operational friction. It is low-value administrative overhead. The AI
Speaker 2: handles the operational friction. By offloading the mechanical tracking and reporting to Copilot, the human
Speaker 2: project manager is freed to actually manage the strategy.
Speaker 1: They can do what humans are good at.
Speaker 2: Right. They can focus on negotiating with difficult stakeholders, managing the complex portfolio priorities, and
Speaker 2: navigating the nuanced, unquantifiable human elements of team dynamics and organizational politics that AI just
Speaker 2: cannot process.
Speaker 1: The human becomes the strategic pilot. You rely on the AI autopilot to handle the
Speaker 1: micro-adjustments of the wind and the altitude, so you can focus entirely on navigating the
Speaker 1: storm ahead.
Speaker 2: Exactly. The human manages the vision and the relationships; the AI manages the mechanical execution.
Speaker 2: But—and this is the key—that synergy only materializes if the underlying data foundation—the Dataverse architecture,
Speaker 2: the strict governance, the Power Platform integrations—is built correctly during this narrow migration window.
Speaker 1: This has been an incredibly dense, highly technical deep dive. Let's synthesize the absolute core
Speaker 1: takeaways for anyone staring down this transition:
Speaker 2: Absolutely. Do not expect Planner Premium to be a reskinned version of your legacy environment.
Speaker 2: You must understand the profound architectural shift from flat tasks storage to the relational, governed
Speaker 2: power of Dataverse.
Speaker 1: You have to choose your modernization path based on your actual operational reality, not just
Speaker 1: feature parity. Use the decision framework:
Speaker 2: And if you are running an end-to-end, billable professional services operation, you must adopt Dynamics
Speaker 2: 365 Project Operations.
Speaker 1: And above all, you must treat this transition as an opportunity to aggressively clean house.
Speaker 1: Do not succumb to the lift-and-shift mentality. Audit your environment, redesign your reporting, establish strict
Speaker 1: Dataverse governance, and shed the legacy technical debt. Don't try to plug your leaky gas
Speaker 1: pipes into the new smart grid.
Speaker 2: Very well said.
Speaker 1: I want to leave you with one final, provocative concept to mull over as you
Speaker 1: begin mapping out your new architecture today. We spent a lot of time discussing how
Speaker 1: Copilot reads the structured data in Dataverse—you know, the task durations, the dependencies, the resource
Speaker 1: costs—to predict a project's health. But if Microsoft's ecosystem is truly unifying all enterprise data
Speaker 1: under the Microsoft 365 umbrella, what happens when the AI starts factoring in the unstructured
Speaker 1: data?
Speaker 2: Oh, the behavioral layer.
Speaker 1: Exactly. What happens when Copilot is trained to factor in the tone of your development
Speaker 1: team's Teams chats? What happens when it analyzes the frequency of panicked emails sent after
Speaker 1: 10:00 PM, or the sudden increase in muted microphones during weekly standup meetings, and feeds
Speaker 1: that telemetry into a project's risk assessment algorithm?
Speaker 2: That changes everything.
Speaker 1: If the platform connects absolutely everything, are we rapidly moving toward a future where the
Speaker 1: health of a multi-million-dollar project is measured not just by whether the tasks are checked
Speaker 1: off, but by the digital behavioral footprint of the team executing it? If the AI
Speaker 1: senses the team's internal chat sentiment turning deeply negative and fragmented, does it automatically flag
Speaker 1: the project to the C-suite as "at risk," even if the Gantt chart is perfectly
Speaker 1: green? It is a fascinating, slightly terrifying frontier to consider as you build the foundation
Speaker 1: for this intelligence today.
Announcer: You've been listening to Support Engineering Weekly from the Support Engineering Blog. For the full
Announcer: articles, references, and technical resources from today's discussion, visit the URL blog.sadhan.ch.
