Estrategia strangler fig: cómo modernizar sin reescribir todo

Hay un patrón que cualquier equipo serio de modernización conoce y que casi ninguna empresa fuera de tecnología ha escuchado nombrar. Se llama strangler fig — higuera estranguladora — y es probablemente la mejor estrategia disponible para modernizar un sistema legacy sin parar la operación ni jugarse el trimestre a un big bang.

De dónde viene el nombre

El término lo acuñó Martin Fowler tomando prestada una imagen de la naturaleza. La higuera estranguladora crece envolviendo a un árbol anfitrión: lo rodea con sus raíces, se sostiene en su estructura y, con el tiempo, lo reemplaza por completo. Cuando el árbol original muere, la higuera ya está en pie por sí sola. Aplicado al software, esa es exactamente la idea.

Por qué el big bang rewrite falla

Reescribir un sistema completo desde cero, en paralelo a la operación, es la tentación clásica. En el papel se ve limpio: el equipo construye la nueva versión durante doce o dieciocho meses, llega el día del corte y la empresa se moderniza de golpe. En la práctica casi nunca pasa así. El alcance se mueve, el sistema viejo sigue evolucionando, el nuevo nunca alcanza la paridad funcional, el presupuesto se acaba, y el cliente termina con dos sistemas a medias.

Los tres principios del strangler fig

• Envolver el sistema viejo con una capa nueva de acceso — un API gateway, un proxy o un router de tráfico que se vuelve la puerta de entrada única.
• Redirigir el tráfico al módulo nuevo cuando esté listo — un módulo a la vez, no todos a la vez.
• Apagar el módulo viejo solo cuando nadie lo use — el sistema legacy se reduce poco a poco hasta desaparecer.

Un ejemplo concreto

Imagina un sistema de facturación construido hace doce años en una tecnología que ya nadie del mercado domina. La operación depende de él. Reescribirlo de cero es impensable y dejarlo como está, también. El strangler fig se vería así: primero, ponemos un API delante que se vuelve la única forma de hablarle al sistema. Después, identificamos el módulo de emisión de facturas y lo reimplementamos por separado, manteniendo la misma base de datos. El API empieza a enrutar las llamadas de emisión al módulo nuevo. Después siguen los reportes, después la consulta de saldos, después la conciliación. Mes a mes, el viejo se encoge.

Feature flags y router de tráfico

La pieza técnica que hace posible el patrón es el control granular del enrutamiento. Un feature flag permite enviar el 1% del tráfico al módulo nuevo, después el 10%, después el 50%, midiendo en cada paso si el comportamiento coincide con el del viejo. Si algo se desvía, se vuelve al 0% en segundos. El sistema viejo nunca se desconecta hasta que el nuevo demuestra paridad real con tráfico real.

Cómo verificas que el nuevo da los mismos resultados

Dos técnicas hacen el trabajo pesado. La primera es shadow traffic: las peticiones reales se envían al módulo viejo (que responde al cliente) y simultáneamente al nuevo (cuya respuesta solo se compara contra la del viejo, sin afectar al cliente). La segunda es diffing de salidas: se registran las diferencias entre ambas respuestas y se investigan. Cuando las diferencias caen a cero — o se explican todas — el módulo nuevo está listo para servir tráfico real.

Rollback instantáneo

La belleza del patrón es que el sistema viejo nunca deja de funcionar hasta el último día. Si el módulo nuevo falla a las tres de la mañana, el router devuelve el tráfico al viejo y la operación sigue. No hay restauración de backup, no hay ventana de mantenimiento, no hay reunión de crisis. Hay un flag que vuelve a estar en off.

Dónde encaja Claude Code

• Entender el código heredado — lo que tradicionalmente requería semanas de arqueología técnica pasa a ser una exploración dirigida de horas.
• Generar tests de caracterización — describir cómo se comporta hoy el sistema antes de tocarlo, para tener la red de seguridad lista.
• Mapear dependencias entre módulos — saber qué llama a qué y dónde están las fronteras reales para decidir por dónde cortar primero.
• Acelerar la reimplementación módulo por módulo — sin saltarse el review humano de cada cambio.

Qué deja un proyecto bien hecho

Cuando termina, no solo queda un sistema moderno. Queda una documentación viva del negocio que antes vivía en la cabeza de dos personas, una suite de pruebas que protege contra regresiones, una arquitectura que el equipo interno entiende y puede mantener, y la confianza — bien ganada — de que la próxima modernización ya no va a doler así. La capacidad de evolucionar el software vuelve a estar dentro de la empresa.