Testing de Migración de Datos

Por Qué Importa el Testing de Migración de Datos #

La migración de datos mueve datos de un sistema a otro — frecuentemente de una base de datos legacy a una plataforma moderna. Son operaciones de alto riesgo porque:

• La pérdida de datos puede ser catastrófica e irreversible.
• Las diferencias de schema requieren transformaciones complejas.
• El downtime impacta directamente las operaciones del negocio.
• Los datos migrados pueden comportarse diferente en el nuevo sistema.

Tipos de Migración #

El Proceso de Testing de Migración #

Fase 1: Análisis Pre-Migración #

Antes de escribir tests, analiza la migración y crea un documento de mapeo.

Fase 2: Preparación de Datos de Test #

1. Identificar edge cases en datos fuente: valores NULL, caracteres especiales, strings de longitud máxima.
2. Muestrear datos representativos.
3. Crear registros de test conocidos con resultados esperados precalculados.

Fase 3: Tests de Ejecución de Migración #

Verificación de conteo de registros:

-- Antes de migración
SELECT COUNT(*) FROM legacy_db.users;
SELECT COUNT(*) FROM legacy_db.orders;

-- Después de migración
SELECT COUNT(*) FROM new_db.users;
SELECT COUNT(*) FROM new_db.orders;

Verificación de valores agregados:

SELECT SUM(order_total) FROM legacy_db.orders;
SELECT SUM(amount_usd) FROM new_db.orders;

Fase 4: Validación de Calidad de Datos #

Integridad referencial:

SELECT COUNT(*) FROM new_db.orders o
LEFT JOIN new_db.users u ON o.user_id = u.id
WHERE u.id IS NULL;
-- Esperado: 0

Correctitud de tipos de datos:

SELECT legacy_id, legacy_created_at, new_created_at
FROM migration_audit
WHERE ABS(EXTRACT(EPOCH FROM legacy_created_at - new_created_at)) > 1;
-- Esperado: 0 filas

Fase 5: Validación de Aplicación #

Después de migrar datos, prueba la aplicación contra los datos migrados:

1. ¿Pueden los usuarios iniciar sesión con credenciales existentes?
2. ¿Se muestran correctamente los pedidos existentes?
3. ¿Pueden los usuarios realizar nuevas operaciones?
4. ¿Los reportes generan números correctos?

Testing de Estrategia de Rollback #

Toda migración necesita un plan de rollback probado:

1. Verificación de backup: Restaurar en ambiente de test.
2. Script de rollback: Probar que revierte correctamente.
3. Punto de no retorno: Identificar cuándo el rollback ya no es factible.
4. Tiempo de rollback: Medir duración.

Testing de Rendimiento #

Migraciones en datasets grandes pueden tomar horas. Prueba con datos a escala de producción.

Ejercicio: Plan de Testing de Migración de Datos #

Escenario #

Tu empresa migra de una base PostgreSQL legacy a un nuevo sistema con 2 millones de usuarios, 8 millones de pedidos y 25 millones de items.

Tarea 1: Crear Documento de Mapeo #

Crea un mapeo completo campo-por-campo entre schemas legacy y nuevos.

Tarea 2: Escribir Queries de Verificación #

Escribe queries SQL para verificar:

1. Todos los usuarios legacy existen en el nuevo sistema.
2. Los nombres se dividieron correctamente.
3. Los códigos de estado se mapearon correctamente.
4. Las fechas se convirtieron de string a timestamp correctamente.
5. Los montos se convirtieron a USD con tasa correcta.
6. Todas las relaciones foreign key están intactas.

Tarea 3: Datos de Test de Edge Cases #

Crea registros que cubran edge cases: nombre NULL, nombre complejo, caracteres no-ASCII, monto cero, fecha bisiesta, moneda sin tasa de cambio.

Tarea 4: Plan de Rollback #

Documenta: qué se respalda, cómo se restaura, cuál es el punto de no retorno, cuánto toma el rollback, cuál es el plan de comunicación.

Entregables #

1. Documento de mapeo completo campo-por-campo.
2. Queries SQL de verificación con resultados esperados.
3. Datos de test de edge cases con resultados esperados.
4. Documento de plan de rollback.