Guía de estrategia de migración de datos

La migración de datos es el proceso de mover datos de una ubicación de almacenamiento a otra, ya sea de un centro de datos en las instalaciones a la nube, entre plataformas de bases de datos o de matrices de almacenamiento heredadas a una infraestructura moderna. La ejecución de una migración sin una estrategia clara puede provocar excesos presupuestarios, pérdida de datos e interrupción de las operaciones comerciales.

Las apuestas son altas. Según la investigación de Oracle, más del 80 % de los proyectos de migración de datos pasan con el tiempo y superan el presupuesto. Esa cifra no ha mejorado mucho a lo largo de los años, no porque la tecnología sea insuficiente, sino porque las organizaciones subestiman la planificación, el trabajo de calidad de datos y la gestión de riesgos que exigen las migraciones exitosas.

Esta guía 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 debe planificar y un marco de trabajo de proyecto paso a paso para mantener su migración encaminada.

Decidir pasar 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 en la nube, la migración se vuelve inevitable. La pregunta es cómo abordarla sin crear más problemas de los que resuelve.

Una estrategia de migración de datos sólida le brinda un camino estructurado desde la planificación hasta el desmantelamiento. Aborda la mecánica técnica de los datos móviles, los riesgos comerciales involucrados y los procesos de gobierno necesarios para mantener los datos precisos y accesibles durante toda la transición.

La migración de datos es el proceso de mover datos de una ubicación de almacenamiento a otra, incluidos los pasos de planificación, asignación, extracción y formato 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 datos de manera eficiente se ha vuelto fundamental a medida que las organizaciones manejan exponencialmente más datos en entornos más diversos. Lo que una vez significó copiar una base de datos de un servidor a otro ahora a menudo implica plataformas en la nube, arquitecturas distribuidas y requisitos de cumplimiento que agregan una complejidad significativa.

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

• Analizar los datos que desea migrar para identificar problemas de compatibilidad entre los entornos de origen y destino, incluidas las diferencias de esquema, las discrepancias de tipos de datos y las inconsistencias de codificación.
• Asignación de campos de origen a sus equivalentes de destino. Una buena documentación de mapeo de datos es esencial para detectar 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 la pérdida permanente de datos.
• Pruebe su lógica de migración con una copia del entorno de producción para validar la precisión de los datos en el sistema de destino antes de comprometerse.
• Extraer datos del sistema de origen usando un cargador de datos o una aplicación ETL.
• Transformar los datos cuando sea necesario para cumplir con el formato, el esquema o los requisitos de calidad de datos del sistema objetivo.
• Carga de los datos transformados en el entorno objetivo.
• Verificar que los datos transferidos estén completos, sean precisos y accesibles, incluidos los recuentos de filas, las sumas de comprobación y las pruebas a nivel de la aplicación.

Los pasos de asignación y prueba son los lugares donde la mayoría de las migraciones tienen problemas. Las organizaciones que tratan la migración como una operación de copia pura, omitiendo el perfil y la validación de datos rigurosos, tienden a descubrir problemas de calidad de datos solo después de la transición, cuando son más difíciles de solucionar.

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

1. Superar el presupuesto

Según un informe técnico de Oracle sobre migración de datos, los costos superan el 30 % promedio y el tiempo superan el 41 % promedio en los proyectos de migración de datos. Estos excesos casi siempre se remontan a subestimar la complejidad de los datos fuente, específicamente, la cantidad de trabajo de limpieza y transformación que se requiere una vez que comienza el perfil de datos real.

La otra causa común de los excesos presupuestarios es la fluencia del alcance. Con frecuencia, las migraciones descubren dependencias, integraciones y problemas de calidad de datos que no eran visibles durante el alcance inicial. Cada descubrimiento agrega trabajo que no estaba presupuestado. Las organizaciones que incorporan contingencia en sus presupuestos de migración, generalmente entre un 20 % y un 25 % por encima de la estimación inicial, manejan estos descubrimientos sin descarrilar el proyecto. Aquellos que no terminan acortando los límites o buscando aprobación de presupuesto adicional a mitad del proyecto, ambos presentan sus propios riesgos.

2. 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 confirmar que puede restaurarla.

La distinción importa más de lo que parece. Muchas organizaciones descubren durante un intento de restauración real 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, es una suposición. Las pruebas de restauración deben ser un requisito de aprobación formal antes de que comience la ejecución de la migración, no una idea posterior programada para después de la transición.

3. Tiempo de inactividad

Sin georreplicación o arquitecturas de ejecución paralela, la migración de datos generalmente requiere desconectar los sistemas. Esto afecta el rendimiento de la aplicación y el acceso del usuario. El enfoque de migración que elija, Big Bang, trickle o cero tiempo 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 forma de ser optimistas. Una ventana de migración proyectada a las cuatro horas puede extenderse a 12 si los volúmenes de datos son más grandes de lo esperado, la lógica de transformación se ejecuta más lento de lo probado o los problemas de superficie de los pasos de validación que deben resolverse antes de que se pueda proceder con la transición. Comunicar una estimación realista del tiempo de inactividad, y crear un búfer en la ventana de mantenimiento, evita el tipo de presión de mitad de la migración que conduce a malas decisiones sobre si continuar o retroceder.

4. Corrupción de datos

La corrupción de datos ocurre cuando los datos innecesarios, malformados o incompatibles se transfieren al nuevo sistema. Los datos corruptos pueden causar fallas en las aplicaciones y producir resultados inexactos que a veces son más difíciles de detectar que la pérdida de datos absoluta. Un registro faltante es obvio, pero un registro con valores sutilmente incorrectos puede pasar desapercibido durante semanas.

Las fuentes comunes de corrupción incluyen errores de codificación de caracteres entre los sistemas de origen y de destino, conversiones de tipos de datos que truncan o transforman los valores en silencio y lógica de transformación que maneja los casos de borde de forma incorrecta. Las defensas principales son la limpieza rigurosa de los datos antes de la migración y la validación después de la transición. La validación debe incluir tanto verificaciones técnicas, recuentos de filas, sumas de comprobación, verificación de restricciones, como pruebas a nivel de aplicación que confirmen que los datos se comportan correctamente en el contexto de los procesos comerciales 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 con ellos con el tiempo. Cuanta más gravedad tenga un conjunto de datos, más difícil será moverse sin interrumpir esas dependencias. Las organizaciones a menudo descubren la gravedad de los datos a mitad de la migración cuando mover una base de datos también requiere reconfigurar 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 con cadenas de conexión y las herramientas de informes apuntan a fuentes de datos específicas, a menudo sin documentación centralizada. Un ejercicio de mapeo de dependencia exhaustivo durante el análisis de paisajes es la mejor manera de descubrir estas conexiones antes de que se conviertan en sorpresas del día de la transición. Cada aplicación, servicio y trabajo programado que toque los datos que se migran debe identificarse, probarse y actualizarse como parte del plan de migración.

6. Mala calidad de datos

Los problemas de calidad de datos, como duplicar registros, formateo inconsistente, valores faltantes y datos obsoletos, no desaparecen cuando migra. Llegan al sistema objetivo y se convierten en los problemas de su nuevo sistema. Una revisión de la gobernanza de datos previa a la migración y un proceso de limpieza son la única forma confiable de ayudar a prevenir esto. Las organizaciones que omiten el perfil de datos antes de la migración dedican constantemente más tiempo a la limpieza posterior a la migración de lo que habrían dedicado a la limpieza inicial, y lo pasan en peores condiciones, con usuarios que ya están en el nuevo sistema y operaciones comerciales, dependiendo de los datos que aún no son confiables. Tratar la migración como una oportunidad para mejorar la calidad de los datos, en lugar de solo moverla, produce un resultado significativamente mejor en el otro lado.

Su estrategia de migración define cómo se mueven los datos de un origen a otro: todo a la vez, en fases o sin interrupciones perceptibles. El enfoque correcto depende de su tolerancia al tiempo de inactividad, la complejidad de su entorno y la criticidad de los sistemas que se migran.

1. Migración Big Bang

Una migración Big Bang transfiere todos los datos en una sola operación, generalmente durante un período de mantenimiento programado. Los sistemas se desconectan, se ejecuta el procesamiento de ETL y el sistema objetivo presenta el conjunto de datos completo.

La ventaja es la sencillez y la velocidad: no es necesario mantener sistemas paralelos ni administrar la sincronización de datos. La desventaja es la exposición al riesgo: Si la migración falla a mitad de camino, podría enfrentar una reversión o un tiempo de inactividad extendido. Big Bang funciona bien para conjuntos de datos más pequeños, sistemas con ventanas de mantenimiento natural y organizaciones en las que un breve tiempo de inactividad es aceptable.

2. Migración de Trickle

En una migración lenta, los datos se mueven en fases, mientras que los sistemas nuevos y antiguos funcionan en paralelo. El sistema de origen permanece activo durante la migración, lo que elimina el tiempo de inactividad de los usuarios. Las herramientas de sincronización de datos mantienen ambos entornos consistentes durante el período de transición.

Las migraciones de Trickle son más complejas de ejecutar. La ejecución de sistemas paralelos requiere infraestructura adicional, lógica de sincronización cuidadosa y un punto de transición definido en el que el nuevo sistema se vuelve autorizado. Pero para los entornos de misión crítica, esta complejidad adicional suele ser la compensación correcta.

3. Migración sin tiempo de inactividad

La migración sin tiempo de inactividad es una extensión del enfoque de goteo que utiliza replicación continua y una migración casi instantánea para eliminar cualquier interrupción del servicio. En lugar de una ventana de mantenimiento planificado, la transición ocurre cuando el sistema objetivo alcanza la paridad con la fuente. Este enfoque es cada vez más común para 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 tiempo de inactividad es la más alta de los tres enfoques, pero el riesgo de interrupción del negocio es la más baja. El almacenamiento moderno y las plataformas de base de datos han hecho que este enfoque sea más accesible: las herramientas como la georreplicación y el clúster active-active admiten la sincronización continua a escala.

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

El tipo de migración se determina por lo que se mueve y los entornos involucrados. Cada tipo tiene sus propias consideraciones técnicas, modos de falla y requisitos de planificación. Comprender qué tipo, o combinación de tipos, se aplica a su proyecto es una de las primeras decisiones que debe tomar su estrategia de migración.

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 actualizar el software de base de datos. Los desencadenantes comunes incluyen anuncios de fin de vida útil de un proveedor de bases de datos, cambios en los costos de licencias, limitaciones de rendimiento en la plataforma actual o un cambio hacia alternativas de código abierto.

Las diferencias en los esquemas son la principal fuente 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 a menudo requieren una nueva escritura para el sistema de destino.

Las dependencias de las aplicaciones componen el desafío. La mayoría de las bases de datos de producción son utilizadas por varias aplicaciones que leen y escriben. Es necesario probar cada una de esas aplicaciones en comparación con la base de datos de destino antes de la transición, y cualquier consulta que dependa del comportamiento específico del proveedor debe identificarse y volver a escribirse. Omitir este paso es una de las razones más comunes por las que las migraciones de bases de datos fallan la validación después del hecho.

Qué debe tener en cuenta:

• Conversiones implícitas de tipos de datos que se comportan de manera diferente en todas las 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 de manera limpia entre los proveedores.
• Disparadores y procedimientos almacenados escritos en dialectos SQL específicos del proveedor

las migraciones en la nube;

Las migraciones a la nube trasladan datos o aplicaciones de entornos en las instalaciones a infraestructura en la nube, o entre proveedores de la nube. A menudo son los de mayor alcance y los de tipo de migración más complejos desde el punto de vista organizativo, ya que con frecuencia implican migraciones de bases de datos, migraciones de almacenamiento y migraciones de aplicaciones que se ejecutan en paralelo.

Las migraciones de elevación y cambio, que trasladan 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 costos en su lugar. El cambio de plataforma o la refactorización de cargas de trabajo para aprovechar los servicios nativos en la nube aumenta la complejidad de la migración, pero generalmente produce mejores resultados a largo plazo.

Los requisitos de cumplimiento, las reglas de residencia de datos y la latencia de red agregan dimensiones que las migraciones puramente en las instalaciones no enfrentan. GDPR, HIPAA y otras regulaciones 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 verdadero cuello de botella: algunas migraciones son más rápidas y económicas mediante el uso de servicios de transferencia de datos físicos que la transmisión por cable.

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

Qué debe tener en cuenta:

• Costos de salida que inflan significativamente el presupuesto de migración
• Dependencias de servicio exclusivas que no tienen equivalente directo en el proveedor objetivo
• Conflictos de residencia de datos con los requisitos de cumplimiento
• Impactos de latencia en aplicaciones diseñadas para el acceso en las instalaciones de latencia baja

Migraciones de almacenamiento

Las migraciones de almacenamiento trasladan los datos de las matrices de almacenamiento existentes al nuevo hardware. Se encuentran entre los tipos de migración más comunes en entornos empresariales, impulsados por ciclos de actualización de hardware, necesidades de expansión de capacidad y el cambio de discos giratorios a arquitecturas basadas íntegramente en tecnología flash.

A diferencia de las migraciones de bases de datos o aplicaciones, las migraciones de almacenamiento no implican inherentemente la transformación de datos. El formato de 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 matrices de almacenamiento que interrumpa el acceso a los datos de producción afecta a cada aplicación y usuario, dependiendo de ese almacenamiento.

Las migraciones basadas en host utilizan software que se ejecuta en el servidor para copiar datos del almacenamiento de origen al de destino. Son flexibles y no requieren hardware especializado, pero consumen CPU de servidor y recursos de memoria durante la migración. Las migraciones basadas en matrices utilizan capacidades de replicación incorporadas en el hardware de almacenamiento, lo que generalmente produce menos gastos generales del lado del host y admite la transición sin interrupciones.

Para las organizaciones que utilizan matrices basadas íntegramente en tecnología flash, las migraciones de almacenamiento a menudo coinciden con un esfuerzo de modernización de infraestructura más amplio. Pasar del almacenamiento en disco híbrido o giratorio a las características de rendimiento basadas íntegramente en tecnología flash cambia significativamente: las aplicaciones que se ajustaron para el almacenamiento de mayor latencia pueden necesitar una reconfiguración para aprovechar al máximo el nuevo entorno.

Qué debe tener en cuenta:

• Configuración multiruta del host que necesita actualización 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 matrices de origen y de destino que afectan el comportamiento de la aplicación
• Planificación de capacidad que representa diferentes proporciones de reducción de datos entre hardware antiguo y nuevo

Migraciones de aplicaciones

Las migraciones de aplicaciones trasladan las aplicaciones entre entornos, en las instalaciones a la nube, de la nube a la nube o a una nueva plataforma SaaS. Son el tipo de migración más complejo para planificar y ejecutar porque casi siempre activan las 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 restricciones de secuenciación.

Las migraciones de aplicaciones también conllevan el mayor riesgo comercial de cualquier tipo de migración porque afectan directamente a los usuarios y los procesos comerciales. Una migración de almacenamiento incorrecta es un problema de infraestructura. Una migración de aplicaciones incorrecta interrumpe los flujos de trabajo en los que las personas confían para hacer su trabajo.

Las migraciones de SaaS, pasando de una aplicación autogestionada a un servicio de nube administrado por un proveedor, presentan un conjunto diferente de desafíos. A menudo, se traslada a un entorno de varios inquilinos con opciones de personalización limitadas, lo que significa evaluar si la plataforma objetivo realmente puede admitir sus flujos de trabajo actuales antes de que se muevan los datos.

Qué debe tener en cuenta:

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

Comprender estas dependencias es importante para la secuenciación. Las migraciones de almacenamiento generalmente deben completarse antes de que se puedan validar las migraciones de aplicaciones. Las migraciones de bases de datos deben ejecutarse antes del corte de la aplicación. Tratarlos como flujos de trabajo independientes en lugar de una secuencia dependiente puede provocar 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 de manera consistente a mitad de la migración que sus datos fuente contienen duplicados, formato inconsistente, registros huérfanos y valores faltantes que no eran visibles hasta que los datos necesarios para ajustarse a un nuevo esquema.

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

• Perfil de datos: Análisis sistemático de datos fuente para identificar problemas de calidad, distribuciones de tipos de datos, tasas nulas y violaciones de restricciones. El perfil le brinda 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 creación de perfiles antes de que comience la migración. Esto incluye desduplicación, estandarización de formatos, corrección de problemas de codificación y eliminación o archivo de registros obsoletos.
• Validación del mapeo de origen a objetivo: Confirmar que cada campo de origen tiene un destino objetivo válido, que los tipos de datos son compatibles y que la lógica de transformación se documenta y prueba.

El resultado de esta evaluación debe ser un informe de calidad de datos que las partes interesadas firmen antes de que se muevan los datos. Esto crea responsabilidad y evita el escenario común en el que los problemas de calidad de datos descubiertos después de la migración son culpables de la migración en sí en lugar de problemas de datos fuente 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 inactivos en un entorno conocido y seguro. Cualquier estrategia de migración que maneje datos regulados, información personal, registros financieros, datos de salud, necesita abordar explícitamente los requisitos de cumplimiento.

Las consideraciones de seguridad clave para las migraciones incluyen:

• Encriptación en tránsito: Asegúrese de que los datos estén encriptados en todo el proceso de migración. Esto se aplica tanto a las transferencias de red como a cualquier entorno de almacenamiento intermedio.
• Controles de acceso: Restrinja el acceso al sistema de migración solo al personal autorizado. Los permisos temporales elevados otorgados con fines de migración deben revocarse inmediatamente después de su finalización.
• Registro de auditoría: Mantenga registros detallados de todo el acceso y movimiento de datos durante el período de migración. Estos registros sirven tanto como registros operativos como documentación de cumplimiento.
• Residencia de datos: Para las organizaciones sujetas al GDPR, HIPAA u otras regulaciones de gobierno de datos, confirme que los datos no transiten ni residan temporalmente en jurisdicciones que no cumplan con los requisitos 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 sea técnicamente factible antes de la migración. Un plan de reversión que existe solo en papel no es un plan de reversión.

Los requisitos de cumplimiento regulatorio deben revisarse y documentarse durante la fase de planificación previa a la migración, no descubrirse durante la ejecución. Involucrar a sus equipos de seguridad y cumplimiento de forma temprana ayuda a evitar retenciones de último minuto 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, el perfil de datos, la selección de estrategias y la revisión de seguridad, deben incorporarse a 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 para el entorno fuente.

Un plan de proyecto de migración del centro de datos mantiene su migración a tiempo y dentro del presupuesto. Este es un marco paso a paso que se basa en la metodología de migración establecida:

1. Planificación previa a la migración

Realice una evaluación del impacto previo a la migración para verificar el costo real de la migración. Examine si las estimaciones de costos se basan en análisis concretos o conjeturas. Es probable que las cifras de presupuesto obtenidas de las estimaciones de proveedores o los promedios de la industria sin referencia a su entorno específico sean inexactas. Informe a los ejecutivos y a TI sobre su participación requerida, incluidos los compromisos de tiempo que tienden a subestimarse hasta que ya están atrasados.

Obtenga la aprobación formal del gobierno de seguridad antes de comenzar cualquier trabajo técnico. Determine la estructura de entrega del proyecto (ágil frente a cascada), defina los roles y la autoridad para tomar decisiones, diseñe un plan de capacitación y confirme su política de administración de configuración. El objetivo de esta fase es asegurarse de que todos estén de acuerdo en 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 oficina administrativa esté en orden. Cree un plan de comunicación con las partes interesadas que especifique quién recibe 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 fases posteriores.

No omita los acuerdos con proveedores. Las migraciones se detienen de forma rutinaria porque no había un contrato de proveedor vigente cuando se necesitaba hardware o licencias. Lograr que estos se finalicen de forma temprana ayuda a eliminar una posible fuente de retraso.

3. Análisis de paisajes

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 asignación de origen a objetivo de alto nivel y un informe de alcance. Determine los datos volumétricos (cuántos datos, cuántos registros, cuántas dependencias), establezca un proceso de administración de la calidad de los datos, cree un registro de riesgos y refine las estimaciones del proyecto según lo que descubra. Las estimaciones que se producen antes del análisis del paisaje son marcadores de posición. Las estimaciones que se producen después son compromisos.

4. Diseño de soluciones

Mapee las transformaciones de origen 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 construcción: especificaciones de diseño de mapeo detallado, una especificación de diseño de interfaz y una especificación de administración de calidad de datos.

Defina los requisitos de hardware de producción y acuerde acuerdos de nivel de servicio para la migración en sí, no solo para el entorno objetivo 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 contra un espejo del entorno en vivo, no 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 solucionar los problemas de la migración sin depender del conocimiento institucional que posee una persona.

Desarrolle un motor de validación para confirmar de manera independiente la precisión de los datos en el sistema objetivo. Establezca un monitoreo continuo de la calidad de los datos, cree una política de recuperación y complete la capacitación de ejecución. El equipo que ejecuta la migración el día de la transición debería haberla ensayado, no haberla ejecutado por primera vez bajo presión.

6. Migración y validación

Ejecute la migración utilizando el enfoque elegido: Big Bang, trickle o cero tiempo de inactividad. La validación no es una formalidad en esta etapa, son los criterios los que determinan si la migración está realmente completa. Confirme de manera independiente que los recuentos de filas, sumas de comprobación y pruebas a nivel de aplicación pasan antes de declarar el éxito.

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

7. Desmantelamiento y monitoreo

Retire el entorno heredado solo después de que el sistema de destino haya sido validado y esté funcionando de manera estable con carga de producción. La ejecución de ambos entornos de manera indefinida agrega costos y crea un riesgo de sincronización, pero el recorte demasiado pronto antes de confirmar la estabilidad crea un conjunto diferente de problemas.

Transfiera las responsabilidades de monitoreo de calidad de datos al equipo adecuado y documente la transferencia explícitamente. Complete una validación de retiro del sistema y documente el proceso de desmantelamiento para fines de auditoría. Las migraciones que terminan en la transición sin una fase de desmantelamiento formal tienden a dejar los sistemas huérfanos funcionando por más tiempo de lo que cualquiera pretendía, a menudo a un costo real de infraestructura.

Las organizaciones que ejecutan migraciones con éxito tienden a compartir algunas prácticas comunes que las personas que tienen dificultades tienden a omitir.

• Comience con una auditoría de datos, no con un plan de migración. Comprender el estado real de sus datos fuente, problemas de calidad, dependencias, volumen, debe preceder a cualquier planificación estratégica. Las migraciones analizadas antes de la creación de perfiles de datos casi siempre requieren una reescruzamiento a mitad del proyecto.
• Nunca migre datos que no necesite. Las migraciones son una oportunidad para archivar o eliminar datos que ya no tienen un propósito comercial. Mover datos innecesarios agrega costo, tiempo y riesgo sin retorno.
• Pruebe con datos a escala de producción. Las pruebas con una pequeña muestra con frecuencia no logran detectar problemas de rendimiento y escalabilidad que solo aparecen en el volumen de producción total. Si su ETL de migración tarda dos horas en probarse, espere que tarde 20 horas con datos de producción completos.
• Defina los criterios de éxito antes de la transición. Sepa exactamente lo que significa la “migración exitosa” antes de comenzar: recuentos de filas específicos, verificaciones de integridad, pruebas de funcionalidad de aplicaciones. Sin criterios definidos, no existe una base objetiva para declarar que la migración está completa.
• Comuníquese con los usuarios afectados. Los usuarios finales y los propietarios de aplicaciones deben saber qué está cambiando, cuándo y qué hacer si tienen problemas después de la transición. La 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 retroceso 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 de forma dinámica entre entornos, la distinción entre “migración” y “administración de datos de rutina” es borrosa.

La automatización está impulsando este cambio. Las herramientas de creación de perfiles de datos asistidas por AI ahora pueden identificar problemas de calidad y sugerir reglas de transformación sin análisis manual. Las plataformas de migración inteligente pueden monitorear la sincronización de datos en tiempo real e identificar anomalías durante las migraciones lentas 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 sin interrupciones como una capacidad nativa en lugar de un procedimiento excepcional.

Las organizaciones que desarrollan 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 continúen evolucionando. El mejor momento para establecer prácticas de migración y herramientas es antes de que se anuncie la próxima migración.

El almacenamiento de datos es un elemento fundamental de cada migración. Sin una infraestructura de almacenamiento que admita el movimiento de datos sin interrupciones, las organizaciones enfrentan una difícil elección entre tiempos de inactividad prolongados y soluciones alternativas complejas.

Las ofertas de suscripción a Everpure, basadas en la arquitectura Evergreen®, están diseñadas para hacer que las migraciones de datos sean más fáciles y asequibles al eliminar los ciclos de actualización y las ventanas de mantenimiento que requieren las matrices de almacenamiento tradicionales:

• Evergreen//One™ reduce la complejidad y el costo de la administración y el soporte del almacenamiento, lo que proporciona flexibilidad financiera y simplicidad operativa, al mismo tiempo que mitiga el riesgo de TI.
• Evergreen//Flex™ le brinda la flexibilidad de responder a los cambios en la demanda y el uso, aumentar la agilidad del almacenamiento y maximizar el retorno de la inversión en el uso de la capacidad con costos iniciales más bajos.
• Evergreen//Forever™ proporciona agilidad de TI real: compre su almacenamiento una vez y escale sin interrupciones, sin sanciones, indefinidamente.

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

Explore la cartera Everpure Evergreen para ver cómo la infraestructura de almacenamiento diseñada específicamente puede simplificar su próxima migración de datos.