By Herb Schreib
Microsoft will end extended support for SQL Server 2008 on July 9, 2019. For many organizations, that means the clock is running out and it’s time to update, a process many have been pursuing or postponing since Microsoft announced the product’s end of life back in 2014.
Making the necessary updates sounds simple enough, but in reality, if it were easy, you probably would have upgraded already. Which is why when businesses are caught with out-of-date systems and software that haven’t been patched or updated, a chorus erupts about the risks and vulnerabilities they’re likely harboring as a result. And the vulnerabilities are real. You see them play out in news reports detailing data breaches and cyberattacks nearly every day.
Everyone knows patching and updating software or hardware is critical to security, compliance and resiliency, not to mention productivity, and should be standard practice for your organization. But managing software lifecycles can be complex, and out-of-support software may be present in your IT environment leaving your business at risk.
“Should we update?” is a larger question than it might first appear. Here’s how to navigate those decisions and ensure you understand and mitigate the risks that unsupported software can have for your organization.
Enterprise organizations typically have over 200 unique services and datasets to enable their business. While some are commercial off the shelf (COTS) applications and tools, you might also have important custom software as well as proprietary tools that may be out of service by many years.
Some of these tools may have been created by employees that have long since left the organization. Some systems were developed by companies that have long since gone out of business. If you’ve been in business for decades, it’s not unusual if some important business tools date back to the 70s or 80s. SQL Server 2008 might not even be the oldest part of your infrastructure.
If you simply update a part of that ecosystem, you could “break” software. Before deploying any updates, organizations must test to determine and document applications’ interdependencies, as well as see how the various components react to the updated or patched software. But updating isn’t your only option.
When evaluating what to do when tools need updating, you typically have three options:
For example, in the case of SQL Server 2008, you might be running multiple database tools—maybe you have Oracle or another database platform in addition to SQL. Could you move everything to another solution and simply turn off SQL instead of updating? Usually it’s a little more complex than that, but it should be a consideration.
Ask yourself the following questions:
Most of the talk around updates and patches relates to high-visibility items: Microsoft is ending extended support for SQL Server 2008 or hackers are exploiting a vulnerability after new patches or software versions are released, knowing some may not be applied or upgraded in client environments. It seems like an obvious time to update.
But if you dig deeper, it becomes a bigger question. It’s not just about the ways an ancient tool could be exploited if it isn’t updated, but about the ways it’s being used in the organization. It’s not just the obvious risk from a vulnerability standpoint, but operational risks if you don’t update that tool.
Need help making the move or understanding the implications of a major software update? Get in touch.