Developer environment triage: let go, move, or convert

Say your tenant has forty unmanaged developer environments and the suspension date is in seven weeks. The instinct is to enable Managed Environments on all of them and deal with it later. That is the expensive answer, because Managed Environments use rights are not included in the Power Apps Developer Plan: every user who runs an app or flow in a managed developer environment needs a premium licence, and going forward each user gets one managed developer environment rather than the several some makers have accumulated.

The cheaper and more defensible approach is to sort the estate into three outcomes, and to be able to show the evidence behind each decision afterwards. Most of the forty will not be in the pile people expect.

Three outcomes, and the evidence each needs

In most tenants "let go" is the largest pile by a wide margin, and it is free. It is also the pile that needs the most defensible evidence, because deleting something somebody quietly depends on is the one outcome you cannot undo after 15 January.

Why "let go" needs more evidence than it sounds like

Three things make an object look abandoned when it is not. A flow that runs on a schedule has no recent edits but plenty of recent runs. An app shared with a security group looks shared with nobody if you only read the direct permissions. And an object nothing seems to use may be called by a flow in a completely different environment, which the called object itself holds no record of — the reference exists only on the caller's side.

So the test for "safe to lose" is not last-modified alone. It is: no sharing including groups, no inbound calls from anywhere in the tenant, no connection to a production data source, and an owner who either agrees or no longer works here.

Sequencing the middle pile

The "move" pile is the real work, and the order within it is what decides whether it goes smoothly. Two rules carry most of the value.

• Dependencies before dependents. A child flow moves before the flow that calls it; a flow moves before the app that calls it. Otherwise an app arrives in the target environment and fails the first time a button is pressed, with nothing in the import log to say why.
• Risk-banded, not alphabetical. The fragile items — many connectors, hard-coded endpoints, premium bindings, a departed owner — get attention while there is still time to fix them. Sort by ease and they arrive last, on 14 December, in the worst possible week.

It is also worth deciding the destination per object rather than per environment. Several developer environments frequently contain work for the same team, and consolidating that into one target is less effort than reproducing the sprawl.

If you run out of time

Past the start of December, the honest plan changes from triage to preservation. Export what cannot be lost, individually if necessary, even knowing the export does not import into a solution cleanly. A .zip of an app on a file share is worse than a proper migration and infinitely better than a deleted environment. Do that for the objects on the "move" list you have not reached, and treat converting as the fallback for anything too entangled to export in the time left.

Write down what you decided

This part gets skipped and it is the part people need in March, when somebody asks where an app went. For every environment: what was in it, who owned it, what the dependencies were, what was decided and why, and where the work ended up. For the "let go" pile particularly, the record of the evidence is the answer to the question nobody asks until the thing is gone.

It does not have to be elaborate. A write-up per app covering its data sources, environment, flows, screens, users and a diagram of its dependencies, or one bound document for a whole collection of apps, is enough for sign-off and enough for the question in March.

The shape of the seven weeks

1. 1Inventory the whole tenant, not just the environments you remember — including the objects inside each environment, their owners and their sharing.
2. 2Sort into the three piles, and record the evidence for each decision.
3. 3Resolve dependencies across the "move" pile, so each object travels with what it needs.
4. 4Create the destination solutions, add or convert the objects, and move in dependency order with the fragile items first.
5. 5Convert and licence the small "convert" pile.
6. 6Document the outcome per environment, then confirm the affected environments are empty of anything that mattered before the suspension date.

Steps one to three are most of the elapsed time and all of the risk. The moving is the easy part, and it is the only part most plans budget for.