Guía de la estrategia de migración de datos

La migración de datos es el proceso de mover los datos de una ubicación de almacenamiento a otra, ya sea de un centro de datos local a la nube, entre plataformas de bases de datos o de cabinas de almacenamiento tradicionales a una infraestructura moderna. La ejecución de una migración sin una estrategia clara puede dar lugar a un exceso presupuestario, una pérdida de datos y una interrupción de las operaciones empresariales.

Hay mucho en juego. Según un estudio de Oracle, más del 80% de los proyectos de migración de datos pasan con el tiempo y por encima del presupuesto. Esa cifra no ha mejorado mucho con los años, no porque la tecnología sea insuficiente, sino porque las organizaciones subestiman la planificación, el trabajo de calidad de los datos y la gestión de riesgos que exigen las migraciones exitosas.

Esta guía le explica todo lo relacionado con una estrategia de migración de datos: cómo funcionan las migraciones, qué enfoque se adapta a su situación, los riesgos que hay que planificar y un marco de proyecto paso a paso para mantener su migración en el buen camino.

Decidir pasarse a un nuevo sistema nunca es fácil. Pero cuando su entorno actual ya no satisface sus necesidades —ya sea debido a limitaciones de capacidad, limitaciones de rendimiento, cambios en las licencias o un cambio a la infraestructura de la nube—, la migración se vuelve inevitable. La pregunta es cómo abordarlo sin crear más problemas de los que resuelve.

Una estrategia de migración de datos sólida le proporciona un camino estructurado desde la planificación hasta el desmantelamiento. Aborda la mecánica técnica del movimiento de los datos, los riesgos empresariales implicados y los procesos de gobernanza necesarios para mantener los datos precisos y accesibles durante toda la transición.

La migración de datos es el proceso de mover los datos de una ubicación de almacenamiento a otra, incluidos los pasos de planificación, asignación, extracción y formateo necesarios para garantizar que los datos sean accesibles y precisos en el nuevo entorno. Abarca la transferencia de bases de datos, archivos, aplicaciones y cargas de trabajo completas entre sistemas que pueden diferir en formato, estructura o plataforma.

Poder migrar los datos de manera eficiente se ha vuelto fundamental, ya que las organizaciones manejan exponencialmente más datos en entornos más diversos. Lo que antes significaba copiar una base de datos de un servidor a otro ahora suele implicar plataformas en la nube, arquitecturas distribuidas y requisitos de cumplimiento normativo que añaden una complejidad significativa.

La mayoría de las migraciones de datos siguen un proceso ETL general —extraer, transformar, cargar—, aunque los detalles específicos varían en función de los entornos de origen y de destino. En esencia, la migración implica estos pasos:

• Analizar los datos que desea migrar para identificar los problemas de compatibilidad entre los entornos de origen y de destino, incluidas las diferencias de esquema, las discrepancias de tipo de datos y las incoherencias de codificación.
• Asignar campos de origen a sus equivalentes de destino. Una buena documentación de asignación de datos es esencial para detectar los errores de transformación antes de que lleguen a la producción.
• Realizar una copia de seguridad de todos los datos antes de que comience la migración. Esto no es negociable. Sin una copia de seguridad verificada, una migración fallida puede significar una pérdida permanente de datos.
• Pruebe su lógica de migración comparándola con una copia del entorno de producción para validar la precisión de los datos en el sistema de destino antes de comprometerse.
• Extracción de datos del sistema de origen usando un cargador de datos o una aplicación ETL.
• Transformar los datos cuando sea necesario para cumplir los requisitos de formato, esquema o calidad de los datos del sistema de destino.
• Carga de los datos transformados en el entorno de destino.
• Verificar que los datos transferidos son completos, precisos y accesibles, incluidos los recuentos de filas, las sumas de comprobación y las pruebas a nivel de aplicación.

Los pasos de asignación y prueba son los que hacen que la mayoría de las migraciones tengan problemas. Las organizaciones que tratan la migración como una operación de copia pura, omitiendo la creación y la validación rigurosas de perfiles de datos, tienden a descubrir problemas de calidad de los datos solo después de la transición, cuando son más difíciles de corregir.

Estos son los riesgos más comunes asociados con las migraciones de datos y por qué cada uno de ellos debe abordarse explícitamente en su estrategia.

1. Superar el presupuesto

Según un informe de Oracle sobre la migración de datos, los costes superan la media del 30% y el tiempo supera la media del 41% en todos los proyectos de migración de datos. Estos excesos casi siempre se remontan a la subestimación de la complejidad de los datos fuente —específicamente, la cantidad de trabajo de limpieza y transformación que se necesita una vez que comienza la elaboración real de perfiles de datos—.

La otra causa común de que el presupuesto se sobrecargue es la fluencia del alcance. Las migraciones suelen revelar dependencias, integraciones y problemas de calidad de los datos que no eran visibles durante el alcance inicial. Cada descubrimiento añade un trabajo que no estaba presupuestado. Las organizaciones que incorporan contingencias en sus presupuestos de migración —normalmente del 20% al 25% por encima de la estimación inicial— manejan estos descubrimientos sin desbaratar el proyecto. Aquellos que no acaban recortando los límites o buscando una aprobación presupuestaria adicional a mitad del proyecto, lo que introduce sus propios riesgos.

2. de pérdida de datos

La pérdida de datos es un resultado común de las migraciones que omiten o aceleran la fase de copia de seguridad. Cada plan de migración debe incluir una estrategia de copia de seguridad verificada y probada antes de que se muevan los datos. Esto significa no solo crear una copia de seguridad, sino también confirmar que puede restaurarla a partir de ella.

La distinción es más importante de lo que parece. Muchas organizaciones descubren durante un intento real de restauración que su copia de seguridad está incompleta, dañada o es incompatible con el entorno de destino. Una copia de seguridad que nunca se ha probado no es una copia de seguridad, sino una suposición. Las pruebas de restauración deben ser un requisito formal de aprobación antes de que comience la ejecución de la migración, no una idea posterior programada para después de la transición.

3. Interrupciones

Sin la georreplicación o las arquitecturas de ejecución paralela, la migración de datos suele requerir desconectar los sistemas. Esto afecta al rendimiento de las aplicaciones y al acceso de los usuarios. El enfoque de migración que elija —Big Bang, goteo o cero tiempos de inactividad— determina en gran medida cuánto tiempo de inactividad debe absorber su empresa.

Las estimaciones de tiempo de inactividad también tienen una manera de ser optimistas. Una ventana de migración proyectada a las cuatro horas puede ampliarse a 12 si los volúmenes de datos son mayores de lo esperado, la lógica de transformación se ejecuta más lentamente de lo probado o los problemas de superficie de los pasos de validación deben resolverse antes de que pueda procederse con la transición. La comunicación de una estimación realista de los tiempos de inactividad —y la incorporación de un búfer en la ventana de mantenimiento— impide el tipo de presión de mitad de la migración que genera malas decisiones sobre si continuar o revertir.

4. Corrupción de los datos

La corrupción de los datos se produce cuando los datos innecesarios, malformados o incompatibles se transfieren al nuevo sistema. Los datos dañados pueden provocar fallos en las aplicaciones y producir resultados inexactos que a veces son más difíciles de detectar que la pérdida total de datos —un registro que falta es obvio, pero un registro con valores sutilmente incorrectos puede pasar desapercibido durante semanas.

Las fuentes comunes de corrupción incluyen las discordancias de codificación de caracteres entre los sistemas de origen y de destino, las conversiones de tipos de datos que truncan o transforman valores de manera silenciosa y la lógica de transformación que maneja los casos perimetrales de manera incorrecta. La limpieza rigurosa de los datos antes de la migración y la validación después de la transición son las defensas principales. La validación debe incluir tanto comprobaciones técnicas —recuentos de filas, sumas de comprobación, verificación de limitaciones— como pruebas a nivel de aplicación que confirmen que los datos se comportan correctamente en el contexto de los procesos empresariales reales.

5. Gravedad de los datos

La gravedad de los datos se refiere a la tendencia de los datos a acumular dependencias —aplicaciones, servicios y otros conjuntos de datos que se conectan a ellos con el tiempo—. Cuanta más gravedad tiene un conjunto de datos, más difícil es moverse sin interrumpir esas dependencias. Las organizaciones suelen descubrir la gravedad de los datos en mitad de la migración cuando mover una base de datos también requiere la reconfiguración de docenas de servicios conectados.

Este riesgo es especialmente pronunciado en entornos que han crecido orgánicamente durante muchos años. Las integraciones se crean, las API se codifican de manera rígida con cadenas de conexión y las herramientas de creación de informes se dirigen a fuentes de datos específicas —a menudo sin documentación centralizada—. Un ejercicio exhaustivo de asignación de dependencias durante el análisis del paisaje es la mejor manera de sacar a la luz estas conexiones antes de que se conviertan en sorpresas de un día de transición. Cada aplicación, servicio y trabajo programado que toca los datos que se están migrando tiene que identificarse, probarse y actualizarse como parte del plan de migración.

6. La poca calidad de los datos

Los problemas de calidad de los datos —el duplicado de registros, el formateo incoherente, los valores faltantes y los datos obsoletos— no desaparecen cuando migra. Llegan al sistema de destino y se convierten en los problemas de su nuevo sistema. Una revisión y un proceso de limpieza de la gobernanza de los datos previos a la migración es la única manera fiable de ayudar a prevenirlo. Las organizaciones que omiten la elaboración de perfiles de datos antes de la migración dedican de manera constante más tiempo a la limpieza posterior a la migración del que habrían dedicado a la limpieza inicial —y lo gastan en peores condiciones—, ya que los usuarios ya están en el nuevo sistema y en las operaciones empresariales, en función de los datos que aún no son fiables. El hecho de tratar la migración como una oportunidad para mejorar la calidad de los datos, en lugar de solo moverla, produce unos resultados significativamente mejores por el otro lado.

Su estrategia de migración define el modo en que los datos pasan de origen a destino: todo a la vez, por fases o sin interrupciones perceptibles. El enfoque adecuado depende de su tolerancia al tiempo de inactividad, de la complejidad de su entorno y de la importancia de los sistemas que se están migrando.

1. Migración Big Bang

Una migración Big Bang transfiere todos los datos en una sola operación, normalmente durante una ventana de mantenimiento programada. Los sistemas se desconectan, el procesamiento ETL se ejecuta y el sistema de destino genera el conjunto de datos completo.

La ventaja es la simplicidad y la velocidad —no hay necesidad de mantener sistemas paralelos ni de gestionar la sincronización de datos—. La desventaja es la exposición al riesgo: Si la migración falla a mitad de camino, puede enfrentarse a una reversión o a un tiempo de inactividad prolongado. Big Bang funciona bien con conjuntos de datos más pequeños, sistemas con ventanas de mantenimiento naturales y organizaciones en las que es aceptable un breve tiempo de inactividad.

2. Migración de Trickle

En una migración complicada, los datos se mueven por fases, mientras que tanto los sistemas antiguos como los nuevos funcionan en paralelo. El sistema de origen permanece activo durante la migración, lo que elimina los tiempos de inactividad de los usuarios. Las herramientas de sincronización de datos mantienen ambos entornos homogéneos durante el periodo de transición.

Las migraciones difíciles son más complejas de ejecutar. Para ejecutar los sistemas paralelos se necesita una infraestructura adicional, una lógica de sincronización cuidadosa y un punto de transición definido en el que el nuevo sistema se convierte en autorizado. Pero para los entornos de misión crítica, esta complejidad añadida suele ser la compensación adecuada.

3. Migración sin interrupciones

La migración sin tiempos de inactividad es una extensión del enfoque complicado que utiliza la replicación continua y una transición casi instantánea para eliminar cualquier interrupción del servicio. En lugar de una ventana de mantenimiento planificado, la transición se produce cuando el sistema de destino alcanza la paridad con la fuente. Este enfoque es cada vez más común en las organizaciones con requisitos de disponibilidad las 24X7 de la semana o compromisos de SLA que prohíben cualquier tiempo de inactividad.

La complejidad de las migraciones sin interrupciones es la más alta de los tres enfoques, pero el riesgo de disrupción de la empresa es menor. Las plataformas modernas de almacenamiento y bases de datos han hecho que este enfoque sea más accesible —herramientas como la georreplicación y el clúster activo-activo admiten la sincronización continua a escala—.

La mayoría de las migraciones empresariales no encajan perfectamente en una única categoría. Un patrón común es usar un enfoque de goteo o de cero tiempos de inactividad para las bases de datos de producción activas, mientras se usa Big Bang para los datos de archivo que pueden tolerar una breve indisponibilidad.

El tipo de migración está determinado por lo que se mueve y los entornos implicados. Cada tipo tiene sus propias consideraciones técnicas, modos de fallo y requisitos de planificación. Entender qué tipo —o combinación de tipos— se aplica a su proyecto es una de las primeras decisiones que su estrategia de migración tiene que tomar.

Migraciones de bases de datos

Una migración de base de datos transfiere datos o aplicaciones entre dos sistemas de base de datos, ya sea para cambiar de proveedor o para actualizar el software de la base de datos. Los desencadenantes más comunes son los anuncios de fin de vida de un proveedor de bases de datos, los cambios en los costes de las licencias, las limitaciones de rendimiento de la plataforma actual o el cambio a alternativas de código abierto.

Las diferencias de esquema son la fuente principal de complejidad. Dos bases de datos pueden almacenar datos conceptualmente similares de maneras estructuralmente incompatibles, como: 

• Diferentes tipos de datos
• Convenciones de nomenclatura
• Reglas de restricción
• Enfoques de indexación

Los procedimientos almacenados y las funciones personalizadas escritas en el dialecto de una base de datos suelen requerir la reescritura del sistema de destino.

Las dependencias de las aplicaciones agravan el reto. La mayoría de las bases de datos de producción son utilizadas por múltiples aplicaciones que leen y escriben en ellas. Cada una de esas aplicaciones tiene que probarse con la base de datos de destino antes de la transición y cualquier consulta que se base en un comportamiento específico del proveedor tiene que identificarse y reescribirse. La falta de este paso es una de las razones más comunes por las que las migraciones de bases de datos fallan en la validación después del hecho.

A qué hay que prestar atención:

• Conversiones implícitas de tipo de datos que se comportan de manera diferente entre plataformas
• Diferencias de codificación de caracteres (UTF-8 frente a Latin-1, por ejemplo) que corrompen los datos de texto
• Secuenciar e incrementar automáticamente los comportamientos que no se transfieren limpiamente entre proveedores.
• Activadores y procedimientos almacenados escritos en dialectos SQL específicos del proveedor

Migraciones a la nube

Las migraciones a la nube mueven los datos o las aplicaciones de los entornos locales a la infraestructura de la nube o entre los proveedores de la nube. A menudo son los de mayor alcance y el tipo de migración más complejo desde el punto de vista organizativo, porque suelen implicar migraciones de bases de datos, migraciones de almacenamiento y migraciones de aplicaciones que se ejecutan en paralelo.

Las migraciones Lift-and-shift —trasladar las cargas de trabajo a la nube con una modificación mínima— son las más rápidas de ejecutar, pero a menudo dejan los problemas de rendimiento y costes en marcha. El cambio de plataforma o la refactorización de las cargas de trabajo para aprovechar los servicios nativos de la nube aumenta la complejidad de la migración, pero normalmente produce mejores resultados a largo plazo.

Los requisitos de cumplimiento normativo, las reglas de residencia de datos y la latencia de red añaden dimensiones a las que no se enfrentan las migraciones puramente locales. El RGPD, la HIPAA y otras normativas pueden restringir dónde pueden transitar o residir los datos, incluso temporalmente. Para las organizaciones que mueven grandes conjuntos de datos, el ancho de banda de la red puede convertirse en un auténtico cuello de botella —algunas migraciones son más rápidas y baratas usando servicios de transferencia de datos físicos que la transmisión por cable.

Las migraciones de nube a nube (el paso entre AWS, Microsoft Azure y Google Cloud, por ejemplo) son cada vez más comunes a medida que las organizaciones reevalúan las relaciones con los proveedores o consolidan los entornos multinube. Estas migraciones requieren comprender las dependencias de servicio propias que se han acumulado en la nube de origen, las API de almacenamiento de objetos, los servicios de base de datos gestionada, las funciones sin servidor y determinar si existen servicios equivalentes en el destino.

A qué hay que prestar atención:

• Costes de salida que inflan significativamente el presupuesto de migración
• Dependencias de servicio propias que no tienen equivalente directo en el proveedor objetivo
• La residencia de los datos entra en conflicto con los requisitos de cumplimiento normativo
• Impactos de latencia en las aplicaciones diseñadas para el acceso local de baja latencia

Migraciones de almacenamiento

Las migraciones de almacenamiento mueven los datos de las cabinas de almacenamiento existentes al nuevo hardware. Se encuentran entre los tipos de migración más comunes en los entornos empresariales, impulsados por los ciclos de renovación del hardware, las necesidades de ampliación de la capacidad y el cambio del disco giratorio a las arquitecturas totalmente flash.

A diferencia de las migraciones de bases de datos o aplicaciones, las migraciones de almacenamiento no implican intrínsecamente la transformación de datos. El formato de los datos no cambia; está moviendo bloques o archivos de una ubicación física a otra. Pero el riesgo operativo es igual de real. Cualquier migración de cabina de almacenamiento que interrumpa el acceso a los datos de producción afecta a todas las aplicaciones y usuarios, en función de ese almacenamiento.

Las migraciones basadas en host utilizan software que se ejecuta en el servidor para copiar los datos del almacenamiento de origen al de destino. Son flexibles y no necesitan hardware especializado, pero consumen recursos de CPU y memoria de servidor durante la migración. Las migraciones basadas en matrices utilizan capacidades de replicación integradas en el hardware de almacenamiento, que normalmente producen menos sobrecargas del lado del host y admiten una transición no disruptiva.

Para las organizaciones que utilizan cabinas totalmente flash, las migraciones de almacenamiento suelen coincidir con un esfuerzo más amplio de modernización de la infraestructura. El paso del almacenamiento de disco híbrido o giratorio a all-flash cambia significativamente las características de rendimiento — las aplicaciones que se han ajustado para un almacenamiento de mayor latencia pueden necesitar una reconfiguración para aprovechar al máximo el nuevo entorno.

A qué hay que prestar atención:

• Configuración multirruta de host que necesita actualizarse cuando cambian los objetivos de almacenamiento
• Aplicaciones con rutas de almacenamiento codificadas que se rompen después de la migración
• Diferencias de rendimiento entre las cabinas de origen y de destino que afectan al comportamiento de las aplicaciones
• Planificación de la capacidad que tiene en cuenta las diferentes ratios de reducción de datos entre el hardware antiguo y el nuevo.

Migraciones de aplicaciones

Las migraciones de aplicaciones mueven las aplicaciones entre entornos, localmente a la nube, de nube a nube o a una nueva plataforma SaaS. Son el tipo de migración más complejo que hay que planificar y ejecutar, porque casi siempre desencadenan migraciones de bases de datos y almacenamiento como dependencias.

La complejidad se agrava rápidamente. La migración de un sistema ERP, por ejemplo, puede requerir la migración de su base de datos subyacente, el almacenamiento en el que se ejecuta, los servicios de red de los que depende y las integraciones que mantiene con otras aplicaciones, cada una de las cuales tiene sus propios requisitos de migración y limitaciones de secuenciación.

Las migraciones de aplicaciones también conllevan el mayor riesgo empresarial de cualquier tipo de migración, porque afectan directamente a los usuarios y a los procesos empresariales. Una migración de almacenamiento incorrecta es un problema de infraestructura. Una migración de aplicaciones mal realizada interrumpe los flujos de trabajo de los que las personas dependen para realizar su trabajo.

Las migraciones de SaaS, que pasan de una aplicación autogestionada a un servicio de nube gestionado por el proveedor, plantean un conjunto diferente de retos. A menudo se pasa a un entorno multiusuario con opciones de personalización limitadas, lo que significa evaluar si la plataforma de destino puede soportar realmente sus flujos de trabajo actuales antes de que se mueva cualquier dato.

A qué hay que prestar atención:

• Integraciones de terceros que se conectan a la aplicación a través de API documentadas o no documentadas.
• Dependencias de autenticación de usuario (LDAP, Active Directory) que tienen que replicarse o migrarse
• Configuraciones y extensiones personalizadas que pueden no transferirse al entorno de destino
• Requisitos de formación del usuario final que deben tenerse en cuenta en el calendario del proyecto

Entender estas dependencias es importante para la secuenciación. Las migraciones de almacenamiento generalmente tienen que completarse antes de poder validar las migraciones de aplicaciones. Las migraciones de bases de datos tienen que ejecutarse antes de la transición de la aplicación. Tratarlos como flujos de trabajo independientes en lugar de como una secuencia dependiente puede generar problemas inesperados en la transición.

La calidad de los datos es el factor más ignorado en la planificación de la migración. Las organizaciones descubren constantemente en mitad de la migración que sus datos fuente contienen duplicados, un formato incoherente, registros huérfanos y valores faltantes que no eran visibles hasta que los datos tenían que ajustarse a un nuevo esquema.

Una evaluación previa a la migración debe incluir tres componentes:

• Elaboración de perfiles de datos: Análisis sistemático de los datos fuente para identificar problemas de calidad, distribuciones de tipos de datos, tasas nulas e infracciones de limitaciones. La creación de perfiles le proporciona una imagen precisa de lo que realmente está migrando, no de lo que cree que está migrando.
• Limpieza de datos: Resolver los problemas identificados durante la elaboración de perfiles antes de que comience la migración. Esto incluye la deduplicación, la estandarización de los formatos, la corrección de los problemas de codificación y la eliminación o el archivado de los registros obsoletos.
• Validación del mapeo de origen a destino: Confirmar que cada campo de origen tiene un destino de destino válido, que los tipos de datos son compatibles y que la lógica de transformación está documentada y probada.

El resultado de esta evaluación debe ser un informe de calidad de los datos que las partes interesadas firmen antes de que se muevan los datos. Esto genera responsabilidad y evita el escenario común en el que los problemas de calidad de los datos descubiertos después de la migración se culpan a la propia migración en lugar de a los problemas de datos de origen preexistentes.

Las migraciones de datos crean ventanas temporales de alto riesgo. Los datos en tránsito entre sistemas son potencialmente más vulnerables que los datos en REST en un entorno conocido y seguro. Cualquier estrategia de migración que gestione datos regulados —información personal, registros financieros, datos sanitarios— tiene que abordar explícitamente los requisitos de cumplimiento.

Las consideraciones de seguridad clave para las migraciones incluyen:

• Cifrado en tránsito: Asegúrese de que los datos están cifrados en toda la canalización de migración. Esto se aplica tanto a las transferencias de red como a cualquier entorno de ensayo intermedio.
• Controles de acceso: Restrinja el acceso al sistema de migración solo al personal autorizado. Los permisos temporales elevados concedidos con fines de migración deben revocarse inmediatamente después de su finalización.
• Registro de auditoría: Mantener registros detallados de todos los accesos y movimientos de datos durante el periodo de migración. Estos registros sirven tanto como registros operativos como documentación de cumplimiento.
• Residencia de los datos: En el caso de las organizaciones sujetas al RGPD, la HIPAA u otras normativas de gobernanza de datos, confirme que los datos no transitan ni residen temporalmente en jurisdicciones no conformes durante la migración.
• Política de reversión: Defina las condiciones en las que revertiría la migración y verifique que una reversión es técnicamente factible antes de la transición. Un plan de reversión que solo existe en papel no es un plan de reversión.

Los requisitos de cumplimiento normativo deben revisarse y documentarse durante la fase de planificación previa a la migración, no descubrirse durante la ejecución. La participación temprana de sus equipos de seguridad y cumplimiento ayuda a prevenir las retenciones de última hora que pueden convertir una migración de dos semanas en un proyecto de tres meses.

Todas las migraciones de datos implican alguna forma de ETL, pero la forma exacta de su plan de migración depende de las necesidades únicas de su empresa. Los pasos anteriores —perfil de datos, selección de estrategia, revisión de seguridad— deben introducirse en un plan de migración formal antes de que comience cualquier ejecución.

Un plan de migración debe especificar el alcance de los datos que se mueven, la estrategia de migración elegida y por qué, la política de reversión, los criterios de prueba para la validación, los plazos de comunicación de las partes interesadas y el plan de desmantelamiento del entorno de origen.

Un plan de proyecto de migración del centro de datos mantiene su migración a tiempo y dentro del presupuesto. Aquí tiene un marco paso a paso basado en la metodología de migración establecida:

1. Planificación previa a la migración

Realizar una evaluación del impacto previa a la migración para verificar el coste real de la migración. Examine si las estimaciones de costes se basan en análisis concretos o conjeturas —las cifras presupuestarias obtenidas de las estimaciones de los proveedores o de las medias del sector sin referencia a su entorno específico probablemente sean inexactas—. Informe a los ejecutivos y a la TI sobre su participación necesaria, incluidos los compromisos de tiempo que tienden a subestimarse hasta que ya están vencidos.

Consiga la aprobación formal de la gobernanza de la seguridad antes de empezar cualquier trabajo técnico. Determine la estructura de entrega del proyecto (ágil frente a cascada), defina los roles y la autoridad para la toma de decisiones, diseñe un plan de formación y confirme su política de gestión de la configuración. El objetivo de esta fase es asegurarse de que todo el mundo está de acuerdo con lo que se está haciendo y quién es responsable antes de que alguien toque un sistema.

2. Inicio del proyecto

Asegúrese de que su back-office está en orden. Cree un plan de comunicación con las partes interesadas que especifique quién recibe las actualizaciones, con qué frecuencia y a través de qué canal. Configure su plataforma de colaboración de proyectos, formalice acuerdos con proveedores externos y defina los requisitos de hardware y software para las fases posteriores.

No se salte los acuerdos con los proveedores. Las migraciones se paran de manera rutinaria porque no había un contrato de proveedor cuando se necesitaba hardware o licencias. Conseguir que estos se completen de manera anticipada ayuda a eliminar una posible fuente de retraso.

3. Análisis del panorama

El análisis del panorama es la fase más importante de la planificación de la migración, porque determina lo que realmente está migrando, no lo que supone que está migrando. Estas dos cosas rara vez son las mismas.

Cree un diccionario de datos detallado, una especificación de mapeo de fuente a destino de alto nivel y un informe de alcance. Determine la volumétrica (cuántos datos, cuántos registros, cuántas dependencias), establezca un proceso de gestión de la calidad de los datos, cree un registro de riesgos y refina las estimaciones del proyecto basándose en lo que descubre. Las estimaciones generadas antes del análisis del paisaje son marcadores de posición. Las estimaciones generadas después son compromisos.

4. Diseño de la solución

Mapee las transformaciones de fuente a objetivo en detalle y produzca el diseño final para la construcción. Esta fase produce los artefactos con los que trabajará el equipo de compilación: especificaciones detalladas del diseño del mapeo, una especificación del diseño de la interfaz y una especificación de gestión de la calidad de los datos.

Defina los requisitos del hardware de producción y acuerde acuerdos de nivel de servicio para la migración en sí, no solo para el entorno de destino después de la transición. Las migraciones tienen sus propios requisitos de rendimiento y disponibilidad que deben documentarse y acordarse antes de que comience la ejecución.

5. Desarrollo y pruebas

Implemente su arquitectura de migración y pruébela con un espejo del entorno en vivo, no con una pequeña muestra. Las pruebas con una fracción de los datos de producción con frecuencia no logran detectar problemas de rendimiento y escalabilidad que solo aparecen a volumen completo. Documente la lógica de migración en su totalidad para que cualquier miembro del equipo pueda ejecutar o resolver la migración sin depender del conocimiento institucional que posea una persona.

Desarrolle un motor de validación para confirmar de manera independiente la precisión de los datos en el sistema de destino. Establecer una supervisión continua de la calidad de los datos, crear una política de recuperación y completar la formación de ejecución. El equipo que ejecuta la migración el día de la transición debería haberla ensayado, no debería estar ejecutándola por primera vez bajo presión.

6. Migración y validación

Ejecute la migración usando el enfoque que haya elegido: Big Bang, goteo o cero tiempos de inactividad. La validación no es una formalidad en esta fase, sino que son los criterios los que determinan si la migración se ha completado realmente. Confirme de manera independiente que los recuentos de filas, las sumas de comprobación y las pruebas a nivel de aplicación se superan antes de declarar el éxito.

Demostrar el cumplimiento normativo a los auditores y patrocinadores empresariales como parte de esta fase, no después. Si la documentación de cumplimiento es una idea posterior, espere que genere retrasos en el lanzamiento del nuevo entorno.

7. Desmantelamiento y supervisión

Retire el entorno tradicional solo después de que el sistema de destino haya sido validado y esté funcionando de manera estable bajo carga de producción. La ejecución de ambos entornos indefinidamente añade costes y genera un riesgo de sincronización, pero si se corta demasiado pronto antes de confirmar la estabilidad se crea un conjunto de problemas diferente.

Transfiera las responsabilidades de supervisión de la calidad de los datos al equipo adecuado y documente explícitamente la transferencia. Complete una validación de retirada del sistema y documente el proceso de desmantelamiento con fines de auditoría. Las migraciones que acaban en la transición sin una fase formal de desmantelamiento tienden a dejar los sistemas huérfanos funcionando más tiempo del previsto, a menudo a un coste real de la infraestructura.

Las organizaciones que ejecutan migraciones con éxito tienden a compartir unas pocas prácticas comunes que las que luchan tienden a saltarse.

• Empiece con una auditoría de datos, no con un plan de migración. Entender el estado real de sus datos fuente —problemas de calidad, dependencias, volumen— debe preceder a cualquier planificación estratégica. Las migraciones dentro del alcance antes de la elaboración de perfiles de datos casi siempre requieren una reescrutinio a mitad de proyecto.
• Nunca migre datos que no necesite. Las migraciones son una oportunidad para archivar o eliminar datos que ya no tienen un propósito empresarial. El traslado de datos innecesarios añade costes, tiempo y riesgos sin retorno.
• Pruebe con datos a escala de producción. Las pruebas realizadas con una pequeña muestra con frecuencia no logran detectar problemas de rendimiento y escalabilidad que solo aparecen en el volumen de producción completo. Si su ETL de migración tarda dos horas en probarse, espere que tarde 20 horas con todos los datos de producción.
• Defina los criterios de éxito antes de la transición. Sepa exactamente lo que significa la "migración exitosa" antes de empezar: recuentos de filas específicos, comprobaciones de integridad, pruebas de funcionalidad de las aplicaciones. Sin criterios definidos, no hay una base objetiva para declarar que la migración ha finalizado.
• Comunicarse con los usuarios afectados. Los usuarios finales y los propietarios de las aplicaciones tienen que saber qué está cambiando, cuándo y qué hacer si tienen problemas después de la transición. Una mala comunicación convierte los éxitos técnicos en problemas organizativos.
• Planifique la reversión antes de que la necesite. Los planes de reversión deben probarse, no solo documentarse. Saber que su procedimiento de reversión es técnicamente sólido reduce significativamente la presión de la ventana de transición.

La migración de datos está evolucionando de una actividad basada en proyectos a una capacidad operativa continua. A medida que las organizaciones adoptan estrategias multinube y mueven las cargas de trabajo dinámicamente entre entornos, la distinción entre la «migración» y la «gestión de datos rutinaria» se está difuminando.

La automatización está impulsando este cambio. Las herramientas de creación de perfiles de datos asistidas por IA ahora pueden identificar problemas de calidad y sugerir reglas de transformación sin análisis manuales. Las plataformas de migración inteligente pueden supervisar la sincronización de datos en tiempo real y señalar anomalías durante las migraciones complicadas antes de que se conviertan en problemas. Las plataformas de almacenamiento basadas en arquitecturas de estructura de datos admiten cada vez más la movilidad de datos no disruptiva como capacidad nativa en lugar de como un procedimiento excepcional.

Las organizaciones que incorporen la preparación para la migración en su infraestructura de datos, en lugar de tratarla como una capacidad única, tendrán una ventaja estructural a medida que los entornos de datos sigan evolucionando. El mejor momento para establecer las prácticas y las herramientas de migración es antes de que se anuncie la siguiente migración.

El almacenamiento de datos es un elemento fundamental de cada migración. Sin una infraestructura de almacenamiento que admita un movimiento de datos no disruptivo, las organizaciones se enfrentan a una opción difícil entre tiempos de inactividad prolongados y soluciones alternativas complejas.

Basadas en la arquitectura Evergreen®, las ofertas de suscripción Everpure se han diseñado para facilitar y hacer que las migraciones de datos sean más asequibles, al eliminar los ciclos de actualización y las ventanas de mantenimiento que las cabinas de almacenamiento tradicionales necesitan:

• Evergreen//One™ reduce la complejidad y el coste de la administración y el soporte del almacenamiento, proporcionando flexibilidad financiera y simplicidad operativa y mitigando al mismo tiempo los riesgos informáticos.
• Evergreen//Flex™ le proporciona la flexibilidad de responder a los cambios en la demanda y el uso, aumentar la agilidad del almacenamiento y maximizar el ROI del uso de la capacidad con unos costes iniciales más bajos.
• Evergreen//Forever™ proporciona una agilidad informática real —compre su almacenamiento una vez y escale de manera no disruptiva, sin penalizaciones, indefinidamente—.

Para las organizaciones que migran a o entre entornos de nube, la plataforma de almacenamiento unificado Everpure admite la resiliencia y la continuidad de los datos durante todo el ciclo de vida de la migración. El resultado son las migraciones que son menos disruptivas, más previsibles y menos propensas a convertirse en los costes y los excesos de programación que caracterizan la mayoría de los proyectos de migración.

Explore la cartera Everpure Evergreen para descubrir cómo la infraestructura de almacenamiento creada expresamente puede simplificar su próxima migración de datos.