Microsoft recently nixed support for SQL Server 2005. You might not care about the announcement if your organization runs dB2, Oracle, MySQL, or another backend database. Also, if it had upgraded from the 2005 version over the past decade, the news probably didn’t matter much to you.

Still, odds are that many organizations continue to run legacy versions of the database. Case in point: Even though Microsoft has been touting Windows 10 for a while now, many companies never migrated their employees from Windows XP. This is astonishing, since XP launched on October 25, 2001. As an interesting aside, nearly all automated teller machines (ATMs) continue to run XP.

Work in enterprise IT long enough, as I have, and it’s only a matter of when—not if—your organization faces a similar dilemma. At some point, a software vendor is going to stop providing support for key enterprise applications and technologies. In this post, I’ll discuss the main options for organizations to consider.

Options

The six main options for organizations facing this dilemma include:

• Going naked. (Cue Old School reference.) In a nutshell, this entails doing nothing. It’s a high-risk stratagem that I have never recommended to my clients. Very rarely does this ever make sense.
• Purchasing and deploying an entirely new technology. This is no small task. As I wrote in Why New Systems Fail, moving from a database or CRM or ERP suite is fraught with peril.
• Procuring independent third-party support. Many organizations have taken advantage of this option, particularly for large software vendors. For instance, Rimini Street represents a viable option for Oracle clients.
• Upgrading to a new(er) version for the applications, databases, and programs. This is often the wisest move. Few if any software vendors suddenly refuse to support a major software release. They generally communicate at least year ahead of time of their plans and, as I’ve seen, will move dates if clients object strenuously enough.
• Asking the vendor for an exception. This Band-Aid approach often involves cutting a check for “sunset” support. There’s still no such thing as a free lunch. Also note that CIOs can only go to the well so often. That is, don’t expect software vendors to routinely make exceptions. It simply doesn’t make sense for them allocate staff who primarily maintain older versions of products. This is doubly true in the case of SQL Server 2005.
• Hiring in-house developers and support folks to handle bugs, patches, and fixes. I’ve seen a few organizations do this in my career. Generally speaking, it’s not for the faint of heart. It’s a resource-intensive endeavor. Still, depending on the extent to which the organization wants to customize its software and maintain legacy applications, it might make sense,

Think about your options well before the expiration date.

It’s important to note that the support ramifications of each option hinge upon the type of infrastructure involved. That is, an organization may face different costs and resource requirements depending on where an application ultimately resides (re: on-premise vs. through a third-party’s cloud-computing service).

Simon Says: Think about your options well before the expiration date.

There’s no easy answer to this conundrum, but a responsible organization cannot let key enterprise apps go unsupported. Think about the options in this post well before a software vendor pulls the plug.