Modernizar un sistema legacy sin detener la operación

Casi todas las conversaciones sobre modernización empiezan mal, porque empiezan por la tecnología: "está en PHP 5", "usa jQuery", "corre en un servidor propio". Nada de eso es, por sí solo, un problema.

Un sistema es legacy cuando cambiarlo cuesta más de lo que debería y nadie puede predecir el costo. Esa es la definición útil, porque es la que se conecta con el dinero.

Las señales que sí importan

No la edad del código, sino estas:

Nadie puede estimar un cambio

Si la respuesta a "¿cuánto toma agregar este campo?" es "depende, hay que ver qué más toca", el sistema perdió su modularidad. Los cambios se propagan por rutas que nadie tiene mapeadas.

No hay red de seguridad

Sin tests, cada despliegue es una apuesta, y como cada despliegue es una apuesta, se despliega poco. Como se despliega poco, cada entrega acumula muchos cambios, lo que hace más probable que algo se rompa y más difícil saber qué lo rompió. Es un círculo que se cierra sobre sí mismo.

El conocimiento vive en una sola cabeza

Cuando hay una sola persona que entiende cómo funciona el módulo de facturación, el riesgo dejó de ser técnico y pasó a ser organizacional.

La operación depende de pasos manuales

Alguien corre un script a fin de mes. Alguien ajusta un registro a mano cuando el proceso falla. Esos parches son señales de que el sistema no modela bien el negocio actual.

El stack bloquea decisiones

Aquí sí entra la tecnología, pero como consecuencia: una versión del lenguaje sin soporte de seguridad, una dependencia abandonada, una base de datos que ya no recibe parches. El problema no es que sea viejo — es que ya no se puede actualizar sin tocar todo lo demás.

Las cuatro estrategias, con sus costos reales

No son alternativas ideológicas: son respuestas distintas a situaciones distintas, y se combinan.

Estrategia	Qué implica	Cuándo conviene	Su costo
Rehosting / replatforming	Mover el sistema a infraestructura moderna sin tocar la lógica	El problema es operacional: caídas, respaldos, escalado, costos de servidor	No mejora nada del código; el techo de mantenibilidad sigue igual
Refactoring	Reestructurar el código por dentro, sin cambiar el comportamiento	El sistema hace lo correcto, pero cuesta modificarlo	No produce funcionalidad visible, así que necesita respaldo explícito del negocio
Reemplazo gradual	Sacar el sistema por partes, módulo a módulo, con el viejo y el nuevo conviviendo	El sistema es grande y la operación no puede parar	Hay que mantener dos sistemas en paralelo un buen tiempo
Reescritura completa	Construir el reemplazo y cambiar de uno a otro	El sistema es pequeño, o su dominio cambió tanto que la lógica actual ya no sirve	El riesgo más alto de todos, y crece con el tamaño

Por qué la reescritura completa falla tan seguido

No por incompetencia técnica. Por dos razones estructurales:

No se puede congelar el negocio. Mientras se construye el reemplazo, el sistema viejo sigue recibiendo cambios: una ley nueva, un cliente grande que pide algo, un error que hay que corregir. El proyecto de reescritura persigue un blanco en movimiento, y cada cambio en el viejo hay que implementarlo dos veces.

El sistema viejo contiene reglas que nadie documentó. Años de casos especiales — el cliente que factura distinto, el descuento que aplica solo en una sucursal, el redondeo que contabilidad exige — viven en el código y en ningún otro lugar. Aparecen cuando el sistema nuevo ya está en producción y alguien nota que los números no cuadran.

Por eso el reemplazo gradual es, en la mayoría de los casos, la apuesta más razonable: cada módulo que se migra entrega valor de inmediato, y si algo sale mal, lo que falla es una parte y no todo.

Cómo se ve un reemplazo gradual en la práctica

El patrón se conoce como strangler fig — la higuera que crece alrededor del árbol y lo va reemplazando hasta sostenerse sola. Aplicado a software:

1. Poner una capa delante. Un enrutamiento en la entrada (un proxy inverso, o rutas a nivel de aplicación) que decide qué peticiones atiende el sistema viejo y cuáles el nuevo. Al principio, todas van al viejo.
2. Elegir el primer módulo por riesgo y valor, no por facilidad. El mejor candidato suele ser algo con límites claros, cambios frecuentes y poco acoplamiento — por ejemplo, la emisión de reportes o una integración con un tercero. Lo que menos conviene tocar primero es el núcleo transaccional.
3. Definir de dónde sale la verdad. Este es el punto que decide si el proyecto funciona. Para cada dato, un solo sistema es el dueño y el otro lo consulta. Dos sistemas escribiendo la misma tabla sin una regla clara es la fuente número uno de inconsistencias.
4. Migrar, desviar el tráfico, y recién entonces borrar. El código viejo se elimina cuando el nuevo lleva tiempo en producción, no el día del cambio.
5. Repetir, midiendo. Cada módulo migrado debería reducir el tiempo de los cambios siguientes. Si no lo hace, el orden elegido está mal.

Antes de escribir una línea

Tres cosas que valen más que cualquier decisión de arquitectura:

• Tests sobre el comportamiento actual. Aunque sean pocos y de alto nivel. Sin ellos no hay forma de saber si el reemplazo hace lo mismo, y "hace lo mismo" es el requisito que nadie escribe pero todos asumen.
• Un inventario de integraciones. Todo lo que consume el sistema: reportes, otro software, un archivo que alguien descarga, una consulta directa a la base de datos que hace el contador. Lo que no está en el inventario es lo que se rompe.
• Un criterio de éxito medible. Tiempo para poner un cambio en producción, incidentes por mes, horas de trabajo manual. Sin línea base, la modernización se evalúa por sensaciones — y el proyecto siempre "se siente" largo.

Nuestro enfoque

En id3a no partimos de "hay que reescribirlo". Partimos de entender qué duele y cuánto cuesta:

• Revisión de la arquitectura y las dependencias actuales, incluyendo qué ya no tiene soporte de seguridad.
• Identificación de los puntos que concentran el riesgo y de los que concentran los cambios — no siempre son los mismos.
• Un plan por etapas donde cada una entrega algo aprovechable por sí sola.
• Migración con los dos sistemas conviviendo, para que la operación no se detenga.
• Tests y documentación como parte del trabajo, no como una fase posterior que nunca llega.

A veces la conclusión es que no hay que modernizar todavía, y que conviene invertir en tests y en actualizar dependencias. Eso también es una respuesta.

Conversemos sobre tu sistema