Pillar page
Modernización de sistemas legacy
Refactor incremental de monolito a microservicios, migración desde tecnologías obsoletas a stacks modernos, migración a la nube — sin downtime de negocio, con plan de rollback y audit trail completo.
Toda empresa tiene algún sistema legacy. Algunas tienen varios. Una aplicación contable de 2008 que de algún modo sigue funcionando. Un CRM escrito por consultores que ya nadie recuerda. Un almacén corriendo sobre Access. Cada uno de ellos habrá que reemplazarlo tarde o temprano — la pregunta no es si, sino cuándo y cómo.
La modernización de sistemas legacy es uno de los tipos de proyecto IT más difíciles. Requiere equilibrar tres fuerzas: mantener la continuidad del negocio (el sistema debe seguir funcionando todo el tiempo), introducir tecnologías modernas (microservicios, cloud, IA) y controlar el riesgo (cualquier refactor puede romper algo que llevaba años funcionando).
¿Por qué no basta con „reescribir desde cero"?
Según nuestra experiencia, 9 de cada 10 modernizaciones exitosas son refactorings incrementales, no rewrites. Los rewrites son conceptualmente tentadores („empezamos con una hoja en blanco"), pero en la práctica tienen tres problemas fundamentales:
- Lógica de negocio invisible. El sistema antiguo acumula años de reglas de negocio — condiciones especiales para los mayores clientes, exenciones fiscales para sectores concretos, workarounds para regulaciones de 2015. La mayoría no está documentada. Un rewrite debe reconstruirlas todas a partir de la memoria de las personas o del análisis del código.
- Trabajo duplicado. Mientras se escribe el nuevo sistema, el negocio sigue exigiendo cambios en el antiguo (regulaciones, nuevos clientes, pequeños bugs). El equipo o duplica el trabajo (cambios en dos lugares) o congela el sistema antiguo (riesgo de negocio).
- Despliegue big bang. Tras un año de trabajo, el sistema nuevo está „casi listo". Cambiar a todos los usuarios en una sola noche genera un riesgo monumental. Cualquier problema inesperado significa volver al sistema antiguo, perder moral del equipo y erosionar la confianza del negocio.
El refactor incremental (habitualmente siguiendo el patrón Strangler Fig) resuelve los tres: la lógica de negocio se descubre gradualmente, una única fuente de verdad por entidad, despliegue por etapas con feature flags.
Seis patrones de modernización
Cada uno aborda un riesgo concreto. En la mayoría de proyectos combinamos varios, eligiendo un patrón por módulo.
Strangler Fig
„Envolver" gradualmente el sistema antiguo con componentes nuevos. El código antiguo sigue corriendo, pero cada nueva funcionalidad se desarrolla en un microservicio nuevo y los módulos existentes se reemplazan uno a uno. Tras 12-24 meses, el monolito antiguo se apaga.
Anti-corruption layer
Un adaptador que protege al código nuevo de las rarezas del sistema antiguo (nombres de campo ilegibles, formatos de fecha extraños, tipos inconsistentes). Toda la lógica „fea" queda aislada en un único lugar — el código nuevo opera sobre un modelo de dominio limpio.
Database refactoring
Patrones del libro Refactoring Databases (Ambler/Sadalage): expand-and-contract para migraciones de esquema, validación de datos antes de eliminar columnas antiguas, mantenimiento paralelo de ambos esquemas durante la migración de la aplicación.
Branch by abstraction
Introducir una capa de abstracción alrededor del componente antiguo, implementar el nuevo componente en paralelo, ir cambiando el tráfico del 0% al 100% (feature flag). Sin despliegue „big bang".
Shadow mode
El código nuevo corre en paralelo al antiguo — ambos procesan las mismas peticiones, pero solo los resultados del antiguo llegan al usuario. Los resultados se comparan offline. Tras confirmar la compatibilidad (típicamente 2-4 semanas) cambiamos el tráfico al nuevo código.
Event sourcing para migración
Grabamos el flujo de eventos de negocio del sistema antiguo y lo replicamos en el nuevo. Permite la validación previa de la nueva arquitectura sin riesgo de producción, y volver a cualquier estado histórico.
Hoja de ruta típica de modernización
Para un sistema mediano (monolito de ~200k líneas de código, 5-10 módulos de negocio):
- Mes 1: Discovery y documentación. Ingeniería inversa de la arquitectura, mapeo de dependencias, identificación de flujos de datos, documentación de procesos de negocio con ayuda de los stakeholders del negocio.
- Mes 2: Arquitectura objetivo y piloto. Diseño de la nueva arquitectura, selección de tecnologías, piloto sobre el módulo más sencillo (proof of concept). Primera validación del enfoque.
- Meses 3-4: Extracción del primer módulo productivo. Patrón Strangler Fig, shadow mode durante 2-3 semanas, cutover de tráfico, hypercare. Primer valor real de negocio.
- Meses 5-12: Extracción iterativa de los siguientes módulos. Cada uno en un ciclo de 4-6 semanas: refactor → tests → shadow → producción → hypercare. Mejora continua del proceso, reducción del tiempo por módulo.
- Meses 12-18: Migración de datos y retirada del monolito. Cuando todos los módulos críticos están extraídos, finalizamos la migración de datos históricos, apagamos el sistema antiguo y archivamos. A celebrar.
Sistema antiguo vs. modernizado
| Aspecto | Sistema legacy (típico) | Tras la modernización |
|---|---|---|
| Tiempo para entregar una nueva funcionalidad | 4-8 semanas (alto riesgo de regresión) | 3-7 días (tests automáticos minimizan el riesgo) |
| Cobertura de tests | 5-15% (o ninguna) | >80%, en el pipeline CI/CD |
| Disponibilidad de desarrolladores | Baja (tecnología obsoleta) | Alta (stacks populares y modernos) |
| Seguridad | Bibliotecas antiguas con CVEs sin parchear | Escaneo OWASP, gitleaks, actualizaciones automáticas |
| Escalado | Vertical (más recursos para el monolito) | Horizontal (escalado de microservicios concretos) |
| Observabilidad | Logs en ficheros, sin métricas | Prometheus + Grafana + Sentry + SIEM |
| Compliance (RGPD, EU AI Act, ISO 27001) | Exigente, costoso de demostrar | Incorporado a la arquitectura, listo para auditoría |
Seis riesgos típicos — y cómo los abordamos
Riesgo: Sistema legacy sin tests
Mitigación: Primero construimos tests de caracterización (capture tests) — grabando el comportamiento actual del sistema a partir de logs de producción y capturas de tráfico. Solo entonces comenzamos el refactor, con los tests como red de seguridad.
Riesgo: Conocimiento concentrado en una persona („truck factor 1")
Mitigación: La transferencia de conocimiento empieza la primera semana del proyecto. Todas las reuniones con la persona que conoce el sistema se graban y transcriben, los procesos clave se documentan, las decisiones de arquitectura se justifican. Al finalizar, todo el equipo entiende el sistema.
Riesgo: Ralentización temporal del equipo
Mitigación: Durante los primeros 2-3 meses, el equipo mantiene el sistema antiguo + construye el nuevo. Ralentización natural del ritmo de cambio. Lo mitigamos: priorizando los cambios que solo van al nuevo sistema y congelando los cambios de baja prioridad en el antiguo.
Riesgo: Migración de datos
Mitigación: Cada migración de datos tiene tres fases: dry-run (sobre copia de producción), staging (entorno de pruebas con datos a escala real), producción (en ventana de servicio o de forma incremental). Plan de rollback listo antes de empezar.
Riesgo: Resistencia organizacional
Mitigación: Comunicación con el negocio desde el primer día: por qué modernizamos, qué cambia para el usuario, qué calendario, cómo medimos el éxito. La primera iteración se elige para mostrar rápidamente un valor tangible (p. ej. una nueva UI o un informe más rápido).
Riesgo: Subestimación del coste
Mitigación: Discovery (1-2 semanas) antes de presupuestar el proyecto. Iteraciones de 2-3 semanas con entregables concretos — es más fácil corregir el rumbo que en un proyecto largo „todo a la vez". Presupuesto con un colchón del 20-30% para imprevistos.
Preguntas frecuentes
¿Qué es un sistema legacy?
¿Por qué modernizar si el sistema funciona?
¿No es más fácil reescribirlo todo desde cero?
¿Requiere la modernización un downtime de negocio?
¿Cuánto tarda una modernización típica?
¿Desde qué tecnologías migramos con más frecuencia?
¿Qué pasa con las integraciones existentes con otros sistemas?
¿Cómo reducís el riesgo de negocio?
¿Qué pasa con la documentación del sistema que no existe?
¿Cómo se compara el coste de la modernización con el de mantener el sistema antiguo?
Empecemos con una auditoría
Auditoría técnica de una semana: mapeo del estado actual, identificación de las áreas de modernización más urgentes, plan por fases con resultados de negocio concretos en la primera iteración.