Cuando una empresa se enfrenta a un sistema de software que ya no cumple con sus necesidades, surge la pregunta inevitable: ¿es mejor tomar el software existente y modernizarlo, o descartarlo y construir uno nuevo desde cero? Esta decisión puede tener un impacto de millones de pesos y años de trabajo, así que merece un análisis cuidadoso.
En IT Efectivos hemos visto ambos escenarios decenas de veces, y la respuesta casi siempre sorprende a nuestros clientes.
La prueba de los diez minutos
Antes de entrar en definiciones, hay una forma rápida de orientarse. Responde estas cinco preguntas sobre tu sistema:
- ¿Funciona hoy, aunque sea con quejas?
- ¿Tienes el código fuente completo y compila?
- ¿El lenguaje sigue teniendo versiones soportadas? (PHP, Java, .NET, Python sí; Visual FoxPro no)
- ¿Las reglas de negocio se afinaron durante años y nadie las tiene escritas fuera del código?
- ¿Parar la operación tres meses sería inaceptable?
Si respondiste que sí a cuatro o más, la retoma es casi con seguridad tu camino. Si respondiste que no a las dos primeras, probablemente estés ante uno de los casos donde reescribir tiene sentido. El resto de este artículo explica por qué.
¿Qué es la retoma de software?
La retoma de software (también conocida como software rescue o modernización) consiste en tomar un sistema existente, diagnosticarlo en profundidad y actualizarlo de manera incremental. Esto puede incluir:
- Actualizar el lenguaje de programación y frameworks a versiones modernas y soportadas
- Optimizar la base de datos y las consultas lentas
- Refactorizar el código para mejorar la mantenibilidad
- Agregar APIs para integración con otros sistemas
- Migrar la infraestructura a la nube
- Implementar medidas de seguridad modernas
- Documentar el sistema completo
Lo clave es que se preserva la lógica de negocio existente, las reglas que fueron refinadas durante años de operación y que representan un conocimiento invaluable.
¿Qué implica reescribir desde cero?
La reescritura total significa descartar el código existente y construir un sistema nuevo que replique (y mejore) la funcionalidad actual. Suena atractivo en teoría, pero en la práctica implica:
- Relevamiento completo de requerimientos (muchos de los cuales están ocultos en el código actual)
- Diseño de arquitectura desde cero
- Desarrollo, pruebas y despliegue de un sistema completamente nuevo
- Migración de datos del sistema viejo al nuevo
- Capacitación de todos los usuarios
- Un periodo de transición donde ambos sistemas pueden coexistir
Comparación de costos y tiempos
Basándonos en nuestra experiencia con empresas colombianas, estos son los números típicos:
Retoma de software
- Tiempo: 4 a 12 semanas
- Costo: 20% a 40% de una reescritura
- Riesgo de falla: bajo (el sistema sigue funcionando durante el proceso)
- Interrupción operativa: mínima o nula
Reescritura desde cero
- Tiempo: 6 a 18 meses (frecuentemente con retrasos)
- Costo: 100% (y con alta probabilidad de sobrecostos del 50-200%)
- Riesgo de falla: alto (el famoso "segundo sistema")
- Interrupción operativa: significativa durante la migración
El síndrome del "segundo sistema"
Frederick Brooks, en su clásico libro The Mythical Man-Month, describió el "efecto del segundo sistema": la tendencia a sobrediseñar la segunda versión de un sistema, añadiendo funcionalidades innecesarias y complejidad que retrasan el proyecto indefinidamente.
Veinticinco años después, Joel Spolsky lo puso en términos más duros en su ensayo Things You Should Never Do: reescribir desde cero es, según él, el peor error estratégico que puede cometer una empresa de software. Su argumento es sencillo y difícil de rebatir.
Hemos visto empresas colombianas que invirtieron 2-3 años y cientos de millones de pesos en reescrituras que nunca se completaron, terminando por volver al sistema viejo. Este es un riesgo real y devastador.
Por qué el código viejo parece peor de lo que es
Aquí está el punto que casi nadie ve a tiempo. Cuando un desarrollador nuevo abre un sistema de diez años, ve un desastre: condicionales anidados, excepciones raras, funciones con nombres que no dicen nada. La conclusión natural es «esto está mal hecho, hay que rehacerlo».
Pero buena parte de ese desorden no es mala programación: es memoria. Cada condición extraña suele ser un caso real que alguien reportó, un cliente que factura distinto, una excepción tributaria de un año concreto, un cambio normativo que hubo que aplicar en tres días.
Ese conocimiento no está en ninguna otra parte. No está en el manual, porque el manual no existe. No está en la cabeza de nadie, porque quien lo escribió se fue. Está en el código, y solo en el código.
Cuando se reescribe desde cero, ese conocimiento se pierde entero, y se vuelve a aprender de la peor manera posible: fallando en producción, un caso por vez, delante de los usuarios.
La trampa de la paridad funcional
Toda reescritura empieza con la misma promesa: «hacemos lo mismo que hace hoy, pero moderno». Esa frase esconde el trabajo real.
«Lo mismo que hace hoy» no es lo que dice el manual ni lo que recuerdan los usuarios: es todo lo que el sistema hace de verdad, incluidos los comportamientos que nadie sabe que existen hasta que faltan. Alcanzar esa paridad consume la mayor parte del presupuesto, y es un trabajo del que el negocio no percibe ningún beneficio: al terminar tiene lo mismo que tenía, con suerte.
Por eso tantas reescrituras se quedan a mitad de camino. El dinero se acaba en replicar lo viejo, antes de llegar a lo nuevo que motivaba el proyecto.
Cuándo sí conviene reescribir
La reescritura puede ser la mejor opción cuando:
- La tecnología base es tan antigua que literalmente no se consiguen desarrolladores (COBOL, Visual FoxPro, PowerBuilder)
- La arquitectura es tan frágil que cualquier cambio rompe algo
- Los requerimientos del negocio cambiaron radicalmente y el sistema actual no puede adaptarse
- El código fuente se perdió completamente
Conviene matizar el primer punto, porque es el que más se usa como excusa. Que un lenguaje sea viejo no lo hace irrecuperable: el problema aparece cuando ya no hay quien lo lea, no cuando ya no está de moda. Un sistema en Delphi con el código completo y alguien capaz de entenderlo es un candidato razonable a retoma. El mismo sistema sin fuentes, no.
Cuándo conviene la retoma (la mayoría de casos)
La retoma es la mejor opción cuando:
- El sistema funciona pero tiene problemas de rendimiento, seguridad o mantenibilidad
- La lógica de negocio es compleja y fue refinada durante años
- La empresa no puede detener operaciones durante meses
- El presupuesto es limitado y se necesitan resultados rápidos
- El sistema está en tecnologías actualizables (PHP, Java, .NET, Python)
Cómo se moderniza sin apagar nada
La objeción razonable a la retoma es: «si no lo reescribo, ¿cómo lo cambio sin romperlo?». Hay un método, y tiene nombre.
Lo primero es documentar lo que el sistema hace hoy, no lo que debería hacer. Se toman las operaciones reales, se registra qué entra y qué sale, y eso se convierte en la red de seguridad: cualquier cambio posterior tiene que producir exactamente el mismo resultado. Sin esa red, cada modificación es una apuesta.
Después se moderniza por partes, no de una vez. El patrón se conoce como Strangler Fig, por la higuera que crece alrededor de otro árbol hasta reemplazarlo: se construye lo nuevo alrededor de lo viejo y se van desviando funcionalidades una por una, hasta que el sistema original se puede apagar sin que nadie lo note.
La diferencia con una reescritura no es de herramientas, es de riesgo: en cada momento hay un sistema funcionando, y si un paso sale mal se revierte ese paso, no el proyecto entero.
¿Y los datos?
En casi toda conversación sobre modernizar aparece el mismo miedo, y suele ser el verdadero freno: no es el código, son los años de histórico.
Es un miedo fundado, pero es un problema resuelto y medible. En un caso nuestro movimos 11 TB desde Oracle con 11.360 millones de filas verificadas y 100% de coincidencia entre origen y destino. Lo importante ahí no es el volumen: es que hubo forma de demostrar que no se perdió nada, que es justo lo que permite apagar el sistema viejo con tranquilidad.
Nuestro enfoque híbrido
En IT Efectivos frecuentemente aplicamos un enfoque híbrido: retomamos el sistema existente, estabilizamos lo crítico, y luego modernizamos por módulos. Esto permite que la empresa siga operando normalmente mientras el software se transforma gradualmente.
Por ejemplo, podemos:
- Actualizar el framework de PHP 5 a PHP 8 en la primera fase
- Migrar la base de datos a la nube en la segunda fase
- Reconstruir el módulo de reportes con tecnología moderna en la tercera fase
- Agregar una API REST para integraciones en la cuarta fase
Cada fase entrega valor inmediato sin poner en riesgo la operación.
Preguntas frecuentes
¿Cuánto tarda saber cuál de los dos me conviene?
Un diagnóstico serio toma entre tres y cinco días: revisar el código, las dependencias, la base de datos y el estado de seguridad. Menos que eso es una opinión; más que eso, normalmente, es que ya empezó el proyecto.
¿Se puede retomar un sistema sin documentación?
Es el caso habitual, no la excepción. La documentación se genera durante el diagnóstico: forma parte del trabajo, no es un requisito para empezarlo.
¿Qué pasa si el desarrollador original no quiere colaborar?
No hace falta que colabore. Con el código fuente y acceso al sistema en funcionamiento se puede reconstruir cómo opera. Es más lento que preguntarle, pero se hace.
¿La retoma sirve para pasar a la nube?
Sí, y suele ser el momento natural para hacerlo. Mover un sistema sin actualizarlo antes solo traslada el problema a una factura mensual.
¿Qué pasa si a mitad del camino descubren que sí había que reescribir?
Pasa, y es una respuesta legítima del diagnóstico. La diferencia es cuándo se descubre: en la primera semana, con un informe y sin haber comprometido el presupuesto, o en el mes catorce de una reescritura.
Conclusión
En nuestra experiencia, el 80% de los sistemas legacy pueden y deben ser retomados en lugar de reescritos. La retoma es más rápida, más económica y mucho menos riesgosa. Solo en casos extremos la reescritura total es la respuesta correcta.
Y conviene recordar por qué: no porque el código viejo sea bueno, sino porque contiene años de decisiones que nadie escribió en otra parte. Tirarlo es tirar eso.
¿No sabes cuál es la mejor opción para tu caso? En IT Efectivos ofrecemos un diagnóstico técnico gratuito donde evaluamos tu sistema y te recomendamos el mejor camino, con tiempos y costos estimados. Sin compromiso.
Agenda tu diagnóstico gratuito o escríbenos a info@itefectivos.com.