Every software product has a shelf life. Written when Certero rebuilt its products from the ground up rather than bolting old ones together — and updated to describe what that rebuild actually became.
Why would you use asset management technology designed for yesterday’s problems to address today’s?
The question is prompted by something that happens to every software product eventually: it reaches end of life. That is not a criticism of any particular product. Every piece of software has a shelf life. It is built using the technologies and methods current at the time, to solve the problems that were pressing then. Things move on. New technology, new methods and a changed set of business problems mean that yesterday’s product can stop being fit for purpose surprisingly quickly.
This is especially true in software asset management.
The discipline started as a subset of IT asset management. It became about licence compliance — proving you had bought what you were running. Then it became about software licence optimisation: not just being compliant, but not paying for anything you did not need.
It did not stop there. SaaS arrived and moved a large part of the software portfolio outside the reach of anything that inventories a device. Cloud turned infrastructure into a monthly bill that nobody owns in the way they owned a server. And AI has arrived as a fourth thing again — models, GPU time, agents and seats, each with a different budget holder and a different way of going wrong.
The average enterprise now runs 305 SaaS applications, and 46% of the licences bought for them go unused. Neither number is a problem you can see from a device inventory built in 2010.
So software written a few years ago can simply not be fit for purpose now. That matters if you already run it — and more so if end of life has been announced. But it matters just as much at the point of purchase, which is where it tends to be overlooked. Buyers evaluate against today’s requirements and rarely ask what the product will be capable of absorbing in three years.
Building software from scratch is slow and expensive. Faced with a market moving faster than their architecture, a lot of vendors have taken the cheaper route: contrive a feed between two existing products, bolt older components together, and present the result as a unified platform.
The other version of the same shortcut is acquisition — buy the companies whose products fill the gaps, put them behind one login, and call it end to end. The customer gets multiple products with different interfaces, different data models and no shared record of what is true. Nothing about that removes the complexity. It relocates it.
Both approaches produce the same experience. Data has to be reconciled between modules of what is sold as one product. The interface behaves differently depending on which screen you are on. Upgrades have to be coordinated across parts that were never designed to move together. And the questions that cross asset classes — which departed users still hold a paid licence anywhere, which applications are in use with no single sign-on coverage — cannot be answered at all, because no single system holds both halves of the answer.
We took a different decision, and it was not a comfortable one. Rather than extend what we already had, we stopped and re-engineered the products from the ground up into a single platform.
That rebuild is what CerteroX is. Five products — ITAM, SAM, SaaS Management, Cloud Management and AI Management — on one data model, one interface, one permissions model and one reporting engine. You can adopt one, or several. They work together because they were built together, not because a feed was written between them afterwards.
Concretely, that is:
The modularity is the point. Because the platform is already running underneath whatever you deployed first, extending into a second discipline is a matter of turning on capability that is there, not standing up a second system and training people on a second interface.
When this was first written, the goal we described was policy-based asset management — as little manual intervention as possible, with the expert work encoded in the product rather than performed by hand every quarter. At the time that was still some distance off.
It ships. Governance Policies are compliance-as-code: a reusable filter builder, policies that enforce continuously, and definitions you can export and import as JSON so the standard you agreed is applied rather than remembered. Real examples run in production — BitLocker enabled, Defender running, Azure VM tag hygiene. In SaaS Management the workflow engine gives you eight triggers, eleven conditions and thirteen actions on one canvas, so the step between finding something and resolving it does not depend on someone noticing. In Cloud Management, resource TTL, expense limits and tag correlation rules act at the resource level, with a violation history you can hand to audit.
That is the difference between a product that tells you what is wrong and one that does something about it.
You do not have to take a vendor’s word for any of this. The architecture shows up in questions that are easy to ask in an evaluation:
The answers tend to be revealing, and they are a better guide to whether something will still be fit for purpose in three years than any feature comparison.
We wrote separately about why a single platform matters so much when managing IT assets, and about how CerteroX is built.
If you would rather see the product than read a feature list, book a demo or talk to us.
Other posts covering the same ground.
Locking an application down at user level does not make you compliant with a per-device licence. In a Citrix or RDS environment, one user with access can cost you a licence for every device in the organisation.
A third-party summary of a vendor can be wrong, and it stays wrong for as long as people read it. The case for checking a vendor's facts at source — and the current, sourced record for Certero.
An audit is won or lost on the quality of your inventory long before the letter arrives. Six ways data goes wrong, and what it takes to have the answer already in hand.
Everything argued above is checkable. Name the publisher, the billing account or the platform you would argue with, and the session is built around it — the reasoning attached, not a summary slide.
No gated download at the end of it.