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.
Artículos relacionados
Preguntas frecuentes sobre
Como mejorar mi negocio con la metodología Anticompetencia
En Tangram no queremos que la información pase por una cadena interminable de intermediarios donde se pierden los detalles importantes.
Contarás con un interlocutor que coordinará la comunicación y trasladará las decisiones al equipo responsable de tu proyecto.
Cuando sea necesario profundizar en cuestiones de estrategia, diseño o tecnología, podremos involucrar a los especialistas correspondientes.
Así tendrás una comunicación organizada, sin necesidad de gestionar personalmente a todos los profesionales que intervienen.
Queremos que tengas acceso al conocimiento de un equipo especializado, sin sufrir la complejidad de coordinarlo.
No tendrás que averiguar a quién escribir cada vez que tengas una duda.
En Tangram contemplamos la figura del Account Manager como interlocutor principal, encargado de acompañarte durante el proyecto, coordinar la comunicación y facilitar el seguimiento de las decisiones.
Nuestra metodología incluye reuniones de revisión, canales de comunicación y herramientas para que puedas participar en el trabajo.
La organización concreta, la frecuencia de las reuniones y los canales disponibles se establecerán según el proyecto contratado.
Lo importante es que sepas con quién hablar, en qué punto está tu proyecto y qué decisiones necesitan tu participación.
Sí, podemos valorar una colaboración con los profesionales que ya trabajan en tu empresa.
No siempre tiene sentido sustituir un equipo que conoce bien tu negocio. En muchas situaciones, lo más útil es complementar sus conocimientos con especialistas en determinadas áreas.
Podemos estudiar qué responsabilidades asumiría Tangram, cuáles mantendría tu equipo y cómo coordinar las decisiones para evitar duplicidades.
La forma concreta de colaboración dependerá de la organización, las herramientas y las necesidades del proyecto.
No se trata de reemplazar lo que ya funciona, sino de aportar el conocimiento que necesitas para llegar más lejos.
No tienes por qué cambiar de proveedor para explorar una colaboración con Tangram.
Durante nuestra trayectoria hemos trabajado con agencias y consultoras, participando en proyectos en los que cada empresa asumía una parte diferente del trabajo.
Esa experiencia nos permite comprender la importancia de definir responsabilidades y coordinar a los profesionales implicados.
Podemos valorar una colaboración para cubrir necesidades concretas que tu proveedor actual no ofrece o para reforzar determinadas áreas.
Si tienes una relación profesional que funciona, no queremos que la rompas sin motivo. Queremos encontrar dónde podemos aportar valor.
La confidencialidad es especialmente importante cuando hablamos de nuevas ideas de negocio, información económica, estrategias comerciales o desarrollos tecnológicos.
En Tangram tenemos experiencia trabajando en proyectos sujetos a acuerdos de confidencialidad, motivo por el que no podemos mostrar públicamente muchos de los trabajos en los que hemos participado.
Si tu proyecto requiere un acuerdo de confidencialidad (NDA) antes de compartir información sensible, podemos revisar sus condiciones y acordar cómo proteger esa información antes de entrar en los detalles.
Entendemos que la confianza empieza por respetar lo que todavía no quieres hacer público.