Migración de base de datos sin detener el producto

Una migración de base de datos es el proceso de mover datos de una base de datos a otra, o de un esquema a otro, para que una aplicación funcione sobre la nueva. En un producto en producción, lo difícil no es copiar filas. Es hacerlo mientras los usuarios siguen leyendo y escribiendo, sin perder, duplicar ni corromper nada.

El enfoque que funciona en la práctica: copiar los datos en segundo plano, mantener ambas bases sincronizadas por un tiempo, compararlas, mover las lecturas y luego las escrituras en pasos pequeños, y conservar un camino de vuelta al sistema antiguo hasta que confíes en el nuevo. El resto de este artículo recorre cada paso.

¿Qué es una migración de base de datos?

El término abarca varios trabajos distintos, y confundirlos genera problemas:

• Migración de esquema: cambiar tablas, columnas o índices dentro de la misma base de datos.
• Migración de motor: pasar de un producto de base de datos a otro, por ejemplo de un motor SQL a otro distinto, o de una base documental a una relacional.
• Migración de hosting: llevar el mismo motor a un nuevo servidor o proveedor de nube.
• Migración de modelo: reestructurar los datos para que encajen en un nuevo diseño de la aplicación, a menudo durante una reescritura o un replatforming.

Las migraciones de motor y de modelo son las riesgosas. Cambian la forma de los datos o cómo se almacenan, y la aplicación tiene que seguir funcionando durante el cambio. Todo lo que sigue aplica sobre todo a esos casos. Una limpieza de código pura es otro trabajo, más cercano a la refactorización sin cambiar el comportamiento.

¿Por qué mover los datos es lo más difícil de reemplazar un sistema en producción?

El código se puede desplegar, probar y revertir en minutos. Los datos, no. Una vez que un usuario escribe un registro en la base nueva, no puedes simplemente volver a desplegar la versión antigua y hacer como si nada hubiera pasado.

Algunas razones por las que se complica rápido:

• Los datos no dejan de cambiar. Cualquier copia que hagas ya está desactualizada cuando termina.
• Los datos antiguos son desordenados. Los sistemas legados acumulan nulls, duplicados, formatos inconsistentes y reglas que viven solo en el código de la aplicación, no en el esquema.
• Nadie recuerda las reglas. Una columna llamada status puede haber significado tres cosas distintas a lo largo de los años.
• Los errores son silenciosos. Una conversión de zona horaria incorrecta o un campo truncado no lanza un error. Aparece semanas después en la queja de un cliente.
• Los flujos de dinero dependen de ellos. Pedidos, pagos, suscripciones y saldos tienen que ser exactos.

En avanzzada lideré la migración completa de una plataforma que postula automáticamente a ofertas de empleo por sus usuarios, llevando toda la arquitectura de un stack legado a uno nuevo mientras la gente seguía usándola todos los días. Detener el producto no era una opción, así que cada paso tenía que ser reversible. La lección que me dejó ese tipo de trabajo: primero planificas el movimiento de los datos, y el plan del código se desprende de ahí.

¿Cuáles son las principales estrategias: big bang, trickle y dual write?

Hay tres patrones comunes. La mayoría de las migraciones reales los combinan.

Big bang

Funciona para volúmenes de datos pequeños, herramientas internas o productos en los que una ventana de mantenimiento es aceptable. Es la estrategia más fácil de entender, pero si la verificación falla después del cambio, quedas bajo presión con los usuarios esperando.

Trickle

Migras por porciones: un segmento de clientes, una funcionalidad, una familia de tablas. Cada porción se verifica antes de la siguiente. Encaja bien con la migración incremental, en la que una capa de enrutamiento envía parte del tráfico al sistema nuevo y el resto al antiguo. En una migración con el producto en uso, poner ese enrutamiento delante de todo es lo primero que hago, antes de escribir cualquier código nuevo. Operar dos sistemas en paralelo tiene un costo, pero en mi experiencia una reescritura big-bang suele costar más y tardar más, porque el sistema antiguo tiene que seguir funcionando en paralelo de todos modos mientras el nuevo lo alcanza.

Dual write

La aplicación escribe cada cambio en ambas bases de datos. Suena simple y no lo es. Si la primera escritura funciona y la segunda falla, las bases quedan en desacuerdo, y no existe una transacción que abarque las dos. Uso dual write con cuidado, con la base antigua como fuente de verdad y con jobs de reconciliación que detectan las divergencias. Muchos equipos prefieren replicación o change data capture, que explico a continuación.

¿Cómo mantener sincronizadas la base antigua y la nueva?

La regla que sigo: en cualquier momento, exactamente una base de datos es la fuente de verdad para un dato determinado. La otra la sigue.

Formas comunes de mantener al día a la base seguidora:

1. Copia masiva inicial más puesta al día incremental. Toma un snapshot, cárgalo en la base nueva y luego vuelve a aplicar los cambios ocurridos desde el snapshot.
2. Change data capture (CDC). Lee el registro de cambios de la base antigua y aplica esos cambios en la nueva. Así evitas tocar el código de la aplicación, y muchos motores de base de datos y herramientas lo soportan de alguna forma.
3. Dual write a nivel de aplicación. Útil cuando la forma de los datos cambia mucho, pero necesita reconciliación.
4. Sincronización periódica por lotes. Aceptable para datos que cambian poco, como las tablas de referencia.

Concentra la transformación en un solo lugar

Si el esquema nuevo difiere del antiguo, pon la lógica de mapeo en un único módulo o pipeline bien probado. Cuando la misma transformación se reimplementa en un script de backfill, un job de sincronización y la aplicación, las tres versiones terminan divergiendo.

Haz que las operaciones sean idempotentes

Los jobs de sincronización fallan y se vuelven a ejecutar. Si aplicar el mismo cambio dos veces crea duplicados, tarde o temprano tendrás duplicados. Usa IDs estables y upserts para que las reejecuciones no hagan daño.

Mueve las escrituras después de las lecturas

Un orden seguro es: sincronizar los datos, cambiar las lecturas a la base nueva para un grupo pequeño de usuarios, observar, ampliar el grupo y solo entonces mover las escrituras. Los feature flags son la herramienta habitual para esto, porque te permiten cambiar el enrutamiento sin un despliegue.

¿Cómo verificar los datos antes del cambio?

No confíes solo en el conteo de filas. Los conteos coinciden aunque los datos estén mal de formas que importan. Verifica por capas:

• Conteo de filas por tabla como primera verificación, barata.
• Checksums o hashes sobre las columnas clave, comparados entre la base antigua y la nueva.
• Agregados sobre valores de negocio: monto total de pedidos por día, suscripciones activas por plan, saldos por cuenta.
• Comparación de registros por muestreo: elige registros al azar, más casos límite como el más antiguo, el más grande y los que tienen nulls o caracteres poco comunes.
• Verificaciones de integridad referencial: claves foráneas huérfanas, registros padre faltantes, valores únicos duplicados.

Compara el comportamiento, no solo los datos

Una técnica potente es la lectura en sombra (shadow reading). La aplicación lee de ambas bases para la misma solicitud, devuelve al usuario el resultado de la antigua y registra cualquier diferencia. Las discrepancias te muestran las reglas que nadie documentó antes de que las encuentren tus usuarios.

Verifica con más rigor los flujos de dinero

Empieza por todo lo que involucre pagos, pedidos o saldos. Cuando me hago cargo de un sistema, los flujos de dinero vienen justo después de conseguir acceso y hacer que el build funcione, y una migración merece la misma prioridad. Concílialos con una fuente externa, como los registros de tu proveedor de pagos, y no solo con la base antigua, porque la base antigua ya puede contener errores.

Define de antemano qué es "suficientemente bueno"

Acuerden qué tasa de discrepancias bloquea el cambio. Para datos financieros, son cero diferencias sin explicar. Para datos de bajo riesgo, puedes aceptar excepciones conocidas y documentadas.

¿Cómo hacer rollback si algo sale mal?

El rollback es donde muchos planes de migración se quedan vagos. Revertir código es fácil. Revertir datos solo es posible si lo diseñaste para eso.

Reglas prácticas:

• Mantén la base antigua intacta y funcionando después del cambio, durante un período definido. No la des de baja el día del cambio.
• Sigue sincronizando en sentido inverso cuando puedas. Una vez que las escrituras pasen a la base nueva, replica los cambios de vuelta a la antigua para que volver atrás no pierda datos recientes. Es trabajo extra, y vale la pena en sistemas críticos.
• Cambia por etapas, para que un problema afecte a un grupo pequeño y el rollback sea cambiar un flag para ese grupo.
• Haz backups verificados antes de cada paso importante, y prueba que puedes restaurarlos. Un backup no probado es una esperanza, no un plan.
• Deja el disparador por escrito. Decide de antemano qué señales significan "hacer rollback": tasas de error, conteo de discrepancias, pagos fallidos, tickets de soporte.

Sé honesto sobre los límites. Después de suficiente tiempo en la base nueva, revertir puede ser más difícil que corregir hacia adelante. Define de forma explícita el punto de no retorno, y llega a él solo después de que la verificación haya estado limpia el tiempo suficiente para confiar en ella.

¿Estás planificando una migración?

Si estás por mover una base de datos en producción y quieres una segunda opinión, escribe a me@filipeeduardo.dev con una breve descripción de tu configuración. Con gusto te digo qué revisaría primero, como un ingeniero que compara notas con otro.