Exporting Dynamics 365 solutions between environments

Moving customizations between environments is a core part of Power Platform delivery, and doing it consistently is what keeps development, test and production in step. The mechanics are simple; the discipline around them is what matters. Get the habits right and deployments are boring — which, for deployments, is exactly what you want.

Environments and their roles

A healthy setup separates concerns across environments:

• Development is where change happens, in unmanaged solutions you can edit freely.
• Test (and often a staging or UAT environment) is where managed solutions are validated before they go live.
• Production receives only managed solutions, and is never edited directly.

Keeping these boundaries clean is the single most important habit. The moment people start making “quick fixes” directly in production, environments drift apart and you lose the ability to reason about what’s actually deployed.

Managed versus unmanaged

This is the distinction everything else hinges on.

Unmanaged solutions are editable. Your development environment holds unmanaged solutions because that’s where you’re building and changing components.

Managed solutions are the deployable, locked form. You export a managed solution from development and import it everywhere downstream. Managed solutions are layered and removable, giving you a clean lifecycle: you can update them, and you can uninstall them without leaving debris behind. That’s exactly what you want outside of development.

The rule of thumb: develop unmanaged, deploy managed. Shipping unmanaged solutions to production, or editing components directly there, is the fastest route to environments that drift out of sync and become impossible to maintain.

Order and dependencies

Solutions have dependencies, and import order matters. A solution that references components from another must be imported after the one it depends on — try it the other way round and the import fails.

Keeping dependencies explicit and deploying in the right sequence avoids the frustrating, hard-to-diagnose failures that come from importing things out of order. If you find yourself with a tangle of cross-dependencies, that’s usually a sign the solution boundaries need rethinking rather than a problem to solve at deployment time.

Connection references and environment variables

Anything that legitimately differs between environments — the URL of a service, an API key, the connection a flow uses — should be a connection reference or an environment variable, not a hard-coded value baked into the solution.

This is what lets the same managed solution move from test to production and simply pick up the right values in each place. Hard-coded environment-specific values are one of the most common reasons a deployment “works in test but breaks in production”, and connection references and environment variables are the built-in fix.

Automate it

Exporting and importing by hand is fine while you’re learning the mechanics, but production delivery belongs in a pipeline. Automating export, packing and import:

• removes human error — no more forgetting a step or picking the wrong solution,
• makes every deployment identical, so results are predictable,
• and gives you an auditable record of exactly what went where and when.

In fact, the manual steps described in this article are really a specification for what the pipeline should do for you, every single time. Once it’s automated, “deploying to production” stops being an event people brace for and becomes a routine, low-drama step.

A sensible checklist

Before promoting a solution, a quick mental checklist keeps things clean:

• Am I exporting a managed solution for anything past development?
• Have I set the right environment variables and connection references for the target?
• Am I importing dependencies in the correct order?
• Is this going through the pipeline, with the change tracked back to a commit?

None of it is complicated. The value is in doing it the same way every time — which is precisely what turns solution deployment from a source of anxiety into something you barely think about.