I’ll presume for the moment that you’re aware of your actual end of support contract period. (Though, I’ll admit a lot of companies tend to lose track of this – something of ongoing concern.)
The question I’m really asking though is – the products that you’re using, do you know when their support finishes? In order to have a smooth operating environment, you must know the cut-off point at which point you’ll be:
- Given assistance on that version or
- Told to upgrade or
- Told to patch or
- Told to replace the product
Now, I’ll admit that the challenge here is particularly around the “Told to upgrade” part. Vendors in particular (and EMC is no different) have a tendency to want you to always upgrade to the latest version to see if the problem goes away there. This (in my opinion) is only acceptable with a very small developer team (e.g., from a small company or individual developer), or if there’s release notes or a known bug list that clearly states the problem will go away.
For NetWorker, your key to knowing your end of support dates with both the primary product and the modules comes from the PowerLink NetWorker Product Support Page. To summarise, currently the end of support dates for key NetWorker versions are:
- Version 7.2 – Expired June 30, 2008. That’s why still being on 7.2 is not a great option. You can still get extended support*, but not for long.
- Version 7.3 – Expired March 31, 2009. It’s about half-way through end of extended support.
- Version 7.4 – Expires September 30, 2010. It’s time to at least start planning when you’re going to upgrade. I’m not suggesting you have to rush – quite the contrary!
- Version 7.5 – Expires December 31, 2011.
- Version 7.6 – Expires November 30, 2012.
You should have these sorts of end of support dates flagged in calendars, noted on post-it notes on the wall, tattooed onto your arm, or in general, recorded in such a way as you’ll continue to be aware of them.
As a general rule of thumb, I’d suggest that you should always aim to upgrade at least 3 months before end of primary support for a product. There’s a very important reason why I’d recommend that length of time: if there is a serious issue with the upgrade and you need to temporarily downgrade until it’s resolved, the version you drop back down to will continue to be fully supported in the interim.
Support providers – both vendors and third party ones – do, to varying degrees, tend to be fairly flexible, particularly in emergency situations. Remember though, backup is insurance. Running on an old, unsupported backup product is like taking out an insurance policy but then losing the paperwork. Sure, you’re covered, but you may not be able to make a claim when things go wrong.
End of life and end of support dates should effectively be long range markers in change control processes. If they’re not managed that far in advance, you run the risk of missing easy upgrade windows and instead having to do emergency upgrades without ample preparation.
For what it’s worth, none of this is specific to backup and recovery software. It equally refers to operating system software, or clustering software, or any other critical infrastructure software you may deal with. The message remains the same: always know your end of life/end of support dates.
—
* Extended support = pay more for running old versions.