In IT, there are two schools of thought on when to replace aging equipment. Most organizations depreciate IT assets over a fixed period of time and replace them when the clock ticks down. But many other organizations, especially service providers, happily ride old, gray-market IT gear until it breaks.
As with many conflicting ideologies in IT, pros on both sides of this divide tend to deride those on the other -- with accusations of running a junky, unreliable network or overspending massively flying back and forth. However, as with most seemingly black-and-white issues, both sides can learn a lot from each other.
Replacing equipment before its time is really expensive
A seeming lifetime ago, I worked for a regional ISP, then founded a Web-hosting company. In both cases, we built our own servers (before eBay was a good source for used gear), often recycling the same system case for several generations, with taped-over labels documenting the system's provenance. We also relied on used, previous-generation network gear. Without lots of investment capital, we had to work this way -- every dollar spent on new gear had to be supported by absolute necessity and monthly income.
The obvious cost of doing business in this manner was that things could (and did) die unexpectedly -- usually without a warranty to fall back and, thus, no quick replacements. As insurance, we kept equally cheap spare gear configured on the shelf or built the systems to be mutually redundant; the failure of one system and replacement with another became a relatively frequent and almost expected event. We could live with this because, in a service provider environment with an almost exclusively IT-oriented staff, almost everyone was skilled enough to quickly execute these infrastructural changes.
These days, I work almost exclusively in enterprise IT environments. For most of the usually overextended IT pros running these setups, it's difficult enough to stay on top of the operational workload born from supporting the business, so the idea of dealing with aged infrastructure gear without warranties or support is abhorrent. With few exceptions, everything I work with is relatively new, overengineered, and replaced before it can die of natural causes. Because these businesses look at IT as simply a cost of doing business rather than the actual means with which to do business, the cost of the gear and the support for it is generally accepted without much of a fight.
It's no wonder then that enterprises steer clear of this approach. However, certain aspects of this strategy can be successfully adopted by even the most risk-averse enterprises if they want to save a pile of cash. Not buying manufacturer support contracts is where you get the most savings because it's often one of the largest costs over the equipment's lifecycle. You're paying for that large, always-available vendor support team.
Many IT organizations see buying such manufacturer contracts as no-brainer. That's a mistake. You should think through whether you really need that level of support and consider how you might reevaluate your infrastructure design to make such support unnecessary.
Let's say you have a large campus network composed of 20 aggregation switches located in closets around the building and a high-end core switch to tie it all together.
First, you might be able to avoid the cost of maintaining high-end support contracts on the aggregation switches by simply keeping a spare switch configured on the shelf. In any network that has more than a handful of the same kind of gear, the money saved by downgrading from a 24/7/4 contract to a 8/5/NBD (or even lower) contract is more than enough to buy a spare piece of equipment and still save money. Better yet, by being able to replace that failed switch yourself with a prepositioned spare, you'll almost always beat the manufacturer's SLA for getting a replacement -- gear on a shelf trumps even a two-hour onsite response.
Second, by implementing smaller, dual-redundant core switches with lower-end support contracts, you can often make do with less-expensive gear, provide better overall redundancy, and have a way to take one of the systems out of production for software upgrades without dragging down the whole network. Effectively, you can provide better redundancy and spend less money.