Migración de Sistemas Legacy: Patrón Strangler, Gestión de Riesgo y Plan a 18 Meses
Las reescrituras big-bang matan empresas. El patrón strangler-fig no. Cada migración legacy que hemos entregado con éxito en Alher Tech sigue la misma forma: sustitución incremental, dual-running por un periodo controlado, pasos reversibles y entrega continua de valor de negocio. Esta es la guía a 18 meses para sustituir sistemas legacy COBOL, Java EE, .NET Framework u Oracle sin downtime, incluyendo el framework de gestión de riesgo y qué esperar realísticamente en cada fase.
Por Qué Fallan las Reescrituras Big-Bang
El patrón es deprimentemente consistente: roadmap a 18 meses, scope crece, plazos se rompen, el negocio cambia más rápido que la reescritura, el día del cutover el nuevo sistema tiene bugs que el viejo no tenía, la productividad cae, los ejecutivos se asustan, el proyecto se cancela al mes 24. La empresa ha gastado 5-15M $ en algo que nunca se entregó.
El patrón strangler-fig (Martin Fowler, 2004) no sufre esto. Asume que la reescritura estará mal en algún sitio y hace cada paso reversible.
- Sustitución incremental, no reescritura entera
- Viejo y nuevo corren en paralelo durante meses
- Cada módulo sustituido se prueba antes de empezar el siguiente
- Valor de negocio visible cada 90 días, no en el mes 24
- Reversible en cada paso
El Playbook a 18 Meses
Una migración legacy típica en Alher Tech, por fases:
- Meses 1-2: Discovery e inventario de riesgos: Mapea cada entrada al legacy, cada integración externa, cada flujo de reporting. Identifica el mayor riesgo único: normalmente integridad de datos, a veces un tercero con interfaz SOAP de los 90.
- Meses 2-3: Fundación: Construye la plataforma: identidad, auditoría, observabilidad, deploy pipeline, entorno de test que espeja producción. Los primeros 3 meses suelen ser 'sin progreso visible', pero cada mes posterior depende de esto.
- Meses 3-6: Sustitución del primer módulo: Elige el de mayor dolor × menor complejidad de dependencias. Espejo read-only primero, después dual-write, después cutover. A los 6 meses tienes un módulo en producción y prueba de que el patrón funciona.
- Meses 6-12: Módulos 2-4: El ritmo acelera. Cada nuevo módulo reusa infra del primero. El negocio ve valor trimestral. El sistema viejo encoge, el nuevo crece.
- Meses 12-18: Cola larga y decommission: El último 20% de funcionalidad suele ser el 80% de las sorpresas: batch jobs no documentados, integraciones con terceros, edge cases que el negocio nunca contó. Planifica para ello.
- Meses 18+: Operar y mejorar: Sistema viejo decommissionado. Empieza el ahorro de licencias. Las features nuevas salen a 3-5x la velocidad legacy. La inversión por fin retorna.
El Framework de Gestión de Riesgo
La migración legacy es más gestión de riesgo que ingeniería. Las disciplinas que importan:
- Reversibilidad en cada paso: Cada cambio debe tener rollback documentado. Feature flags en todas partes. Dual-running suficientemente largo para cazar issues lentos (cierres de mes, batches anuales).
- Verificación de integridad de datos: Tras cada ventana dual-write, reconciliación automática: counts, sumas, comparaciones de muestra. Diferencias investigadas en 24h, no 'cuando haya tiempo'.
- Characterization tests: Antes de refactor, escribe tests contra el comportamiento real del legacy, bugs incluidos. El sistema nuevo debe replicar comportamiento, no 'arreglarlo' sin decisión explícita.
- Cadencia de comunicación: Status semanal a stakeholders operativos, mensual a ejecutivos, trimestral al consejo. Las sorpresas matan migraciones; el progreso transparente las salva.
- Skin in the game: Ingenieros de guardia por lo que entregan. Nada de 'tirar por encima del muro' entre dev y ops. El equipo que escribió el módulo nuevo es dueño de sus incidentes.
Eligiendo el Primer Módulo a Sustituir
- Mayor coste de licencia en el legacy o plugin de tercero, para el mayor ROI inmediato
- Más doloroso para el equipo operativo: los quick wins construyen credibilidad para el resto
- Menos integrado con otros módulos legacy, lo que minimiza riesgo de acoplamiento en la primera migración
- Scope razonablemente estable. No elijas un módulo que el negocio está cambiando activamente
- Criterio de éxito auditable: necesitas poder declarar victoria y decommissionar
El primer módulo es la prueba de concepto de los 18 meses. Elige conservador. En el segundo y tercero es donde aceleras.
Realidad de Costes
| Scope de migración | Rango de coste | Plazo |
|---|
| Un módulo de un legacy de 5 módulos | 200K – 600K $ | 4 – 8 meses |
| Sistema legacy mediano (10-15 módulos) | 1,5M – 4M $ | 12 – 24 meses |
| Sistema legacy grande (50+ módulos, varios subsistemas) | 5M – 15M+ $ | 24 – 48 meses |
| Legacy con interfaces EDI / mainframe terceros | +30-50% encima | +6-12 meses |
Los costes incluyen fundación y overhead de operación paralela, que son 30-40% del total. El ahorro de licencias del lado legacy típicamente recupera 40-70% del coste de migración a 5 años.
Errores Comunes
- Big-bang aunque juraste que no. La presión de calendario empuja a 'un solo cutover en cierre de año'. Siempre sale mal.
- Subestimar la migración de datos. Limpiar, mapear y validar décadas de datos legacy suele ser 30-40% del coste. Siempre.
- Ignorar batch jobs no documentados. El cron de las 4 AM que nadie posee lleva 10 años manteniendo vivo un report crítico. Encuéntralo antes del cutover.
- Sustituir funcionalidad sin validación de negocio. El legacy tiene un botón que 3 usuarios pulsan una vez al trimestre. No lo quites sin preguntar: puede ser load-bearing.
- Saltarte characterization tests. Refactor sin tests contra el comportamiento existente es cómo 'simplificar' un cálculo rompe reporting seis meses después.
- No amortizar el legacy. Los módulos nuevos pillan código del viejo, después todos olvidan. Decommissiona agresivo o correrás los dos para siempre.
Strangler, No Mazo
Cada migración legacy que tiene éxito es incremental. Cada una que fracasa es big-bang. Los equipos que interiorizan esto y diseñan para reversibilidad entregan; los que prometen un cutover único en cierre de año colapsan.
Si miras a un sistema legacy que te cuesta 1M+ €/año y ralentiza cada decisión de producto, el camino existe, pero no parece una reescritura. Parece un strangler fig.
Preguntas frecuentes
¿Cuánto tarda una migración legacy?
Un módulo: 4-8 meses. Sistema mediano: 12-24 meses. Sistema grande: 2-4 años. El strangler te deja entregar valor cada 3-6 meses por el camino, no 'al final'.
¿Tengo que migrar todo?
No. Algunos módulos legacy sobrevivirán al proyecto de migración. La respuesta correcta es migrar lo doloroso o caro y dejar los estables y de poca fricción hasta que rompan o se sustituyan por otras razones.
¿Y la migración de datos?
Siempre 30-40% del coste del proyecto en sistemas de más de 10 años. Planifica limpieza, mapeo, validación y dual-running. No subestimes.
¿Lo podemos hacer con equipo interno?
Sí si tu equipo tiene experiencia migratoria. La mayoría no. Los errores son lo bastante caros como para que traer un partner al menos para los 2-3 primeros módulos compense. La transferencia hace el resto viable in-house.
¿Cuál es el stack moderno correcto?
Depende del legacy. Java EE → Spring Boot. .NET Framework → .NET 8/9. Oracle Forms → React + APIs REST. COBOL → Java o Python con capa de traducción deliberada. No elijas por hype. Elige por contratabilidad y madurez operativa.
Guías relacionadas