I hear a lot of talk about Windows application modernization. In conversations with enterprises, I find that people often mean different things when they use the term. For some, modernization is about adopting a new deployment format like MSIX. For others, it’s about moving management to Intune. And for many, it’s about changing their existing packaging and testing processes so they can keep pace with constant updates.
Because I’m regularly asked for advice on this subject, I want to share a straightforward guide that captures the practical approach I recommend when it comes to modernizing Windows application packaging. This blog is the final one in the series that I hope will help you formulate your Windows application modernization journey.
In this article, Windows app modernization is about process change. The old model was slow: repackaging most apps, layering customizations, coordinating testing, and waiting weeks to deploy. The modern model is fast and automation-friendly: default to simple, repeatable installs; reserve heavyweight packaging for exceptions; and use automation to keep pace with constant updates.
Inventory scope: separate managed vs unmanaged applications, and acknowledge unmanaged as a conscious risk, not an out-of-scope problem to be ignored. Historically, apps below a threshold (N installations) would be excluded. With automation, N must be recalculated. It is often faster and safer to manage even apps with limited deployment than to wait for security tools to raise alerts.
Effort profile: capture where time is going today on customizations and repackaging; note apps driving repeat work.
Constraints and goals: define supported deployment tools, turnaround targets, and compliance requirements.
Default approach: vendor silent command lines wrapped in PSADT.
Rationale: consistent logging, user experience control, parameterization, and fewer moving parts.
Rationalization benefit: With a well-managed PSADT template, many common customizations can be centralized and reused in a consistent, repeatable way, instead of being reinvented for each application.
Policy stance: push back on customizations that don’t deliver measurable value; every exception slows you down.
Packaging automation: take consistent input (installer, command line, PSADT wrapper) and produce repeatable packages.
Smoke testing: install and validate on clean VMs, with logs and screenshots to prove results and fail fast when issues arise.
Publishing automation: promote good packages to Intune or ConfigMgr with version control.
The point is to reduce the work of repetitive, low-value steps so more applications can be handled at scale.
Smoke testing: automated and fast. Catch obvious problems early and avoid wasted time downstream.
Functional testing: used sparingly, reserved for critical applications that have a track record of causing issues. It is not a scalable default.
Pilot deployments: the real proving ground. A small but representative ring one deployment will surface environment-specific issues that cannot be easily predicted. Pilot testing minimizes the need for heavy functional testing while still catching real-world problems.
When to repackage: only when the fast path cannot meet requirements.
MSI: often chosen for familiarity and the control model it provides to teams that know it well, but not universally suitable (e.g., protected files, drivers).
MSIX: offers lifecycle benefits such as clean uninstall, simpler updates, and App Attach when compatibility allows.
Repackaging and automation: Repackaging does not need to mean going back to a slow, manual process. Solutions exist that can incorporate repackaging into an automated workflow, keeping exceptions manageable.
Guardrails: document criteria for exceptions and make the process repeatable and auditable.
Patch catalogs: valuable, but often cover only about a third of enterprise portfolios. Relying too much on them leaves large gaps.
Unmanaged applications: historically ignored due to resource constraints, yet still part of the risk landscape. Automation makes managing these applications practical, even when installed on only a handful of machines. Proactive packaging and updating here reduces the reactive churn of alarms and urgent fixes driven by security tools.
Together: modern processes mitigate both problems. You maximize catalog value while expanding beyond it to increase coverage and shrink the unmanaged estate.
Lead time: from new version to deployment, measured in hours or days, not weeks.
Throughput: packages delivered per week or month.
Coverage: percentage of the portfolio under automated management.
Exception rate: proportion requiring repackaging, tracked and minimized over time.
Quality: smoke test pass rates, rollback frequency, and incident counts after release.
Decision rights: clarify who can request and who must approve exceptions.
Defaults as policy: make “fast path first” the enforced standard.
Hygiene: retire legacy customizations that no longer provide value but add friction.
The modernized process is format-agnostic and automation-first. Start with command lines and PSADT because they are fast, reliable, and highly automatable. When that isn’t enough, choose the fallback intentionally:
MSI: familiar to many teams and offers control, though not a universal solution
MSIX: brings lifecycle advantages—clean uninstall, simplified updates, App Attach, and isolation benefits—when compatibility allows
The key is that repackaging need not mean slowing down. When built into an automated process, it remains part of a modern pipeline rather than a step backward.
Too much customization: every tweak adds maintenance; demand justification and ownership
One-off tooling: ad hoc scripts or manual steps break automation; standardize instead
Unclear exception policy: set rules for when heavy customization or testing is justified
Ignoring uninstall and rollback: define both as required outputs
Treating catalogs as complete: don’t ignore what falls outside catalog coverage; automation makes it feasible to manage more
| Aspect | Old way | Modern way |
|---|---|---|
| Default approach | Repackage into MSI | Vendor command line + PSADT + automation first |
| Customization | Heavy and pervasive | Minimal, value-justified, and centralized in PSADT |
| Speed | Weeks | Hours or days |
| Scale | Human-bound | Automation-driven |
| Format stance | Single format mindset | Dynamic: format-agnostic with automated fallback |
| Coverage | Catalog plus a limited managed set | Patch catalog coverage plus unmanaged apps addressed |
| Testing | Manual, functional-heavy | Automated smoke, targeted functional, pilot rings |
Select 10 representative apps and run them end-to-end through the fast path
Stand up automated smoke testing to fail fast and capture proof
Integrate publishing into Intune or ConfigMgr
Define and enforce exception criteria; document each exception
Begin measuring lead time, throughput, coverage, and exception rates
Add a pilot ring and use it consistently to catch environment-specific issues
Revisit unmanaged apps: treat them as a conscious risk until automated packaging makes them practical to manage
Modernizing packaging is changing how you work so you can move faster with the staff you already have. Start with a fast default, automate the repetitive tasks, and build in testing that balances assurance with speed. Use repackaging as plan B, but in a way that stays within the automation process. By expanding beyond catalogs and revisiting unmanaged applications, you gain coverage, consistency, and security. Do this, and you will not only keep up with the pace of updates but also shrink risks that have long been accepted by default.