Power Platform

Microsoft is switching off unmanaged developer environments. How many do you have?

Unmanaged developer environments are suspended on 15 December 2026 and deleted from 15 January 2027. The dates are the easy part — the hard part is that most tenants cannot say how many they have or what is inside them.

LogiSam · 27 October 2026 · 7 min read
Power Insights banner: which of your Power Platform environments are actually managed?

Microsoft is retiring unmanaged developer environments in the Power Platform. Not restricting them, not warning about them — switching them off, on a published schedule, starting in about three weeks.

Most of the coverage has focused on the dates. The dates are the easy part. The hard part is that almost no tenant can say how many of these environments it has, who owns them, or which ones are holding something that matters.

Three dates

All three come from Microsoft's own deprecation notice, Important changes (deprecations) coming in Power Platform.

15 November 2026

Signing up for the Power Apps Developer Plan stops creating a developer environment. No new unmanaged developer environments can be created at all — not from Power Apps, not from the admin centre, not from PowerShell, not from the CLI.

15 December 2026

Existing unmanaged developer environments are suspended. Their apps, flows, agents, Power Pages developer sites and data become unavailable. The environment still exists, but nothing in it runs and nothing in it opens.

15 January 2027

Suspended unmanaged developer environments are deleted.

Between the second date and the third there is a month in which the contents still exist but cannot be reached. That month is not a grace period for development. It is a grace period for admins who notice something is missing.

Developer environments are not going away. Unmanaged ones are.

This is the part that gets lost in the summaries. Developer environments continue — one per user, as managed developer environments. The capability survives. The unmanaged version of it does not.

Two consequences catch people out, and both are in the same Microsoft notice:

Running an app in one needs a premium licence

Managed Environments use rights are not included in the Developer Plan. Users need a premium licence to run apps and flows in a managed developer environment. A maker who has been building happily on the Developer Plan for two years is not automatically able to carry on after the switch.

That is a procurement question with a November deadline attached, and procurement questions do not move quickly in December.

A Power Pages site inside one dies with it

Power Pages developer sites are suspended with the environment and deleted with it. Converting the environment before 15 December is the only way to keep the site. There is no separate rescue path afterwards.

So the first question is not "how do we migrate"

It is "what have we actually got, and which of it is already managed".

Most tenants cannot answer that from memory, and the reason is structural rather than careless. Developer environments are created by individual makers, on demand, without a request going anywhere. That is the entire point of them. Three years of that leaves an estate nobody deliberately designed and nobody wrote down.

The admin centre will list them. What it will not do is tell you, in one view, which of them are managed, which are holding apps somebody still uses, and which are empty shells from a workshop in 2024.

An environment list showing each environment's type, region and whether Managed Environments is enabled
Every environment, its type, and whether it is managed — including the developer environment that is not.

What a useful inventory answers

Before any migration planning is worth doing, you want five columns, for every environment in the tenant:

  • Type — developer, trial, sandbox, production. The deprecation only touches developer environments, and mixing the rest into the list makes the job look bigger than it is.
  • Managed or not — the ones already managed need nothing at all. In most tenants this removes a meaningful share of the list immediately.
  • Owner — and whether that person still works here. Dormant environments belonging to leavers are common and are usually the easiest decisions.
  • What is inside — apps, flows, solutions, connections. An environment with nothing in it is a deletion, not a migration.
  • Whether it is actually used — an app that has not been opened in eighteen months is a different conversation from one that runs a weekly finance process.

That last distinction is the one that decides how much of the next seven weeks you spend on each environment, and it is the one least likely to be in anybody's head.

Power Insights reads all of it straight from the tenant: every environment, its type, whether it is managed, and how many apps, flows, solutions and connections sit inside each one. No spreadsheet, no survey sent to makers, no waiting for replies.

You cannot plan a migration you cannot see.

Next in this series: how you actually move an app from an unmanaged to a managed developer environment — including the route most people do not realise they can take, and the four steps where imports quietly go wrong.

Power PlatformPower AppsPower AutomateManaged EnvironmentsGovernancePower Insights

Want to apply this in your tenant?

Book a free call with a LogiSam consultant — we will show you the quickest, safest way to do it on Microsoft 365.

LogiSam Assistant Guided help & instant answers

Answers come from this website. Privacy policy

↑↓ to navigate ↵ to open