In my last article, I made the case for command-line packaging for Windows applications as the modern default. But that doesn’t mean Windows application repackaging is obsolete. It used to be the only viable way to standardize deployments—and while its role has diminished, it still has value when used deliberately. While the need for it has declined in recent years, some organizations continue to rely on it for higher levels of control. In this follow-up to my previous article on command-line packaging, I’ll explore both the valid and questionable motivations for Windows application repackaging and where I believe it still earns its place.
This blog is part of a series that I have written on the arguments for and against modern ways of managing Windows applications and how you should think about your approach as we move forward:
Let’s dive into some reasons why some teams still repackage Windows applications—and the arguments to substantiate them.
Although it is common for organizations not to repackage Windows applications, there are still valid, strategic motivations why repackaging makes sense. In the right situations, it can provide real value—especially when command-line deployment falls short or is simply not supported by the vendor or internal development team that created the application. Whilst the creator of the Windows application should be the best source of knowledge on how to install or upgrade it (and therefore have built a process to handle it properly), a manual repackaging will confirm that the behaviours for the change are consistent and expected.
While command-line support is commonly available today, identifying the correct options can still be challenging—especially for older applications or those developed in-house. In some rare cases, silent installation might not be supported at all.
Even when command-line switches are available, they may not be sufficient. Some applications may revert to the wrong edition, become unlicensed, or overwrite desired user customizations when deployed in this manner. In these situations, repackaging provides a more reliable path—ensuring the deployment meets expectations without introducing post-install surprises.
Solutions like Juriba App Readiness help identify and test command-line support more quickly by offering application-specific recommendations, powered by its own knowledge base, online repository data, programmatic assessments, and AI-driven suggestions.
There are times when you need to make changes that go beyond what’s possible with command-line switches—and you don’t have the time, tools, or interest to script them. Repackaging offers a faster and simpler alternative by embedding these changes directly into the package.
This is especially useful when dealing with settings chosen during the application's installation wizard or after first launch. Capturing those outcomes through repackaging can be far more straightforward than scripting them—particularly when the application doesn’t expose the necessary switches.
Scripting requires a deeper understanding of how the application behaves, what it modifies, and where it stores its preferences. It also takes time to write and test a solution. Repackaging sidesteps much of that effort by capturing and deploying those outcomes as part of a single, self-contained package.
In these scenarios, repackaging becomes not just viable—but the most efficient way to meet installation requirements without excessive manual effort.
Thefollowing justifications should no longer apply and are often rooted in habit or outdated assumptions. While they may have made sense in the past, they’re now more likely to introduce unnecessary complexity, ultimately resulting in slower (and at times more error-prone) deployments.
This mindset is common but unhelpful. Just because a process has worked in the past doesn’t mean it remains the best choice. Continuing to repackage everything without re-evaluating the alternatives wastes time and effort that could be better spent elsewhere.
Some argue that repackaging provides them with greater insight into what is being installed, thanks to the table-based structure of formats like MSI. While technically true, this level of transparency rarely translates into practical value—especially when it comes at the cost of added complexity and reduced supportability.
A desire for uniform deployment formats often leads teams to repackage everything into a single format—typically MSI. While consistency has value, it shouldn’t be achieved at the expense of flexibility. Forcing all deployments into a single mold adds unnecessary overhead when the original installer already does the job well. Those who are particularly stubborn about maintaining a single deployment format may also be compelled to spend an inordinate amount of time trying to make troublesome applications conform through setup authoring-- the most costly way to produce deployment packages.
Rollback support, logging, and advertised shortcuts are occasionally cited as reasons to prefer repackaging to Windows Installer (MSI). While these features have merit, they’re rarely critical—and many can be replicated or replaced with modern scripting or deployment practices when needed.
Rollback and logging support, for example, are certainly useful—but they typically indicate a package failure. In practice, these features tend to matter most when repackaging itself introduces instability. A vendor MSI failing to install and rolling back with helpful logs should be an extremely rare event, not a common occurrence or primary benefit.
Advertised shortcuts are another often-mentioned feature. This can help install user-specific components on demand, but it is a double-edged sword. From the end-user’s perspective, watching Windows Installer unexpectedly launch to obtain missing components can feel like an error, even resulting in support tickets. Workarounds like ActiveSetup are available, and for many teams, avoiding this behavior leads to a more stable user experience overall. While advertised shortcuts can be helpful, they’re rarely critical-- and for specific cases when they are seen as critical, repackaging could be appropriate.
Repackaging still has a place—but it works best when treated as a fallback for cases where command-line options aren’t viable or sufficient. The goal is to deploy reliably and efficiently, and that means choosing the best method that fits the application in question (which I get into more here).
In the right context, repackaging can save time, avoid scripting complexity, and help work around installer limitations. But it should be chosen for the right reasons—not just because it’s what you’ve always done.
If command-line packaging is your primary approach, you're already on the right track. Just don’t shelve your repackaging tools—keep them ready for the cases where that approach isn't right and flexibility and control matter more.
Command-line packaging vs. repackaging blog series
- The case for Windows application command-line packaging
- The case for Windows application repackaging (current article)
- Command-line Windows application packaging vs. repackaging: Choosing the right approach (coming soon)
- How to modernize your Windows application packaging approach (coming soon)