Data Migration — esencia, métodos y proceso de transferencia de datos

Qué es Data Migration

Data Migration es el proceso de transferir datos de un origen a otro garantizando su integridad, consistencia y disponibilidad tras la finalización. A diferencia de una simple copia, la migración incluye transformación de formatos, eliminación de duplicados, verificación de integridad referencial y validación de resultados.

La necesidad de Data Migration surge al actualizar un SGBD (por ejemplo, de MySQL 5.7 a MySQL 8.0), cambiar de proveedor en la nube, migrar de un monolito a microservicios o al pasar a un esquema NoSQL. Según Stripe (2024), el 89% de las empresas se enfrentan a la migración de datos al menos una vez cada dos años, y el 43% la considera la fase de actualización técnica más difícil.

Principales objetivos de la migración de datos

El primer objetivo es mejorar el rendimiento mediante la transición a una solución de almacenamiento más moderna. El segundo es reducir los costes operativos al cambiar de proveedor de infraestructura. El tercero es garantizar el cumplimiento normativo (GDPR, 152-FZ), cuando los datos deben almacenarse en una jurisdicción específica.

En qué se diferencia la migración de la integración

La integración implica una sincronización continua entre dos sistemas en funcionamiento. La migración es una transferencia única seguida del desmantelamiento del origen. La integración no elimina los datos en el origen; la migración finaliza con la transición del sistema de destino al estado primario. Esta diferencia fundamental determina la elección de herramientas y enfoques de validación.

Modelo ETL de migración de datos

La arquitectura básica de cualquier Data Migration se basa en el modelo ETL (Extract, Transform, Load). Extract: extracción de datos del origen. Transform: conversión al esquema de destino. Load: carga en el destino. Cada fase tiene sus propios métodos de control de calidad.

Extract: extracción de datos

En la fase de extracción, los datos se leen de la base de datos original, del almacenamiento de archivos o de la API. La extracción incremental (CDC — Change Data Capture) permite transferir solo los registros modificados, reduciendo el volumen de tráfico. El volcado completo es adecuado para volúmenes pequeños, pero para bases de datos de terabytes es preferible la replicación en streaming mediante Debezium o Kafka Connect.

Transform: transformación del esquema

La transformación incluye renombrar columnas, cambiar tipos de datos, normalizar valores y agregar. Por ejemplo, al migrar de MySQL a PostgreSQL, el tipo numérico DECIMAL debe convertirse a NUMERIC y el formato de fecha a ISO 8601. Según Talend (2024), el 70% del tiempo de migración se dedica a la transformación, no a la transferencia.

Load: carga en el destino

La carga se realiza por lotes (batch insert) o en streaming. Se utiliza una clave de idempotencia para eliminar duplicados. Después de la carga, es obligatoria una fase de validación: comparación del número de registros, cálculo de sumas de verificación y comprobación de reglas de negocio. Sin validación, la migración de datos se considera incompleta.

Estrategias de migración de datos

La elección de la estrategia de Data Migration determina el tiempo de inactividad del sistema, la complejidad de la reversión y el volumen de trabajo preparatorio. Las principales estrategias son Big Bang, Trickle y Parallel Run. Cada una es aplicable en diferentes escenarios.

Migración Big Bang

Big Bang es el apagado único del sistema antiguo, la transferencia de datos y el arranque del nuevo. Adecuado para volúmenes pequeños y esquemas simples. Riesgo: en caso de fallo, el sistema no está disponible hasta la recuperación completa desde la copia de seguridad. En 2024, GitLab utilizó Big Bang para migrar 5 TB de datos de AWS RDS a GCP Cloud SQL con una ventana de inactividad de 14 horas.

Migración Trickle

Trickle es una sincronización en streaming en pequeñas porciones. Los sistemas antiguo y nuevo funcionan en paralelo, los cambios se replican en tiempo real. Tras la estabilización de los datos, el origen antiguo se desconecta. Este enfoque requiere sincronización bidireccional y resolución de conflictos. Se utiliza en Continuous Delivery al actualizar el esquema de la base de datos sin tiempo de inactividad.

Parallel Run

Parallel Run — ambos sistemas funcionan simultáneamente, la aplicación escribe y lee de ambas fuentes. Tras la verificación de los datos en el destino, el origen antiguo se desconecta. Es la estrategia más segura, pero también la más cara: requiere mantener dos infraestructuras. Se utiliza al migrar sistemas financieros críticos.

Tipos de migración de datos

En el desarrollo de aplicaciones se distinguen varios tipos de Data Migration según el objeto de transferencia y el contexto. Cada tipo tiene su propia metodología y herramientas. Comprender el tipo es el primer paso para elegir la estrategia correcta.

Migración de base de datos (Database Migration)

La migración de base de datos es la transferencia entre SGBD de diferentes proveedores: de Oracle a PostgreSQL, de SQL Server a MySQL, de MongoDB a DynamoDB. La complejidad radica en la incompatibilidad de tipos de datos, dialectos SQL y mecanismos de indexación. Herramientas: AWS DMS, Debezium, Liquibase.

Migración de datos de aplicación (Application Data Migration)

Transferencia de datos entre diferentes versiones de una misma aplicación, por ejemplo, al actualizar el código con cambios en la estructura de las entidades. A menudo va acompañada de la ejecución de scripts de migración en el lenguaje de la aplicación: Active Record Migrations en Ruby on Rails, Flyway para Java, Entity Framework Migrations en .NET. Estos scripts transforman secuencialmente el esquema y los datos.

Migración en la nube (Cloud Data Migration)

Cloud Data Migration es la transferencia de datos desde una infraestructura local a la nube o entre nubes. AWS Snowball, Azure Data Box y Google Transfer Appliance se utilizan para el transporte físico de conjuntos de terabytes. Para la migración en línea se utilizan túneles VPN y replicación. Según Gartner, para 2027 el 70% de las migraciones se realizarán en un entorno de nube híbrida.

Planificación de la migración de datos

Data Migration sin un plan es un fracaso garantizado. La planificación incluye auditar el esquema actual, perfilar los datos, elegir la estrategia, preparar el entorno, probar y aprobar el plan de reversión. Según un estudio de McKinsey (2024), el 54% de las migraciones fallidas se deben a la ausencia de un plan formal.

Auditoría y perfilado

Antes de la migración, es necesario auditar el sistema de origen: determinar el volumen de datos, el número de tablas, las dependencias entre entidades, los tipos de campos anulables y la presencia de duplicados. El perfilado identifica anomalías: valores NULL en campos clave, discrepancias de formato, enlaces rotos. Estos datos forman la línea base del volcado completo.

Preparación del entorno de pruebas

Se realiza una migración de prueba sobre una copia de los datos de producción antes del lanzamiento principal. El objetivo es comprobar el rendimiento del pipeline ETL, la corrección de la transformación y la velocidad de carga. Se recomienda un mínimo de tres ciclos completos de prueba antes de Big Bang. Cada ciclo incluye una transferencia completa, validación y reversión.

Plan de reversión (Rollback)

La reversión es el retorno al sistema original cuando se detectan errores críticos. El plan de reversión incluye: una copia de seguridad completa del origen antes del inicio, scripts de recuperación del esquema, una instrucción paso a paso para reactivar el sistema antiguo y un plan de comunicación para notificar a los usuarios. Sin un plan de reversión aprobado, la migración de datos no debe lanzarse en producción.

Ejemplos de código de migración de datos

Consideremos un ejemplo práctico de Data Migration en Kotlin combinado con Flyway. El script de migración V1 crea una tabla de usuarios y transfiere datos desde un formato heredado. Flyway rastrea automáticamente las migraciones aplicadas y garantiza la idempotencia.

// V1__Migrate_Users.kt — migración de datos desde formato heredado
import org.flywaydb.core.api.migration.BaseJavaMigration
import java.sql.Connection
import java.sql.PreparedStatement

class V1__MigrateUsers : BaseJavaMigration() {
    override fun migrate(connection: Connection) {
        val legacyUsers = connection.prepareStatement(
            "SELECT id, name, legacy_role FROM users_legacy"
        ).executeQuery()

        val insertStmt: PreparedStatement = connection.prepareStatement(
            "INSERT INTO users (id, name, role, migrated_at) VALUES (?, ?, ?, NOW())"
        )

        while (legacyUsers.next()) {
            insertStmt.setInt(1, legacyUsers.getInt("id"))
            insertStmt.setString(2, legacyUsers.getString("name"))
            val role = mapLegacyRole(legacyUsers.getString("legacy_role"))
            insertStmt.setString(3, role)
            insertStmt.executeUpdate()
        }
    }
}

Un ejemplo de migración en Python usando SQLAlchemy para transferir datos de CSV a PostgreSQL. El script extrae del archivo, convierte tipos y carga las tablas de destino.

# migrate_data.py — cargando CSV en PostgreSQL con transformación
import pandas as pd
from sqlalchemy import create_engine

engine = create_engine("postgresql://user:pass@host/db")
df = pd.read_csv("legacy_orders.csv")

df["order_date"] = pd.to_datetime(df["order_date"])
df["amount"] = df["amount"].astype("float")
df.to_sql("orders", engine, if_exists="append", index=False)

print("Migración de datos completada")