Pulling the Plug: When Old Tech Loses Its Life Support

In April of last year, Windows XP went out of extended support. I know a lot of people in the IT community considered that a watershed moment, but why is that? What is so special about a product being in support, and what is the support lifecycle? That’s an important concept to understand for developers, customers, and observers of the industry, so let’s talk about it a bit.

In simplest terms, a product being “in support” means that the developer will continue to develop patches in responses to problems with that product, and that their technical support organization will attempt to help you if you have a problem with it. This is particularly important for large firms like Microsoft and Oracle, who have hundreds of thousands or millions of instances of their software running around the world, but it is also important for the smaller developer, who only has 1 or 2 dedicated support people and very little time to patch previous versions of their product.

Many firms have at least two occasions when they will stop supporting various customers. First, the vendor stops selling the product to new customers, then afterwards, mainstream support ends when they stop supporting anybody who didn’t buy a special “extended” support agreement. Eventually, the extended support agreement will also reach the end of its lifecycle, and customers will no longer be able to get technical help from the vendor. (Note: Oracle adds a third category called “Sustained”, which has no fixed end date, although few vendors I’ve ever seen explicitly have this third option.)

Recently, we’ve seen this model extended to hardware; last month my trusty Nexus 7 became the first tablet Google declared to be at its End-of-Life, and would no longer be guaranteed to receive updates. Apple has no public policy on when it will discontinue support for various devices, iOS revisions, or even OS X revisions, but in practice they seem to terminate support around 30-48 months after release.

For cloud-based tools, such as GMail, Office 365, Salesforce, and the thousands upon thousands of other web-based apps out there, the question of lifecycle support becomes even murkier. Frequently, lifecycles are updated on relatively short notice. For example, when Google terminated its Reader product, they made the announcement 110 days before the product was taken offline. At the end of March 2009, users received a warning only 60 days before Yahoo’s Briefcase (a forerunner to OneDrive and Google Drive) closed, limiting the time they had to remove their files.

Clearly, different players in the marketplace have made different decisions about how to handle lifecycle support. So what are the upsides and downsides to having a public lifecycle model? Well, there are a few.

The benefits are mainly to the customer. Knowing years in advance what your support situation will be provides security for a potential user. When the VP of Information Technology is drafting their budget for a new year, its beneficial to know if they need to roll out a new operating system, productivity suite, or replace everyone’s phone. Greater vision allows for better planning, and that fact isn’t lost on large customers.

The disadvantages are largely to the developer. Committing to support something for five years means you need the infrastructure to maintain that product for five years, even if you would prefer that users upgrade to a newer version that is available. It means maintaining expertise in development, support, and sales long after newer and more exciting things have been launched. That can be especially difficult for smaller companies where the team supporting the old application, and the team developing the new application are the same people.

Even so, there are opportunities in maintaining a strong support lifecycle. Transitioning a product from Mainstream to Extended support can help sell support contracts that will keep your support organization robust, and keep customers without forcing them to pay the price of a full upgrade. It makes your product and company more attractive to risk-adverse IT managers who worry about their vendors capriciously terminating support for an application on short notice, forcing them to scramble to find a replacement. Ultimately, public support lifecycles are about ceding one of the advantages a developer has to a customer in order to make their lives easier and more predictable. Whether or not that is a price your firm can pay is a question for each product manager to answer for themselves.