Seven weeks and Christmas: planning the move off unmanaged developer environments

Microsoft suspends unmanaged developer environments on 15 December 2026 and deletes them from 15 January 2027. Counting from the end of October, that is about seven weeks — and it includes Christmas, a change freeze, and whatever else was already in the plan for Q4.

You will not move everything. Accepting that early is what makes the rest of it tractable, because the first real decision is not what to migrate. It is what to abandon.

Decide what you are not moving

A developer environment estate usually holds three kinds of thing, and they need three different decisions.

Work in progress that matters

Something half-built that somebody intends to finish. Convert the environment in place, or move the solution to a proper development environment. This is the smallest group in most tenants and the one people assume is the biggest.

Something that quietly became production

This is the dangerous category. It was never meant to last. It has no owner on paper, no test environment, no documentation, and somebody's month-end depends on it.

These are worth finding deliberately rather than discovering on 16 December. The signal is usage, not intent: an app in a developer environment with regular users is production regardless of what anyone calls it.

Abandoned experiments

Workshop output, a proof of concept from a project that got cancelled, a copy somebody made to try something. Let them go.

If you want a copy, export the solution first — solutions exported before suspension are not affected by any of this. An export sitting in source control costs nothing and removes the argument entirely.

Then work in waves

Not all at once, and not strictly one at a time. A wave is a set of apps that share dependencies, so they can be moved, tested and signed off together.

Grouping by dependency rather than by owner or by department is what stops the classic failure: app A moves in week one, the flow it shares with app B moves in week three, and for a fortnight both are subtly broken in ways nobody reports clearly.

The first wave should be the one with the fewest dependencies and the most forgiving users. You are testing the process as much as the apps, and the process will be wrong the first time.

Track state per app, not per environment

Environment-level progress hides everything interesting. An environment that is "in progress" could be one app from done or could have not started.

Per app, with a small fixed vocabulary — awaiting, ready in dev, pushed to UAT, passed, failed, blocked — you can answer "how far are we" with a number rather than an opinion, and the blocked ones surface as a list rather than as a surprise.

The counts that matter on a plan like this are the derived ones: how many connections have to be recreated, how many premium connectors need licensing before anybody can run anything, how many solutions have to exist in the target before the first import will succeed. None of those are facts anybody types in. All of them are facts about the estate.

The three questions a plan has to survive

Before you commit to a date, check the plan answers these:

• Who converts? Enabling Managed Environments needs a Power Platform or Dynamics 365 Administrator — not the maker, not an Environment Admin. If the plan assumes makers can do their own, it is already wrong. Part two covers why.
• Who is licensed? Users need a premium licence to run apps and flows in a managed developer environment. A conversion that completes on time and leaves people unable to open the app has not completed.
• What is definition of done? Not "imported". Imported, published, connections rebound, flows running, and somebody who uses it daily has said so.

The deadline you actually have

Microsoft's date is 15 December. Yours is whenever your change freeze starts — which in a lot of organisations is the first week of December, and in some is late November.

Work backwards from that, not from Microsoft's date, and the seven weeks are closer to four.

Power Insights builds the plan from the tenant rather than from a spreadsheet: it picks up the flows each app calls, flags the risks, groups work into waves, and tracks every app through to production. The plan stays accurate while the estate keeps changing underneath it, which a spreadsheet does not.

If you want a second opinion on your estate before the dates land, get in touch — a read-only look at the tenant takes an afternoon and usually changes the shape of the plan.

Start of the series: what you have, and which of it is already managed.