“If it ain’t broke, don’t fix it.”
This advice may be a good general principle, but when it comes to databases, not so much. Yet we often hear it when it’s time to upgrade database software. Installing an upgrade may be a significant undertaking, so many people will take any excuse to avoid it. Don’t fall back on a cliché. Here’s how to decide whether to upgrade.
- What’s the upgrade supposed to accomplish? If the upgrade includes performance improvements, those could have a positive effect on your business. Performance enhancements could include reduced disk calls or improved compression, which might lead to energy or cost savings or an improved experience for your users. And if the upgrade includes security fixes, then it’s a no brainer. You don’t want the next big data breach story to be about your company. Go for the upgrade.
- What about new features? Only you can decide if the new features will contribute to your business. But I would advise you to consider new features with an out-of-the-box approach. Often a new feature can dramatically change your work processes in ways that aren’t apparent from reading the vendor’s promotional literature. Be open to the possibility that you could find better ways to get the work of your business accomplished. Try to reimagine your work processes in light of the new features.
- Where are you in the software’s life cycle? If the vendor is about to end support for the version you’re using, you should upgrade. Otherwise, you’re gambling with your database, which means you’re gambling with your business.
- How are your applications behaving? If your applications are giving you trouble, and you have reason to believe the upgrade will bring them in line, it’s time to upgrade.
- How long has the upgrade been out? Finally, my advice is to stay current without being obsessive. The computer industry has a long history of using its own customers for product testing. Even the biggest and best vendors can’t know how new software will behave in all user installations. Let everybody else test the upgrade for you. When it becomes available, wait for the first two patches before doing the upgrade yourself.
Once you’ve decided to upgrade, look for opportunities to do it when the systems aren’t so critical. This may have to do with the seasonality of your business or some change in your industry.
When you do upgrade, do it in a test environment first. Nine times out of ten you will catch critical issues. But don’t expect complete protection from this step, because that tenth time can blow up in your face. Always have a way back to where you started, meaning a complete backup and a written rollback plan.
I can tell you so many stories of customers who have tested a system in a development environment with no issues and still had critical issues when they went to the live environment. We even gained a customer this way. They came to us with an issue that should have been terminal and they had no backup to restore service. We were able to restore their systems with only three weeks of downtime. Three weeks represented tens of millions of dollars in lost revenue to our client. But with the business itself hanging in the balance, it could have been a lot worse.