Solution upgrade, update and patches

What it does

When you import a managed solution that's already installed, Dataverse offers three actions under Advanced settings. They differ in one respect that matters more than everything else: whether components missing from the new version get deleted.

Key facts

Upgrade is the default. It moves to the latest version, rolls up all previous patches in one step, and deletes any component from the previous version that isn't in the new one. The result matches the importing solution exactly.
Stage for Upgrade does the same version move but defers the deletions until you later choose Apply Solution Upgrade. Both solutions sit in the environment concurrently in the meantime, which is the point — it's for data migration between the old and new shapes.
Update replaces the solution with the new version but leaves behind anything that's no longer in it. It's the fastest of the three and it lets dev and production drift apart.
Staged upgrades produce a second solution suffixed _Upgrade. Applying the upgrade uninstalls the previous patches and base solution, then renames _Upgrade to the base name. Microsoft notes that platform changes mean the single-step upgrade path no longer uses a temporary _Upgrade solution or an uninstall operation on the original.
Version format is major.minor.build.revision. An update needs a higher number in any position.
A patch carries only changes to a parent solution. It can add or update components; it can't delete them. One parent can have many patches, a patch has exactly one parent, and the parent must be installed in the target.
Patches are created from unmanaged solutions and should be exported and imported as managed. A patch's version must exceed the parent in build or revision, never major or minor — for a 3.1.5.7 parent, 3.1.5.8 or 3.1.7.0 are valid, 3.2.0.0 isn't.
After you create the first patch, the parent solution locks — no changes, no export — until every child patch is deleted.
Cloning a solution rolls all patches into a new base version and removes the originals. Microsoft's own guidance now warns against clone-a-patch and clone-solution as an update mechanism because it hurts team development and source control.
Removing a managed component from a target environment is done by upgrading a solution that no longer contains it. The alternative — deleting the managed solution — removes everything and its data.

When to use / skip

Upgrade, by default, every time. It's the only one of the three that guarantees the target ends up looking like the source, and consistency between environments is the entire reason you're doing ALM. Use Update when you're deploying under time pressure and you know nothing has been removed — it finishes faster, and that's its only advantage. Use Stage for Upgrade when the new version changes the shape of data enough that you need both versions live to migrate between them; that's a planned, rehearsed operation, not something you pick from a dropdown on the day. Skip patches entirely for team-developed solutions. They lock the parent, they complicate source control, and Microsoft now steers away from them. Version the whole solution instead.

Configuration decisions

Upgrade versus Update as your standing policy, and who is allowed to deviate.
Whether a release needs staging, which comes down to whether data has to move between old and new component shapes.
Version numbering scheme, and which position increments for which kind of change.
Whether to enable plug-in steps and flows included in the solution on import, which is a separate checkbox and a separate decision from the upgrade action.
Whether Overwrite Customizations is ever used, given it removes unmanaged customisations on the components in the solution.

Gotchas

Choosing Update because it's quicker is how environments drift. Six months of Updates and production contains components that no longer exist anywhere in source.
Deleted components on upgrade catch people out in the other direction too: remove a column from the dev solution to tidy up, upgrade production, lose the data in that column.
The parent solution locking after the first patch is created stops the dev team dead and the error message doesn't explain why.
A patch can never remove anything. Teams use patches for hotfixes, then discover the hotfix that needs to remove a component requires a full upgrade anyway.
Stage for Upgrade leaves the environment in a half-finished state that looks fine until someone notices two solutions with similar names. Applying the upgrade is a required second step, not optional cleanup.

Consultant notes

Write the upgrade action into the deployment runbook so it isn't a judgement call at 7am. "Advanced settings > Upgrade" as a literal instruction.
Before any upgrade that removes components, get someone to confirm in writing that the data in them is expendable. Component removal is data removal.
If a client is running a patch-based release process, plan the migration off it. Roll the patches into a base version, move to whole-solution versioning, and put the solution into source control.
Rehearse staged upgrades in a copy of production. The data migration step in the middle is where they fail, and it's not the part anyone tests.

Revisit once the reworked single-step upgrade behaviour is fully rolled out, or if patch guidance changes again.