Modernización de sistemas legacy: el patrón strangler fig en la práctica

Por qué las reescrituras completas fracasan

La tentación ante un sistema legacy doloroso es familiar: “Tiramos todo y lo reescribimos desde cero.” La historia de la ingeniería de software está plagada de cadáveres de reescrituras completas. Netscape lo intentó y tardó tres años en lanzar un navegador mientras Firefox le comía el mercado. Las estimaciones de la reescritura siempre subestiman la complejidad acumulada del sistema original, porque esa complejidad no es accidental. Son años de reglas de negocio, edge cases y decisiones que ya no recuerda nadie pero que mantienen el sistema funcionando.

El patrón strangler fig ofrece una alternativa: reemplazar el sistema legacy pieza a pieza, manteniendo el sistema antiguo en funcionamiento hasta que no quede nada que reemplazar. Es la estrategia que recomendamos en el 90% de los casos. No es sexy. No es rápida. Pero funciona.

El patrón strangler fig, explicado

El nombre viene de la higuera estranguladora, un árbol tropical que crece alrededor de su huésped, alimentándose de sus nutrientes, hasta que el árbol original muere y la higuera queda en su lugar. El paralelismo con software es directo: el sistema nuevo crece alrededor del antiguo, asumiendo funcionalidad progresivamente, hasta que el legacy puede apagarse.

En términos técnicos, el patrón tiene tres fases:

Fase 1: Interceptar. Se coloca un proxy o fachada delante del sistema legacy que intercepta todas las peticiones. Inicialmente, el proxy simplemente redirige todo al sistema antiguo. No cambia nada. Pero establece el punto de control necesario para el reemplazo incremental.

Fase 2: Reemplazar. Funcionalidad por funcionalidad, se construyen implementaciones nuevas. El proxy redirige el tráfico de cada funcionalidad reemplazada al sistema nuevo. El sistema legacy sigue manejando todo lo que aún no se ha migrado.

Fase 3: Eliminar. Cuando toda la funcionalidad relevante está en el sistema nuevo, se apaga el legacy. En la práctica, esta fase suele dejar un residuo: funcionalidades que nadie usa pero que nadie se atreve a eliminar. El strangler fig te obliga a tomar esa decisión explícitamente.

La anti-corruption layer

El mayor riesgo del strangler fig no es técnico. Es que el sistema nuevo herede la deuda técnica del antiguo. Si el nuevo servicio de pedidos habla directamente con la base de datos del sistema legacy, el modelo de datos del legacy contamina el diseño del sistema nuevo.

La solución es una anti-corruption layer (ACL): una capa de traducción entre el sistema nuevo y el legacy. La ACL traduce los conceptos del dominio legacy a los conceptos del dominio nuevo y viceversa. Un “ORDER_HEADER” con 47 campos nullable en la base de datos legacy se convierte en un objeto Order limpio en el nuevo sistema, con solo los campos que el negocio realmente usa.

La ACL tiene un coste: es código adicional que hay que mantener durante la migración. Pero ese coste es trivial comparado con la alternativa de construir un sistema nuevo que replica los defectos del antiguo.

En la práctica, la ACL se implementa como:

• Un adaptador de base de datos que lee del schema legacy y expone un modelo limpio
• Un servicio de traducción que convierte eventos del legacy a eventos del nuevo dominio
• Un API gateway que transforma peticiones y respuestas entre formatos

¿Cuál elegir? Depende de cómo se comunican los sistemas. Si comparten base de datos (común en monolitos legacy), el adaptador de base de datos es el punto de partida. Si hay comunicación vía API o mensajería, el servicio de traducción es más apropiado.

Sincronización de datos durante la migración

El problema más difícil del strangler fig no es mover funcionalidad. Es mantener los datos sincronizados entre el sistema antiguo y el nuevo durante el periodo de coexistencia, que puede durar meses o años.

Hay tres patrones de sincronización:

Dual write: el sistema nuevo escribe en ambas bases de datos. Es el patrón más intuitivo y el más peligroso. Si una escritura falla y la otra no, los datos se dessincronizan. Sin transacciones distribuidas (que añaden su propia complejidad), el dual write es una bomba de relojería.

Event sourcing: cada cambio genera un evento que ambos sistemas consumen. Es el patrón más robusto pero también el que requiere más infraestructura (necesitas un broker de eventos como Kafka o RabbitMQ) y más cambios en el sistema legacy (que debe empezar a publicar eventos).

Change Data Capture (CDC): una herramienta monitoriza los cambios en la base de datos del legacy (normalmente vía el log de transacciones) y los replica al sistema nuevo. Debezium es el estándar open-source para esto. La ventaja: no requiere cambios en el legacy. La desventaja: estás acoplado al schema de la base de datos, y los cambios de schema pueden romper la sincronización.

Nuestra recomendación: CDC con Debezium para la fase inicial (porque no requiere tocar el legacy), evolucionando hacia event sourcing a medida que el sistema nuevo asume más funcionalidad. El dual write solo como última opción y con mecanismos de reconciliación.

Decidir por dónde empezar

No toda funcionalidad se migra igual de fácil. La prioridad debería basarse en tres criterios:

Valor de negocio: ¿qué funcionalidad genera más dolor hoy? Si el módulo de facturación tarda 20 minutos en generar una factura y el equipo de administración pierde 3 horas diarias, ese es un candidato prioritario.

Independencia: ¿qué funcionalidad tiene menos dependencias con el resto del sistema? Un módulo de reporting que lee datos pero no los modifica es más fácil de extraer que el núcleo de procesamiento de pedidos.

Riesgo: ¿qué funcionalidad es más segura de migrar? Empezar por funcionalidades de bajo riesgo permite probar la infraestructura de migración (proxy, ACL, sincronización) antes de tocar lo crítico.

La intersección de alto valor, alta independencia y bajo riesgo es el punto de partida ideal. Rara vez existe una funcionalidad perfecta en los tres ejes, pero la combinación de al menos dos suele señalar un buen candidato.

Lo que los libros no cuentan

La migración tarda más de lo estimado. Siempre. Planifica un 50% de margen. Las reglas de negocio ocultas en el sistema legacy aparecen cuando empiezas a reemplazar funcionalidad, no cuando la analizas desde fuera.

El equipo necesita mantener dos sistemas. Durante la migración, el equipo soporta el legacy y construye el nuevo. Si no se dimensiona la capacidad para ambas cosas, o el legacy se degrada (porque nadie quiere trabajar en él) o el nuevo se retrasa (porque el legacy absorbe toda la atención).

La definición de “terminado” es borrosa. ¿Cuándo se apaga el legacy? Cuando toda la funcionalidad está migrada, dicen los libros. En la realidad, siempre hay un 5-10% de funcionalidad que nadie usa lo suficiente para justificar la migración pero que nadie se atreve a eliminar. Hay que tomar esa decisión explícitamente. Nuestra regla: si una funcionalidad no se ha usado en 6 meses, no se migra. Se documenta y se apaga.

El proxy es la pieza más crítica. Si el proxy que intercepta el tráfico falla, todo falla. Tiene que ser extremadamente fiable, con failover, con métricas, con alertas. No es un componente glamuroso pero es el que mantiene la migración en pie.

Un patrón, no una receta

El strangler fig no es una receta paso a paso. Es un patrón que requiere adaptación a cada situación. Un monolito Java de 15 años con base de datos Oracle requiere una implementación diferente que una aplicación PHP con MySQL. Los principios (interceptar, reemplazar, eliminar) son universales. Los detalles son siempre específicos.

Lo que sí es universal: la paciencia necesaria para hacerlo bien. Una migración legacy exitosa se mide en trimestres, no en sprints. Pero cada funcionalidad migrada es un paso irreversible hacia un sistema mejor. Y a diferencia de la reescritura completa, cada paso entrega valor al negocio inmediatamente.

Si tu organización enfrenta un sistema legacy que frena la innovación, podemos ayudarte a diseñar una estrategia de modernización incremental. Nuestro equipo de desarrollo a medida tiene experiencia en migraciones strangler fig para sectores como logística y legal. Consulta también nuestro análisis sobre el coste real de la deuda técnica para cuantificar el impacto de mantener el status quo.