Unmanaged developer environments are being deleted: what to do before 15 December 2026

Microsoft has set three dates for unmanaged developer environments, and the middle one is the one that matters. On 15 December 2026 the apps, flows, agents, Power Pages developer sites and data in those environments stop being available. A month later the environments are deleted. Between now and then, somebody has to decide which of them contains something the business would miss — and in most tenants nobody can currently answer that.

The three dates

Microsoft's deprecation page describes suspension and then deletion. It does not describe a route back from a suspended environment, so the planning date is 15 December, not 15 January. Check the page before you quote the dates internally — deprecation timelines move, and that page is the source of truth.

What is in scope, and what is not

This is being widely overstated as "Microsoft is making Managed Environments mandatory". It is not. The deprecation is scoped to developer environments, and getting the scope right is worth doing before you send an email to the whole maker community.

• In scope: environments of type Developer that do not have Managed Environments enabled. That includes the free ones the Power Apps Developer Plan creates automatically, which is where the volume is.
• Not in scope: production, sandbox, trial and default environments. They are unaffected by this change, managed or not.
• Not happening: Managed Environments has not become a tenant-wide requirement. Your unmanaged production environments are not being switched off.

The narrower story is the more serious one. Production environments are inventoried, owned and backed up because somebody signed off on them. Developer environments are the opposite: created on demand, owned by one person, invisible to the people who would have to explain their absence.

Why a developer environment is not a scratch pad

In principle a developer environment is for building and testing. In practice, in a tenant that has been running the Developer Plan for a few years, a measurable share of what is in them is load-bearing: the approval flow somebody wired up for their own team, the tracker a department actually runs on, the integration that was going to be rebuilt properly once there was time. None of it went through a release process, which is exactly why none of it appears on anybody's list.

Two further reasons the contents are hard to reason about. A developer environment belongs to one person, so when that person has left, the apps inside are still running on their connections. And sharing a canvas app from a developer environment is restricted, which means the ones that are shared have usually been shared through a connection or a flow rather than directly — a dependency that does not show up as sharing at all.

Finding the environments takes a minute

In the Power Platform admin centre, open Environments and filter on type Developer, then look at the Managed column. Everything that is Developer and not managed is in scope. Export the list. That is the right first step and it is genuinely quick.

If you prefer the API, the environments listing on the Business Application Platform surface returns environmentSku and the governance configuration that carries the Managed Environments flag, per environment, tenant-wide, for an account with the Power Platform Administrator role. An account without that role gets only the environments it personally belongs to, and the API does not tell you it has filtered.

What the admin centre will not tell you

The list of affected environments is not the decision. The decision needs what is inside each one, and that is where the admin centre stops:

• What is in there. Canvas apps, model-driven apps, cloud flows, desktop flows, Power Pages sites, custom connectors and Dataverse tables — per environment, not as a total.
• Who owns each object, by name rather than by object id, and whether that account still exists.
• Who else is using it. Sharing on each app and flow, including the security groups, and the co-owners who would have to re-create it if it vanished.
• What it connects to. Not "SharePoint" but the specific site and list; not "SQL" but the server and database. This is what decides whether an app can be moved at all.
• Whether it is in a solution, which decides whether there is anything to export. Solution membership is not in the apps or flows APIs — it is in Dataverse.
• When it was last modified, per object, which is a far better signal than the environment's own last-activity date.

The two options Microsoft offers per environment

For each developer environment you want to keep, the remediation is either to enable Managed Environments on it, or to move the solutions somewhere supported. Both have a cost worth understanding before you pick one wholesale.

Enabling Managed Environments is not a free switch for developer environments. Microsoft states that Managed Environments use rights are not included in the Power Apps Developer Plan: users need a premium licence to run apps and flows in a managed developer environment. And going forward each user gets one managed developer environment, not the several some makers have accumulated. So "enable it everywhere" is a licensing decision, not an administrative one.

Moving the solutions is the cheaper answer for most of what you will find — but it assumes the work is in a solution, and in personal developer environments a great deal of it never was. That is a problem with its own article; the short version is that an app created from a blank canvas does not land in a solution unless somebody deliberately put it there, so there is frequently nothing to export.

The questions to answer per environment

1. 1Is there anything in it at all? A surprising number of developer environments are empty, and an empty environment is a free decision.
2. 2Does the owner still work here? If not, everything inside it needs an owner before anything else can happen.
3. 3Is any of it shared, called by something else, or connected to a production data source? Those three are what turn a personal experiment into a dependency.
4. 4Is each object inside a solution, and if not, which ones need to be put in one?
5. 5Does anything in it bind a premium connector? That decides what converting the environment would cost in licences.
6. 6Is there a newer version of this work already in production? Duplicates of something that already shipped are the easiest items to let go.

A sensible order of work

Inventory first, across the whole tenant and not just the environments you remember. Then sort: empty and abandoned environments are let go, work that matters is moved into a sandbox or production environment properly, and the genuinely active developer environments belonging to people who are still building get converted and licensed. Only then start moving things, dependencies first, so nothing arrives in a target environment missing the flow it calls.

The triage is the work. The moving is comparatively easy, and it is also the part that cannot start until somebody can say what is at stake.