Microsoft has been busy adding entries to the deprecations list for Power Platform lately. Not only are a bunch of built-in AI features getting scrubbed away from the maker experiences, but significant changes will also impact much of what we knew about environment strategy. The “free” Dataverse environments are going away.

First, Dataverse for Teams will be deprecated this month and all environments will be wiped away by October 2027. “Introduced in September 2020, Microsoft Dataverse for Teams is was a built-in, low-code data platform for Microsoft Teams that empowers users to build custom apps, agents, and flows in Teams by using Power Apps, Copilot Studio, and Power Automate.” Hardly a surprise at this point, given how it had been one of the dead features in the platform for many years already.

A more impactful decision is the deprecation of unmanaged developer environments and the Power Apps Developer Plan. From November 15 onwards, each user can only create one developer environment. It has to be managed, meaning the usage of any features in it requires a premium license. Effectively, the door for any new developers wanting to learn how to build on Dataverse without their employer sponsoring them has now been nailed shut.

Why is this happening? The MS Learn pages talk about better governance controls for admins as the answer to that question. Well, sure. It is technically true. It sounds like a similar excuse as the one given about privacy and compliance as the reason why Microsoft deletes nearly all Feedback Portal submissions after 15 months automatically. The common thread is that when there are fewer things users can do on their own, everything remains better under central control. Whether that encourages community engagement / citizen developer activity is another topic.

Allowing these environments to be provisioned without any new license purchases has obviously been a cost that someone at Microsoft has to pay for. It is very logical that such expenses are then aligned to support the current business strategy, rather than something that was a top priority back in 2020. Today, that priority is getting users to build with Copilot and encouraging consumption of services with UBB (usage-based billing).

There is also a big architectural shift behind these changes in policy for handing out Power Platform environments. Namely, the move away from Dataverse being the center of everything and the rise of Copilot as a platform. Today I’ll look at what the new ALM model is about, how it impacts your governance model, and what remains unanswered still.

I’m not sure I’ll ever get fully used to the CMR acronym, thanks to my background in CRM, but it stands for Copilot Managed Runtime. By now, you should have already seen demos of how quickly and easily you can prompt Cowork, Copilot Studio or Copilot Code into generating a modern React app for you. If you’ve only used the earlier Power Apps Vibe Apps or the App Builder agent so far, you should waste no time jumping on the latest preview feature before the old ones are decommissioned.

Unlike the earlier efforts for AI app builders, this time Microsoft is putting an actual platform play behind those prompts and React front-ends. This hasn’t yet been broadly advertised, nor mentioned on the AI at Work roadmap, so we need to rely on conference decks shared on GitHub to discover what’s going on. The repo for PPCC26-ALM contains plenty of interesting news to analyze for those of us who didn’t fly to Vegas.

We already know Managed Apps are backed by platform-hosted Git repos (or your own) rather than Dataverse solutions. While trying to get your Power Apps into Git through native Power Platform tools requires the slow and cumbersome Dataverse-Git integration (which seemed exciting 2 years ago), in CMR, source control just works as it does with any other modern app builder.

This part is pretty crucial since Microsoft clearly wants to invite vibe coded apps that users have built with popular tools and agents to be moved onto CMR. One month after the initial MS announcement, the connector for publishing Lovable apps onto CMR remains missing in action. Whether the story works in practice therefore remains to be seen. But that’s the aspiration clearly.

It’s not just about where the source code lives. When it comes to application lifecycle management, pretty much everything changes when going from the Power Platform to the Copilot platform:

Environments are the big difference here. Given the legacy of how Power Platform environments used to originally be Dynamics CRM Online instances, it’s not a huge surprise their core architecture doesn’t suit the modern web app development needs all that well. The world sure looked different back in 2014:

The line about the role of environments in the PPCC26 slide says what’s really changing here. Environments used to be a lifecycle + governance boundary. With CMR, their only role is the governance boundary. App lifecycle is decoupled from environments. And that “changes everything”, as people on social media and YouTube like to express these things.

It sort of actually does this time, though. Anyone who has worked with Dynamics 365 CE and Power Apps/Automate for a long time has grown accustomed to the idea that we need separate dev, test and prod environments. Each with their own configurations and governance controls. And now, in the Copilot Managed Runtime world, that’s no longer true. If your app isn’t storing things in Dataverse, having multiple Power Platform environments might be an unnecessary waste of resources.

The separation between dev/test/prod is of course still needed. The implementation in CMR will be through stages in a project (repo). These elements are already visible on the code side of things (behind a feature gate), but the official ETA for the public preview is the end of November. Presumably, that’s when they’ll appear in the portal experiences. Given how the management of CMR features is already on the Microsoft 365 admin center side, it seems likely we’ll have two complementary/conflicting control planes for app lifecycle management in the near future. Exciting times!

The most controversial part of this modern ALM story from Microsoft must be the idea that personal Power Platform environments can be the final destination for most apps. “We expect the vast majority of apps to never leave the environment they were built in”, say the PPCC26 slides. No matter how broadly the app might be used, if it isn’t hitting any real development or administration constraints, the personal developer environment might as well be its permanent home.

That’s quite a departure from the earlier stance where Microsoft made it clear that no production use whatsoever should take place inside the developer environment. The apps even had a banner showing that. So, which one is it now? Are customers supposed to use the Power Platform developer environments for merely personal experiments and development work, or are they good to be used “forever”?

On one hand, Microsoft is actively working to remove unmanaged developer environments. Suspension starts next month already, as indicated by the timeline:

At the same time, anyone who tests creating a Managed App via Cowork or Copilot Studio will have a personal developer environment provisioned for them. Will these also be affected by the deprecation process? No, because they are provisioned as managed by default. Same thing if you have the environment routing rules enabled in the tenant: those were already managed, too. Meaning, everything running on them required a premium license from day one.

So, Microsoft is not against there being personal environments for users. As long as there’s a licensing element attached to them, everything is good and MAU go up. The new model for Copilot Managed Runtime could end up making such developer environments a permanent part of your tenant, with important business apps running inside them. It sounds wild to anyone who’s done Power Platform governance, but let’s examine what the justification here is.