Let’s imagine you have chosen a CRM system from a SaaS vendor to manage your critical business processes. It could be Microsoft Dynamics 365 Sales, Salesforce, or something similar. One key reason for your choice will have been the platform capabilities that ensure you’re not just buying an as-is app but rather a customizable solution that can adapt to your current and future needs.

You’re in the process of specifying the detailed use cases of how your employees will work with this system. The required fields, views and forms to make the app easy and efficient for users have been defined. Then, once you move to the development stage, you discover a surprise: “Hey, the contact table cannot be modified at all! It’s locked!”🔒

Welcome to the life of Microsoft Planner Premium customers/partners. This is the equivalent of what happened to them this week, in the context of project management rather than CRM. But let’s start from the very beginning, so that we understand why the product is going through uncertain times.

Readers of this newsletter may recall my earlier investigation into the amazing history that connects MS Project from the 1980s with the Planner Premium of 2026. To understand the full context of what I’m writing about today, revisiting the earlier piece is a good idea — unless you work with these products on a professional basis.

Here’s the short version: the Planner brand today covers two software products with a very different background. 1) The O.G. Planner (aka Planner Basic) was built on top of Microsoft Graph as an app with hardly any dedicated data store of its own for the key elements (groups, tasks). 2) Planner Premium, on the other hand, was a database-centric initiative built originally as Project for the Web, leveraging Dataverse (then Common Data Service) as the back-end and Power Apps as one front-end.

Unlike the M365 family of products like Teams or SharePoint, data stored in Dataverse has never been made available natively via MS Graph. Those of you with a Dynamics 365 background may recall the now deprecated PSA product (Project Service Automation) and know about the current ERP side offering of Dynamics 365 Project Operations. The strange duality of Planner’s Basic (M365) vs. Premium (Dataverse) sides in terms of the underlying technology stack makes it a product that’s much more complex than it appears at first. One side is firmly the M365 collab world. The other is flirting with hardcore ERP software in terms of shared components.

As you can imagine, this divide makes it quite difficult to work with Planner from a customization and extensibility perspective. I’d argue the gap is as big as the one we’ve had between Microsoft’s CRM and ERP products for 20+ years now. The bundling of Planner Basic into M365/O365 makes this product very widely used in organizations. The fact that the “upgrade to Premium” upsell path takes the users away from M365 land and deep into the D365 ERP domain with Project Scheduling Service dependencies is simply unsustainable in the long run. The web is full of angry customers who didn’t know what would happen when they chose a different plan type in the Planner UI.

At Ignite 2025, there was one session on Microsoft Planner that addressed this very issue. The tech divide between Basic and Premium Planner is supposed to become less of a concern for customers, thanks to a single plan type being introduced in the Planner app. Here’s my summary post of it on LinkedIn:

This plan unification would be a major step forward, for end users as well as partners and developers. The part that I personally would very much want to be real already today is the single API surface. Because so far, the Planner connector in Power Platform will only work with the Graph world of Planner Basic data. Most customers will have banged their heads on this, with very few discovering the crazy hoops that you must jump through to automate anything related to Planner Premium tasks.

I am pretty good at finding official and unofficial information sources on Microsoft product news. These are the skills that I have honed during my blogging career and continue to make use of when writing this newsletter or covering niche areas like business apps licensing. Knowing the right portals and having the right bookmarks often makes uncovering MS product mysteries possible (and fun, I got to admit).

Planner is a formidable challenge in this sense. Because compared to what the Dynamics 365 and Power Platform product teams put out into the web, the Project/Planner team seem to prefer keeping things to themselves. Since the software it lives in the cracks between M365 and Power Platform, you can’t expect it to be properly covered in main communication channels of either two clouds.

Microsoft 365 Roadmap entries for Planner follow the corporate comms pattern of “the less concrete details we reveal the better” and aren’t therefore useful for people working with the technology, rather than just using product features. We have to follow the good ol’ read-between-the-lines strategy and decipher things like M365 Admin center messages to deduce what is happening and when. Like this message from December:

This confirmed for us that something big is about to happen:

One temporary impact of this update was mentioned: “Convert a basic plan to a premium plan will be temporarily unavailable.” That would make perfect sense for the underlying service unification. It would have also made sense that more communication about the impact would have been shared with customers as we got closer to the mid-January 2026 and mid-February 2026 rollout. Which is where we are right at this moment.

This gets us to what I talked about at the start of this post. This week, when checking on whether there were any recent news about the Planner updates, I discovered this thread in the MS Tech Community: Microsoft Project Service Core Jan 2026 Update locked Plans table.

I know enough about Dataverse and the Power Platform managed solutions customization enforcement to realize something very serious had happened. I immediately went to my own tenant’s environments to check the status of those solution updates. I discovered that in the Default environment the update hadn’t yet been applied, whereas in a non-Default Power Platform environment it was installed already. This allowed me to take screenshots of what exactly the impact of this update was:

Before the update, I was able to add new columns, views, modify forms etc. on the Plan (Project) table. After the update, none of these actions were possible. What can cause such a thing? Simple: it’s a built-in feature of Power Platform designed to allow publishers of managed solutions to control what parts of their solution can be customized. This is what the docs say about managed properties:

It literally is a kill switch for customizations in customer environments. There can be valid reasons why partners building products on top of Microsoft Power Platform wish to keep certain areas of their solutions standardized across all deployments. When you know what you are doing and why, this is a legit platform feature. But when you as the creator of the managed solution just flip it on AFTER years of inviting customers/partners to extend things on top of your solution, it’s simply mayhem.

I can’t recall such a decision ever having been made by Microsoft before when it comes to their products. And I’ve been in this game for quite a while. I participated in the Early Access Program for Dynamics CRM 2011 that launched the whole solutions concept. Yes, I’m old and I’ve seen things. But never something quite as reckless as this.

In the absence of official communication coming from Microsoft, the community has to support itself. Five days after the forum post, I haven’t yet seen anything in public from Microsoft about this. I have, however, heard from several credible sources that this is a bug that Microsoft is working on to get fixed.

But let’s look at it from the perspective of folks who are not well-connected and deep in the MS ecosystem. If you’re a customer or a “normal” developer who pays for Microsoft Planner licenses and tries to make it work for the task and project management scenarios it is sold for, will you know what’s going on? Will you even have confidence about the customizability option ever having been there for the Plan/Project table?

You won’t have any documentation to refer to directly, because MS has skipped most of that for these work management products. You don’t know what to search for online because the products have been rebranded many times. You won’t necessarily understand that custom fields in Planner are a completely different feature from adding a custom column to the Planner Plan table.

What do you think would happen if you opened a support ticket? What are the chances that it would reach a human in the MS org who understands what the issue is really about? I’d say: slim to none.

So where do people turn to? They could of course ask their M365 Copilot for an answer. And they would get the wrong answer:

Seriously, most people would just give up at this point and accept that it’s a feature that has always been there. Unless they were knowledgeable enough to use AI tools that go a bit further and get all the details, like Claude Opus 4.5:

I can’t help thinking that the original bug is also somehow related to AI tools. Because obviously there’s immense pressure inside Microsoft for all employees to demonstrate they are leveraging tools like GitHub Copilot / Claude Code in their work. So, when doing a major architectural change like the plan unification, there will surely be plenty of AI coding agents burning tokens for the development team. And all it takes is one rogue agent that produces an elaborate plan of how to meet the requirements — with no one noticing a tiny change in the isCustomizable setting of the Plan table in Dataverse.

I joked on LinkedIn about what the answer from the coding agent might be when the developer asks why the Plan table got locked down:

🤖 “You're absolutely right! Existing solutions depend on this setting. Let me go and revert the change and update the how-to-develop-planner.md instructions to make note of this."

I think this is a perfectly plausible explanation at this point. LLM coding capabilities have grown sharply in the past few months. People give them more and more autonomy because the results look convincing. And yet the pace of code changes that this makes possible is now overloading most organizations’ ability to set up guardrails to keep unwanted product changes from happening.

(Yeah, that’s an AI pun.)

Microsoft isn’t a $3.1T company because of its own software excellence. It’s all about the ecosystem. Partners ranging from solopreneurs like me to global system integrators like Accenture are what make the magic happen in the real-world, making the software fit the real-world needs of customers. We often hear how “for every $1 of revenue MS makes, the partners make ~10x” as proof of the deep connection between these parties.

So, imagine you are developing your own value-add service or a software product on top of Microsoft Planner. Then, imagine that one morning you wake up and you just can’t do it anymore. You’ve sold your software/projects to customers. You have commitments to deliver business application functionality and demonstrate the value of the MS platform, to prove you’re a trustworthy partner to the customer. What are you gonna say? “Oops”?

Things like this should not happen. Yet they increasingly keep happening and people are starting to think it ain’t just a coincidence. The badwill for the Microsoft brand is accumulating with every botched Windows update and software issues like this one with Planner. It is fueling the organic #microslop campaign where customers are rising against the relentless push for new AI features while the basic IT tools are degrading in quality.

I chose the clickbaity kill switch term for the subject line for a reason. If you live in Europe and your organization relies on big US clouds like Microsoft, this topic has recently been appearing in news articles and discussions quite often. People are increasingly thinking about their dependency on technology that could in theory be disabled remotely. The trust levels are not what they used to be.

At times like these, cloud vendors should be very cautious about making moves that further erode this trust. I even recall someone saying Microsoft runs on trust.