For years, the free Power Apps Developer Plan has provided developers and makers with an accessible environment to experiment with Dataverse, build applications, test Power Automate flows and explore Power Platform capabilities without requiring production licensing.
That development experience is about to change.
Microsoft has announced the retirement of unmanaged developer environments, with restrictions beginning on 15 November 2026 and existing environments scheduled for suspension from 15 December 2026.
This isn’t simply another platform deprecation. It changes how developers access development environments, how organisations govern experimentation and potentially how much that experimentation costs.
Let’s examine what’s changing, who’s affected and what developers should do before the deadlines.
Which Power Apps developer environments are retiring?
First, an important distinction: Microsoft isn’t retiring developer environments entirely.
It’s retiring unmanaged developer environments, including those automatically provisioned when users sign up for the free Power Apps Developer Plan.
Developer environments will continue to exist, but only as Managed Environments.
According to Microsoft’s official deprecation announcement, the retirement follows three phases:
| Date | Change |
|---|---|
| 15 November 2026 | Creation of new unmanaged developer environments ends |
| 15 December 2026 | Existing unmanaged developer environments begin suspension |
| 15 January 2027 | Suspended unmanaged developer environments begin deletion |
Once suspended, developers lose access to the environment’s apps, flows, agents, Power Pages developer sites and data.
There are several important exceptions:
Existing managed developer environments aren’t affected, even where a user already has multiple.
Production, sandbox, trial and default environments aren’t included in this retirement.
Solutions exported before suspension remain available.
Going forward, users will be limited to creating one managed developer environment each.
Also, don’t confuse unmanaged developer environments with unmanaged solutions. The latter remain a normal part of Power Platform application lifecycle management (ALM).
Why is Microsoft making this change?
Microsoft’s reasoning centres on governance.
Unmanaged developer environments don’t participate in several governance capabilities available through Managed Environments, including advanced sharing restrictions, usage insights and Managed Environments policies.
As Power Platform adoption grows, organisations need visibility into what developers create, which connections they use and how applications are shared.
Moving development activities into Managed Environments enables more consistent administrative controls.
From a governance perspective, the direction makes sense.
However, improving administrative consistency introduces another consideration: the distinction between providing a governed development environment and providing an accessible development environment.
Those aren’t necessarily the same thing.
Power Apps licensing implications developers shouldn't overlook
Perhaps the most consequential aspect of this change is licensing.
Historically, the free Power Apps Developer Plan allowed makers to experiment with premium capabilities such as Dataverse and premium connectors within a developer environment.
However, the Developer Plan does not include Managed Environments usage rights.
Microsoft’s Managed Environments licensing documentation confirms that users, including makers running their own apps and flows, require appropriate licensing to run assets in managed developer environments.
Qualifying entitlements include certain standalone Power Apps, Power Automate, Dynamics 365 and other applicable product licences. Exact requirements depend on the workload.
This means converting an existing unmanaged developer environment to a managed one isn’t necessarily a cost-neutral change.
Consider an independent developer experimenting with a Dataverse-backed canvas app.
Previously, the free Developer Plan provided a suitable development and testing experience. Under the new model, continuing to run that application in a managed developer environment requires an appropriate licence.
Microsoft offers alternatives, including standard trial environments, but these aren’t permanent replacements for ongoing development.
The distinction matters particularly for students, independent developers and organisations supporting large communities of makers.
How to check whether your environment is affected
Before making any changes, identify which environments actually require attention.
Administrators can perform this assessment directly in the Power Platform admin center.
Step 1: Identify unmanaged developer environments
Open the Power Platform admin center.
Navigate to Manage > Environments.
Filter environments where Type = Developer.
Apply the additional filter Managed = No.
Review the Last activity column to identify environments still being used.
These are the environments affected by the retirement.
For organisations with multiple developers, I’d recommend documenting the environment owner, important solutions, last activity, licensing position and intended remediation.
Don’t assume an inactive environment is disposable. It might contain prototypes, reusable components or development work that hasn’t been exported.
Step 2: Decide whether to convert or migrate
Microsoft provides several options.
Option A: Convert the existing environment
Where licensing permits, administrators can enable Managed Environments without replacing the original environment.
In the admin center:
Navigate to Manage > Environments.
Select the affected environment’s ellipsis menu.
Choose Enable Managed Environments.
Configure the required settings and select Enable.
The environment retains its apps, flows, agents and data.
This approach avoids a full migration, but licensing needs to be addressed beforehand.
See Microsoft’s guidance on enabling Managed Environments.
Option B: Move your solutions
If conversion isn’t appropriate, export your solutions and import them into another supported environment, such as an organisational sandbox.
This is particularly relevant when development already follows a defined ALM process.
Option C: Use a trial environment
For short-term experimentation, standard trial environments remain available.
However, trial limitations and expiry dates make them less suitable for maintaining long-running development projects.
Exporting Power Apps solutions: don't forget the dependencies
For developers choosing to migrate, exporting the solution is an important first step.
In Power Apps:
Select the source environment.
Navigate to Solutions.
Select the unmanaged solution containing your components.
Select Export.
Publish changes, review dependencies and export the solution package.
Microsoft provides detailed instructions in its Export solutions documentation.
However, there’s an important distinction between exporting application customisations and migrating an entire working environment.
A solution export doesn’t automatically preserve everything needed to recreate the original experience.
For example:
Dataverse data: Table definitions can be included in solutions, but table records require a separate migration approach.
Connections: Connection references may need to be mapped to appropriate connections in the destination environment.
Environment variables: Environment-specific values should be reviewed and configured during deployment.
Dependencies: Apps and flows may depend on components outside the exported solution.
Other assets: Non-solution flows, agent configurations and Power Pages resources require individual assessment.
For configuration data, Microsoft’s Configuration Migration tool can help move supported Dataverse records.
After importing, test the application, reconnect dependencies, verify permissions and validate any cloud flows.
An exported solution isn’t a complete disaster recovery strategy unless you’ve verified that the required components and data can actually be restored.
What does this mean for the Power Platform developer experience?
There is a reasonable argument for Microsoft’s approach.
Managed developer environments provide greater consistency, administrative visibility and opportunities to enforce governance controls.
Organisations can also use environment routing to provision managed personal development environments automatically, reducing reliance on development in the default environment.
But governance comes with trade-offs.
A developer experimenting with a custom connector or learning Dataverse shouldn’t necessarily need the same administrative overhead as a team building a business-critical application.
The associated licensing requirements could also create additional barriers for independent developers and beginners.
This raises a broader question:
How do we establish appropriate governance without making experimentation unnecessarily difficult?
The answer shouldn’t be to abandon governance. Instead, organisations should differentiate between personal experimentation, team development and production workloads, applying proportionate controls and providing suitable development environments.
What should developers and administrators do before December 2026?
With suspension beginning on 15 December 2026, developers and administrators should act before their environments become inaccessible.
Start by identifying affected developer environments, exporting valuable solutions and reviewing whether existing licences support conversion.
Where migration is necessary, validate the target environment, dependencies, connections and data rather than assuming the solution package contains everything.
Finally, review how new developers will receive access to appropriate development environments going forward.
The retirement of unmanaged developer environments is more than an administrative change. It signals a continued shift towards centrally governed Power Platform development.
That direction has clear benefits for security and operational consistency.
The challenge will be ensuring that improved governance doesn’t come at the expense of the accessibility and experimentation that helped Power Platform become such a widely adopted development platform.
Good governance should make responsible development easier, not development itself harder.
