La mayoría de las empresas medianas que enfrentan un sistema legacy complejo terminan escuchando la misma propuesta: "hay que reescribirlo desde cero". Es la respuesta más fácil del consultor y la más cara para el negocio. En la práctica, la modernización progresiva —evolucionar el sistema pieza a pieza sin parar la operación— ha probado ser una estrategia más segura, más económica y más alineada con la realidad del negocio.
En este artículo explicamos en qué consiste, qué patrones técnicos se usan (con énfasis en el patrón Strangler Fig), cuándo conviene y cuándo no, y cómo se estructura un proyecto real.
El problema con las reescrituras completas
Joel Spolsky, fundador de Stack Overflow, lo resumió famosamente: "la peor decisión estratégica que puede tomar una empresa de software es reescribir el código desde cero". La experiencia de empresas como Netscape, que perdió su liderazgo de mercado durante una reescritura de tres años, respalda la afirmación.
Los costos típicos de una reescritura completa:
- Entre 12 y 36 meses antes de tener un reemplazo funcional equivalente.
- Pérdida de lógica de negocio sutil que estaba implícita en el código original.
- Período prolongado de doble operación (costo duplicado de infraestructura, soporte y licencias).
- Rotación del equipo durante el proyecto (la probabilidad de terminar con el mismo equipo es baja).
- El negocio sigue cambiando durante la reescritura: cuando "termina", ya está desactualizada.
Frente a esto, la modernización progresiva ofrece una alternativa que preserva la inversión ya hecha.
¿Qué es la modernización progresiva?
Es una estrategia en la que el sistema existente y el nuevo coexisten durante un período. Cada nueva funcionalidad se construye en la arquitectura moderna, y progresivamente se van migrando los módulos del sistema viejo al nuevo. Al final del proceso, el sistema legacy ha sido reemplazado pieza a pieza, no de un golpe.
El patrón más conocido que la implementa se llama Strangler Fig, en honor a la higuera estranguladora: un árbol que crece alrededor de otro hasta reemplazarlo completamente sin que la estructura original se caiga.
Cómo funciona el patrón Strangler Fig
El patrón tiene tres componentes:
1. Un proxy o gateway
Se coloca un componente delante del sistema original que recibe todas las peticiones. Este proxy decide, para cada petición, si la resuelve el sistema viejo o el nuevo. Inicialmente, el proxy redirige el 100% al viejo; progresivamente, a medida que se moderniza, va enviando más tráfico al nuevo.
2. Nuevos servicios o módulos en arquitectura moderna
Cada nueva funcionalidad se construye en la arquitectura objetivo (microservicios, APIs REST, stack moderno). Estos nuevos módulos conviven con el sistema viejo y se comunican con él cuando necesitan datos.
3. Migración gradual
Módulo a módulo, las funcionalidades existentes se reimplementan en el nuevo sistema. El proxy va redirigiendo tráfico al nuevo servicio, y cuando se verifica que funciona igual o mejor, se apaga la parte correspondiente del sistema viejo.
Ventajas frente a una reescritura
- Entregas tempranas de valor: cada módulo modernizado ya suma desde el primer mes.
- Menor riesgo: si algo falla en el nuevo, el proxy regresa el tráfico al viejo (rollback rápido).
- Aprendizaje continuo: el equipo aprende del sistema real mientras moderniza, no con documentación muerta.
- Negocio operando: la operación no se detiene ni entra en riesgo durante el proceso.
- Presupuesto controlado: se puede parar o replantear en cualquier momento sin perder toda la inversión.
Cuándo conviene y cuándo no
Conviene cuando
- El sistema es grande y crítico para la operación.
- No puedes detener el negocio durante la modernización.
- Hay presupuesto limitado o necesitas entregas incrementales visibles.
- La tecnología base, aunque vieja, aún es accesible (PHP, Java, .NET antiguos).
No conviene cuando
- El sistema es muy pequeño (menos de 6 meses de desarrollo total). Reescribir es más rápido.
- La tecnología base es tan antigua o exótica que no hay desarrolladores disponibles (Visual Basic 5, Clipper, Foxpro en algunos casos).
- La lógica del negocio cambió tanto que el sistema viejo ya no sirve de referencia.
Fases típicas de un proyecto de modernización progresiva
Fase 1: Diagnóstico y arquitectura objetivo (3-6 semanas)
Se mapea el sistema actual, se identifican los módulos y sus dependencias, y se diseña la arquitectura objetivo. Sin este diseño, la modernización se vuelve un conjunto de parches sin rumbo.
Fase 2: Instalación del proxy o gateway (1-2 semanas)
Se coloca el componente que recibirá las peticiones. Puede ser un API Gateway (Kong, Tyk, Apigee), un reverse proxy (NGINX, HAProxy) con lógica de enrutamiento, o una aplicación hecha a la medida.
Fase 3: Primer módulo modernizado (4-8 semanas)
Se elige un módulo no crítico pero visible para probar el enfoque: por ejemplo, el módulo de reportes. Se reconstruye en la arquitectura moderna, se prueba en paralelo al viejo y se redirige tráfico cuando hay confianza.
Fase 4: Iteración por módulos (6-24 meses según tamaño)
Se repite el proceso con los módulos siguientes. La cadencia típica es uno cada 1-3 meses, con equipo de 3-5 desarrolladores.
Fase 5: Desactivación del legacy (2-4 semanas)
Cuando todos los módulos críticos han sido reemplazados, el sistema viejo se desactiva completamente. Su infraestructura se libera, sus licencias se cancelan, su mantenimiento termina.
Qué elementos debe tener el gateway
- Enrutamiento configurable por módulo (no hardcoded).
- Autenticación unificada: el usuario no debe notar qué parte resuelve el sistema nuevo o el viejo.
- Observabilidad: logs y métricas por cada decisión de enrutamiento.
- Feature flags: poder activar/desactivar el nuevo servicio para porcentajes de usuarios.
- Rollback automático: si el nuevo servicio falla, regresar al viejo sin intervención manual.
Errores comunes
Modernizar sin arquitectura objetivo
Si cada módulo nuevo usa tecnologías distintas "porque son las de moda este año", terminas con un sistema peor que el original: fragmentado, inconsistente y con su propia deuda técnica.
Empezar por el módulo más crítico
Es tentador atacar primero el módulo que más duele. Pero es donde más riesgo hay. Empezar por algo menos crítico permite al equipo calibrarse, documentar el proceso y entregar victorias rápidas.
No retirar el legacy
Muchas modernizaciones progresivas se estancan con el sistema viejo operando al 20% por años. Es una cola larga que cuesta dinero. Definir desde el inicio la fecha de desactivación del legacy es clave para no caer en ese limbo.
Falta de disciplina en el enrutamiento
El proxy debe ser la única forma de entrar al sistema. Si los clientes o sistemas externos empiezan a saltárselo (llamando directamente al legacy), la migración se estanca.
Casos reales
Hemos acompañado procesos de modernización progresiva en sectores tan distintos como logística (un sistema de rastreo en Delphi 7 migrado a Laravel + Vue en 11 meses), seguros (núcleo de pólizas en VB6 encapsulado como servicio mientras se construye un frontend React) y manufactura (ERP propietario en FoxPro con módulos migrados uno a uno a una arquitectura Python/PostgreSQL en 18 meses).
En todos los casos, el negocio siguió operando, el ROI empezó a verse en los primeros meses, y el presupuesto se mantuvo controlado porque se avanzaba por entregas.
Conclusión
La modernización progresiva no es la solución para todos los casos, pero para sistemas legacy medianos y grandes es casi siempre la mejor opción. Evita el riesgo del "big bang" de una reescritura y entrega valor incremental desde el primer trimestre.
Si tu empresa está considerando una reescritura completa, antes de tomar esa decisión conversa con quien haya hecho modernización progresiva. En IT Efectivos hemos liderado más de 30 procesos de este tipo en los últimos diez años. Una reunión inicial puede ahorrarte meses y cientos de miles de pesos. Escríbenos.