Proyectos legacy: ¿evolucionar o sustituir?

Escrito por Olivér Haszpra

¿Por qué evolucionar y no sustituir?

Aunque no siempre guste oírlo, sustituir un sistema antiguo no es tan sencillo como parece, porque:

  • No conoces la especificación real
  • Probablemente ni siquiera exista una especificación completa
  • El sistema en producción debe seguir funcionando mientras se desarrolla el nuevo
  • Por eso no puedes asignar simplemente a tu equipo actual al nuevo proyecto

¿Entonces no puedo sustituirlo?

, puedes, pero habrá retos:

  • Necesitarás más capacidad hasta que el sistema antiguo pueda retirarse
  • Necesitarás una especificación muy detallada de qué debe hacer exactamente el sistema y cómo, algo que muchas veces nadie conoce con precisión dentro de la empresa

¿Cuándo conviene sustituirlo?

  • Si tienes dinero ilimitado para invertir
  • Si el proyecto antiguo ya no atrae a desarrolladores con talento
    • A los developers les gusta trabajar con tecnologías más nuevas
    • Quieres atraer talento usando nuevas tecnologías
  • Si el sistema antiguo tiene problemas demasiado graves como para corregirlos
  • Si sería demasiado difícil o imposible introducir nuevas funcionalidades
  • Si sería demasiado difícil o imposible implantar una nueva UI o un nuevo diseño

¿Cuándo conviene evolucionarlo?

  • Si los problemas del sistema no son tan críticos
    • Sigues pudiendo contratar buenos desarrolladores para trabajar en él
    • A tus clientes, usuarios o empleados les sigue gustando
    • No hacen falta grandes cambios; en general estás razonablemente satisfecho con el sistema
  • Si solo necesitas añadir pequeñas funcionalidades o correcciones de vez en cuando y el sistema no lo impide
  • Si no tienes los recursos necesarios para construir un sistema nuevo desde cero
  • Si no tienes, y en la práctica tampoco puedes obtener, una especificación precisa ni del sistema antiguo ni del nuevo

¿Cómo evolucionarlo y cómo sustituirlo?

Léelo en nuestro próximo artículo.

Volver a las entradas de blog