Respuesta.

En la historia de la experiencia mundial en TI, las tareas de migración de datos a menudo se han convertido en fuentes de fallos inesperados: distorsión, pérdida o duplicación de información, especialmente en grandes contornos informáticos diversos (por ejemplo, al pasar de un monolito a microservicios o de una plataforma legada a soluciones modernas).

El problema radica en la falta de una representación unificada de la migración: los clientes o desarrolladores a menudo consideran esta tarea solo técnica, sin evaluar los riesgos para los procesos de negocio y sin trabajar los escenarios de casos fronterizos (desajuste de formatos de datos, estructuras, pérdida de reglas de negocio únicas en el antiguo sistema).

La solución radica en un enfoque sistemático:

Inventario completo de modelos de datos, incluyendo conexiones no evidentes y reglas de negocio.
Desarrollo de escenarios detallados de migración: qué sucede con los datos históricos, no actualizados, frágiles y dispares.
Inclusión obvia en la documentación de los requisitos de migración, incluyendo el orden de carga, métodos de reversión, verificación de la integridad y corrección de la transferencia.
Fijación de zonas de riesgo: qué no se migra, por qué y cómo se documenta.

Características clave:

Se requiere comunicación estrecha entre el analista de negocios, el arquitecto y el DBA.
Siempre se añade una etapa de validación de la migración (por ejemplo, replicación selectiva y posterior auditoría).
Documentación facetada (paso a paso): qué se migra completamente, qué parcialmente, qué requiere trabajo manual.

Preguntas trampa.

¿Se puede llevar a cabo la migración de datos sin la participación de las unidades de negocio, si "todo está en la base"?

No, sin la participación del negocio es imposible determinar la validez, criticidad y actualidad de los datos. Las antiguas reglas de negocio, incluso si no están formalmente descritas, pueden afectar el ciclo de vida de la información.

¿Es obligatorio conservar todos los campos del antiguo modelo de datos en el nuevo sistema?

No siempre: algunos campos pueden ser rudimentarios o haber perdido su significado. Sin embargo, esta decisión debe ser acordada y documentada, de lo contrario, existe el riesgo de incoherencia en los procesos de negocio.

¿Se puede limitar la migración a solo los datos "frescos"?

Esto depende de los requisitos comerciales. A menudo, los datos históricos son necesarios para informes, cumplimiento o auditoría. La migración selectiva sin acuerdo crea riesgos de pérdida de información legal u operativa.

Errores comunes y anti-patrones

Falta de especificación de la transformación de datos (qué campos se convierten y cómo).
Omisión de atributos que afectan a los procesos downstream.
Ignorar la necesidad de retesting y auditoría de migraciones.

Ejemplo de la vida real

Caso negativo: Un banco estaba migrando a un nuevo sistema CRM; los analistas no documentaron las interrelaciones entre la ciudad del cliente y las ventajas fiscales regionales. Esto llevó a errores en el cálculo de bonos.

Pros:

Implementación rápida de la solución.

Contras:

Miles de compensaciones a los clientes.
Riesgos legales y pérdida de confianza de los clientes.

Caso positivo: Antes de la migración, los analistas crearon un mapa detallado de atributos, llevaron a cabo una selección y extracción de datos piloto, probaron la corrección de cada transacción en clientes aleatorios, y acordaron todos los escenarios con el negocio y la auditoría.