Moving an app from an unmanaged to a managed developer environment

The plan usually starts as "export everything and import it somewhere else". For most developer environments that is considerably more work than the job actually needs.

There are two routes out of an unmanaged developer environment, and they are not equivalent. One of them moves nothing at all. Choose per environment, not per tenant.

Route 1 — convert it where it stands

Enabling Managed Environments on the existing developer environment leaves the apps, flows, connections and URLs exactly as they are. Nothing is exported. Nothing is re-imported. Nothing needs re-testing, because nothing moved.

In the Power Platform admin centre: Manage → Environments → the ellipsis next to the environment → Enable Managed Environments.

For most of the estate this is the whole job. Two things are worth knowing before you plan it, though, because both change the shape of the schedule.

Developer environments do not need Dataverse for this

Production, sandbox and trial environments all require Dataverse before Managed Environments can be enabled. Developer environments do not.

This matters because the usual objection to converting a developer environment — "we would have to provision Dataverse across dozens of these" — is not true. The conversion is available on a bare developer environment with a canvas app and two flows in it.

The maker who owns the environment cannot do it

Enabling or editing Managed Environments requires the Power Platform Administrator or Dynamics 365 Administrator role. Users with the Environment Admin security role or the Delegated Admin role are explicitly unable to change the property — on their own environment included.

So this is not a task you can delegate to the makers and chase. Every single environment is a ticket for a tenant admin. If you have ninety developer environments, that is ninety admin actions, and the clock runs out on 15 December.

Plan the queue properly, or script it. The admin centre has a PowerShell equivalent that takes an environment ID and a governance configuration, which turns ninety clicks into a loop over a list — and the list is exactly the inventory from part one.

Route 2 — move the content

Some environments should not survive. The usual candidate is the one that quietly became production: built as an experiment, shared with eleven people, now load-bearing for a process somebody depends on. Converting that in place preserves a mistake. It belongs in a proper environment with a lifecycle.

Moving it is a solution export and import, and there are four places it goes wrong.

1. It has to be in a solution first

Solutions are the unit of transport. Anything built straight into the environment — a canvas app created from the maker portal without choosing a solution, a flow created from a template — is not in one, and cannot be exported until it is added to one.

This is the step that turns a one-afternoon job into a one-week job, because nobody finds out until they go looking.

2. Export unmanaged or managed, deliberately

The convention is worth restating because getting it backwards is expensive. Unmanaged solutions are your source — they belong in the environment where development happens. Managed solutions are build artifacts, deployed to everything downstream.

If people will carry on developing in the target, export unmanaged. If the target is a test or production environment, export the unmanaged solution as managed.

Two constraints to design around: you cannot import a managed solution into the environment that still holds the originating unmanaged solution, and a solution file cannot exceed 95 MB.

3. Connections do not travel

A connection is a credential, and credentials are not portable. On import you are prompted to pick or create a connection for every connection reference in the solution, and to type a value for every environment variable.

Which means somebody has to know what each of those should be. "Pick a connection" is a question about identity: a production process authenticating as a named individual is a decision, not a default, and import time is a bad moment to make it for the first time.

On-premises data gateway connections are worse. They have to be removed and re-added with the correct gateway ID after the import, as a separate step.

4. An unmanaged import lands in a draft state

This is the one that generates support tickets. When you import a managed solution, components arrive published. When you import an unmanaged solution — the route you take for a dev-to-dev move — the changes arrive in a draft state and must be published before they are active.

The import reports success. The app does not behave. People read that as a failed migration and start again.

Either route, know what travels with the app

An app is not a self-contained thing. It calls flows, and those flows bind connectors the app never touches. Move the app, leave the flows, and it opens perfectly and does nothing — the button works, the approval never arrives.

The custom connectors are the ones to find before you start. A first-party connector already exists in the target. A custom one does not, and if it is missing the import fails late with an error that does not name it.

Two things bite once the environment is managed

Both are Managed Environments behaving as designed. Both surprise people who converted on a Friday.

Sharing rules apply asymmetrically

If the environment limits sharing — excluding security groups, or capping the number of individuals — the rules are enforced when someone tries to share. People who already have access keep it.

But an app that is already out of compliance enters a one-way state: the only sharing change permitted is removing people, until it complies. An app shared with "Everyone" in a developer environment becomes an app you can only un-share.

Allow up to an hour after setting the rules before they start being enforced, which is long enough to conclude they are not working and change something.

Solution checker enforcement can cancel an import

Managed Environments can run solution checker automatically on import, at one of three levels. On Warn, a solution with critical issues imports and you get an email. On Block, the import is cancelled before anything changes in the environment.

Two details make this manageable rather than alarming: only critical severity rules block, and specific rules can be excluded from enforcement. If one rule is going to take a quarter to fix across a large solution, exclude that rule and keep the rest.

And the licence, again

Worth repeating because it applies to both routes: users need a premium licence to run apps and flows in a managed developer environment. Managed Environments use rights are not in the Developer Plan. Convert the environment, do nothing about licensing, and the app is intact and nobody can run it.

Which route for which environment

The decision needs three facts per environment: is anything in it already in a solution, what does each app actually call, and which of those connectors are custom. Power Insights computes all three from the tenant rather than asking the maker to remember.

Next: turning this into a plan with waves, owners and a definition of done — in seven weeks that include Christmas.