This post documents how for years IT asset management has chased accuracy (the exact right date), but the real bottleneck today is coverage: having a usable, explainable lifecycle signal for every in-scope asset, even when the perfect date does not exist. It explains why the gap is structural (publishers disclose unevenly, normalization caps everything, legacy and long-tail items are underserved), why piecemeal fixes plateau, and what a “coverage-first” operating model looks like: measure coverage as a real metric, let confidence-tagged data tiers coexist, treat approximation as a labeled signal, and (the biggest reframe) count a record as covered if it has either a usable date or a lifecycle code that explains the situation. It closes with where this is heading and the ideas to carry into a planning cycle.
For two decades, IT asset management has been a conversation about accuracy. Do you have the right edition, the right version, the right end-of-support date? Accuracy still matters. It is the gold standard for any individual date. But it is no longer the binding constraint. The binding constraint is coverage: in a typical enterprise estate, lifecycle metadata exists for nearly every product, yet usable end-of-life dates exist for fewer than half.
That gap is the whole story, and the shift it demands is small to say and large to act on. The old question was “Do we have the exact date?” The new one is “Do we have the exact date or, where we don’t, a usable signal we can explain, govern, and act on?”
Why this became urgent
A lifecycle date used to be a procurement input, a nudge that a renewal or refresh was coming. Now the same field is a control point for three audiences at once. Security treats unsupported software as unpatched software. Auditors expect end-of-life-anchored reporting on every in-scope asset; frameworks from FFIEC to ISO/IEC 19770 to OSFI B-13 all expect management to know, at any moment, which assets are past support and what the plan is. Finance references the same field for renewals, true-ups, and consolidation. “Raise a content request if it’s missing” no longer satisfies an examiner who wants a defensible position across the whole estate.
The gap is structural, not accidental
Here is the shape of it, from a recent customer review: about 98% of products carried a lifecycle code, 78% had any usable date, and only 42% had a confirmed end-of-life date. A near-forty-point drop from “metadata exists” to “a date you can act on,” and that shape repeats across industries.
It repeats because the causes are structural. Publishers and manufacturers disclose unevenly. Some never publish dates for patches, drivers, or subscription products at all. Coverage is downstream of normalization, which has a moving ceiling as the catalog and estate change monthly. Phase definitions disagree across vendors, so a report fixated on one phase misclassifies assets the vendor tracks under another. Publishers define lifecycle at the market version (“SQL Server 2019”), not at the hundreds of builds underneath it. And long-tail, legacy, and open-source items are structurally underserved, which is exactly where audit findings cluster.
The hard takeaway: missing dates are not missed work. They are unavailable inputs. A strategy that assumes the dates exist somewhere and just need retrieving will plateau. A strategy that treats absence as a first-class condition, with its own handling, will not.
Why the usual fixes plateau
Most teams already have workarounds, and none of them are wrong. Manual overrides are perfect for a contract or a policy, but do not scale to thousands of long-tail products. Content requests are reactive by design, closing gaps one ticket at a time, often after the auditor flagged them. Silent best-guess approximation improves the report but erodes trust the moment someone asks where a date came from. Each tool has its place; the failure is using them as uncoordinated tactics, with no connective tissue deciding which applies where, and labeling the result honestly.
A coverage-first operating model
Coverage works when it is treated as a system, not a backlog. Five principles define it.
Make coverage a measurable metric: the share of in-scope products with actionable dates, segmented by phase, publisher, criticality, and install count, with the same number driving both the audit report and the improvement backlog.
Define data tiers and let them coexist: publisher dates (highest confidence), inherited, approximated, and custom, with the most authoritative source winning, and a customer’s negotiated contract taking precedence over everything, because for that customer it is the truth.
Treat approximation as a labeled, governable signal. An approximated date is not a guess if it carries a code explaining how it was derived. The reader knows exactly what they are looking at and whether it is good enough for the decision in front of them.
Anchor everything to normalization, which has a multiplier effect on coverage that chasing individual dates never will. And build a feedback loop from gap to content, so every gap found in the estate directs what gets added next.
The reframe that matters most
If there is one idea to carry out of all this, it is how you count. Most coverage definitions only credit a record when a date is populated. That is the wrong test, and it punishes diligence. A record with a lifecycle code but no date is a record where someone investigated, classified the situation, and documented why a date is or is not there. APX explains a derived date; END confirms a product is end-of-something without a pinned calendar date; EXC documents why no date will ever come (patches and drivers, by design). Each is a defensible, auditable answer.
So a record is covered when it has a usable date for any in-scope phase, or a code that explains the situation. Only records with neither (no date, no code) are the true gaps, and they are the proper target of the backlog. Count it this way and the report stops measuring effort and starts pointing at the work that remains.
Where this goes
The capabilities to do all of this exist today, and the rest of this series walks through them: approximation and calculated lifecycle, custom records and publisher add-ons, parent-child inheritance, and the reports and Guided Experience that make the cycle repeatable. The direction of travel is toward continuous, AI-assisted lifecycle intelligence: faster vendor-signal ingestion, inference that recognizes release patterns at scale, and lifecycle taking its place inside a fuller context graph alongside criticality, exposure, and regulatory scope.
None of it requires waiting. The thread connecting today to the future is the same one running through the whole argument: stop treating uncertainty as an embarrassment to hide, and start treating it as a signal to surface, label, and act on.
Where to go next
© 2026 ServiceNow, Inc. All rights reserved. ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks of ServiceNow, Inc.
