Migrar una base de datos es una de las operaciones más delicadas que puede hacer una empresa. Por eso no improvisamos.
Auditamos, planificamos y ejecutamos migraciones de bases de datos con rollback garantizado, validación de integridad y cero tolerancia a la pérdida de datos — independientemente del motor, el volumen o la complejidad del esquema.
Qué es una migración de base de datos y por qué ocurre
Una base de datos no es estática. A lo largo de la vida de una empresa, la infraestructura de datos necesita evolucionar: cambiar de proveedor de hosting, actualizarse a una versión más reciente del motor, adaptarse a nuevos requisitos de rendimiento o escala, o transformarse de raíz cuando el modelo de datos original ya no encaja con la forma en que el negocio ha crecido.
Una migración de base de datos es el proceso de mover datos de un sistema a otro — conservando su integridad, adaptando su estructura al nuevo entorno y asegurando que la aplicación que los consume sigue funcionando correctamente después. Puede ser tan directa como mover una base de datos MySQL de un servidor a otro, o tan compleja como transformar un esquema relacional completo en una estructura de documentos NoSQL o viceversa.
Lo que todas las migraciones tienen en común es que operan sobre datos reales en producción. No hay entorno de pruebas que lo sustituya completamente. Y cuando algo sale mal, las consecuencias son inmediatas y costosas.
¿Te reconoces en alguno de estos escenarios?
Cambias de proveedor de hosting o infraestructura. Tu base de datos vive en un servidor que vas a abandonar — por coste, por rendimiento o por cambio de arquitectura — y necesitas moverla al nuevo entorno sin perder datos ni interrumpir el servicio más de lo necesario.
Cambias de motor de base de datos. Tienes MySQL y necesitas PostgreSQL. Tienes una base de datos SQL y tu arquitectura requiere MongoDB. O al revés — tienes MongoDB y la madurez del negocio requiere la consistencia y las relaciones de un modelo relacional. El cambio de motor implica no solo mover datos sino adaptar el esquema, reescribir queries y actualizar la capa de datos del backend.
Transformas el modelo de datos — SQL a NoSQL o NoSQL a SQL. Es la migración más compleja y más transformadora. Un modelo relacional normalizado en tablas no se mapea directamente a documentos, y un esquema de documentos flexible no se convierte automáticamente en tablas relacionales con integridad referencial. Requiere decisiones de arquitectura de datos que tienen consecuencias a largo plazo.
Modernizas infraestructura legacy. Tus datos viven en Excel, Access, FileMaker o cualquier sistema que no fue diseñado para escalar — y necesitan llegar a una base de datos real antes de que el volumen o la complejidad los haga inmanejables.
Actualizas el ORM sin cambiar de motor. Tienes Sequelize y quieres migrar a Prisma. O tienes Mongoose y necesitas actualizar a una versión con esquemas estrictos. El motor no cambia pero los modelos, las queries y las migraciones hay que reescribirlos.
Lo que distingue una migración bien ejecutada de una que sale mal
Una migración de base de datos mal ejecutada puede causar pérdida parcial o total de datos, downtime no planificado y regresiones en la aplicación que la consume. No es un riesgo teórico — es lo que ocurre cuando se ejecuta sin el proceso correcto.
Nuestro proceso existe para eliminar ese riesgo de forma sistemática, no para gestionarlo una vez que ya ha ocurrido.
Auditoría antes de tocar nada.
Antes de diseñar cualquier plan, analizamos el esquema actual en profundidad: tablas o colecciones, relaciones, índices, constraints, volumen de datos, calidad de los datos y problemas existentes. El resultado es un informe escrito con los hallazgos y los riesgos identificados. No se diseña nada hasta que este paso está completo.
Diseño del esquema destino validado con el cliente.
El nuevo esquema se diseña y se documenta antes de ejecutar nada. El cliente lo revisa y lo aprueba. No empezamos a escribir scripts hasta que el diseño está cerrado.
Rollback plan testeado antes de ejecutar.
Todo proyecto incluye un procedimiento documentado y verificado para revertir la migración completa si algo falla. El backup se verifica antes de la ejecución. Si el rollback no funciona, la migración no se ejecuta.
Validación de integridad post-migración.
Tras la ejecución, verificamos que los datos han llegado correctamente: conteo de registros, integridad referencial, comprobación de datos críticos, queries de validación automatizadas. Tolerancia cero: si la validación falla, se ejecuta el rollback.
Ejecución en ventana de mantenimiento.
La migración se ejecuta en horario de bajo tráfico, coordinada con el cliente, con monitorización activa durante y después del proceso.
Para productos con usuarios activos las 24 horas, ofrecemos migración sin downtime — una estrategia de escritura dual que mantiene ambos sistemas sincronizados durante la transición y permite un corte instantáneo sin interrupción del servicio.
Lo que incluye cada proyecto
€3.000 – 8.000+
El precio base de €3.000 cubre migraciones de hasta 10 tablas o colecciones con el mismo motor de base de datos. El rango sube según el tipo de migración, el volumen de datos y los add-ons del proyecto.
| Auditoría de base de datos origen | Análisis completo del esquema actual con informe escrito de hallazgos y riesgos. Incluida en el precio base del proyecto — es el primer paso que determina el alcance real. |
| Diseño del esquema destino | Modelado del nuevo esquema con documento de mapeo origen → destino. Revisado y aprobado antes de ejecutar. |
| Plan de migración | Estrategia paso a paso con orden de ejecución, ventana de mantenimiento, rollback plan y criterios de validación. |
| Rollback plan verificado | Procedimiento documentado y testeado para revertir la migración completa. El backup se verifica antes de ejecutar. |
| Scripts de migración | Scripts automatizados para transferir y transformar los datos. Documentados y reutilizables. |
| Data cleaning básico | Deduplicación, normalización de formatos, corrección de encoding y eliminación de registros huérfanos. |
| Validación de integridad | Verificación post-migración de conteo, integridad referencial y datos críticos. Rollback automático si falla. |
| Adaptación de capa de datos del backend | Actualización de modelos ORM, reescritura de queries incompatibles y conexión del backend a los nuevos endpoints de base de datos. El backend existente se adapta para funcionar con la nueva base de datos — no se crean endpoints nuevos ni lógica de negocio nueva. |
| Ejecución en ventana de mantenimiento | Migración coordinada con el cliente en horario de bajo tráfico con monitorización activa. |
| Soporte post-migración 15 días | Monitorización y corrección de cualquier issue derivado durante los primeros 15 días. |
No incluye: endpoints nuevos, lógica de negocio nueva, cambios en el frontend ni mantenimiento continuo posterior.
Cada escenario tiene su complejidad
Mismo motor
Cambio de servidor, hosting o versión sin cambiar el motor. La más directa e incluida en el precio base.
Motor similar
Entre bases relacionales como MySQL a PostgreSQL. Requiere adaptación de tipos, sintaxis y queries específicas del motor.
SQL → NoSQL
Desnormalización de tablas relacionales a documentos. Requiere rediseño completo del esquema y decisiones de arquitectura sobre embeddings vs referencias — qué datos se incrustan dentro del documento y qué datos se referencian externamente.
NoSQL → SQL
Normalización de documentos a tablas relacionales. Diseño de relaciones entre entidades, establecimiento de claves foráneas, definición de constraints de integridad referencial y migración de datos embebidos a tablas independientes con sus propias relaciones. Es la migración que más decisiones de arquitectura de datos requiere.
Legacy → base de datos moderna
Desde Excel, Access, FileMaker o CSV a PostgreSQL, MongoDB o MySQL. Incluye parsing y transformación de formatos.
Ejemplos orientativos de proyecto completo:
| Proyecto | Precio estimado |
|---|---|
| MySQL → PostgreSQL (15 tablas, ~50k registros) | ~€3.400 |
| Excel/CSV → PostgreSQL (20 archivos, data cleaning) | ~€4.200 |
| MongoDB → PostgreSQL (12 colecciones, normalización) | ~€5.500 |
| PostgreSQL → MongoDB (25 tablas, zero-downtime) | ~€6.800 |
| SQL Server legacy → PostgreSQL (40 tablas, 1M+ registros) | ~€8.500 |
Depende del tipo de migración y del add-on elegido. Una migración estándar ejecutada en ventana de mantenimiento implica un periodo de indisponibilidad controlado y acordado con el cliente — habitualmente entre minutos y pocas horas según el volumen. Para productos con usuarios activos las 24 horas donde cualquier downtime es inaceptable, la migración sin downtime mantiene ambos sistemas sincronizados durante la transición y permite un corte instantáneo sin interrupción del servicio. Es el add-on que recomendamos a cualquier producto en producción con tráfico continuo.
El rollback plan existe exactamente para esto. Antes de ejecutar la migración, el backup está verificado y el procedimiento de reversión está probado. Si la validación de integridad post-migración falla en cualquier punto, se ejecuta el rollback de forma inmediata. El cliente no se queda con una base de datos en estado inconsistente — o la migración termina correctamente o volvemos al punto de partida con los datos intactos.
Sí — la capa de datos del backend está incluida en el precio base. Eso significa actualización de modelos ORM, reescritura de queries incompatibles con el nuevo motor y conexión a los nuevos endpoints de base de datos. Lo que no está incluido son endpoints nuevos, lógica de negocio nueva o cambios en el frontend — eso es desarrollo y se presupuesta como proyecto independiente.
Sí. La auditoría inicial existe precisamente para esto — entender el esquema y los datos tal como están antes de tocar nada. Si durante la auditoría encontramos problemas estructurales graves que hacen la migración inviable en las condiciones del proyecto, lo comunicamos antes de comprometer ningún precio ni fecha de ejecución.
Depende del problema que estés resolviendo. Un esquema SQL que empezó a usarse para datos con estructura muy variable puede beneficiarse de NoSQL. Una base de datos de documentos que ha crecido con relaciones complejas y necesidad de consistencia transaccional puede beneficiarse de SQL. No hay una respuesta universal — es una decisión de arquitectura que evaluamos en la auditoría inicial con los requisitos reales del negocio como punto de partida.
Los 15 días de soporte post-migración cubren cualquier issue que aparezca en producción derivado de la migración. Para el mantenimiento continuo de la nueva base de datos — backups, actualizaciones, monitorización — el retainer de DevOps es el paso natural siguiente.
CONTACTO
Hablemos de tu proyecto.
Cuéntanos qué necesitas y te respondemos en menos de 24 horas con una propuesta inicial y un plan de acción personalizado.