The Sun also Sets: Ending the Life of a Software ProductSlinger Jansen1 , Karl Michael Popp2 , Peter Buxmann313Utrecht University, Utrecht, the [email protected] AG, Waldorf, [email protected] University of Technology, Darmstadt, [email protected] Sunsetting a software product is a painful and frustrating process,whether it happens in times of crisis or in an organized and planned manner.It is surprising that little information is available on how to perform sunsettingand it appears to be a blind spot in software product management literature. Thispaper describes the sunsetting method and provides practitioners with a welldefined process of how software products must be taken out of development,maintenance, and finally use. With the sunsetting method, product managers willhave as little trouble as possible based on the experiences of others. The processdescription is elaborated using a method description. Furthermore, three retrospective case studies have been conducted to evaluate the method.Key words: sunsetting, product software, end-of-life, method engineering1 IntroductionWe define sunsetting as the process of planning and executing the end-of-life of a software product that is currently in use by customers and maintained by a software producing organization. The end-of-life of a software product describes the point after whichthe product is no longer maintained or supported by the manufacturer of the softwareproduct. Phase-out is an alternative term for sunsetting. Sunsetting is actually part ofthe portfolio management process.Portfolio management is defined as the strategic decision process, whereby a business portfolio is constantly updated and revised in order to meet business objectives [1].In the context of software vendors, the aim of portfolio management is to get the mostout of a companys investments and products [2]. Good portfolio management requiresclose oversight, constant review of historical and current performance, and the courageto rebalance and rationalize the portfolio when necessary while aligning your actionswith the overall strategy of the organization [3]. Basically, product phase-out is part ofthe continuous assessment that a software product manager undertakes when evaluatingthe product portfolio.In a time of double-digit growth in the software industry, it may seem illogical to address the death of a software product. Why would one wish to phase out an unsuccessfulproduct when there is always the chance that a customer might order it, or orders extralicenses out of the blue? As more experienced software product and portfolio managers

2Slinger Jansen et al.know, there are many reasons to do so. These reasons are found in three categories,being product strategy, platform changes, and portfolio decisions [4, 5].In regards to product strategy, there are simple reasons such as release deprecation(e.g. a software vendor only supports the last two minor releases) and a lack of demandfor the product. Another reason may be that maintenance becomes too expensive, i.e.,upkeep for multiple products is too expensive for one company, or when developers fora technical platform become too scarce. It must be noted that a products life expectancyand potential profitability is more relevant than current profitability. If a product is successful presently, but will be hard to monetize in a couple of years because the product isno longer needed or based on technology that will become outdated soon, it can becomea candidate for discontinuation.The platform on which the product is built can also change the course of a products lifecycle. If a new release is made of the underlying technology, for instance theoperating system as a basis for applications, the product owner has to decide when thereleases of the product based on the older platform are no longer required to maintain ahealthy business. Another platform on which the product depends might be a databasesystem. If a database system is phased out, the product needs to evolve as well, or bephased out as well.Finally, there may be portfolio decisions that end the life of a product. A productmay be an inferior duplicate to another product, or a product may be outdated. Anotherreason may be that the product is no longer profitable or even performing badly insuch a manner that it is causing harm to the software vendors reputation. Finally, legalconstraints may force a product owner to kill off a product. These legal constraints maybe that the company has formed a monopoly and is forced to reduce specific activities,or that intellectual property laws are broken by the product.There are several factors that influence the ideal moment, with the least damageto the company, to end the life of a software product. Environmental influences, suchas the entrance of a new standard or the introduction of regulatory requirements, suchas XBRL-based reporting (a universal standard that allows for automatic processingof business accounting data), may mark such an ideal moment. Also, please note thatthere is a difference between ending the life of a product all-together and ending its lifeas a customer of an application [6], even though these processes have many things incommon, such as changing customer needs, technical change, regulatory change, andcompetitive change.To further illustrate, we take the example of Microsoft when it ends the life of oneof its own products, by taking a closer look at one of the Windows versions. Microsoftpublishes three dates to customers for each version of the Windows operating systemin regards to sales, being the date of general availability, retail end of sales, and theend of sales for PCs with Windows version pre-installed. Furthermore, three dates arepublished in regards to support, being the publication of the latest service pack, the endof mainstream support date, and the end of extended (paid) support date. Obviously,for some organizations a major operating system upgrade is a huge undertaking, interms of system maintenance (imagine an organization with over 5000 workstations),in terms of system compatibility (organizations easily have over 10,000s of applicationsof which many are compatible with one version of Windows only), and in terms of in-

Ending the Life of a Software Product3vestment (hardware may be outdated, the upgrade will involve acquiring new licenses).An interesting detail of Microsoft’s terms of service is that pre-installed deploymentsof Windows sometimes have downgrade rights, enabling the customer to downgrade toa previous version of Windows that is compatible with the other Windows versions inthe organization.We continue this paper by describing the research method in section 3. The researchmethod is followed by a decomposition of the interactions between software vendor andcustomer in section 2, to illustrate what type of agreements need to be dismantled whenending the life of a software product. In section 4 the product software discontinuationmethod is presented and described in detail. Section 5 continues with the description ofthree case studies that illustrate the method and show the intricacies of the sunsettingprocess. Finally, in section 6, the conclusions are derived and discussed.2 Decomposing SunsettingWe now provide a further explanation of the complex operation of sunsetting. Thispaper looks specifically at on-premise software, which is provided from a softwarevendor to the customer. For the sake of simplification, let us assume a simple, directrelationship between the software vendor and the customer. In this case, sunsetting islike rolling back a distributed transaction between the software vendor and a customer.This distributed transaction can be divided into three subtransactions: Provide software,Provide maintenance and Provide support. While rolling back this transaction and itsthree subtransactions seem simple, the next level of detail shows that there are subtransactions that cannot be rolled back. They need compensating transactions and thusintroduce complexity and efforts into the process of sunsetting solutions. Another factorfor adding complexity and efforts is customer lock-in.Provide software - The transaction Provide software is divided into the subtransactions Provide a copy of the software, Transfer usage rights and Provide license key. Thefirst transaction Provide a copy of the software can be easily rolled back if the customerhas a time limited license. The customer just has to give back the copy of the softwareat the end of the license term. If the customer has a perpetual license, the customer cankeep the copy of the software. The second transaction Transfer usage rights cannot berolled back in a simple manner. Based on the contract terms, the customer can keep theusage rights, the usage rights can end. If the customer has perpetual usage rights, heneeds to get usage rights on a software product that replaces the sunsetted product.Replacing the sunsetted software product introduces more complexity and effort forthe software vendor and the customer. Replacing a sunsetted software product with anew software product means that the results of activities that have gone into installing,implementing, maintaining and running the software cannot be rolled back and usuallycarry high sunk cost. A compensating transaction has to collect the results of these activities and migrate these results into a new software product that replaces the sunsettedproduct. Simple examples for these results are customer data or customer specific extensions of the software product. How this replacement is properly planned and executedwill be covered later in this paper. The third transaction Provide license key follows thesame logic of rolling back as Transfer usage rights.

4Slinger Jansen et al.Provide maintenance - Provide maintenance is divided into subtransactions Provide new release, Provide new version and Provide bugfix. Over time, the customer isserved by multiple executions of these subtransactions. At a certain point in time, thecustomer arrives at a combination of release, version and bugfix. In the case of replacement of sunsetted product, the customer needs a replacement of exactly the combinationof release, version and bugfix he is currently running. This shows additional complexityin replacing sunsetted software, since each of the customers might have a specific combination that might differ from the combination each other customers have. Numerousinstances of these transactions have been executed and have lead to the current systemlandscape at the customer.Provide support - The third high-level transaction is Provide support, which aimsat providing resolutions or workarounds for customer issues with the software. Each ofthe transactions was executed several times. The result of the transactions is a customerspecific set of resolutions or workarounds. The transactions do not have to be rolledback.3 Research MethodThe research question of this paper is:How can a method be created for a product manager to sunset a product (line)?The research question is answered by applying method engineering in a design research project. Method engineering is used for designing, constructing and adaptingmethods, techniques and tools to develop information systems [7]. Design science is anoutcome based information technology research method, which offers specific guidelines for evaluation and iteration within research projects [8].Research Execution - The research consists of three steps. A first version of themethod was created to create a baseline method, based on literature and experience.The method is evaluated with several experts from the industry (with 15, 15, and 13years of experience), who have long-standing experience with retiring and sunsettingsoftware products and product lines. Thirdly, the method is evaluated by doing threeexploratory case studies, to establish that the method is complete. The case studies arelisted in table 1 and further discussed in section 5.Method Engineering - van de Weerd et al. [9] describe a meta-modeling techniquebased on UML. This technique depicts a method in a Process-Deliverable Diagram(PDD). A PDD consists of two parts: a process model (UML activity model) on theleft side and the deliverable model (UML class diagram) on the right side. An example PDD is depicted in Figure 1, which models a highly simplified requirements engineering process. On the left-hand side an activity called “Requirements elicitation”is modeled, which contains the sub-activity “Write requirements document”. The requirements engineer executes the activity. The activity results in a deliverable called“Requirements Document”, which has several properties. The main reason for usingthis type of method descriptions is that it enables us to present the sunsetting methodin a structured manner, and enriches the main contribution of this paper from a simple

Ending the Life of a Software Product5checklist, to a rich method description that can be reused by practitioners and improvedupon by academics.RequirementselicitationRequirements DocumentWrite requirements eriaTechnical sepcificationFig. 1. Process-data diagram [9]Case Study CompanyIdentifier# of em- Age Locationployees/productsPubCompERPComp18000/40 15* Netherlands,Europe51000/100 38 Germany,world-wideServicesComp 9100/100 18 Netherlands,EuropePhased out productReasons for phase-out# of em- Ageployees inproductunitOut of portfolio scope, 12020not making targetsRedundant,rebranded 2010product branch, contractstandardization, reducemaintenance effortsDuplicate functionality, 13516aged technologyTable 1. Companies and Products (* age of the software business, the company was establishedin 1878)The three companies were opportunistically selected, since we had access to boardlevel management in each of the companies. Each of the companies, however, has a longexperience dealing with large product portfolios and were selected with that reasonin mind. Each of the interviewees was working at one of the case companies at thetime. The interviews were undertaken in four steps. First, a general discussion was hadabout the organization. Secondly, we discussed the topic of phase-outs, and tried toestablish the interviewees view on the topic, including any previous experiences theinterviewee had with the topic. The interviewees were asked to develop a quick outlinefor a method themselves, to see whether they understood the topic and to see whethertheir experiences further confirmed the first version of the method. Documentation, if

6Slinger Jansen et al.available, was handed over in regards to product end-of-life. In the third step, the firstversion of the method was shown to the interviewees and walked through with theexact same narration for all interviews. The interviewees were allowed to comment onthe method and all three at some point grabbed a pen to make their own additions andchanges. During step four, an example from the interviewee’s past was taken to seewhether the method was followed in any way.Three interviews were undertaken, of which two in Dutch and one in English. Themethod was always described in English and each term was explained in a glossary,which the researchers brought to the interview. Interviews took between 100 and 150minutes. Each of the interviews was recorded. The interviews were conducted by oneresearcher only. The results from one of the interviews were checked by a second researcher.4 The Product Software Discontinuation MethodThis section describes the method shown in figure 2. On the left side the method activities are displayed, on the right side the deliverables created during the execution of themethod are shown. These deliverables are further explained in table 2. The first versionof this method was created from literature, the second version was created based onthree interviews and case studies.The first version of the method was in part inspired by IEEE std 1074 [10], a process standard for the software lifecycle, which provides a concise description of theretirement process. The description consists of three steps, being “notify user”, “conduct parallel operations”, and “retire system”. The “parallel operations” step consists ofusing two systems simultaneously, while one of the two is being phased out. The IEEEstandard provides some insight into the retirement process, but does not specifically address the challenges a software vendor may experience during a product phase out. Themethod was also inspired by several product phase-out overviews from larger softwarevendors, such as the Microsoft Windows phase out web pages, the information pagesfrom SAP about Business Object’s (acquired by SAP) SRC, and the pages from Ciscoabout the Quality of Service (QoS) Device Manager Software, which was phased outover a long period in the previous decade.Discontinuation Assessment - Any organization that maintains a software productmust regularly assess the viability of its products and product lines, as part of the portfolio management process. This process consists of reviewing the portfolio plans forcurrent products, assessing their success, profitability, market size, and growth. Whena product becomes a potential candidate for discontinuation, a customer assessmentneeds to be done to establish how important the product is for these customers and howimportant these customers are, since discontinuation of the product could mean the termination of a long-lasting relationship. Finally, a list must be created of all the productsthat depend on the product that may be discontinued. In case of discontinuation, theteams behind all products on the list of dependent products must be informed.Phase-out Planning - Whenever a phase-out is impending, software vendors needto evaluate possible alternatives before actually phasing out a software product. Thereare several alternatives to phasing out a software product that still ensure continuation of

Ending the Life of a Software onassessmentReview lifecycle and portfolio plansPerform customer assessmentCustomerassessmentReview product dependenciesDependentproduct Evaluate alternative option listAlternativeoption listOrganizationalchange planCreate organizational change planPerform legal -phase outMake sunset planningEstablish communication policyPhase outCreate detailed transition templateplan for customersSunset/Release planCommunicationpolicyTransition templateplan for customersStop shippingEnter maintenance modeInform organizationInform sales departmentInform customersInform resellersInform regulatory bodiesStop selling licensesStop supporting/maintainingRe-allocate maintenance teamEnd product's lifeProduct eulogyFig. 2. Product Software Discontinuation Method (all activities executed by product owner)7

8Slinger Jansen et al.the business, although perhaps with different levels of quality of support. The followinglist is not exhaustive, but presents some of the alternatives to completely phasing outthe software product:– Open source - it is possible to establish an open source community that further supports and maintains the product. This option, if the product is not already open source,should provide a real alternative, i.e., a sustainable community must be created thatmaintains and provides support, and there should not be a contractual conflict in regards to licenses.– Management Buy-out - if a product is being maintained by an isolated group ofpeople within the organization and the product could become more profitable if it didnot have to support the parent organization, one option to avoid product phase-outis to have a group of adequate managers or key people in the product group buy theproduct out of the portfolio, and continue as an independent organization.– Sale - when a product no longer fits the portfolio of an organization, it can be soldto a third party, along with (parts of) its maintaining organization. Organizations willgenerally go to great lengths to sell off a product instead of killing it off. A commonphenomenon is that an organization starts “putting lipstick on the pig”, i.e., trying tomaximize profit and growth numbers to make the product group more attractive to apotential seller.Based on the alternatives, an organizational change plan is created and a legal assessment is performed. The organizational change plan establishes how the productdiscontinuation is implemented in the organization, together with a timeline of events.A legal assessment is performed as well, to establish the consequences of the differentvariations of the plan. The legal implications can be serious, in that contractual obligations towards customers and partners may need to be altered to accommodate a productsdiscontinuation.Pre-phase out - If no alternatives are found, the product will need to be phased out.To do so, a planning is made that details the steps that are taken in the process. Suchsteps include the cessation of maintenance and support of a product, and the last saleof licenses. One of the most precarious processes of the phase-out is the establishmentof a communication policy, due to the nature of the phase-out process. Phasing out asoftware product entails in some cases the complete disbandment of a products maintaining unit. The impact the discontinuation of a software product can have requires thata communication policy is set-up that minimizes damage to the organization.Phase-out - After a phase-out plan has been crafted, the plan must be executed,starting with the creation of a customer transition plan template, which lists severalroutes to a new solution for customers, such as migration to a replacement product.This is a template and must be adjusted for each individual customer, since each customer operates from a unique situation. If the product is still being sold that must bestopped. Furthermore, the product must fully go into maintenance mode, such that nonew functionality is added to the product, with the exception of updating time-sensitivecontent. Once the product is in maintenance mode, the communication policy is executed according to the timeline created earlier. After communicating with all stakeholders that the product will be discontinued, a last round of license sales can be done,

Ending the Life of a Software Product9after which license sales are ceased as well. As soon as the product legally no longerrequires support and maintenance, these processes can be stopped as well, after whichthe maintenance team needs to be re-allocated. Finally, the product is finished, and theproduct manager or entrepreneur who has been responsible for the phase-out process,can write a product eulogy.Painful Process - The method description does not sufficiently show that the process of phasing out a software product actually has great consequences for the peopleworking with it. Think, for instance, of the support engineer who knows every nookand cranny of the software product, or the user who has configured the product just toher specifications and is described as the wizard of that product by her colleagues. Weadvise practitioners to make compromises and be sensitive towards the emotions thatsurround legacy products, both in their internal and external communication. By taking it slow and on-boarding fanatic proponents of the legacy products, transitions maypotentially go much easier.5 Case StudiesThe case studies were performed to provide different examples of how the lives ofproducts are ended. The cases served as a measure to evaluate the method provided infigure 2.5.1 Case Study: Health and Safety Product at PubCompContext. The HSP (a Health and Safety Product) was a relatively successful product that no longer supported the business goals of PubComp, a software vendor in theNetherlands with a large portfolio. The HSP came up in regular evaluations at PubCompas being out-of-scope of the product portfolio, and was consistently underperforming.Process. These evaluations were top-level management evaluations, and were treatedas top-secret, since they deciding on the future of approximately 120 people. After considerable time, a team was identified within the HSP business unit that could potentiallyundertake a management buy-out. The HSP team and PubComp agreed to a buy-outprice and strategy. Within 18 months the HSP business unit was functioning independently and the formal contract was signed.Findings. When a management buy-out or the sale of a product to another companyis in sight, some interesting processes start taking place. There are issues with personell, resources, and business unit value determination (although one could argue this isrelevant for ‘regular’ phase-outs as well). Purchasers attempt to find all the things thatcould bring the value of the company down, whereas the seller will be tempted to makethe business unit look more successful than it actually is. The sale of a business unit isa more organic and management-directed transition than a planned phase-out.Impact on the method. The first version of the method assumed that the end ofa life of a software product always entails the complete ending of sales, support, etc.This first case already showed that it is rarely the case that the product, whose customers always represent some kind of business value, is completely phased out without

10Slinger Jansen et al.Concept NameConcept DescriptionP RODUCT DISCONTINUATION This document describes the complete plan on how to disconDOCUMENTtinue the product. The creation of the document only expressesthe intent to explore the options for discontinuation and plansmay be discarded after the LEGAL ASSESSMENT and CUS TOMER ASSESSMENT have been completed.C USTOMER ASSESSMENTThe CUSTOMER ASSESSMENT is performed to explore what theeffect will be for customers and how relationships will be altered after discontinuation. The assessment includes a generalassessment and a specific assessment per individual customer.D EPENDENT PRODUCT LIST The DEPENDENT PRODUCT LIST lists all products that are dependent on the discontinued product and therefore may alsohave to be discontinued.A LTERNATIVE OPTION LIST The list of alternatives provides an overview of alternatives todiscontinuation, such as the sale of the product to a third-party.L EGAL ASSESSMENTThis document describes the legal risks and consequences,based on the CUSTOMER ASSESSMENT and DEPENDENTPRODUCT LIST .O RGANIZATIONAL CHANGE This document describes how the organization will change inPLANthe following period as the product is discontinued.S UNSET / RELEASE PLANThe SUNSET / RELEASE PLAN describes how the product wasplanned to be phased out, if such a plan is available. If not asunset plan is created. It is also called a lifecycle plan.C OMMUNICATION POLICYThe COMMUNICATION POLICY describes how and especiallywhen the discontinuation plans are communicated. These documents are generally sensitive and must be treated so by theentire organization to avoid leaking.T RANSITION TEMPLATE FOR Based on the CUSTOMER ASSESSMENT a TRANSITION TEM CUSTOMERSPLATE is created for each customer group, that can be filled inby a consultant, as to advise a customer in the transition to (forinstance) a new system.P RODUCT EULOGYThe PRODUCT EULOGY describes what the product was, howwell it performed, and why it was phased out.Table 2. Concept Tableany viable alternatives for the product (management buy-out or purchase by anothercompany) or for the customers (in the form of a product alternative, for instance).5.2 Case Study: Enterprise Resource Planning Product at ERPCompContext. A large platform provider in Germany has been growing autonomously, for almost 40 years. The company has gone through several product sunsets, but availabilityof knowledge on these processes within the organization remains scarce. In 2007, ERPComp acquired a company that specializes in identity management products and wasaimed to be complementary to the ERP platforms supplied by ERPComp. Throughoutthe years, ERPComp integrated some of the technological feats that came with the iden-

Ending the Life of a Software Product11tity management products into a new identity management platform, thereby makingsome of the original products redundant. In 2007 it was decided that the last productsthat were still being supported by ERPComp from the acquired company were to besunsetted. In total, different versions of six products were to be phased out.Process. First, an overview was created of the different products that were currentlyin use and of how many active customers each of these products had. Secondly, anoverview was created of upgrade and migration routes that could be traveled by customers. Part of this overview was a plan that described what happened when a customerordered extra support, licenses, or even a new deployment.Findings. An extra complication was that some of the products had been resold andrebranded under another label and these also needed to be phased out. Phasing out therebranded product proved to be a challenge, since the resellers that sold the rebrandedproduct also had service contracts with their customers. As soon as ERPComp phasedout the product, the reseller contracts were also ended. Because of this, the customersof those resellers no longer received support and maintenance. ERPComp solved thiselegantly by timing exactly when these customers would be willingly transitioned fromthe reseller to ERPComp.The phase-out timeline had to be extended twice with one year, because ERPCompwrongly estimated the availability of consultants that would be needed for each transition. Furthermore, for some customers it proved to be interesting to extend the maintenance period f

The Sun also Sets: Ending the Life of a Software Product Slinger Jansen1, Karl Michael Popp2, Peter Buxmann3 1 Utrecht University, Utrecht, the Netherlands [email protected] 2 SAP AG, Waldorf, Germany [email protected] 3 Darmstadt University of