Cómo modernizar un ERP legacy sin parar la empresa (estrategia strangler)
El patrón "strangler fig" para sustituir un sistema antiguo módulo a módulo, sin parar la operación en ningún momento.
Toda empresa con más de una década de vida tiene un sistema del que nadie quiere hablar: el ERP a medida de hace quince años, que funciona pero que solo entiende una persona (si es que esa persona sigue en la empresa). Sustituirlo de golpe es el escenario que toda dirección teme, con razón: un "big bang" que sale mal puede parar la facturación, la producción o los envíos durante días.
El patrón strangler fig: por qué funciona
El patrón "strangler fig" (llamado así por la higuera estranguladora, que crece rodeando un árbol hasta sustituirlo) evita el riesgo del big bang: en lugar de reescribir todo el sistema y cambiar de golpe, la plataforma nueva va absorbiendo módulos del sistema viejo uno a uno.
El primer módulo es siempre el que tiene más dolor o el que es más mantenible aislado, no el más complicado ni el más estratégico. Se construye en paralelo al sistema viejo, con una capa de sincronización bidireccional mientras dura la transición. Cuando el módulo nuevo supera al viejo en funcionalidad y fiabilidad, se apaga el viejo. El sistema legado sigue funcionando durante todo el proceso, como red de seguridad.
Esto exige diseñar la sincronización bidireccional desde el principio, no es gratis técnicamente, pero el resultado es que en ningún momento hay "el día del cambio": cada módulo se valida en producción con datos reales antes de retirar su equivalente legacy.
El beneficio invisible: rescatar el conocimiento tácito
El beneficio que no se ve a primera vista es el rescate de conocimiento: un ERP de quince años suele contener reglas de negocio que nadie ha documentado en ningún otro sitio, excepciones fiscales de un cliente concreto, cálculos de tarifa que "siempre se han hecho así", casos límite que el sistema maneja silenciosamente.
El proceso de migración módulo a módulo obliga a hacer explícito ese conocimiento en código legible, en lugar de perderlo cuando la única persona que lo entendía se jubila o cambia de empresa. En un caso real, la migración descubrió tres reglas de negocio que nadie en el equipo actual sabía que existían, y que si se hubieran perdido habrían causado errores de facturación.
Plazos y cómo estructurar el proyecto
Una migración strangler correctamente ejecutada dura entre 12 y 24 meses para un ERP de tamaño medio (10-15 módulos). No es rápido, pero tampoco lo es recuperarse de un big bang fallido.
La estructura de fases es: (1) auditoría del sistema legado y mapa de dependencias entre módulos, (2) diseño de la arquitectura destino y de la sincronización, (3) módulo piloto con criterios de aceptación claros, (4) módulos siguientes en orden de prioridad, (5) desconexión del sistema legado cuando el último módulo esté validado. En un caso real de catorce meses con esta estrategia, la empresa tuvo cero días de parada y terminó con cambios legales desplegándose en horas, no en semanas. Evaluar tu caso concreto.
¿Tu empresa está en esta situación?
30 minutos con el equipo técnico, sin compromiso
Te decimos si el problema que describes tiene solución, cómo lo enfocaríamos y qué costaría arrancar.
Agendar auditoría gratuitaCuándo el strangler no es la respuesta
El patrón strangler tiene sentido cuando el sistema legado puede seguir funcionando en paralelo durante la transición. Si el sistema es tan frágil que no es viable mantenerlo durante 12-18 meses más, o si la arquitectura está tan acoplada que no es posible extraer módulos sin romper todo, puede ser más sensato un reemplazo total planificado con muy buen rollback.
Otro caso en que el strangler no encaja: cuando la empresa va a cambiar radicalmente su modelo de negocio simultáneamente a la migración. Migrar y transformar al mismo tiempo sobre el mismo sistema añade una capa de complejidad que suele acabar mal. En ese caso, el consejo correcto es freezar el sistema legado mientras dura el cambio de negocio, y abordar la migración técnica después con el modelo nuevo estabilizado.
Quién hace la migración y qué cuesta
La migración strangler exige un equipo que entiende tanto el sistema viejo como la arquitectura nueva. El mayor riesgo que vemos es cuando el equipo que desarrolló el legado hace la migración sin experiencia en arquitecturas modernas, o cuando un equipo nuevo hace la migración sin conocer las reglas de negocio que el sistema viejo maneja. Lo ideal es una combinación: alguien que conoce el legado desde dentro y un equipo con experiencia en el patrón de migración.
El coste depende del tamaño del sistema y del volumen de reglas de negocio a rescatar. Lo que siempre decimos: el coste de la migración hay que compararlo con el coste acumulado de mantener el sistema viejo durante los próximos cinco años (incidencias, adaptaciones normativas, dependencia de una o dos personas que lo entienden), no con cero. Ese cambio de perspectiva suele cambiar la ecuación.
