Migrar la DB en vivo: 5 etapas, cero downtime

El instinto automático de cualquier founder novato cuando la base de datos se vuelve inmanejable y hay que refactorizar el esquema, es planificar un mantenimiento de madrugada. "Ponemos un cartelito de mantenimiento, hacemos un dump and restore el domingo a las 3 AM, corremos un script y levantamos de nuevo".

En 2026, si tenés clientes B2B operando 24/7, ese atajo técnico es un suicidio. Si tu sistema tiene 400 PyMEs liquidando sueldos críticos el último día del mes, sumado a un yacimiento petrolero en Neuquén donde los operarios fichan el ingreso a las 5 AM contra tu API, y un SLA firmado del 99.95%, sencillamente no podés apagar el sistema cuatro horas.

Apagar la base de datos en un SaaS serio cuesta plata, rompe la confianza de los clientes institucionales y te muestra como un amateur. A los usuarios no les importa tu deuda técnica; les importa que el sistema esté disponible cuando lo necesitan.

El rescate técnico no es reescribir código, es sanear datos

Tengo 52 años y casi 40 años de oficio peleando con arquitecturas de software. Cuando un equipo me llama desesperado porque su SaaS está colapsando bajo su propio peso y la base de datos está infectada de inconsistencias acumuladas, la solución que buscan instintivamente es que alguien reescriba el backend de cero con herramientas modernas.

Pero el problema rara vez es el código. Un verdadero "Rescate Técnico" en un sistema en llamas no consiste en refactorizar funciones en el repositorio; consiste en migrar, sanear y reestructurar la data en vivo, sin apagar el negocio un solo segundo.

Y acá voy a hacer un anti-claim que va en contra de los instintos de muchos ingenieros: NO siempre hay que migrar. La migración es cara, riesgosa y lenta. Muchas veces, lo correcto frente a una base de datos degradada es simplemente agregar los índices compuestos que faltan, borrar registros huérfanos y endurecer las validaciones a nivel motor sobre la estructura que ya existe. Pero cuando el esquema no da para más, o cuando el motor se volvió un lastre insostenible, la migración es inevitable. Y si vas a hacerlo, tenés que hacerlo sin cortar el servicio.

El playbook de las 5 etapas para cero downtime

Lograr un zero-downtime migration no requiere genialidad algorítmica. Requiere una coreografía estricta. Este es el playbook de cinco etapas que aplicamos en sistemas críticos B2B.

1. Dual Write (Doble Escritura)

El primer paso es modificar tu capa de acceso a datos para que cada cambio que ocurre en producción (sea un insert, un update o un delete) se escriba obligatoriamente en la base de datos vieja (old) y en la estructura de la base de datos nueva (new) en paralelo.

El detalle crítico acá es el asincronismo. La escritura hacia la base nueva tiene que ser ASÍNCRONA. Implementás una cola interna en tu backend para no degradar la latencia de respuesta del usuario. Si la escritura en la base vieja funciona, la transacción principal se completa y el usuario recibe su 200 OK. Si la escritura en la base nueva falla o da timeout, se loguea exhaustivamente para que vos lo revises, pero jamás se hace un rollback de la operación en la base vieja. El usuario nunca se entera de que estás armando un sistema paralelo por detrás.

2. Backfill Histórico

Mientras el Dual Write ataja los datos nuevos que van entrando en tiempo real, tenés que pasar la historia pesada. Esto no se resuelve con un script de Bash corriendo un loop infinito que te ahoga el servidor.

El backfill es un proceso que tiene que ser pausable, reanudable e idempotente. Vas moviendo la información de old a new en bloques controlados (chunks) de 1.000 a 10.000 registros. Tenés que aplicar políticas de throttling hiper estrictas para no saturar los IOPS (operaciones de entrada/salida por segundo) del clúster de producción y tirar tu propio sistema abajo. Además, usás checkpoints (marcas de agua de estado) guardados en disco. Si el contenedor del script de migración muere a la mitad de la noche, al levantarse tiene que retomar la copia exactamente donde la dejó, sin duplicar ni corromper un solo registro en el destino.

3. Shadow Reads (Lecturas en la Sombra)

En este punto, la base nueva ya tiene la historia y los datos en tiempo real. Pero no podés confiar ciegamente en que la lógica de transformación de tu backfill haya sido perfecta.

Las queries de lectura reales de tus usuarios siguen yendo exclusivamente a la base vieja. Sin embargo, empezás a enrutar un porcentaje de ese tráfico (arrancás en un 1% y lo vas subiendo de a poco hasta el 100%) para que se ejecute TAMBIÉN contra la base nueva, en las sombras. El sistema compara los resultados de ambas consultas en memoria y loguea las diferencias (diffs). Si la base nueva devuelve algo distinto, el sistema NO devuelve un error al cliente; simplemente entrega el resultado seguro de la base vieja y te manda una alerta silenciosa. Recién cuando tenés un 99.99% de coincidencia absoluta durante una semana entera bajo tráfico real, podés considerar que la base nueva es confiable.

4. Switchover Atómico

Llegó el momento de la verdad, y tiene que ser instantáneo. Usás un feature flag dinámico o una variable de configuración en memoria para flipear la lectura principal de la aplicación, pasando de old a new.

El tiempo de corte dura los milisegundos que tarda la memoria de tu aplicación en procesar el flag. Todo el tráfico pasa a leer y escribir primariamente en la base nueva. Si en los siguientes cinco minutos explota un caso de uso esotérico que no habías mapeado y el sistema empieza a escupir errores 500, el rollback de emergencia toma exactamente los mismos milisegundos: flipeas el flag de vuelta y el tráfico vuelve a la base vieja que sigue sincronizada.

5. Decommission (El Apagón Final)

Ya estás operando exitosamente sobre la base de datos nueva. Pero el proceso no termina ahí. Mantenés el Dual Write (ahora desde new hacia old) funcionando en reversa por una o dos semanas más. Esto es por pura paranoia técnica, para garantizar que si descubrís una falla catastrófica a los 10 días, tu base vieja siga teniendo los datos al día para volver atrás.

Solo cuando pasa ese período de gracia con total estabilidad, cortás definitivamente el flujo de escritura hacia old, sacás un snapshot en frío para archivo, y apagás los servidores de la base vieja.

Las trampas de las que ningún tutorial de IA te avisa

Si le pedís a Cursor o a Claude que te generen el código para esta migración, te van a escupir la estructura del Dual Write perfectamente. Lo que la IA no te va a decir son los casos borde destructivos que te rompen la producción.

La primera trampa es la cursor-based pagination con ObjectId. En bases como MongoDB, el ObjectId tiene el timestamp de creación embedido matemáticamente. Si en tu backfill generás IDs nuevos para los registros en la base de datos de destino, estás cambiando su orden temporal implícito. Peor aún, si la API de tu cliente guarda el ID del último registro que vio para pedir la página siguiente, cuando flipees a la nueva base, ese cursor va a apuntar a un registro que no existe o a una posición completamente errónea. Tenés que preservar obligatoriamente los ObjectId originales.

La segunda trampa silenciosa es el $lookup entre colecciones. Si tenés aggregations que cruzan datos y decidís migrar la colección de users hoy, pero dejás la colección de invoices para la semana que viene, durante esos 7 días cualquier join cruzado en memoria va a fallar estrepitosamente porque los datos viven en clústeres distintos.

La tercera trampa es el manejo del estrés productivo: los hot reads vs cold reads. No pierdas tiempo intentando validar toda la historia completa desde el año 2014 de una sola vez. El 80% del tráfico diario de tu plataforma ocurre sobre los datos generados en los últimos 7 días. Validá esos datos calientes primero, asegurate de que la operación actual fluya sin fisuras, y dejá que los diffs de la data histórica se vayan validando de a poco en background.

Y por último, la trampa de los tiempos irreales. Cualquier tutorial te dice que esto es un proyecto de una semana. En la ingeniería de la calle, para un cluster mediano de entre 50GB y 1TB operando bajo tráfico, este proceso completo toma de uno a tres MESES de punta a punta. Acelerar los tiempos de sincronización en caliente es la forma más rápida de tirar la latencia de tu aplicación por la basura y afectar al cliente.

La disciplina de no pedir disculpas

En FirmaLaboral llevamos más de siete años de desarrollo continuo y superamos los seis años con el sistema operando ininterrumpidamente en producción. El stack histórico siempre fue robusto pero pesado: Node, MongoDB gestionado vía Mongoose, empaquetado en Docker y orquestado en DigitalOcean, procesando pagos e integraciones con Mercado Pago y AFIP. Hoy soportamos la operación diaria de más de 400 PyMEs en Argentina y Uruguay.

A lo largo de estos años, pasamos por migraciones múltiples. Refactorizamos colecciones enteras, pasamos de instancias aisladas a Replica Sets complejos, reconstruimos la indexación desde cero y saltamos de Mongoose 3.6 a la versión 8 sin un solo corte masivo del servicio. Y la métrica de la que más orgulloso estoy es que, en todos estos años, NUNCA tuvimos que mandarles a las 400 empresas un mail diciendo "el sábado vamos a estar abajo 4 horas por mantenimiento".

La diferencia entre downtime de 4 horas anunciado por mail y un sistema que migra en vivo no es talento ni framework. Es disciplina y paciencia. Y a veces, saber que la fricción de armar el dual write durante 6 semanas vale infinitamente más que el costo de pausar la operación de tus clientes.