Modernización
Deuda técnica vs reescribir desde cero: cuándo conviene cada camino
La pregunta no es si el sistema está viejo. Es si lo que hay adentro vale la pena conservar. La respuesta cambia el costo, el plazo y el riesgo del proyecto.
La pregunta llega siempre en el mismo momento: cuando el sistema ya duele lo suficiente como para que alguien en la dirección diga "hay que hacer algo".
El error más común no es tomar la decisión equivocada. Es tomar la decisión antes de tener el marco correcto para tomarla.
Por qué "reescribir desde cero" suena atractivo y por qué eso es un problema
Reescribir desde cero tiene una lógica limpia. Hoja en blanco, tecnología moderna, sin el peso del código viejo. Para un equipo que lleva años lidiando con un sistema frágil, la idea de empezar de nuevo tiene un atractivo genuino.
El problema es que esa lógica ignora el activo más valioso que tiene el sistema actual: el conocimiento de negocio que está codificado adentro.
Un sistema que lleva diez años en producción tiene diez años de reglas de negocio, excepciones, casos borde y flujos especiales que reflejan cómo opera realmente la empresa. Parte de ese conocimiento está documentado. La mayoría no lo está: vive en el código, en las cabezas de quienes lo construyeron, y en los hábitos del equipo operacional.
Reescribir sin mapear ese conocimiento primero es uno de los errores más costosos del ciclo de vida de sistemas empresariales. El resultado es un sistema nuevo que no sabe hacer lo que hacía el viejo, y lo descubres en producción.
"El sistema viejo es lento y frágil. El sistema nuevo es rápido y no sabe manejar los casos borde que el viejo tenía resueltos desde hace ocho años."
Esto no significa que reescribir sea siempre la opción equivocada. Significa que la decisión requiere criterios más precisos que "el sistema está viejo".
Los 4 factores que determinan cuál camino tomar
No hay una fórmula universal, pero hay cuatro factores que en la práctica determinan si modernizar o reescribir tiene más sentido para una empresa mediana con sistemas en producción.
1. Estado de la arquitectura
La pregunta no es si el sistema es viejo. Es si su arquitectura puede evolucionar. Un sistema con arquitectura modular, aunque tenga deuda técnica en el código, puede modernizarse reemplazando componentes uno a uno sin tocar todo al mismo tiempo. Un sistema monolítico donde todo está acoplado, donde cambiar una cosa obliga a tocar todo lo demás, es candidato a reescritura porque la modernización incremental tiene un techo bajo.
2. Distribución de la deuda técnica
Si la deuda técnica está concentrada en módulos específicos (el módulo de reportes, la integración con un sistema externo, el motor de cálculo) se puede atacar por partes. Si está distribuida en todas las capas del sistema, la modernización incremental nunca termina de resolver el problema raíz.
3. Retención del conocimiento de negocio
¿Qué tan bien está documentado cómo funciona el sistema actual? Si la documentación es escasa y las personas que lo construyeron ya no están, la reescritura tiene un riesgo mayor: el nuevo sistema va a reproducir el comportamiento del viejo de manera incompleta, porque nadie tiene el mapa completo. En ese caso, la modernización incremental (que preserva y documenta el comportamiento existente mientras lo reemplaza) reduce ese riesgo.
4. Tolerancia al riesgo de transición
Una reescritura implica un período donde dos sistemas coexisten: el viejo que mantiene la operación y el nuevo que se construye en paralelo. Ese período puede durar 12 a 24 meses. Durante ese tiempo, el equipo TI mantiene el sistema antiguo y desarrolla el nuevo; el equipo operacional trabaja en dos sistemas a la vez durante la migración. Si el negocio puede tolerar ese riesgo y ese costo doble, la reescritura es viable. Si no puede, la modernización incremental, que reemplaza el sistema viejo módulo por módulo con el negocio funcionando, es más segura.
Cuándo modernizar lo existente es la mejor opción
La modernización incremental conviene cuando se dan dos o más de estas condiciones:
El sistema tiene partes que funcionan bien. Si el motor de negocio central es sólido pero la interfaz es anticuada, o si la lógica de procesamiento es correcta pero las integraciones son frágiles, tiene sentido preservar lo que funciona y reemplazar lo que no.
La arquitectura puede evolucionar. Si es posible extraer módulos y reemplazarlos sin tocar todo el sistema, la modernización incremental permite entregar valor en plazos cortos mientras el sistema en producción sigue funcionando.
El conocimiento de negocio está mal documentado. La modernización incremental obliga a documentar el comportamiento de cada módulo antes de reemplazarlo, lo que convierte el proceso en una oportunidad de transferencia de conocimiento. Al final del proceso, el equipo tiene documentación del sistema que antes no existía.
El negocio necesita certeza de resultado. La modernización por fases permite demostrar resultados concretos en cada etapa: un módulo que funciona mejor, una integración que dejó de ser frágil, un proceso que se automatizó. Eso reduce la incertidumbre y facilita sostener el apoyo interno a largo plazo.
Un ejemplo concreto: una distribuidora con un ERP propio de doce años que maneja bien los pedidos y el stock, pero cuyas integraciones con los sistemas de transporte son frágiles y manuales. El camino correcto no es reescribir el ERP. Es modernizar la capa de integraciones y automatizar los procesos manuales mientras el motor central sigue funcionando. Ese trabajo puede hacerse en tres a seis meses con riesgo operacional bajo.
Cuándo reescribir desde cero tiene sentido real
La reescritura desde cero conviene cuando se dan dos o más de estas condiciones:
La arquitectura está comprometida en todas las capas. Si el sistema es tan monolítico y tan acoplado que cualquier cambio requiere tocar todo al mismo tiempo, la modernización incremental tiene un techo bajo. El costo de cada cambio se mantiene alto indefinidamente. En ese caso, una reescritura bien planificada puede ser más eficiente a largo plazo.
El negocio cambió de modelo y el sistema no puede seguirlo. Si la empresa creció, diversificó su operación, o cambió su modelo de negocio de maneras que el sistema actual no puede modelar sin distorsionar la arquitectura, la reescritura permite partir de los requerimientos reales de hoy en lugar de adaptar lo que existe.
El conocimiento de negocio está bien documentado. Esto es el requisito más importante para una reescritura exitosa. Si el equipo puede escribir casos de uso, reglas de negocio y flujos de excepción con precisión, el equipo nuevo tiene el mapa que necesita para construir el sistema correcto. Sin ese mapa, la reescritura reproduce el caos del sistema viejo con código nuevo.
El equipo tiene capacidad para operar dos sistemas en paralelo. La transición (el período donde el sistema viejo mantiene la operación y el nuevo se construye) requiere capacidad doble. Si el equipo TI no puede sostener eso, o si el costo operacional de ese período es inaceptable, la reescritura se transforma en una crisis en lugar de en un proyecto controlado.
El camino que nadie menciona: la migración incremental por capas
Entre "modernizar" y "reescribir desde cero" hay un tercer camino que muchas veces es el más sensato: reemplazar el sistema capa por capa, empezando por la capa de mayor riesgo o mayor costo operacional, mientras el resto del sistema sigue funcionando.
En la práctica, esto puede significar:
- Reemplazar la interfaz de usuario con tecnología moderna mientras el motor de negocio sigue siendo el mismo
- Extraer la capa de integraciones en un servicio independiente, eliminando la fragilidad sin tocar el núcleo
- Reemplazar el motor de reportes con una solución más flexible mientras el sistema operacional central no cambia
- Migrar el sistema de un servidor on-premise a la nube sin cambiar el código de negocio, como primer paso antes de modernizar el código
Este enfoque reduce el riesgo al mantener el sistema en producción funcionando, y permite avanzar hacia una arquitectura moderna sin el costo y el riesgo de una reescritura total. Para sistemas con una arquitectura medianamente modular, casi siempre es el camino con mejor relación entre riesgo y resultado.
La decisión correcta empieza con el diagnóstico correcto
La pregunta "¿modernizamos o reescribimos?" no tiene respuesta sin un diagnóstico del sistema actual. Cuánta deuda técnica hay y dónde está distribuida, qué partes funcionan bien y cuáles no, qué tan bien documentado está el conocimiento de negocio: esas respuestas son las que determinan cuál camino tiene sentido.
Para estructurar ese diagnóstico, el artículo sobre cómo evaluar la deuda técnica en TI cubre el proceso en detalle. Y si ya tienes el diagnóstico pero la decisión no está clara, ese es el tipo de conversación que hacemos en AW: sin compromiso de proyecto, solo para ayudar a que la decisión sea la correcta.
Puedes revisar cómo abordamos proyectos de modernización de sistemas legados y rescate de proyectos TI si quieres entender primero cómo trabajamos.
Preguntas frecuentes
Lo que la gente pregunta sobre este tema
¿Reescribir desde cero no es siempre más limpio y más fácil?
Es más limpio al inicio: no hay que entender código viejo ni lidiar con decisiones del pasado. Pero 'más fácil' depende de qué tan bien el equipo nuevo entiende el negocio que va a modelar. El sistema actual, por más deuda técnica que tenga, contiene diez años de reglas de negocio, excepciones y casos borde que están implícitos en el código. Reescribir desde cero sin capturar ese conocimiento primero es uno de los errores más costosos que puede cometer una empresa. Terminas construyendo una versión nueva que no sabe hacer lo que hacía la vieja.
¿Cuánto tiempo toma reescribir un sistema versus modernizarlo?
Depende del tamaño y la complejidad, pero en sistemas medianos (los típicos en empresas con 50 a 500 personas) una reescritura completa rara vez toma menos de 12 a 18 meses si se hace bien. La modernización incremental puede entregar valor en 3 a 6 meses en los módulos más críticos, con el resto siguiendo en fases. La diferencia es de tiempo, pero sobre todo de riesgo: durante una reescritura, el sistema viejo sigue corriendo la operación. Durante una modernización incremental, los nuevos módulos van reemplazando a los viejos con el negocio funcionando.
¿Qué pasa con el conocimiento de negocio que está en el sistema actual?
Es el activo más valioso y el más ignorado. El sistema actual, por más deuda técnica que tenga, tiene diez o quince años de reglas de negocio, validaciones, excepciones y flujos especiales que reflejan cómo opera realmente la empresa. Parte de ese conocimiento está documentado. La mayoría no lo está: vive en el código, en las cabezas de quienes lo construyeron, y en los hábitos del equipo operacional. Antes de cualquier decisión de reescritura o modernización, ese conocimiento tiene que mapearse. Lo que no se mapea antes, se redescubre después, a costa de incidentes en producción.
¿Hay casos donde ninguna de las dos opciones es la correcta?
Sí: cuando el problema no es el sistema sino el proceso. Si el proceso de negocio que el sistema automatiza es ineficiente o está mal diseñado, ni modernizar ni reescribir lo va a resolver. El resultado será un sistema nuevo o renovado que automatiza mal el mismo proceso. En esos casos, el trabajo correcto empieza antes del código: rediseñar el proceso con el equipo operacional, y solo después decidir qué sistema lo soporta mejor.
¿Cómo se decide entre modernizar en etapas o reemplazar de una vez?
Tres preguntas concretas: ¿La arquitectura actual puede evolucionar, o cada cambio requiere tocar todo al mismo tiempo? ¿El sistema tiene partes que funcionan bien y vale la pena conservar, o la deuda está distribuida en todas las capas? ¿El negocio puede tolerar el riesgo de una migración larga, o necesita certeza de resultado en un plazo corto? Si la arquitectura puede evolucionar y hay partes que funcionan bien, la modernización incremental casi siempre es más segura. Si el sistema está comprometido en todas las capas y el riesgo de una transición larga es tolerable, la reescritura tiene sentido.
¿Cuál es el costo oculto más común de una reescritura desde cero?
El tiempo en que coexisten dos sistemas: el viejo que mantiene la operación y el nuevo que se construye en paralelo. Ese período (que puede durar 12 a 24 meses) tiene un costo doble: el equipo TI tiene que mantener el sistema antiguo mientras desarrolla el nuevo, y el equipo operacional tiene que operar en dos sistemas a la vez durante la migración. Ese costo doble rara vez aparece en el presupuesto inicial del proyecto y es la principal causa de que las reescrituras tarden el doble de lo estimado.