Claves
- La migración de software legacy es gestión de riesgo: la tecnología rara vez es la causa del fracaso, sino intentar cambiarlo todo de golpe.
- La auditoría previa (datos, integraciones y deuda oculta) evita la mayoría de los problemas y es lo que permite un presupuesto honesto.
- El patrón Strangler Fig permite modernizar sin parar el negocio: migrar módulo a módulo, con feature flags y rollback en cada paso.
- Los datos son lo único irreemplazable: usa scripts idempotentes, ensaya contra copias de producción y valida integridad antes del corte real.
- Migra por fases con pruebas de humo E2E: cada módulo en producción de forma independiente da valor en semanas, no en años.
Una **migración de software legacy** bien hecha es, sobre todo, un ejercicio de gestión del riesgo. La **modernización de sistemas** rara vez fracasa por la tecnología elegida: fracasa por intentar cambiarlo todo de golpe, por subestimar la deuda oculta o por parar la operación durante el cambio. Si gestionas una empresa que depende de un ERP antiguo, una aplicación a medida de hace una década o un puñado de hojas de cálculo críticas, la pregunta no es *si* hay que modernizar, sino *cómo* hacerlo sin que el negocio note el corte.
En esta guía abordamos la migración paso a paso desde un criterio de ingeniería real: qué auditar antes de tocar nada, qué estrategia elegir, cómo migrar datos sin perder integridad y cómo desplegar de forma incremental. No es teoría: es el mismo enfoque con el que en NAYSOF llevamos a producción productos propios multi-tenant y agentes de IA sobre sistemas vivos, con miles de operaciones diarias y cero ventanas de parada.
Qué es un sistema legacy y cuándo conviene modernizarlo
Un sistema legacy no es necesariamente uno viejo: es uno que se ha vuelto caro de mantener, difícil de cambiar y arriesgado de tocar. El síntoma clásico es que nadie se atreve a modificar una parte por miedo a romper otra, o que las nuevas funcionalidades tardan meses porque el código está acoplado y sin pruebas.
Antes de lanzarte a la modernización de sistemas, conviene tener claro el detonante de negocio. No se moderniza por moda, sino porque hay un coste real: incidencias que paran ventas, imposibilidad de integrar pagos o IA, costes de licencias o servidores obsoletos, o riesgo de cumplimiento (RGPD, facturación electrónica VeriFactu, etc.).
- El proveedor original ya no da soporte o el stack está fuera de mantenimiento.
- Cada cambio pequeño dispara errores en cascada y requiere semanas de pruebas manuales.
- No puedes integrar lo que el negocio pide hoy: pagos online, IA, multi-empresa, API externas.
- Los costes de infraestructura o licencias suben mientras el rendimiento baja.
- Hay riesgo regulatorio: datos sin cifrar, sin trazabilidad o sin cumplir normativa fiscal.
Auditoría previa: el paso que evita el 80% de los problemas
Ningún proyecto de migración de aplicaciones legacy debería empezar por elegir tecnología. Empieza por entender lo que tienes. La auditoría técnica es la fase más infravalorada y la que más fracasos previene: mapear el flujo real de datos de entrada a salida, las dependencias ocultas, las integraciones externas y, sobre todo, la deuda que nadie documentó.
En este punto hay que inventariar el modelo de datos real (no el que dice la documentación), las reglas de negocio escondidas en el código, los procesos batch nocturnos y cualquier integración con terceros. Una sola query mal entendida o una clave foránea ignorada puede corromper datos en producción.
- Mapea el flujo completo: entrada de datos, lógica, persistencia y salida a usuario.
- Inventaria integraciones externas (pagos, mensajería, correo, organismos, API).
- Documenta el esquema de datos real: tablas, relaciones, índices, triggers.
- Localiza la lógica de negocio escondida en procedimientos almacenados y scripts.
- Clasifica cada hallazgo en bloqueante, importante o cosmético antes de planificar.
Estrategias de migración: rehost, replatform, refactor o reescritura
No todas las migraciones son iguales y elegir mal la estrategia es caro. Las cuatro grandes opciones son: rehost (mover el sistema tal cual a infraestructura nueva), replatform (cambios mínimos para aprovechar la nube o contenedores), refactor (reescribir por módulos manteniendo el comportamiento) y reescritura completa (empezar de cero con arquitectura moderna).
La reescritura total es la más tentadora y la más peligrosa: rara vez se justifica salvo que el sistema sea inviable de mantener. En la práctica, la mayoría de proyectos serios combinan replatform y refactor incremental. La clave es elegir según el valor de negocio y el riesgo, no según la moda tecnológica.
- Rehost: rápido y barato, pero arrastra la deuda técnica intacta.
- Replatform: buen equilibrio para llevar a la nube o a contenedores Docker.
- Refactor incremental: moderniza por módulos sin congelar el producto.
- Reescritura completa: solo si el sistema es irrecuperable; planifica meses, no semanas.
Migración sin parar el negocio: el patrón Strangler Fig
La gran preocupación de cualquier decisor es la misma: "no puedo permitirme parar". La buena noticia es que la migración no exige un apagón. El patrón Strangler Fig (estrangulador) consiste en construir el sistema nuevo *alrededor* del viejo, redirigiendo funcionalidad módulo a módulo hasta que el legacy queda vacío y se apaga sin drama.
El sistema nuevo y el antiguo conviven durante un tiempo. Cada función modernizada se enruta de forma progresiva, con la posibilidad de volver atrás si algo falla. Esto convierte una migración de alto riesgo en una serie de cambios pequeños y reversibles, que es exactamente como reducimos el riesgo en producción cuando trabajamos sobre sistemas vivos en NAYSOF.
El requisito técnico para que esto funcione es disciplina de despliegue: feature flags para activar y desactivar funcionalidad sin redeploy, pruebas de humo que validen el flujo real antes de redirigir tráfico, y un plan de rollback documentado para cada paso.
- Construye el nuevo sistema en paralelo y redirige una función cada vez.
- Usa feature flags para encender o apagar lo nuevo sin tocar código.
- Valida con un smoke test E2E real antes de mover tráfico productivo.
- Ten un plan de rollback escrito para cada módulo migrado.
Migración de datos sin pérdida ni corrupción
Los datos son lo único verdaderamente irreemplazable. El código se reescribe; un cliente, una factura o un histórico perdido, no. La migración de datos legacy merece su propio plan: nunca debe ser un "copiar y pegar" la noche del despliegue.
El enfoque correcto es iterativo. Se preparan scripts de migración idempotentes (que se pueden ejecutar varias veces sin duplicar ni corromper), se ensayan contra una copia de producción, se validan los conteos y la integridad referencial, y solo entonces se ejecuta en real. La deduplicación, el saneamiento de filas corruptas heredadas de importaciones antiguas y la validación de formatos (fechas, identificadores, importes) son donde se concentran los problemas.
- Scripts idempotentes: repetibles sin duplicar ni romper datos.
- Ensaya siempre contra una copia de producción antes del corte real.
- Valida conteos, claves foráneas e integridad referencial tras cada lote.
- Planifica deduplicación y limpieza de datos corruptos heredados.
- Conserva el sistema antiguo en solo lectura un tiempo como red de seguridad.
Checklist accionable para una modernización segura
Si tuvieras que resumir un proyecto de modernización de sistemas legacy en una lista de control para tu equipo o tu proveedor, esta es la secuencia que debería seguirse de principio a fin. Cada punto reduce un riesgo concreto.
- 1. Define el detonante de negocio y el resultado medible que esperas.
- 2. Audita el sistema actual: datos, integraciones, deuda y dependencias ocultas.
- 3. Elige estrategia (rehost / replatform / refactor / reescritura) por módulo.
- 4. Diseña la arquitectura objetivo: nube, contenedores, multi-tenant, seguridad.
- 5. Aplica Strangler Fig: migra por módulos, con feature flags y rollback.
- 6. Planifica la migración de datos con scripts idempotentes y ensayos.
- 7. Monta pruebas de humo E2E y observabilidad antes de mover tráfico real.
- 8. Forma al equipo y documenta el nuevo sistema para evitar el próximo legacy.
Preguntas frecuentes
¿Cuánto cuesta una migración de software legacy en España?
Depende del tamaño y la estrategia. Un replatform o una modernización modular acotada puede moverse en rangos de mercado español de unos pocos miles a decenas de miles de euros, mientras que una reescritura completa de un sistema crítico entra en proyectos de mayor envergadura. La auditoría previa es justo lo que permite dar una cifra honesta: sin ella, cualquier presupuesto es humo. Lo recomendable es presupuestar por fases y empezar por la auditoría.
¿Es posible modernizar sin parar el sistema en producción?
Sí. El patrón Strangler Fig permite que el sistema nuevo y el antiguo convivan, migrando funcionalidad módulo a módulo con la posibilidad de volver atrás. Con feature flags, pruebas de humo y un plan de rollback por paso, la migración se convierte en una serie de cambios pequeños y reversibles, sin ventanas de parada que afecten al negocio.
¿Cuánto tiempo lleva un proyecto de modernización de sistemas?
Una modernización por fases bien planteada empieza a dar valor en semanas, no en años, porque cada módulo migrado entra en producción de forma independiente. Una reescritura total, en cambio, puede llevar muchos meses antes de aportar valor visible, por eso solo se recomienda cuando el sistema actual es irrecuperable.
¿Qué riesgo hay de perder datos al migrar?
El riesgo se controla con scripts de migración idempotentes, ensayos contra copias de producción, validación de integridad referencial y mantenimiento del sistema antiguo en solo lectura como red de seguridad. El error más común es tratar la migración de datos como un paso de última hora en lugar de como un subproyecto con sus propias pruebas.