In modern application management, there are several ways to deliver software. You can use the installers provided by the vendor (often called legacy or native installers), or you can create repackaged packages tailored to your environment.
Each approach has its own purpose and benefits, but the key question is:
Do you really need to repackage if the application already works reliably?
In most cases, using the original vendor installer is the safer and more efficient choice. It keeps the logic the vendor built, reduces complexity, and simplifies ongoing maintenance.
Repackaging is typically used only for those situations where using the original installer is impossible.
How often repackaging is actually used today
A decade ago, repackaging was the default way to prepare applications for deployment.
Most installers weren’t designed for managed environments, so IT teams had to rebuild them into standardized MSI packages before rolling them out through tools like SCCM.
Today, the situation is very different. With the shift to cloud-based management platforms like Microsoft Intune, the move to Windows 10/11, stronger security requirements, and growing automation – full repackaging is rarely needed anymore.
- Modern platforms accept native installers — Intune can deploy EXE, CMD, or script-based setups wrapped into
.intunewinwithout modifying the installer itself. - Vendors have improved their installers — most modern applications already support silent installation and proper uninstallation out of the box.
- Security policies discourage altering vendor packages — keeping the original installer reduces risk and keeps vendor support intact.
- Automation reduces manual work — companies prefer to streamline deployment pipelines rather than rebuild every package from scratch.
Internally, we’ve noticed the same trend: requests for full MSI repackaging have been steadily declining, while more and more projects are delivered using vendor installers without repackaging.
As a result, many organizations now use vendor (legacy) installers as they are and only turn to repackaging in rare, specific cases where it’s truly necessary.
What are the reasons to keep repackaging
Even though full repackaging has become less common in recent years, it hasn’t disappeared completely.
The overall trend shows that most organizations now rely on vendor (legacy) installers by default.
There are still situations where repackaging is the only practical option. For example, when applications don’t install correctly when deployed under the system context or simply don’t meet organizational requirements.
In some cases, organizations continue repackaging out of habit, following long-standing internal policies and processes rather than changing their approach.
Typical scenarios include:
- No silent install or uninstall keys
The installer requires user interaction and cannot be automated. - Installs into the user profile
The application installs under the current user context, which makes it hard to manage and update centrally. - Changing the default installation path or behavior
The vendor installer doesn’t allow adjusting where or how the app is installed, but your environment requires a specific structure. - Online installers
The setup downloads components from the internet during installation, which may break in offline or restricted networks.
In these cases, repackaging helps turn an unpredictable or incompatible installer into a controlled, manageable, and supportable package.
Why keeping vendor logic is usually the best choice
Within Apptimized Factory, we always start by analyzing each application individually. Before deciding on any packaging method, we review how the installer behaves. We check what logic it contains and whether it can be deployed as is.
Our priority is to keep the vendor’s logic whenever possible and here’s why it matters:
- Predictable behavior
Vendor installers contain the logic designed by the application developers:
custom actions, prerequisites, and post-install steps. Keeping this logic reduces the risk of unexpected behavior during actual use. - More stable structure for long-term maintenance
Keeping the original structure makes the package easier to maintain over time.
Repackaging often changes how the application is installed and can make troubleshooting harder later. - Lower risk of breaking the application
The less you modify the installer, the lower the chance of disrupting how the application works.
Repackaging adds an extra layer of complexity that can unintentionally affect its logic.
Because of this, if an installer can run reliably without modification, we prefer using it in its original (legacy) form. It keeps deployments stable and predictable, while avoiding the added complexity and potential risks of full repackaging.
If repackaging is truly needed, we also have the expertise to do it safely.
Don’t break what already works
While repackaging still has its place in specific scenarios, the overall trend is clear – most applications no longer require it.
At Apptimized, we always aim to keep the vendor’s logic whenever possible, ensuring stability, consistency, and predictable results for our customers.
If you have any questions or would like to discuss your packaging needs, feel free to contact us.
