You install the new version expecting it to replace the old one, but it doesn’t.
Suddenly both appear in Add or Remove Programs, user settings get mixed up, or the application behaves unpredictably.
Application upgrades often look simple, but behind the scenes they rely on a delicate balance of version logic, GUIDs, and uninstall conditions.
Even a small inconsistency can leave traces of the old version behind, creating unpredictable results and breaking stability.
That’s what makes upgrades one of the most technically demanding parts of packaging — a process that requires precision, consistency, and attention to detail.
Why It Happens
An application upgrade looks straightforward in theory, but it’s one of the most fragile packaging processes in practice.
Everything depends on how the original installer was built and how the upgrade logic is defined.
When even one link in that chain is missing, the result is not a clean replacement but a second, parallel installation.
A few technical details are usually to blame:
- Inconsistent product identifiers.
Every MSI has three key GUIDs: ProductCode, PackageCode, and UpgradeCode.
When the UpgradeCode changes between versions, or even worse, generates dynamically within the same version, Windows no longer recognizes the new installer as a replacement for the existing one.
As a result, Windows installs it as a separate product, which often causes version stacking and conflicting components. - Changed naming conventions.
Vendors sometimes modify the Product Name or Publisher field with each release.
That simple change breaks continuity for version tracking, because the system no longer sees the new version as part of the same product line. - Incomplete major upgrade logic.
The Upgrade Table in MSI defines which products should be removed before installation.
If this table is misconfigured or omitted, the new version installs without touching the old one.
Even the order of actions such as RemoveExistingProducts in the sequence table affects whether the process works correctly. - Lack of built-in upgrade logic in EXE installers.
Unlike MSI, many EXE-based setups don’t include internal mechanisms for handling upgrades.
As a result, the new version installs independently, leaving the old version’s components untouched.
Each of these details may seem minor when packaging a single version, but together they determine whether the upgrade process will work predictably or cause silent inconsistencies that surface much later.
How It Shows Up in Real Environments
When the upgrade logic lacks proper definition, the first symptoms seem subtle but eventually cause long-term instability.
Two versions of the same application might quietly coexist. Old registry entries and files remain untouched. Shortcuts can point to outdated executables, and uninstall operations remove only part of what was installed.
The upgrade may seem successful on the surface, but the application continues to run as an older build, with legacy components still present.
These small inconsistencies create technical debt that grows over time, making each new version harder to manage.
For end users, it looks like a minor glitch. For packaging engineers, it clearly shows that the upgrade path requires rebuilding to maintain one clean, continuous installation chain.
How We Simplified It
Some installers include built-in logic for handling upgrades, but many do not.
In such cases, packagers have to manage the process manually, and it often becomes inconsistent because every vendor uses different installation logic.
To make this process predictable, we extended PSAppDeployToolkit v4 with a dedicated Apptimized function that handles upgrades in any scenario, regardless of how the original installer was built.
Our function allows multiple clean-up strategies:
- uninstall MSI installers by ProductCode,
- uninstall MSI installers by DisplayName from Add & Remove Programs (with Match and RegExp options to remove all possible previous versions under the same DisplayName),
- uninstall legacy setups by specifying the path to a particular uninstall.exe with custom parameters,
- uninstall legacy setups by DisplayName from Add & Remove Programs (again with Match and RegExp support).
This flexibility ensures that any previous version can be detected and removed automatically before the new one is installed, keeping the system clean and stable.
Our customized flavor of PSAppDeployToolkit makes upgrade handling simple and reliable across both Apptimized Factory and Apptimized Workspace.
Factory engineers use it to manage complex customer environments, while Workspace users can access the same PSADT version directly in the packaging tool enabling them to wrap applications and configure upgrade logic easily on their own.
Making Upgrades Simple
Upgrades are one of the least visible yet most impactful parts of application packaging.
When handled correctly, they keep environments predictable and maintainable, no matter how many versions are released over time.
With our enhanced PSADT functions, upgrade management becomes simple, consistent, and fully under control, turning a hidden challenge into a smooth, automated process.
