Free tool
Application Advisor
Which method for which application, how many to package, and does a third-party tool pay for itself?
Describe your families of applications — where they come from, what they demand, what they weigh — and the tool names the Intune delivery method that suits each one: managed catalogue, Store, winget, or a Win32 package. It counts the ones that genuinely need packaging, works out what that costs the first time and then every year, and sets the arithmetic of a third-party factory against the quote you were given.
No sign-up, no cookie: what you enter stays in your browser and is gone when you close the tab — none of it leaves. Only the visit itself is counted, by a cookieless audience measurement that does not identify you, described in the legal notice.
The estate, and what it can spend
Two of these answers veto every family at once: whether any link gives you pause, and whether the managed catalogue is covered by your licences. The rest turn a count of applications into days, and days into money.
Your families of applications
A family is a set of applications that would answer the questions below the same way: “common vendor products with no configuration”, “business applications packaged by hand”, “in-house development”. An application you want to arbitrate on its own makes a family of one.
The plan
Every day-count shown derives from one number you gave: what packaging a standard application costs here. The tool scales it by the customisation you declared and by how many versions you deploy, and assumes a repackaging costs a fraction of a first packaging. Those ratios are conventions, stated in the disclaimer, not measurements. Measure twenty real applications before quoting a figure to anybody, and run this again: it is an evening's work and it changes the whole case.
A decision aid, not an audit. The tool reasons on what you declare; it sees neither your catalogue, nor any vendor's real coverage of your products, nor what your applications do at install time. The licensing position of the managed catalogue moved in 2026: check it on the day you read this rather than assuming it.
The strategy
Six methods, and none covers a catalogue on its own
Choosing between a Win32 package and a Store app is not a decision about how a file is uploaded. It is a decision about who owns the next version, where its bytes come from, and what you are still allowed to control once it is in production. What follows is what you need in order to decide.
The six methods, and what each one commits you to
A method is not a packaging format: it is a lifecycle. It decides who produces the next version, where its bytes come from every time it changes, and what you are still allowed to modify. It decides neither who receives the application — that is the assignment model — nor whether the application deserves to exist, which only rationalisation settles.
| Method | Who owns the next version | Where the bytes come from |
|---|---|---|
| Standard Win32 | You, package by package | Intune CDN — sharing and cache apply |
| Win32 + winget | The vendor, through the public repository | Vendor CDN — no sharing, no cache |
| Store app | The Store, on its own calendar | Store CDN for UWP; vendor CDN for Win32 |
| Managed catalogue | Microsoft, for its catalogue | Intune CDN — sharing and cache apply |
| LOB (MSI) | You, with fewer tools than Win32 | Intune CDN — sharing and cache apply |
| Third-party factory | The tool, on rings you define | Intune CDN — sharing and cache apply |
LOB (MSI) is not offered by the tool: it accepts no custom detection, no dependency and no supersedence, and everything it can do, the Win32 package does better. It survives only where a vendor contractually forbids repackaging.
The bandwidth verdict: two methods leave the network out of the picture
It is the criterion that settles the most cases and is discussed the least. Content served by the Intune CDN goes through Delivery Optimization and Connected Cache: one machine on the site pays for the download, the rest are served locally. Content served by a vendor CDN — winget, and Win32 applications published to the Store — goes through neither: every machine pulls the whole binary, at every version, and nothing in the console shows it.
The arithmetic is blunt and it is the one to put in front of whoever wants a winget-first catalogue: a hundred-megabyte application, made required on a site of three hundred machines, is thirty gigabytes through one link — and as much again at the next version. The same application delivered as Win32 crosses that link once.
The rule
- Required on a constrained site: the content comes from the Intune CDN, no exceptions.
- winget and Store-published Win32 stay legitimate in self-service, where only the people who ask download.
- Below fifty megabytes nothing is shared between peers by default: lower the threshold if your packages are small.
- A decommissioned distribution point becomes a cache node, not a server to switch off.
What does not show
- A Store-published application can be UWP or Win32, and the console does not say which: the first is served like the Intune CDN, the second not at all.
- No Intune report measures what went through a vendor CDN: the saturation shows on the router, not in the console.
- A family moved from self-service to required changes its network verdict without anybody redoing the arithmetic.
- A package's weight grows at every version: the calculation from two years ago no longer holds.
The update debt: what nobody costs
A catalogue is not migrated once, it is updated for as long as it exists. The initial packaging effort is visible and gets costed in a project plan; the recurring one is invisible and is paid every month by the same team. An application on a monthly cadence costs, over three years, several times its first packaging.
Two traps when handing that debt to an automatic update. The two native mechanisms do not cover the same assignment intent: design the strategy per intent, not per application, or part of the estate will silently stop being up to date. And there is no one-click rollback: the fallback is a reverse supersedence built under pressure. The pilot ring is the protection — it is not a nicety, it is the only thing between a bad vendor build and the whole estate.
What remains to be measured before committing to figures
- What a packaging really costs here — it is the one number the whole page depends on, and it varies by a factor of three between two teams depending on their testing standard.
- The cost of a version rebuild — assumed here to be two fifths of a first packaging. Measure it separately: it is what decides the third-party factory case.
- A catalogue's coverage of your products — a size announced in thousands of products says nothing about the overlap with yours. Require the cross-check against your own list.
- What share of the catalogue survives rationalisation — it is the largest single effect on the workload, and the least often measured before a project is committed.
- What automatic updates do over a year — how often an unwanted version actually arrives, and what it costs when it does.