Todo evoluciona en esta vida sino, tiende a quedar obsoleto, por ello está claro que el software tiene una vida limitada, igual que cualquier aplicación, siempre acaban siendo sustituidas, sea lo buena que sea en el momento de lanzamiento, gracias a esa evolución, tarde o temprano aparecerá algo mejor o distinto que superará a la anterior.

Sustituir un software que funciona, por uno nuevo o más avanzado se debe hacer de manera correcta para no modificar ni dañar nuestra información y trabajo previamente hecho. Lo mejor es hacerlo por partes, no es recomendable sustituir todas las aplicaciones o funciones del software de golpe ya que, además, la novedad implica una adaptación, y se debe dar un margen de tiempo a lo usuarios de ese software para acostumbrarse poco a poco a los cambios, si se hace de golpe puede llegar a parecer un programa completamente nuevo y crear problemas. Necesitaríamos hacer además un traspaso de la información generada y guardada en el anterior sistema para poder adaptarla al nuevo funcionamiento y que no se vea nada dañado o perdido.

Algo recomendable es mantener los dos sistemas trabajando juntos durante un tiempo prudente para poder hacer bien la adaptación y, así también, comprobar que la nueva aplicación funciona correctamente.

Cabe decir que el paradigma más usado es el ciclo de vida en cascada aunque se le han hecho diversas críticas por error que plantea tales como: el proyecto no sigue un ciclo de vida secuencial exactamente, siempre hay interacciones; también es complicado establecer los requisitos necesarios en un principio, estos se van puntualizando durante el desarrollo; otro inconveniente es que los errores se ven una vez el cliente lo prueba.

Son inconvenientes a tener en cuenta pero siempre es mejor seguir un patrón a no tener guía alguna.