You've probably done this. You have a rack of aging gear, you Google the model, you click the top result from one of the big TPM libraries, and the row you actually need — the End of Service Life date — is empty. Just a dash. Or the phrase "Date Not Published." Sometimes both the EOL date and the EOSL date are blank on the same row, on a page that exists specifically to answer that question.
That empty cell is telling you something. It's not telling you what most people think.
What "Date Not Published" actually means
Three completely different things all get flattened into that same empty field, and they mean very different things for how you should respond.
1. The vendor has not publicly disclosed the date yet. Most common. Vendors typically announce EOL and EOSL on a 6-18 month lead time — sometimes shorter for surprise consolidations. For gear that's still in the current or mature phase, no date exists yet because the vendor hasn't set one. The library shows a blank because there is nothing to publish.
2. The vendor disclosed the date, but only through a channel the aggregator doesn't ingest. Vendors publish EOL notices in many places: the main product-support page, PDF advisories linked from a support portal, monthly customer newsletters, partner briefings, per-region announcements in three languages. A library that only scrapes the main support page will miss dates that only appeared in a partner-only PDF. The date exists; the aggregator doesn't know it.
3. Nobody actually knows because the vendor is gone or the product is orphaned. Smaller cases. Acquired product lines, discontinued brand names, vendors that went out of business, gear that came from a merger where the acquiring company never issued a lifecycle statement. A real gap in the disclosure market, and one that no library can fix.
The three cases require completely different responses from you as the buyer. Case 1 means "keep watching, the date is coming." Case 2 means "look harder yourself, the date exists somewhere." Case 3 means "you're on your own, use community knowledge and typical support-window heuristics."
None of the libraries that show "Date Not Published" tell you which case you're in. That's the actual missing information.
The aggregator's problem is your problem
TPM libraries exist because vendor lifecycle information is genuinely fragmented, and someone has to do the collation work. But there's an economic mismatch baked into the model.
The aggregators are paid for lead generation, not for record completeness. Every empty row exists because filling that row would cost more research time than the row generates in sales-qualified leads. A row for a popular current-gen server that thousands of prospects search each month is worth deep research. A row for an obscure 2011-vintage tape library that gets three visits a year is not. Empty cells cluster in exactly the models where a buyer needs the most help — because those are the models with the smallest lead-flow reward for the aggregator.
You are the party who cares whether the row is complete. The aggregator is not.
How to triangulate a real date when the library is silent
The good news: when the field is blank because of Case 1 or Case 2, the actual date is usually reachable. It's just work.
Step 1 — Check the vendor's own support portal for the exact model. Not the aggregator's site; the vendor's. Dell, HPE, Cisco, Lenovo, NetApp all publish EOL notices to their own domain, and Google indexes them. Search for "end of service life" site:vendor.com model-name. Set a date filter for the last three years. If the vendor announced it, this finds it 70% of the time.
Step 2 — Check the vendor's PDF library. Vendors publish per-generation lifecycle-summary PDFs (Dell calls them "Product Support Lifecycle Documents"; HPE calls them "Server Lifecycle Table"; Cisco calls them "End-of-Sale and End-of-Life Notice") that list every model's dates in one document. These PDFs are indexed but often not surfaced by aggregators. Google them with filetype:pdf.
Step 3 — Read the compatibility matrix backward. When a vendor drops a model from its OS support matrix — Dell drops a server from OpenManage certification, Cisco drops a switch from the latest IOS-XE branch — the date of the drop is the de facto end-of-support date, whether or not there's a matching public EOSL notice. Compatibility matrix pages are almost always fresher than the marketing lifecycle pages.
Step 4 — Search community reports. Reddit's r/sysadmin and r/homelab, the Spiceworks community, the TechNet archives, and vendor-specific enthusiast forums often surface EOSL dates weeks or months before the aggregators. Search for "end of support" model-name reddit and read the top three threads. When a real EOL notice hits, someone always posts it there first.
Step 5 — Apply typical support-window math. If none of the above find a date, you can still estimate with useful accuracy. Server vendors typically ship 5-8 years of standard support and another 2-4 years of extended support past GA. Network gear runs longer — often 8-10 years of standard support plus 3-5 years of extended. Storage arrays sit in between. If you know the GA date (which is almost always public), you know the plausible EOSL range within 18 months.
Bushido runs steps 1-4 for you on every record and, when the answer is still uncertain, publishes step 5 as an explicit estimate with a confidence score. That is why our record pages show "est. 2025–2027 · confidence 40%" instead of an empty cell. The confidence score tells you which of the three cases you're in without you having to run the whole investigation yourself.
Why the empty-cell design is worse than an honest estimate
Consider the two ways a lifecycle library can render an unknown date. Option A shows an empty cell or a dash. Option B shows a range and a confidence score.
Option A is what most libraries pick, on the theory that showing anything without full certainty is misleading. In practice it's the opposite: a buyer who lands on an empty cell has to leave and go find the answer somewhere else. The library has given them zero information. The buyer's actual response is almost never "I now know less" — it's "I now know this library is a dead end for my model, and I'll go check another one." Empty cells train buyers to bounce.
Option B commits to the estimation risk. You might be wrong by a year or two on the EOSL date. But the reader now has a working figure to plan against and a confidence score that tells them how much to trust it. "Est. 2025-2027, confidence 40%" is a useful sentence. A dash is not.
Option B also holds the library accountable. When we publish a confidence-scored estimate and the vendor later publishes the exact date, we can measure our estimate against the truth and improve the model. The empty-cell approach gives no such feedback loop. It never learns.
What to do next time you see a blank
Next time you're comparing hardware EOSL dates on any library and see "Date Not Published" or a dash, run this quick check:
- Is the model still current or mature? Then the blank is honest — the vendor hasn't set the date yet. Set a calendar reminder for 12 months out.
- Is the model 5+ years past GA and still missing dates? The vendor probably announced it and the library missed it. Do the vendor-portal + PDF-library search yourself; you'll almost certainly find it.
- Is the model 10+ years past GA and still missing? Now you're in orphan territory. Estimate from GA + typical support window. Document your assumption. Revisit next year.
Bushido will show you which case you're in without making you do the search yourself. That is the entire point of a lifecycle library that doesn't get paid by lead generation.
Blank cells are not honesty. Honesty is the confidence-scored estimate.