How to Handle Support for Decommissioned Enterprise Apps

By: Phil Simon| - Leave a comment

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:

  • Go naked. 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,

Simon Says

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

Topics:

Comments

About The Author

Phil Simon

Professor at ASU’s W. P. Carey School of Business

Phil Simon is a frequent keynote speaker and recognized technology authority. He is the award-winning author of eight management books, most recently Analytics: The Agile Way. He consults organizations on matters related to communications, strategy, data, and technology. His contributions have been featured on The Harvard Business Review, The New York Times, Fox News, and many other sites. He also teaches system design, analytics, and business intelligence at Arizona State University’s W. P. Carey School of Business.

Articles by Phil Simon
See All Posts