Migración de base de datos legacy a un sistema moderno de aplicación: guía práctica para empresas

La primera vez que vi una migración caerse en producción fue un domingo a las 04:17. Un Informix con dieciocho años a las espaldas, un PostgreSQL recién horneado, y un job nocturno que nadie documentó decidiendo que esa madrugada era buen momento para reescribir media tabla de pedidos. El CTO descubrió el load testing tres semanas después. Le sonará.

Un informe de Deloitte de 2023 dice que el 72 % de las empresas europeas sigue operando con al menos un sistema legacy crítico de más de quince años. En España la foto es la misma: Informix, FoxPro, COBOL que nadie toca, AS/400 que aguantan por inercia y backups que nadie ha probado restaurar desde 2019. Todo eso convive, mal, con APIs REST, cloud y dashboards que dirección quiere en tiempo real.

Migrar una base de datos legacy no es capricho. Es supervivencia. Pero hacerlo mal sale más caro que no hacerlo, y de eso va este artículo: las fases, los charcos y las decisiones que separan un proyecto sobrio de un Excel rojo en el consejo siguiente.

Por qué las bases de datos legacy se convierten en un problema

Un sistema legacy no es por fuerza viejo. Es un sistema que ya no aguanta el ritmo del negocio. La base puede seguir respondiendo a la perfección a las consultas para las que la diseñaron en 2006, pero empieza a renquear cuando intentas colgarle encima una capa de microservicios, un pipeline de analítica o, peor, un pico de Black Friday con tres veces el tráfico habitual.

Los síntomas son siempre los mismos:

• Coste de mantenimiento desproporcionado. Gartner estimó en 2024 que las organizaciones destinan de media el 60-80 % de su presupuesto de TI al mantenimiento de sistemas existentes. Traducción: queda poco para innovar y casi nada para hacer las cosas bien.
• Dependencia de perfiles escasos. Encuentra un DBA de Sybase o un cobolero senior en 2026. Te deseo suerte. Y prepara la cartera.
• Riesgo de seguridad. Muchos motores legacy ya no reciben parches. Las CVE conocidas se quedan abiertas para siempre, esperando.
• Imposibilidad de escalar. Los monolitos de hace veinte años no estaban pensados para concurrencia masiva ni distribución geográfica. Cuando metes k6 a lanzar mil usuarios virtuales contra un Informix con bloqueos pesimistas, el p99 se va a la luna en treinta segundos.

Cuando se acumulan dos o tres de estos, la pregunta deja de ser si migrar. Pasa a ser cuándo, y con cuánto sueño vas a llegar al go-live.

Evaluar antes de migrar: la fase que nadie quiere hacer

El error más común en una migración de base de datos legacy a un sistema moderno de aplicación es ponerse a escribir scripts de ETL antes de entender lo que hay. Da pereza. Es trabajo invisible para el comité. Y es exactamente lo que separa un proyecto de seis meses de uno de dieciocho.

Inventario de datos y dependencias

No basta con listar tablas. Hay que mapear relaciones, procedimientos almacenados, vistas que consumen otras aplicaciones, triggers que disparan lógica de negocio en silencio y los jobs nocturnos que llevan ejecutándose desde 2009 porque nadie se ha atrevido a tocarlos.

McKinsey publicó en 2023 que el 38 % de los proyectos de migración sufren retrasos serios porque aparecen dependencias ocultas a mitad del camino. Dos o cuatro semanas de inventario al principio te ahorran meses al final. Lo he visto. Y al revés también.

Calidad de los datos existentes

Las bases legacy acumulan basura: duplicados, campos que cambiaron de significado en 2014 y nadie actualizó, codificaciones mezcladas (Latin-1 conviviendo con UTF-8, todo un clásico), fechas en cinco formatos distintos según el becario de turno. Si migras basura, lo único que ganas es basura más rápida y mejor indexada.

Antes de mover un solo registro hay que definir reglas de limpieza y transformación: qué se migra, qué se archiva en frío y qué se descarta. Y por escrito, no en una reunión de Teams.

Evaluación del sistema destino

El motor destino se elige por requisitos, no por la última charla de la KubeCon. PostgreSQL, MySQL, SQL Server, MongoDB o una mezcla razonable, cada uno tiene su sitio. Decide según volumen, patrones de consulta, requisitos transaccionales y el resto del ecosistema con el que se va a entender. No por el meme del trimestre.

Las cinco fases de una migración bien ejecutada

Fase 1: Diseño del esquema destino

El modelo nuevo no debería ser un calco del antiguo. Casi nunca. Las bases legacy arrastran decisiones que tenían sentido cuando un disco SCSI costaba un riñón: desnormalizaciones por rendimiento, tablas auxiliares que ya no pintan nada, claves compuestas raras. Es el momento de rehacer, no de fotocopiar.

Fase 2: Desarrollo de los scripts de migración

Los ETL (Extract, Transform, Load) son el corazón técnico. Cada tabla necesita su pipeline: extraer del origen, transformar según reglas pactadas y cargar en destino. Apache NiFi, Talend, dbt o scripts Python con SQLAlchemy son herramientas con las que se vive bien. Lo importante no es cuál uses, sino que el proceso sea idempotente y repetible.

Detalle que casi todo el mundo subestima: la gestión de secuencias e identificadores. Si el origen va con autoincrementales y el destino con UUIDs, necesitas una tabla de correspondencia para poder trazar cada registro hacia atrás. Te lo vas a agradecer el día que un usuario pregunte por qué su pedido del 14 de marzo desapareció.

Fase 3: Pruebas de migración en entorno aislado

A producción no se migra nunca a la primera. Se hacen ciclos completos en un entorno espejo, se validan los datos con consultas automatizadas y se comparan contra el origen, registro a registro cuando hace falta. Según el Project Management Institute (PMI), los proyectos que dedican al menos un 25 % del tiempo total a pruebas tienen un 40 % menos de incidencias post-lanzamiento. Y aún así, alguien siempre se queja del calendario.

Aquí es donde entra el testing de carga rendimiento aplicación web lanzamiento que tanta gente descubre la víspera. Validar integridad está bien, pero si las consultas habituales tardan tres veces más sobre el esquema nuevo, has migrado para empeorar. Monta JMeter, Locust o Gatling contra el destino con tráfico realista, mide p95 y p99 sobre los endpoints críticos, y compáralos con la baseline del sistema antiguo. Si el p99 de la consulta del listado de pedidos sube de 180 ms a 1,2 segundos, tienes un problema, no una migración.

He visto managers descubrir el concepto de RPS la víspera del corte. Es divertido, en el sentido cínico del término. No lo seas tú.

Fase 4: Migración con estrategia de corte

Hay dos enfoques principales y los dos tienen sus víctimas.

• Big bang: paras el viejo, ejecutas la migración completa, arrancas el nuevo. Más rápido, más arriesgado. Funciona cuando la ventana de inactividad es aceptable y el volumen permite cerrar el proceso en horas, no en días.
• Migración progresiva: trasladas por módulos o entidades, manteniendo ambos sistemas en paralelo durante semanas o meses. Necesitas sincronización bidireccional, que es donde se mueren los proyectos mal planificados, pero baja muchísimo el riesgo. La opción por defecto para cualquiera que no pueda permitirse caída.

En ambos, el plan de rollback se documenta y se prueba. No el viernes anterior. Antes. Y si nunca lo has ejecutado, no existe.

Fase 5: Validación post-migración y desmantelamiento

Migrado no es terminado. Toca conteo de registros, integridad referencial, pruebas funcionales con usuarios reales (los que de verdad usan el sistema, no el comité) y monitorización fina del rendimiento durante las primeras semanas. Aquí vuelven a entrar k6 y compañía: cargas progresivas, soak tests de varias horas, observabilidad de latencias por endpoint.

Y nada de desmantelar el sistema viejo al día siguiente. Déjalo en modo lectura uno o dos meses. Las discrepancias raras tardan en aparecer, y cuando aparecen, conviene poder volver a consultar la fuente original sin pánico.

Errores que hemos visto repetirse

Después de participar en unos cuantos proyectos de migración, hay patrones que se repiten con una regularidad que da pereza:

• Subestimar el esfuerzo de limpieza de datos. Lo que iban a ser tres meses se convierten en seis porque el origen está peor de lo que admitía el equipo funcional.
• No involucrar a los usuarios. El equipo técnico migra los datos, pero solo quien los usa cada día sabe si el resultado tiene sentido operativo.
• Olvidar los informes y procesos batch. La aplicación principal va, pero el cierre mensual del departamento financiero estalla porque apuntaba a tablas con otros nombres. Esa llamada a las 23:00 del último día del mes no se olvida.
• Falta de documentación del proceso. Si la migración hay que repetirla (y se repite, varias veces antes del corte definitivo), cada ejecución debe ser reproducible sin que dependa de la memoria de alguien.

Cuánto cuesta realmente una migración de este tipo

Depende. Un proyecto va desde 15.000 euros para una base departamental hasta varios cientos de miles para sistemas críticos con millones de registros y decenas de aplicaciones colgando.

Lo que sí es cuantificable es el coste de no migrar. IDC estimó en 2024 que las empresas que mantienen sistemas legacy más allá de su vida útil razonable incurren en un sobrecoste operativo del 20-30 % anual frente a quienes han modernizado. Esa cifra no aparece en una factura, pero la pagas igual: en horas de soporte, en perfiles caros, en oportunidades perdidas y en noches de guardia.

El momento de dar el paso

Cada mes que pasa con un sistema legacy crítico suma deuda técnica, riesgo operativo y dependencia de un ecosistema que se va apagando. La migración de base de datos legacy a un sistema moderno de aplicación no es un proyecto para improvisar. Necesita planificación de adulto, perfiles que conozcan los dos mundos (el viejo y el nuevo, sin desprecio por ninguno) y una gestión de expectativas honesta con dirección, negocio y operaciones.

Si en tu empresa estáis valorando un proyecto de este tipo y queréis un equipo que entienda tanto la parte técnica como el impacto en la operativa diaria, hablemos: https://tangramconsulting.es/contacto. Trabajamos con compañías españolas que quieren dejar atrás sus sistemas legacy sin que la facturación del lunes siguiente se entere.