Blog

Power Platform Developer Environment Deprecation: Act Before December 15th

Executive Summary (TL;DR)

Microsoft has deprecated unmanaged Power Platform developer environments, including those created through the free Power Apps Developer Plan. Creation ends November 15, 2026, suspension begins December 15, 2026, and deletion begins January 15, 2027.
The practical deadline is December 15. Once an environment is suspended, its apps, flows, agents, Power Pages developer sites, and data are unavailable.
Managed developer environments are not affected, but the Developer Plan doesn’t include Managed Environments use rights, so conversion depends on the licenses held by the people who use each workload.
A four-phase triage (discover, classify, decide, govern) protects what matters and gives makers a governed path for future development.

The Sandbox Nobody Is Watching Is About to Disappear

For years, the developer environment was the easiest yes in Power Platform. Anyone could sign up for the free Power Apps Developer Plan, get a personal environment with Dataverse, and start building. That convenience fueled a lot of good work. It also left many tenants with environments IT never provisioned, rarely reviewed, and in some cases can no longer tie to a current owner.

Microsoft is closing that path. Its deprecation of unmanaged developer environments and the Power Apps Developer Plan rolls out in three phases:

Creation ends November 15, 2026. Signing up for the Power Apps Developer Plan no longer creates a developer environment, and users can’t create new unmanaged developer environments from Power Apps, the Power Platform admin center, PowerShell, or the Power Platform CLI.
Suspension starts December 15, 2026. Existing unmanaged developer environments are suspended, and their apps, flows, agents, Power Pages developer sites, and data aren’t available.
Deletion starts January 15, 2027. Suspended unmanaged developer environments begin being deleted.

January 15 is the date in most headlines, but December 15 is when access to the affected assets stops. With year-end change freezes and holiday schedules in between, there is less working time than the calendar suggests.

Why This Matters to You

Developer environments often hold more than experiments. In the tenants we review, it’s common to find an approval flow a department runs every day, a canvas app a field team uses on their phones, a Power Pages developer site shared with a vendor, or a Copilot Studio agent in pilot. When the environment is suspended, all of it goes offline together.

Microsoft’s stated reason for the change is governance, and that is the right lens for your response. Unmanaged developer environments sit outside many of the controls admins rely on, such as Managed Environments policies, usage insights, and sharing limits. In practice, that means personal connections to production data, apps shared more widely than intended, and little visibility into which connectors are in use. The deadline is a good reason to learn what has been built, who depends on it, and what deserves to move forward.

Licensing comes next. The Developer Plan doesn’t provide Managed Environments use rights. Microsoft lists qualifying options that include Power Apps Premium, Power Automate Premium, Microsoft Copilot Studio, Power Pages, qualifying Dynamics 365 licenses, and certain capacity and pay-as-you-go options, and the requirement applies to the people actively using assets in a managed environment. Keeping an environment can carry a real cost, and that cost follows the workload’s users rather than the person who created it.

Interoperability and application lifecycle management are the quieter risks. Assets built outside solutions take more work to move, especially when connections, dependencies, and environment variables are involved. This also isn’t the only environment deadline on the board. Microsoft is retiring Dataverse for Teams environments too, with new creation ending November 15, 2026, suspension of environments that haven’t been upgraded on September 15, 2027, and decommissioning on October 30, 2027. One environment strategy can cover both.

Our Approach: The IncWorx Environment Triage Method

We treat this deprecation as a triage rather than a cleanup. The aim is to protect what’s at risk and leave your tenant with a developer environment model that is governed by design, so the next platform change runs through an established process. The method has four phases, and most organizations can complete it in the time remaining.

1. Discover

You can’t make decisions about environments you haven’t found. Build an inventory of every developer environment where Managed is No (step 1 below shows how), then add the owner, last activity, storage, and the assets inside each one. Organizations running the CoE Starter Kit or admin PowerShell can automate much of this.

2. Classify

This is where judgment comes in. Sort each environment into one of four groups:

Production in disguise: it supports an ongoing business process, or people depend on it to do their jobs.
Active development: a legitimate app, flow, or agent is still being built and tested.
Learning and experimentation: training, exploration, or proof-of-concept work.
Abandoned: no remaining purpose, or no reachable owner.

The classification matters more than the count, because each group calls for a different response.

3. Decide

Assign each environment a disposition:

Convert: enable Managed Environments when keeping the developer environment makes sense and licensing is covered.
Migrate: move solutions that support business operations into an appropriate organizational environment. This is the default for anything classified as production in disguise.
Archive: export solutions to an organizationally controlled location, then let the environment lapse.
Retire: let environments with no remaining value reach the end of their lifecycle.

4. Govern

The last phase keeps you from repeating the exercise. Microsoft recommends environment routing to give makers personal developer environments that are managed by default. Pair it with a review of the Developer environment assignments setting and clear guidance on where personal, team, and production work belongs.

At a Glance

Discover: an inventory of every unmanaged developer environment, its owner, and its contents.
Classify: each environment placed in one of four groups.
Decide: a disposition for each, completed before December 15.
Govern: routing, settings, and maker guidance for future development.

Step-by-Step Actions You Can Take Today

1. Pull the list this week

In the Power Platform admin center, go to Manage, then Environments, and filter where Type is Developer and Managed is No. Export the results and sort by Last activity. That one view shows the scope of the work ahead.

2. Find the owners and look inside

Contact each environment’s creator and ask what it contains and who uses it. Then verify for yourself, because names and original purposes drift over time. Check the apps, flows, agents, Power Pages developer sites, data, and connections, especially anything touching SharePoint, SQL, production Dataverse data, or line-of-business systems.

3. Flag anything the business runs on

If suspension would interrupt a business process or lock employees or external users out of something they rely on, move it to the front of the queue. These workloads usually belong in a governed organizational environment.

4. Confirm licensing before committing to conversion

Map who actually uses each workload you plan to keep, then check those users against the qualifying licenses. Where coverage is missing, migrating to an organizational environment or archiving is often the better answer.

5. Export everything worth keeping

Export solutions from every environment you plan to keep or archive, and store them in source control such as Azure DevOps or GitHub. Microsoft notes that solutions exported before suspension aren’t affected. Treat the export as insurance; the workload itself still has to be moved and tested.

6. Convert or migrate before December 15

A Power Platform admin can enable Managed Environments on the keepers, since makers can’t do it themselves. For migrations, import into the target environment, rebind connection references, set environment variables, and test with real users. Make these calls while you still have access.

7. Give makers a governed place to build

Turn on environment routing so makers land in a managed developer environment automatically. Each user can now create only one managed developer environment, and Microsoft states that a premium license isn’t required to create or preview an app or flow there, only to run assets. Publish a short guide explaining where experiments, team solutions, and production workloads belong.

Best Practices for Governed Developer Environments

Treat December 15 as the operational deadline.
Build in solutions from day one wherever practical.
Keep solution exports in organizationally controlled source control.
Separate personal development, shared testing, and production by purpose.
Give every environment a named business owner and technical owner.
Run business-critical automation under organizational identities.
Convert only where licensing and ongoing value justify it.
Pair environment routing with maker onboarding.
Fold Dataverse for Teams into the same review.

Real-World Example: Bringing Structure to Power Platform Development

The risks surrounding unmanaged developer environments point to a larger issue: what happens when Power Platform development grows faster than the governance around it?

IncWorx encountered that challenge with a manufacturing organization where demand for custom applications had outpaced the processes used to manage development. The organization was working across low-code apps, legacy systems, and manual deployments, with limited visibility into application versions, environments, and dependencies.

IncWorx helped establish a more structured Application Lifecycle Management framework with defined development, testing, and production environments. The solution also standardized solution packaging, integrated Azure DevOps for source control and version tracking, and introduced role-based access and approval workflows.

That structure produced measurable operational results. Deployment time was reduced by 60%, release errors decreased by 45%, and application consistency improved across the organization’s manufacturing plants.

The project wasn’t prompted by the current unmanaged developer environment deprecation, so the connection shouldn’t be overstated. What it demonstrates is the broader principle behind this transition: as Power Platform adoption grows, the environments, applications, and deployment practices around it need to mature too.

Common Mistakes to Avoid

Most problems with this deprecation won’t come from the platform. They’ll come from assumptions about what’s inside developer environments and how much time is left.

Planning around January 15. The deletion date doesn’t buy an extra month of access.
Assuming “developer” means unimportant. Judge each environment by how it’s actually used.
Converting everything by default. Confirm an environment still has a purpose before paying to keep it.
Treating an export as a finished migration. Preserving a solution and moving a workload are different jobs.
Missing less obvious assets. Agents and Power Pages developer sites belong in the inventory.
Leaving critical automation tied to one maker. Use the transition to fix ownership and connections.

Key Takeaways

The retirement of unmanaged developer environments is a firm deadline, and organizations that act early come out of it with stronger governance than they started with.

Unmanaged developer environments are suspended December 15, 2026 and deleted starting January 15, 2027.
Managed developer environments, including those created through environment routing, are not affected.
Conversion licensing follows the people who use a workload.
Inventory and classify every environment, then convert, migrate, archive, or retire it.
Export solutions to source control, then finish migrations before suspension.
Give makers a governed place to build going forward.

Know What’s in Your Tenant Before December 15

If you’re not sure how many unmanaged developer environments you have, what’s inside them, or which ones the business depends on, IncWorx can help. Our Power Platform team can inventory your developer environments, recommend the right path for each one, and set up a governance model for future development within the time left before suspension. Talk with our Power Platform team to get started.