Data Migration

Mover estado conservando obligaciones

Data Migration describe el movimiento controlado y, cuando corresponde, la transformación de datos desde una representación, ubicación o sistema hacia otro, conservando semántica, integridad y obligaciones requeridas. El éxito se refiere al estado utilizable y su autoridad durante la transición, no solamente a bytes transferidos.

Esta es una definición operativa del Atlas. Puede cambiar el store, modelo, schema o ubicación sin necesitar cloud. Un mismo engine puede requerir migrar información al modificar significado o representación. migration-strategy organiza el trayecto; Data Migration aporta las decisiones específicas sobre información y estado, sin convertirse en sinónimo de toda la estrategia.

Términos relacionados, con alcances diferentes

Término	Relación con la migración
Database migration	Término ambiguo: puede significar cambio de host, engine, schema o movimiento de registros. Precisar cuál.
Schema migration	Cambia estructura o representación; puede acompañar movimiento de estado, pero no lo demuestra.
Replication	Mantiene copias mediante un mecanismo; puede ayudar a una transición o continuar permanentemente.
synchronization	Intercambia y reconcilia cambios según reglas acordadas; puede sostener coexistencia sin trasladar autoridad.
Backup/restore	Atiende recuperación y protección; también puede utilizarse como mecanismo de transferencia.
ETL	Extrae, transforma y carga; también sirve a integración o analytics sin migración.
Backfill / conversión	Completa datos históricos o modifica representaciones; puede ser un paso, sin resolver todo el cambio.

Por ejemplo, PostgreSQL admite añadir una columna cuyo default puede representarse sin reescribir cada fila en ese momento. Una operación DDL no demuestra por sí sola una transformación completa de registros existentes. PostgreSQL 18, Modifying Tables. También puede moverse información conservando exactamente su schema.

Semántica antes que equivalencia de archivos

En Payments, 100 necesita moneda y unidad; un null puede significar desconocido, no cero. Un estado histórico puede representar autorización y no captura. Mover valores conservando sus tipos físicos no demuestra conservar esas distinciones.

Revisar precisión, redondeo, fechas, zona horaria, IDs, valores derivados y convenciones históricas. Si una fecha no registra offset, asumir UTC puede inventar información. Un enum desconocido no debería convertirse silenciosamente en «approved» solo para satisfacer un schema destino.

Definir correspondencias, valores no representables y tratamiento de excepciones. Transformaciones lossless conservan información según el alcance definido; agregación o descarte puede ser deliberadamente lossy. Esa pérdida necesita justificación y aceptación de negocio y obligaciones aplicables, no una promesa de equivalencia byte a byte para todo caso.

Descubrimiento y política de calidad

Antes de ejecutar, conocer volumen, distribuciones, nulls, duplicados, huérfanos, valores inválidos y uso efectivo del schema. legacy-systems recuerda que una anomalía puede participar en un procedimiento real, aunque nadie la haya documentado. También pueden existir lectores que no aparecen en el inventario de aplicaciones.

Preservar historia, corregir errores y limpiar representaciones son decisiones diferentes. Una migración puede conservar cierta anomalía por fidelidad histórica, transformarla mediante una regla aprobada o detenerse para resolverla. Limpiar silenciosamente amplía alcance y puede cambiar resultados o evidencia de auditoría.

technical-debt puede quedar expuesta en schemas inconsistentes, transformaciones desconocidas o ownership ambiguo. No es obligatorio resolver toda esa deuda en la misma intervención. Conviene separar las mejoras necesarias para el objetivo de otras que añaden riesgo, sin ocultar condiciones que invalidan el traslado.

Autoridad y coexistencia explícitas

data-ownership pregunta qué capacidad declara el estado válido, quién puede modificarlo y bajo qué reglas. Una copia destino no adquiere autoridad porque esté disponible. Source y target necesitan una asignación comprensible mientras conviven.

En el ejemplo propio de Payments, v1 conserva autoridad mientras v2 recibe una copia. Después puede transferirse una población identificada de operaciones. El corte debe establecer qué admisiones antiguas cesan, cómo se atiende trabajo pendiente y desde qué condición las nuevas escrituras pertenecen a v2. Para operaciones históricas puede mantenerse otra asignación explícita.

Declarar escritores permitidos, dirección de propagación, frescura, conflictos y salida de coexistencia. Si ambas partes pueden modificar el mismo estado lógico, hacen falta reglas de dominio para resolver conflictos; no existe un algoritmo genérico deducible de «migrar». Evitar dual autoridad innecesaria simplifica ese problema.

Dual writes, CDC y límites de los mecanismos

Escribir source y target mediante operaciones independientes expone éxito parcial, reintentos, orden distinto y validaciones divergentes. transactional-outbox puede relacionar un cambio local con publicación posterior; no vuelve atómicas dos escrituras arbitrarias ni decide qué sistema es autoritativo.

Change Data Capture puede propagar cambios del source durante la transición. No decide significado, orden entre fuentes independientes, reparaciones ni cómo tratar escrituras concurrentes del target. Su cobertura de deletes, DDL, transacciones y tipos necesita verificarse en el mecanismo concreto.

PostgreSQL documenta que su replicación lógica no propaga automáticamente el schema ni el estado de secuencias. Esos límites ilustran por qué copiar cambios de filas no basta para declarar migrado todo el sistema. PostgreSQL 18, Logical Replication Restrictions. No se generalizan esas restricciones a todos los productos de CDC.

Copia inicial, catch-up y ventana de cambio

Una forma frecuente combina copia histórica, captura de cambios concurrentes, catch-up, validación y cutover. La arquitectura de replicación lógica de PostgreSQL ejemplifica copia inicial seguida de sincronización de cambios. PostgreSQL 18, Architecture. Es un mecanismo documentado, no un lifecycle universal de Data Migration.

El ejemplo del Atlas necesita relacionar la copia con una posición o estado conocido de cambios para no dejar huecos ni sobrescribir datos posteriores con una versión histórica. «La copia terminó» no demuestra que se aplicó el último cambio requerido. Deben contabilizarse también actualizaciones y borrados.

Una migración offline puede detener escrituras durante una ventana y simplificar coordinación, con interrupción aceptada. Una online mantiene cambios en source y agrega sincronización, orden y corte. constraints puede limitar downtime; eso no elimina la complejidad trasladada a la transición ni convierte online en opción universalmente superior.

Identificadores, relaciones e historia

Cambiar IDs afecta referencias internas, integraciones, URLs, auditoría y reconciliación. Puede necesitarse un mapping persistente mientras existan obligaciones que usen los identificadores anteriores. La correlación con una transacción del proveedor no debe perderse al asignar una nueva clave local.

Padres, hijos y otras relaciones pueden requerir un orden de carga o validación. No todas las relaciones de dominio se representan mediante foreign keys. Requerir orden global para todo puede añadir coordinación sin proteger una propiedad necesaria; precisar qué dependencias importan.

No toda historia tiene que moverse del mismo modo. Puede trasladarse completa, por período, archivarse, mantenerse en source read-only o recuperarse bajo demanda, según requisitos y operación. Retención, borrado, privacidad, auditoría y legal holds siguen aplicando: migrar no reinicia obligaciones. Las copias temporales también necesitan acceso y duración deliberados.

Validación más allá de contar filas

Los conteos ayudan a detectar omisiones, pero pueden coincidir aunque dos registros tengan importes equivocados. Si una transformación divide o agrega registros, incluso el conteo esperado necesita otra regla. Checksums requieren representaciones comparables; un hash diferente puede ser correcto después de una transformación intencional.

Combinar conteos por población, agregados, invariantes, muestras, queries semánticas y resultados de procesos comerciales aporta evidencias distintas. Ninguna demuestra por sí sola toda corrección. También debe definirse contra qué corte temporal se compara: un source que sigue cambiando puede diferir legítimamente de una copia retrasada.

AWS DMS documenta comparación por filas, restricciones y carga adicional de validación; las modificaciones concurrentes pueden limitar la comparación. AWS DMS data validation. Se usa como ejemplo concreto de alcance de una herramienta, sin convertir ese producto en definición general de migración.

Reconciliación y evidencia para decidir

Reconciliación compara source y target para identificar divergencias bajo reglas acordadas. El reporte detecta diferencias; la reparación es otra acción, con autoridad para decidir qué representación corresponde y si debe transformarse o corregirse el origen.

fitness-functions puede evaluar invariantes, correspondencia de autorizaciones, discrepancias pendientes de una población o cese de escrituras antiguas después del corte. El criterio debe incluir lo no validado y las excepciones aceptadas. Un checksum exitoso no demuestra que un refund histórico siga siendo ejecutable.

testability facilita escenarios reproducibles y diagnóstico. Comparar estado sin efectos es diferente de volver a cobrar, reservar stock o generar envíos. Una migración que reejecuta efectos comerciales para «validar» puede producir duplicados aunque las tablas finales parezcan correctas.

Lecturas, escrituras y recuperación

Cambiar tráfico, lecturas, escrituras y autoridad son eventos distintos. Puede leerse una copia mientras source sigue gobernando escrituras; una lectura stale puede alterar decisiones y necesita una tolerancia explícita. Pasar APIs a v2 no prueba que todos los jobs antiguos hayan dejado de escribir.

Antes de nuevas mutaciones autoritativas, volver al source puede ser relativamente sencillo si conserva estado y contratos pertinentes. Después, puede estar atrasado o carecer de representación para datos nuevos. Rollback puede necesitar sincronización inversa, reconciliación o compensación; roll-forward puede resultar más viable. La respuesta depende del estado, no de una preferencia universal.

deployment mantiene visible la secuencia de código y datos: puede prepararse schema o código compatible antes de mover registros, según el caso. parallel-change sostiene formas coexistentes, pero no mueve datos automáticamente. Migrar registros tampoco prueba compatibilidad de consumidores.

Reinicio y carga sobre producción

Transferencias largas pueden quedar parcialmente completas. Checkpoints y idempotency ayudan a continuar con posición y efectos comprendidos. Debezium documenta offsets y posibles eventos duplicados al recuperarse de ciertos fallos; el destino necesita tratar la repetición bajo sus garantías reales. Debezium PostgreSQL connector, sección Behavior when things go wrong.

Migrar es otra carga: copia, backfill, CDC y validación consumen CPU, I/O, conexiones, red y logs. Limitar ritmo o aplicar backpressure puede proteger producción y prolongar catch-up. Si los cambios llegan más rápido de lo que se aplican, el target no converge por esperar más; revisar capacidad, alcance o ventana. No se prescribe aquí una implementación de pipeline.

Commerce: una trayectoria con autoridad conocida

La siguiente síntesis del Atlas ilustra Payments hacia una base relacional gestionada:

Estado	Decisión y evidencia relevante
Preparar	Descubrir schemas, semántica, historia y lectores de BI; acordar modelo y mappings.
Copiar y alcanzar	v1 conserva autoridad; transferir historia y cambios, contrastando lag y divergencias.
Cambiar lecturas y escritores	Declarar poblaciones y corte; impedir admisiones antiguas para el alcance transferido y verificar escritores residuales.
Cerrar el alcance	Resolver excepciones y obligaciones históricas, detener sincronización innecesaria y decidir disposición del source.

Refunds pueden requerir IDs y referencias del proveedor antiguo, aunque ya estén presentes las autorizaciones actuales. Un reporte de BI que consulta tablas legacy necesita migrar su contrato o retirarse deliberadamente antes de eliminar ese acceso. legacy-systems e interfaces permiten descubrir y gestionar esas obligaciones.

Si el target ya aceptó escrituras y aparece un incidente, dirigir la API a v1 no actualiza sus datos. La contingencia necesita reconciliación, reversión de información o reparación hacia adelante; no basta conservar la imagen anterior.

Composición y finalización

strangler-fig puede desplazar capacidad mientras persisten dependencias de datos que deben tratarse. branch-by-abstraction puede ocultar proveedores de storage sin resolver sincronización ni autoridad. refactor-vs-rewrite ayuda a distinguir construcción de implementación y movimiento de estado requerido.

cloud-migration puede incluir esta transición, pero también puede conservar una base remota existente. Data Migration puede ocurrir enteramente on-premises. migration-strategy combina ambas preocupaciones con mecanismos, evidencia y cierre; ninguna es sinónimo de las otras.

Completar exige datos requeridos disponibles, transformaciones contrastadas, autoridad y consumidores resueltos, discrepancias tratadas y disposición del source decidida: retirar, archivar, conservar read-only o mantenerlo temporalmente. No equivale a terminar una copia. Una excepción transitoria puede ser legítima; escrituras paralelas permanentes sin control pueden contribuir a architecture-erosion.

sunsetting desarrolla el cierre de stores y accesos después de resolver escritores, lectores, historia y disposición de datos; no convierte una copia completa en permiso de borrado. El cambio incremental puede apoyar evolutionary-architecture, sin demostrar automáticamente ese enfoque. evolution-and-modernization conecta esas decisiones sin confundir movimiento de estado con retirada del sistema.