Evolución y Migración (Patrón Strangler Fig)
Nivel avanzado — migrar sistemas legacy gradualmente, distribuyendo el riesgo en vez de apostarlo todo a una reescritura completa.
El problema: la trampa del "Big Rewrite"
Los sistemas legacy son críticos para el negocio pero cada vez más difíciles de mantener. La tentación es reescribir desde cero, pero el material advierte que esto falla con frecuencia porque toma más tiempo del estimado, el negocio no puede esperar años sin nuevas features, el conocimiento del dominio se pierde en la traducción, y cuando termina, los requerimientos ya cambiaron.
Situación típica: la empresa decide reescribir su sistema de facturación de 15 años. Estiman 18 meses. A los 24 meses, el nuevo sistema tiene el 60% de la funcionalidad del viejo. El negocio necesita features urgentes que exigen esperar al nuevo sistema o duplicar trabajo en el viejo. A los 36 meses, el proyecto se cancela, habiendo gastado $2M sin nada que mostrar. // el riesgo estaba concentrado en un solo evento: "terminar"
El patrón Strangler Fig
El nombre viene de las higueras estranguladoras, que crecen alrededor de árboles existentes y eventualmente los reemplazan. La aplicación nueva "estrangula" gradualmente a la vieja.
| Componente | Función | Implementación típica |
|---|---|---|
| Interceptor | Rutea tráfico entre legacy y nuevo | API Gateway, Nginx, HAProxy |
| Módulo nuevo | Reimplementación de funcionalidad | Microservicio, módulo en monolito |
| Adaptador de datos | Sincroniza datos entre sistemas | Event sourcing, CDC, ETL |
| Feature flags | Controla qué usuarios van a qué sistema | LaunchDarkly, flags en config |
3 estrategias de migración
1. Asset Capture (por entidad)
Migrar entidad por entidad: primero Users, luego Products, luego Orders — cada una en su propia ventana de semanas.
2. Event Interception (por operación)
Migrar operación por operación: primero Create, luego Read, luego Update, luego Delete — cada sprint mueve un verbo HTTP al sistema nuevo.
3. Facade (por capa)
Crear una nueva API que internamente delega al legacy, y reemplazar la implementación por dentro sin que el contrato externo cambie: delega 100% → implementación propia para usuarios seleccionados → implementación propia al 100%.
El material atribuye al "Big Rewrite" una tasa de fracaso superior al 70% sin citar el estudio del que sale. Es una cifra ampliamente repetida en la industria (asociada a menudo a un ensayo de Joel Spolsky de 2000), pero tratarla como un dato medido y verificado sería el mismo error que el Módulo 2 del máster señalaba sobre estadísticas sueltas sin fuente. El argumento en contra del Big Rewrite (concentración de riesgo, pérdida de conocimiento de dominio) se sostiene igual sin necesitar ese número exacto.
Practica: e-commerce legacy de 10 años
Monolito PHP (~500K líneas), MySQL con 200 tablas, 50K usuarios activos, $10M/año en ventas, integrado con 15 proveedores externos. Equipo: 8 developers que conocen el legacy, 4 nuevos que no. PHP 5.6 (EOL), sin tests automatizados, cada feature toma 3x más tiempo que hace 5 años.
Diseña un plan de migración con Strangler Fig hacia Node.js/Python + microservicios, sin detener el negocio: elige la estrategia (asset capture, event interception o facade), prioriza qué migrar primero, y define criterios de rollback por fase.