Reemplázalo pieza por pieza mientras sigue funcionando: el patrón strangler fig

El sistema viejo funciona, casi siempre. También frena cada cambio y depende de personas que conocen sus rincones. La respuesta tentadora es reescribirlo todo: construir el sistema nuevo al lado y cambiar en un fin de semana. Ese plan le pide al negocio esperar meses para ver valor y concentra todo lo desconocido en un solo corte. Hay una forma más segura: reemplazar el sistema viejo pieza por pieza, mientras sigue funcionando.

El enfoque se conoce como patrón strangler fig (higuera estranguladora), por una planta que crece alrededor de un árbol hasta sostenerse sola. El sistema nuevo crece alrededor del viejo, asume su trabajo una capacidad a la vez, y el viejo se retira solo cuando ya nada depende de él.

Pon una capa de enrutamiento al frente

Todo empieza con un único punto por el que pasan todas las solicitudes antes de llegar al sistema viejo. Puede ser un proxy inverso, un API gateway o una capa delgada de código dentro de la misma aplicación.

Esa capa es lo que hace posible todo lo demás. Una vez que existe, mandar un tipo de solicitud a otro lado es un cambio de configuración, no una reescritura. También es donde agregas registros, para ver qué partes del sistema viejo se usan de verdad. Muchas veces, las funciones que nadie llama se pueden retirar sin reconstruirlas.

Mueve una capacidad a la vez

Elige una capacidad con bordes claros: un reporte, una búsqueda, un cálculo de precios, un grupo de páginas. Una buena primera candidata vale lo suficiente para importar, es lo bastante pequeña para terminarla en semanas y está poco amarrada al resto. Constrúyela en el sistema nuevo, con pruebas que describan lo que tiene que hacer.

Después apunta la capa de enrutamiento hacia ella, primero con una parte pequeña del tráfico o con un grupo de usuarios internos. El resto del sistema viejo sigue corriendo sin cambios.

Corre lo viejo y lo nuevo lado a lado, y compara

Antes de que la parte nueva reciba tráfico real, deja que ambas respondan las mismas solicitudes. El sistema viejo sigue atendiendo al usuario; el nuevo corre en segundo plano (lo que se suele llamar “modo sombra”), y su resultado se guarda junto al del viejo.

• Compara las salidas de forma automática. Totales, estados, registros devueltos, campos mostrados. Un script que marque cada diferencia vale más que revisar a mano unos cuantos casos.
• Investiga cada diferencia. Algunas son errores del código nuevo. Otras revelan una regla de negocio que el código viejo aplicaba y que nadie había escrito. Las dos vale la pena encontrarlas antes que los usuarios.
• Decide cuáles diferencias son esperadas. Si el sistema viejo redondeaba mal o arrastraba un error conocido, deja por escrito la decisión de cambiarlo, para que la diferencia sea una elección y no una sorpresa.

Ten una vuelta atrás en cada paso

Cada cambio tiene un plan de reversa por escrito: qué ajuste de la capa de enrutamiento devuelve el tráfico al camino viejo, quién puede cambiarlo y cuánto tarda. Mantén la parte vieja corriendo y sus datos al día hasta que la nueva haya resistido un tiempo de uso real. Una reversa que depende de restaurar un respaldo no es una reversa; es una recuperación.

Los datos piden el mayor cuidado. Si la parte nueva escribe datos que la vieja también lee, decide quién es dueño de cada registro durante la transición, y mantén ambos lados consistentes hasta que la parte vieja desaparezca.

Retira la parte vieja, de verdad

El patrón solo rinde cuando el código viejo se va. Cuando una capacidad ya funcionó del lado nuevo sin incidentes, quita la ruta vieja y borra el código viejo y sus tareas programadas. Cada pieza retirada achica el sistema viejo y facilita el siguiente paso.

Cómo se ve en la práctica

Los mismos principios se aplicaron cuando nuestros ingenieros consolidaron catorce sitios web en una sola plataforma: primero un inventario, scripts de migración corridos muchas veces sobre copias, sitios movidos por oleadas con sus propias revisiones, una forma escrita de volver atrás en cada oleada, y código borrado en vez de portado.

La IA acelera buena parte de este trabajo: leer código viejo, escribir un primer borrador de la versión nueva, preparar los scripts de comparación. Los ingenieros siguen decidiendo el orden, revisando cada cambio y haciéndose cargo del corte. Si estás evaluando cómo salir de un sistema viejo, nuestro servicio de modernización de software trabaja así.