Managed vs unmanaged solutions

What it does

Unmanaged solutions are what you build in. Managed solutions are what you deploy. The real difference is that a managed solution is a serviceable unit — it can be updated, upgraded and uninstalled as a whole — and an unmanaged solution is just a container that happens to list some components.

Key facts

Delete an unmanaged solution and only the container goes. The customisations stay in effect and fall back into the default solution. Delete a managed solution and everything it contains is removed, including data in its custom tables and in its custom columns on other tables.
You can't export a managed solution. You export an unmanaged one as managed. The managed file is a build artifact.
You can't import a managed solution into the environment that holds its originating unmanaged solution. Testing managed behaviour needs a separate environment.
You can't edit components directly inside a managed solution. To change one, add it to an unmanaged solution — which creates a dependency, and that dependency blocks uninstalling the managed solution until you remove it.
Managed properties are what a managed solution actually protects. They're set while the solution is unmanaged in dev and take effect once installed elsewhere. Allow customizations is the master switch; beneath it sit display name, new forms, new charts, new views, change tracking, hierarchical relationship, sync to external search index, and a catch-all "can change additional properties".
Once installed, managed properties can't be changed in the target except by an update from the original publisher.
Relationships have exactly one managed property — Allow customizations — which governs every change to that relationship.
Managed customisations always import in a published state, so there's no publish step after a managed import.
Solutions are limited to 95 MB.

When to use / skip

Managed everywhere downstream of dev. That's the position, and it's the right one for anything a team maintains over time. The defensible exceptions are narrower than people claim but they do exist: a genuinely single-environment tenant with one maker and no test environment, where managed deployment buys ceremony and nothing else; and a short-lived proof of concept nobody will inherit. What isn't defensible is unmanaged in production because "managed makes it hard to fix things quickly". That's the argument for a fast deployment pipeline, not for giving up layering. The thing to say out loud is that unmanaged in production means every hotfix creates an unmanaged layer that permanently outranks your deployments — you don't lose the ability to fix, you lose the ability to deploy.

Configuration decisions

Which managed properties to lock, decided by what would break your solution if a customer changed it, not by a general preference for control.
Whether the client gets any sanctioned customisation surface at all in production, and if so, in which solution and under whose publisher.
Whether a component that's currently managed needs editing downstream, which is a design question — the answer is usually to change it in dev, not to layer over it.
Whether an environment is a development environment for a given solution, because that answer decides managed or unmanaged for that environment.
How you'll test managed behaviour, given you can't do it in the environment that holds the unmanaged original.

Gotchas

Deleting a managed solution deletes data. Custom tables in the solution, and custom columns it added to other tables, go with it. This is the one that ends careers.
Editing a managed component from an unmanaged solution creates a dependency that quietly blocks uninstalling the managed solution later. Nobody notices until they try.
Managed properties are effectively permanent once shipped. Get them wrong and only a publisher update fixes it.
Locking too much is as bad as locking nothing. Clients whose entirely reasonable label changes are blocked will make the change some other way, usually worse.
Unmanaged solutions provide no protection at all. Two teams working unmanaged in the same environment are editing the same single layer.

Consultant notes

Say the data-loss consequence of deleting a managed solution out loud, in a meeting, with the admin team present. Write it in the runbook. It's the highest-consequence, lowest-awareness fact in Dataverse ALM.
When a client insists on unmanaged production, ask what their rollback plan is. There isn't one, and the conversation usually resolves itself.
Set managed properties deliberately during design rather than accepting defaults at export time. It's a five-minute conversation about what the client is allowed to change, and it's much cheaper than the conversation after.
Keep the unmanaged solution as the source of truth and treat the managed file as disposable build output. If anyone is emailing managed zips around, the pipeline isn't real.

Worth revisiting when managed properties gain new options, or if the 95 MB solution ceiling moves.