Editing Software maintenance (section)

===Transition from release to maintenance to end of the lifespan===
[[File:Software retirement diagram.png|thumb|upright=1.5|Diagram showing the steps for [[Application retirement|software retirement]]]]
Frequently, software is delivered in an incomplete state. Developers will test a product until running out of time or funding, because they face fewer consequences for an imperfect product than going over time or budget.{{sfn |Reifer|2012|p=22}} The transition from the development to the maintenance team is often inefficient, without lists of known issues or validation tests, which the maintenance team will  likely recreate.{{sfn |Reifer|2012|p=21}} After release, members of the development team are likely to be reassigned or otherwise become unavailable. The maintenance team will require additional resources for the first year after release, both for [[technical support]] and fixing defects left over from development.{{sfn |Reifer|2012|p=22}} 

Initially, software may go through a period of enhancements after release. New features are added according to user feedback. At some point, the company may decide that it is no longer profitable to make functional improvements, and restrict support to bug fixing and emergency updates. Changes become increasingly difficult and expensive due to lack of expertise or decaying architecture due to [[software aging]]. After a product is no longer maintained, and does not receive even this limited level of updating, some vendors will seek to extract revenue from the software as long as possible, even though the product is likely to become increasingly avoided. Eventually, the software will be withdrawn from the market, although it may remain in use. During this process, the software becomes a [[legacy system]].{{sfn|Tripathy |Naik|2014|p=89}}