When some of us began packaging 25 years ago, command-line support was rare, and repackaging was the only way to silently deploy new and updated applications. With the introduction of Windows Installer, a compelling standard emerged that was the perfect target for repackaging applications. Since that time, Windows Installer has been shifting out of favor, and thoughtful command-line support for customized, silent installations has been on the rise. When you also consider that most modern installation authoring tools provide at least basic support for silent or unattended installs, it's not surprising to see command-line deployment become the preferred method for many organizations.
Vendor installers have steadily improved, and today’s command-line options are often all you need to get the job done. Whether it's through tools like WinGet, Patch My PC, Evergreen, Chocolatey, or App Readiness (which also offers repackaging), it's now much easier to take advantage of vendor setups as-is. This shift has led more teams to rely on native command-line support rather than repackaging—accelerating deployment while keeping things simpler and more supportable.
This article is part of a short series exploring modern approaches to enterprise application deployment. Next up: The Case for Repackaging, followed by Command-line vs. Repackaging: Choosing the Right Approach to balance patch catalogs, repackaging, and automation.
Speed
It’s always faster to use a vendor's setup than to repackage it. Identifying and validating command-line parameters that meet your needs is generally a one-time task—and a relatively fast one. It is unusual for a new version of an application to significantly change its command-line support. Even the first time through, repackaging is normally a more time-consuming approach. App Readiness narrows that gap significantly by automating the repackaging and smoke testing process, but when possible, skipping repackaging entirely still wins in terms of time invested.
Capability
The vendor’s own setup is going to be the most complete and intelligent installer available. Repackaging can introduce limitations, especially when format constraints conflict with advanced logic baked into the original setup. In some cases, these installers make changes that technically resist repackaging—updating Windows protected files, modifying drivers, or other low-level system alterations. Workarounds do exist, usually in the form of complex authoring of setups with custom actions, but they come at a steep cost in time investment and require specialized expertise. By contrast, using the vendor's command-line options is often both effective and immediate.
Vendor Support
Using the original installer always preserves vendor support. It isn't a surprise that most vendors make it clear that if you alter the package, support is no longer guaranteed. It's been a while since I encountered it, but I have seen a few vendors go out of their way to break inherent support for silent command lines in an effort to prevent silent deployment. More often, they might introduce friction: withholding silent install switches from standard documentation, requiring you to request the information or obtain a special "enterprise version" of the installer. Some introduce friction in the form of requiring a license acknowledgment as a command-line argument (for example, -EULA=True). These moves are rare, but when encountered, they can make the command-line path slower for some. Ultimately, if you modify a product's installation, it's your responsibility if it doesn't work. Should a vendor become aware that you repackaged their installer, you can expect to spend time and effort reproducing any problems with application functionality on a system with the application manually installed to confirm that the issue is unrelated to your repackaged setup.
Availability of Command Line Options
It is now quite uncommon to encounter any recent application installer that doesn’t offer at least basic command-line support. Silent and passive install switches are frequently built in, and documentation or community resources often reveal them even when not published by the vendor. As a result, what once felt like a niche convenience has become an expected part of modern software deployment.
This doesn’t mean repackaging is obsolete. It’s still the right answer in many scenarios—but increasingly, it's the fallback, not the starting point. In a related post (available here), I cover when to make that call and how to integrate multiple approaches into a modern, efficient packaging process.
Customizations
Customizations are an important part of the story. I’ll speak more on that in separate posts, including how tools like PSADT help reduce the friction of customization even when using vendor setups. I’m also seeing more teams deliberately reduce customization to move faster—a notable shift from the earlier mindset where capturing and including every suggested tweak was the norm when repackaging.
If your packaging practices haven’t evolved in a while, now is a great time to re-evaluate. The tools have changed. The expectations have changed. And with the right approach, you can move faster without sacrificing reliability or support.
Stay tuned for the companion piece, The Case for Repackaging, where I’ll dive into the situations where command-line options fall short—and why maintaining strong repackaging skills remains important for any modern packaging team.
Topics:
