1. Ashley Leonzio
BMIS 2056: MIS Practicum
IS Management Issue Identification and Definition
ApplicationRetirement&Technology Obsolesce:Knowing WhichProducts to
Sunset and When
Introduction
Application retirement, or “sunsetting,” is defined as the process pulling products or features
from the market. It seems logical that this process should occur when the cost of development
and maintenance exceeds profit, but in most industries, the decision is not so simple. Other
factors such as functional and technical obsolesce, strategic fit, contractual commitments, and
regulatory compliance standards can come into play. Businesses also make compelling
arguments for keeping a legacy systemin place such as:
 The costs of redesigning or replacing the systemare prohibitive because it is large,
monolithic, or too complex
 Implementing a new system would be costly, compared to the anticipated benefits of
replacing it
 The way that the systemworks is not well understood. This can occur if systemdesigners
have left the organization and the system has not been fully documented or
documentation has been lost.
Knowing when, or if, it is right to retire a product or feature will be the focus of this paper.
Specifically, this paper examines software based applications and services and does not address
issues related to manufacturing and consumer goods.
What is the issue?
Most successful organizations do rather well when it comes to bringing new technologies to
market, but very few of them do a good job of retiring legacy applications. JimDuggan, a
Research VP with Gartner, makes the following observation, "On average, 10% of the
applications in an un-optimized portfolio are candidates for retirement. An additional one-third
can require migration or rationalization."1 This statistic, along with one from ZDNet.com stating
that, on average, organizations spend 75% of their software budgets on ongoing operations and
maintenance, means that there may be significant savings in the retirement of legacy
applications. 2
It seems that sunsetting products would be a no brainer then, so what’s the catch? Knowing
you should, or can, retire an application is one thing, but knowing what products and when is
more difficult to determine. In theory, sunsetting or retiring products should happen when the
1 (Koopman, 2010)
2 (Applimation, 2009)

2. product no longer fits into the company’s competence or market strategy and when the
product is no longer profitable. Figure 1 provides a unique view at the product life cycle stages
in that it depicts what most organizations tend to ignore; at some point, the cost to support and
maintain a product exceeds the sales revenue if a product is not adequately retired, or if there
are no significant upgrades to increase sales revenue.
Figure 1: Product Life Cycle3
Determining what products should be retired is another question organizations grapple with.
Figure 2 provides a framework for determining what to do with a product or feature that is in
question for improvement or retirement.
Figure 2: Business Value Matrix4
Sunsetting can be especially difficult with a new, yet unsuccessful, non-differentiating product.
The worst thing that can happen to a bad new product is sales, because now there are
customers to support. Another potential wrench in making the leap to sunset a product can be
political ramifications. The product might be critical to one customer, or gaining buy in with
management may prove difficult.
3 (Levitt)
4 (Collings & Atherton,2010)

3. It is also possible that an organization wants to axe a product or feature, but the costs of
redesigning or replacing the system are prohibitive. This is particularly applicable in on-premise
monolithic applications where implementing a new system would be costly. It is also common
that the way that the systemworks is not well understood. This can occur if systemdesigners
have left the organization and the system has not been fully documented or documentation has
been lost. In many of these cases, organizations do not even have adequate knowledge of how
their customers are using their systems. Product managers recognize that the product is past its
prime, but without truly understand the product it is likely that the wrong decision will be
made.
One way organizations try to manage the issue of application retirement is through a concept
known as planned obsolescence. For example, Microsoft lists the support end dates for all of
their products on support.microsoft.com. Many other companies, residing mostly in the
software and electronics industries use a planned obsolescence model that allows them to
easily sunset old releases, but this model is not without its own struggles. There are ethical
debates on the use of this model and it still does not address knowing with its time to sunset a
particular feature or an entire product line.
Once a decision is made to retire a product or feature, it is likely that organizations will struggle
with the process because they lack experience and expertise. Generally speaking,
communication to customers (both internal and external) will be insufficient, required data will
be not retained properly and the organization will fail to provide an alternative solutions or
upgrade path. Also, many organizations find it very difficult to tell their customers “no” and
therefore end up supporting products and features they very well know they should not be.
What makes this issue fundamentally difficult?
How can one tell this issue is fundamentally difficult? Everyone wants you to pay for
information to help with this process! This may be why only 20% of technology companies
report discontinuing software products, according to the Software Product Management: Best
Practices (2004) report from Software Minds.5 Standards exist that outline best practices for
the process of sunsetting products, but there is very little documentation on making the
decision. There are an unlimited number of factors to consider, such as strategic and portfolio
fit; contractual commitments; market factors; technology; customer, employee, and supplier
impacts; cost control; ability to archive data; regulatory compliance; knowledge of application
or platform; and the list goes on and on.
This decision making issue tends to make organizations fall into a state of analysis paralysis
whereby no consensus can be reached and no action is taken. Bill Gates is quoted saying, “The
only big companies that succeed will be those that obsolete their own products before
someone else does,” and he is spot on.
5 (Johnson,2007)

4. Who are the stakeholders?
Company employees, suppliers, shareholders, and customers are all stakeholders when it
comes to sunsetting a product or product feature. Without understanding how a customer is
utilizing said product or feature, organizations risk customer dissatisfaction and leading their
customers to feel abandoned if the decision is made to sunset the product. Without proper
communication to internal resources, it is likely that key stakeholders will not be made aware of
the decision and more importantly why the decision is being made. By better understanding
what products to retire and when, organizations can save costs, focus attention and resources
to other more lucrative areas.

5. Bibliography
Applimation. (2009, January). A Practical Guide for Retiring Legacy Applications. Retrieved
October 31, 2010, from ZDNet.com:
http://whitepapers.zdnet.com/thankyou.aspx?&docid=947913&view=947913&load=1&regSrc=z
d-dir
Collings, J., & Atherton, M. (2010, April ). Application Retirement: What about the Data.
Retrieved October 31, 2010, from Freeform Dynamics:
http://www.freeformdynamics.com/fullarticle_subscribe.asp?aid=1048
Johnson, S. (2007, July 19). End of Life: Retiring a Product. Retrieved October 31, 2010, from
Pragmatic Marketing: http://www.pragmaticmarketing.com/publications/magazine/3/3/0505sj
Koopman, J. F. (2010, Feb 10). Solix ExApps Brings New Relief to Application Retirement
Anxiety. Retrieved October 31, 2010, from DCIG Inc:
http://sponsored.dciginc.com/2010/02/solix-exapps-brings-new-relief.html
Levitt. (n.d.). Product Life Cycle. Retrieved October 31, 2010, from 12manager.com:
http://www.12manage.com/methods_product_life_cycle.html