Direct answer: To identify duplicate applications, first separate the three kinds of duplicate, because each needs a different method. The same product under different names is fixed by consolidating variant names into one application family. The same product in many versions is found by counting versions in use per family. Different products doing the same job are found by grouping a clean, family-level inventory by purpose, then asking an owner to decide which tool stays.
Most organisations know they have duplicate applications. Very few can say how many, or which ones. The problem isn’t a lack of data. It’s that a raw inventory mixes three different kinds of duplication together, and buries all of them under noise.
Pull an application inventory from any device management platform and it looks precise. Every row has a name, a version and a device count. But the rows don’t line up with how people think about software.
A single product can appear as a dozen rows: one per edition, per language pack, per installer that left a slightly different display name. Meanwhile, the same row list is full of things nobody would call an application: runtimes, device drivers, redistributables, help files, installers and bundled components.
So when someone asks “how many PDF readers do we have?”, the inventory can’t answer. It might show twenty rows that are really one product, and miss that three genuinely different products are doing the same job.
That’s why the first step isn’t hunting for duplicates. It’s being clear about what kind of duplicate you’re looking for.
Each kind needs its own method. Treat them as one problem and you either overcount (calling editions of one product “duplicates”) or undercount (missing the tools that genuinely overlap).
This is the most common source of apparent duplication, and the easiest to get wrong.
Vendors rename editions. Language packs register as separate entries. An update can leave a display name that differs by a word, a year or a bracketed architecture tag. A 32-bit and 64-bit install can sit side by side under different names. None of these are duplicate applications in any business sense. They’re one product.
The opposite mistake is just as costly. Some rows look like the same product but aren’t.
Add-ins are the classic case. An add-in for a collaboration or office tool often carries the parent product’s name in its own. Merge it into the parent family and two things go wrong. The add-in’s version numbers get mixed in with the product’s, so the version count is wrong. Worse, those version numbers get compared against the parent product’s vulnerability ranges, which they have nothing to do with.
So the rule is: consolidate variants, but keep look-alikes apart. An add-in, a plug-in or a companion utility is its own family, even when its name suggests otherwise.
Once variants are grouped into families, a second kind of duplication shows up: one product running at several versions across the estate.
This rarely looks like duplication in a raw inventory, because each version is a separate row and they’re scattered across the list. Grouped into a family, it becomes obvious. And it matters, because every extra version is another vulnerability range to check, another package to maintain and another exception to explain.
For each application family, measure three things:
A family with high scores on all three has a real version duplication problem. A family with several versions where nearly every device sits on one of them has a few stragglers. We cover how to measure and prioritise this in more detail in Version Debt: How to Measure Application Sprawl.
The point for this article is simpler: version duplication only becomes countable once the naming problem in Kind 1 is solved. Get the families wrong and every version count after that is wrong too.
This is the kind most people mean when they talk about duplicate applications, and the hardest to find mechanically. Several PDF readers. Two or three screen-capture tools. More than one file archiver, remote access client or diagram editor, each installed by a different team at a different time.
These are functional duplicates. The products have different names, different publishers and different version histories, so no amount of name matching will connect them. What connects them is purpose.
This is the step where judgement matters most. A tool can tell you that three products sit in the same category. Only the people who own them can tell you which one the organisation should standardise on.
In most organisations, finding duplicate applications is a project rather than a process. It tends to look like this:
The deeper problem is that the decisions don’t persist. Someone works out that six rows are one product, or that a utility is really a driver, and that knowledge lives in a spreadsheet. The next export arrives without it, and the work starts again.
For a worked example of what a fuller rationalisation looks like in practice, see our enterprise application rationalisation case study.
The figures below are illustrative, not drawn from a customer estate.
The raw list suggests the PDF problem is the biggest. After grouping, it turns out to be a choice between three products, which is a conversation for the owners. The browser looked like one product, which it is, but at five versions it’s a standardisation job. And the office suite, which looked like six duplicates, is really one product that was never a problem at all.
ALICE does the inventory side of this work for Microsoft Intune estates, and for SCCM estates before they move to Intune, and keeps it current with every sync.
Once a decision is made, the same platform carries it through: the chosen product and version can be packaged and rolled out through your own Intune in phases, starting with named testers. Retiring the tools you no longer need, and any licence savings that follow, are actions your team takes on a picture it can trust. If you need to put that in front of a board, our article on the hidden cost of application sprawl covers the case.
You can start finding duplicate applications this week:
Duplicate applications aren’t one problem. They’re three, and most inventories can’t tell them apart. Clean the list, group it into families, and the naming duplicates disappear, the version sprawl becomes countable and the overlapping tools become visible for the people who own them.
Start a 14-day ALICE trial, connect your Microsoft environment and see every application family in your estate.
ALICE is Camwood‘s platform for Autonomous Application Lifecycle Management: discover, rationalise, package, deploy and patch through your own Intune, with every decision kept on one record.
