By Herb Schreib

Microsoft will end extended support for SQL Server 2008 on July 9, 2019. For many organisations, 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 organisation. 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 organisation.

Why updating and patching is more complex than many think

Enterprise organisations 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 organisation. 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, organisations 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.

You have 3 options when you need to upgrade

When evaluating what to do when tools need updating, you typically have three options:

  1. Upgrade. Understand all the dependencies, impact and risks for compliance. Make sure all connections to that tool have been updated, and go through rigorous testing. Depending on the extent to which the tool is a business enabler, decide how aggressively you want to move forward.
  2. Accept risk. What is the risk and cost of “not” upgrading? Your CISO could tell the board of directors that they’re willing to accept the risk of not updating certain hardware or software. Perhaps the underlying data elements aren’t as important, and leaving the server unpatched is a viable decision. Whatever the reason, if you choose this route, make sure the choice is well documented so no one is surprised if something eventually goes wrong.
  3. Deprecate. If certain hardware or software isn’t supported with an update, ask yourself if you still need that hardware or software or if other tools in your portfolio can support the business need it serves.

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.

blog-upgrade-decision-path-graphic-1000x525.jpg

How to decide which option is best

Ask yourself the following questions:

  1. What does the user base look like? Generate a report on how many SQL Server 2008 instances and users you have, for example. If you find that a significant number of your applications or employees use the tool on a regular basis, updating might be your best course of action.
  2. How is the tool being used? Do a deep dive into which downriver datasets, web applications, automated functions and features and other elements are connected to the tool. One way to help the CISO or CIO do that is by auditing the connections, so you’re not surprised by shadow IT elements that are critical functions within the organisation.
  3. What will it take to update? Could you just update web apps or other functions connected to the dataset? Do you still have people on your team who can code in the language the tools are written in? If you’re dealing with decades-old tools, you may struggle to find people with the skills to interface with the programming languages.

Updating is critical, but it’s not always easy

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 organisation. 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.

Related Articles