EOS Switches Found 4 Weeks Before the Budget Cycle Closed
We ran our quarterly discovery scan in late October. Three weeks before the infrastructure budget cycle closed for the year, the results came back with something we had not planned for: 23 Cisco Catalyst 2960-X switches, spread across four of our eight on-premises sites, had already crossed their end-of-sale date and were within 90 days of their end-of-support window. No replacement budget. No project in the queue. Four weeks to either act on this or carry the risk into the next fiscal year.
The incident revealed a deeper problem: our ITAM system was tracking purchase history, not lifecycle status. The gap between what discovery found and what ITAM records showed had widened for seven years without anyone noticing. And when it surfaced, it forced an emergency decision with a $142,000 price tag.
What the Discovery Scan Actually Showed
The 23 switches were not invisible to our infrastructure team. They appeared in our IT asset management system, entered there when we purchased them in 2017. What was missing was lifecycle tracking. No end-of-sale date recorded. No end-of-support date. No flag that these devices would leave the Cisco support window on January 31 of the following year.
When IT discovery ran across our environment, it pulled device model numbers, firmware versions, serial numbers, and network positions. Matching those results against Cisco’s published lifecycle tables took 40 minutes. Our ITAM records had been accumulating as a liability for seven years without anyone noticing — and one scan exposed it.
What we found:
- 23 switches actively handling traffic at core and distribution layers across 4 sites
- Average device age: 7.3 years
- All had crossed end-of-sale in 2022, two years prior to this scan
- 18 were at distribution layer, 5 at core layer
- None had replacement tickets open in our ITSM platform
The Budget Crisis That Followed
At list pricing, 23 enterprise-grade replacement switches at the tier we needed ran approximately $340,000 in hardware. Adding installation labor across four sites brought the estimate to roughly $420,000. The fiscal year budget cycle was four weeks from closing.
We had two paths. Push for emergency budget approval — which meant escalating to finance with a risk justification explaining why our ITAM system had not surfaced this proactively. Or defer to the next fiscal year and accept operating on unsupported hardware for 9–12 months while waiting for new budget.
Neither was acceptable. The emergency approval path required a post-mortem conversation nobody wanted to have: why had seven years of ITAM records failed to surface EOS risk before it became a budget crisis? The deferral path meant running core network infrastructure with no vendor patches, no security updates, and no Cisco incident support eligibility for any failure during that window.
We approved emergency replacement for the highest-risk sites — the 5 core-layer switches across two sites. We formally deferred the 18 distribution switches with a signed risk acknowledgment from the IT Director, documented for audit purposes. Total emergency spend: $142,000 for hardware and installation.
What ITAM Should Have Caught Earlier
The root cause was not the discovery scan. The discovery scan did exactly what it was supposed to do. The root cause was that our ITAM platform was tracking purchase records rather than lifecycle status.
A CMDB or ITAM platform should flag a device as it approaches end-of-sale, not after it has crossed into the unsupported window. Our records showed model number and purchase date. They did not include the Cisco lifecycle dates that had been publicly available for years.
According to a 2024 ITAM Forum industry survey, 61% of organizations rely on manual processes to track hardware end-of-life dates, with most discovering EOS status during audits or incident reviews rather than through proactive monitoring. That is exactly what happened here.
Three specific process failures contributed:
No lifecycle date enrichment. Purchase records were entered at acquisition and never updated. The model-to-lifecycle mapping that would flag EOS status requires an active data source, not a static entry.
No discovery-to-ITAM reconciliation schedule. The gap between what existed in the CMDB and what discovery found had widened for seven years without anyone running a formal comparison.
No budget trigger. Even if lifecycle dates had been recorded accurately, there was no workflow translating an approaching EOS date into a budget planning ticket with enough lead time to act inside a normal cycle.
The Discovery-ITAM Gap Is the Actual Risk
What this incident made clear is that discovery data and ITAM data need to be the same source of truth, not two separate systems allowed to drift apart over time.
Our IT discovery tool found what existed in the environment. Our ITAM tool tracked what we had purchased. Neither was wrong on its own terms. The problem was the gap between them. Seven years of device refreshes, informal decommissions, and site reconfigurations had widened that gap to the point where ITAM records were unreliable for lifecycle planning purposes.
Discovery-sourced ITAM closes that gap. When discovery finds a Catalyst 2960-X with a serial number that maps to a specific purchase record, it should also pull the published lifecycle status for that model and surface it in the ITAM record. This is not a real-time requirement — it is a routine enrichment job that runs on the same schedule as discovery.
The approach treats discovery data as the authoritative source for asset state, with ITAM records built from that source rather than maintained separately by hand. Had we been reconciling discovery against ITAM on a scheduled basis, these 23 switches would have appeared on a lifecycle risk report well before the budget cycle closed.
What We Changed After the Emergency Approval
Following the emergency spend, we rebuilt our ITAM lifecycle tracking process. The changes we made:
- Scheduled IT discovery scans across all sites on a defined cycle, with results feeding directly into ITAM record updates
- Vendor lifecycle data enrichment added to all network hardware records, refreshed from vendor lifecycle tables every quarter
- Budget planning reports generated every June and December, flagging any device within 18 months of end-of-support
- A formal EOS project ticket opened automatically when any hardware record crosses the 18-month threshold
The following June, the planning cycle surfaced 11 additional switches at two other sites approaching end-of-sale in 18 months. Those are now in the budget for the next fiscal year. No emergency approvals required.
For teams managing distributed network infrastructure, the lesson is that ITAM accuracy depends on discovery frequency and lifecycle enrichment, not purchase history. A device record entered in 2017 will not tell you what that device requires in 2024 unless something has been actively maintaining it.
Making Lifecycle Visibility a Standard Part of ITAM
The $142,000 emergency spend was not the most expensive part of this incident. The most expensive part was the escalation to finance, the risk acknowledgment documentation, and the operational disruption from unplanned procurement. Discovery fixed the immediate visibility gap. Rebuilding the process behind it prevented the next one.
For infrastructure teams managing aging hardware across distributed sites, the CMDB best practices that matter most are not about CI schemas or data models. They are about keeping discovery and ITAM synchronized so that lifecycle risk is visible before it becomes a budget problem. Schedule a demo to see how continuous discovery feeds accurate lifecycle data into your CMDB and ITAM system.
