Intune has no "update this app" button for Win32 apps. A new version is a new app object with its own package, commands and detection rule, and supersedence is the relationship that tells Intune the new app stands in for the old one. Set it up well and updates flow with no change to assignments. Set it up badly and two versions of the same app take turns installing over each other.
What a supersedence relationship does
You open the new app (version B) and declare that it supersedes the old app (version A). From then on, on a device where A is detected and B is assigned, Intune installs B. What happens to A first depends on the one choice you make per relationship:
| Mode | What Intune does | Use it when |
|---|---|---|
| Update | Installs B over A. A's uninstall command is not run. A's assignments keep applying to B. | The same installer technology and scope, and the vendor's installer upgrades in place (nearly every version bump). |
| Replace | Runs A's uninstall command first, then installs B. | The installer technology or scope changed (EXE to MSI, per-user to per-machine), or the vendor's upgrade leaves the old version behind. |
Both modes depend on A's detection rule: Intune only knows A is present if A's rule says so. A rule that still matches after B is installed (a file that both versions share, a version compared with equals on the wrong field) is how the two versions end up fighting.
The rules of the chain
- Relationships form a chain: C supersedes B supersedes A. Intune follows the chain up to ten nodes deep; keep it shorter by retiring old versions.
- Assign the newest app. Devices that have any older version in the chain get the newest one; devices with nothing get a fresh install of the newest one. You do not need to keep old versions assigned, and keeping an old version assigned as Required is the most common way to create a fight.
- Supersedence is evaluated with the rest of the app's requirements and detection, roughly every 24 hours for required assignments and at check-in. An update therefore reaches a fleet over a day, not a minute.
- It is Win32-only. MSIX apps published as the native type are updated by uploading a new version to the same app, and the Enterprise App Catalog and macOS app types have their own update paths.
- Dependencies and supersedence are separate graphs. An app can have both, but a dependency on an app that is itself superseded is a chain nobody wants to debug.
Mistakes that leave two versions fighting
The old version stays required
A is Required to All Users, B supersedes A and is Required to the same group. On a device with B installed, A's rule no longer matches, so A's assignment wants to install A, which B then supersedes again. Move the assignment to B and leave A unassigned (or assigned as Available only).
Detection that cannot tell A from B
If A detects "chrome.exe exists", A is detected forever and B is installed on every evaluation. Detection rules in a supersedence chain must be version-aware: A detects its version (or "at least its version"), B detects at least B's.
Update mode with an installer that does not upgrade
Some vendors install side by side (Python, several JDKs, year-versioned suites). Update mode then leaves A in place and both show in Programs and Features. Use Replace, or deploy the vendor's own in-place upgrade package.
Replace mode with a broken uninstall command
Replace runs A's uninstall first; if that command was never tested (it usually was not), the whole update fails at the first step. Test uninstall commands when you create the app, not when you need them.
Rolling back
Supersedence has no reverse gear. To go back from B to A you create the relationship the other way: A (re-uploaded or the existing object) supersedes B, usually in Replace mode so B is uninstalled first, and A takes the assignments. It works, it takes the same day to propagate, and under pressure it is easy to get the mode or the assignments wrong. Which is the argument for staged rings: find the bad build on ten devices, not a thousand.