Flujo de trabajo sugerido para una migración de datos compleja

En este artículo se sugiere un proceso paso a paso para migrar grandes cantidades de datos. Al transferir datos desde un CRM eficaz basado en la nube, es importante planear cuidadosamente debido a su configuración compleja, como objetos personalizados, vínculos entre datos e identificadores de registro únicos. Debe pensar en los pasos técnicos y en cómo funciona la migración en la práctica.

• Enfoque técnico: cubre los pasos clave de migración(extracción, transformación y carga de datos en Dataverse) al tiempo que garantiza la integridad, la conservación de las relaciones y la optimización del rendimiento mediante la validación y el control de errores.
• Enfoque funcional: cubre tareas de migración funcionales, como la segmentación y el archivado de datos, y resalta la necesidad de implicar a las partes interesadas de la empresa para asegurarse de que los datos satisfacen sus necesidades.

Enfoque técnico para la migración de datos

Asegúrese de una migración sin problemas siguiendo un enfoque estructurado: extraer, transformar y cargar datos, a la vez que conserva la integridad y minimiza la interrupción.

Extraer datos del origen a la base de datos de almacenamiento provisional

Para migraciones de datos complejas, se recomiendan los datos provisionales en una base de datos independiente (por ejemplo, SQL Server). Este área de almacenamiento provisional captura una instantánea del sistema de origen sin interrumpir las operaciones empresariales en curso.

Consideraciones clave:

• Carga completa frente a delta: organice los datos como cargas completas o incrementales (delta). Use marcas de tiempo generadas automáticamente para realizar un seguimiento de la llegada de datos e identificar los cambios de las cargas futuras.
• Gestión de conmutación por error: diseñe el proceso para omitir los registros con errores (por ejemplo, debido a la longitud del campo, búsquedas no válidas) sin detener la migración. Registre y resuelva los problemas antes de volver a procesar.
• Asignación de campos: convierta los valores de origen para que coincidan con los formatos de destino en la capa de almacenamiento provisional y los intervalos de valores de la base de datos de almacenamiento provisional antes de migrar los datos a Dataverse para mejorar la eficacia.
• Validaciones de datos: ejecute comprobaciones de integridad para detectar problemas como las referencias que faltan. Dado que la extracción de datos puede abarcar horas o días, use la capa de almacenamiento provisional para filtrar registros incompletos y garantizar la coherencia.
• Visualización de datos: use la base de datos provisional para auditar y analizar datos (por ejemplo, recuento de registros o campos financieros de suma) antes de la migración final.

Transformar los datos en la base de datos de almacenamiento provisional de destino

Después de extraer datos del sistema de origen, transformelos en una base de datos de almacenamiento provisional de destino que refleje el esquema de Dataverse y contenga valores listos para insertar o actualizar directamente.

Pasos de transformación clave:

• Mapeo de campos: Mapee columnas de origen a columnas de Dataverse de destino. Usa scripts para unir y fusionar tablas cuando sea necesario.

• Conversión del conjunto de opciones: convierta los valores del conjunto de opciones basados en texto en enteros de Dataverse utilizando una tabla de asignación (por ejemplo, OptionSetMapping) y consultas de actualización masiva. Cree una tabla para estandarizar y automatizar la transformación de valores del conjunto de opciones de los sistemas de origen a destino.

  Tabla: MapeoConjuntoOpciones

  Nombre de la columna	Tipo de dato
  Nombre de la tabla de origen	cuerda / cadena
  Nombre de la tabla de destino	cuerda / cadena
  Texto de origen	cuerda / cadena
  Texto de destino	cuerda / cadena
  Valor objetivo	cuerda / cadena

  Use la tabla OptionSetMapping para transformar y actualizar de forma eficaz los valores del conjunto de opciones de forma masiva. Por ejemplo, para actualizar todos los valores del conjunto de opciones de la tabla Contact en función de los valores de texto coincidentes:

  Update C.\<OptionsetValue\> = M.\<TargetValue\> 
  FROM Contact C 
  JOIN OptionsetMapping M 
    ON C.OptionsetText = M.TargetText 
    AND M.TargetTableName = 'Contact'
  

• Evitar GUID personalizados: Permitir que Dataverse genere GUID para evitar problemas de fragmentación y rendimiento.

• Comprobaciones de longitud de cadena: Asegúrese de que los valores de cadena se ajusten a los límites de Dataverse. Recorte o ajuste según sea necesario.

• Campos calculados: Agregue campos derivados (por ejemplo, Nombre para búsquedas) si falta en el origen.

• Otras consideraciones: al diseñar tablas para que coincidan con el esquema de Dataverse, tenga en cuenta las siguientes columnas de clave y las tablas auxiliares.

  • DataMigration_CreatedDateTime: marca de tiempo rellenada automáticamente para realizar el seguimiento de lotes de carga de datos.
  • Marca de acción: indica Insertar (I), Actualizar (U) o Eliminar (D).
  • Marca de procesamiento: realiza un seguimiento del estado: Procesado (P), Sin procesar (U), Error (E) o Correcto (S).
  • Columna única: use un identificador único (por ejemplo, el identificador único del sistema de origen) para asignar registros.
  • Tablas de éxito o error: mantenga tablas independientes (por ejemplo, Contact_Success, Contact_Error) para registrar los resultados y admitir reintentos.

Tablas de secuencia y búsquedas de precarga

Después de las transformaciones estáticas, ordene las tablas para reducir las dependencias cíclicas, casos en los que las tablas hacen referencia entre sí, lo que hace que las importaciones aisladas sean imposibles. Use este enfoque:

• Enumere todas las tablas aptas para la migración.
• Recuento de búsquedas únicas por tabla (omita campos predefinidos como Created By y otras búsquedas de tablas si no se migra).
• Ordene las tablas en orden ascendente por recuento de búsquedas.
• Incluya tablas de relaciones de N:N, contando ambas búsquedas.
• Excluya las búsquedas en varias tablas (por ejemplo, campos "referente a").

Este enfoque define la secuencia de carga de migración de datos y funciona bien en la mayoría de los escenarios. Para casos más complejos:

• Use un identificador único (por ejemplo, importsequencenumber) para que coincida con los registros entre el almacenamiento provisional y Dataverse cuando se generan GUID durante la inserción.
• Separe los registros de éxito y errores para evitar problemas de bloqueo y optimizar el rendimiento.
• Cargue previamente los GUID de búsqueda de tablas ya migradas para resolver las referencias durante la inserción.
• Controle las dependencias cíclicas por:
  • Insertar registros sin búsquedas dependientes.
  • Actualizar esas consultas después de cargar los registros relacionados.

Carga de datos en Dataverse

El siguiente paso consiste en determinar e implementar el enfoque para cargar datos en Dataverse.

1. Herramientas: seleccione una herramienta basada en el tamaño y la complejidad de los datos:

   • Herramienta de migración de configuración del SDK
   • Azure Data Factory
   • KingswaySoft
   • Scribe
   • Transporte de datos de XrmToolBox

2. Consideraciones clave (independiente de la herramienta):

   • Controlar las dependencias cíclicas: la tabla de secuencia se carga para minimizar las búsquedas circulares. Inserte registros sin búsquedas dependientes y actualícelos más adelante.

   • Id. de registro de seguimiento: capture los GUID de Dataverse en una tabla de éxitos y, a continuación, actualice la tabla principal mediante un identificador único (por ejemplo, importsequencenumber).

   • Optimizar el tamaño del lote y el número de subprocesos: revise las instrucciones para optimizar el rendimiento de las operaciones masivas. La aplicación que use debe administrar los errores de protección del servicio que se producen cuando se envían números extraordinarios de solicitudes a Dataverse. Si escribe su propio código y usa la API web de Dataverse, asegúrese de reintentar los errores 429, tal y como se describe en Límites de protección de API de servicio. Si usa el SDK de Dataverse, administra estos errores.

     Para lograr un rendimiento óptimo, ajuste el tamaño del lote y el recuento de subprocesos en función de la complejidad de la tabla:

     • Tablas predefinidas (OOB) (por ejemplo, Contacto, Cuenta, Cliente potencial): estas tablas son más lentas debido a los complementos y trabajos integrados. Recomendado: tamaño de lote de 200 a 300, hasta 30 subprocesos (si ≤ 10 búsquedas y 50 a 70 columnas).
     • Tablas simples (pocas o sin búsquedas): Recomendado: tamaño de lote ≤10, hasta 50 hilos.
     • Tablas personalizadas moderadamente complejas (algunas búsquedas): recomendado: tamaño de lote ≤100, hasta 30 subprocesos.
     • Tablas grandes y complejas (>100 columnas, >20 búsquedas): recomendado: tamaño de lote de 10 a 20, hasta 10-20 subprocesos para reducir los errores.

3. Sugerencias de infraestructura: para maximizar el rendimiento de la migración de datos, ejecute la migración desde una máquina virtual (VM) ubicada en la misma región que el entorno de Dataverse. Este enfoque reduce significativamente la latencia y acelera todo el proceso. Aprenda a determinar la región del entorno de Dataverse.

4. Control de errores: no ignore los errores: resíquelos para evitar errores en cascada. Use valores predeterminados (por ejemplo, búsquedas en blanco, valores de conjunto de opciones predeterminados) para insertar registros de marcador de posición y capturar GUID.

5. Actualizaciones de estado: establezca solo el estado activo durante la inserción inicial del registro. Para registros inactivos o códigos de estado o estado personalizados, actualícelos después de la validación de datos. Para la mayoría de las tablas personalizadas, las actualizaciones de estado pueden seguir inmediatamente después de la inserción. Sin embargo, para tablas especiales como "Caso", "Oportunidad" o "Cliente", retrase al actualizaciones de estado hasta el final de la migración. Una vez cerrados estos registros, no se pueden modificar a menos que se vuelvan a abrir, un proceso lento que arriesga la integridad de los datos.

6. Propiedad y seguridad: establezca el propietario del registro correcto durante la inserción de datos, ya que tanto la seguridad de nivel de usuario como de unidad de negocio en Dataverse están vinculadas a la unidad de negocio del propietario. Asigne la unidad de negocio adecuada en la creación; al actualizarla después, se quitan todos los roles de seguridad.

   • Usar usuarios simulados:
     • Dataverse admite usuarios 'stub' (sin licencia), que son útiles para migraciones masivas o de datos históricos. A los usuarios de prueba se les asigna automáticamente el rol de seguridad Salesperson; no cambie el nombre ni modifique este rol. Los usuarios Stub pueden ser titulares de registros si tienen acceso de lectura a nivel de usuario a las tablas pertinentes.
   • Recomendaciones:
     • Cree todos los usuarios sin licencia durante la migración con la unidad de negocio correcta establecida en el momento de la inserción.
     • No se debe cambiar la unidad de negocio después de la creación; ya que se eliminarán todos los roles, incluido el de vendedor.
     • Asegúrese de que el rol de vendedor tenga acceso de lectura a todas las tablas aptas para la migración.
     • Incluso los usuarios deshabilitados en el entorno de Dataverse con este rol pueden poseer registros.

7. Control de divisas: establezca los tipos de cambio durante la inserción mediante un complemento de validación previa, ya que Dataverse no admite tarifas históricas.

Carga de datos en Dataverse

Después de cargar datos en Dataverse, siga estos pasos para garantizar la integridad de los datos y minimizar los problemas de bajada:

1. Actualice la tabla principal con GUID:

   • Después de una carga correcta, copie los GUID de registros de Dataverse de la tabla de éxitos en la tabla principal mediante un identificador único, como importsequencenumber.
   • Actualice la marca de procesamiento para marcar los registros como:
     • P: procesado
     • E – Erróneo
     • U: Sin procesar Esta estrategia permite volver a ejecutar con eficiencia al omitir registros ya procesados y admite la resolución de búsqueda en cargas posteriores.

2. Reintentar registros con errores: para reducir el trabajo y mantener la integridad referencial, considere estas acciones:

   • Recorte los valores de cadena si superan las longitudes permitidas.
   • Aplique valores de conjunto de opciones predeterminados cuando no haya mapeos.
   • Asigne un propietario suplente si el propietario original no está disponible (incluso como usuario provisional).
   • Use valores en blanco o predeterminados para búsquedas sin resolver.
   • Incluso los registros de marcador de posición pueden ayudar a generar GUID necesarios para búsquedas en tablas relacionadas.

Uso de tablas elásticas para la migración de datos

Las tablas elásticas están diseñadas para controlar grandes volúmenes de datos en tiempo real. Con tablas elásticas, puede importar, almacenar y analizar grandes volúmenes de datos sin problemas de escalabilidad, latencia o rendimiento.

Las tablas elásticas ofrecen funcionalidades únicas para el esquema flexible, el escalado horizontal y la eliminación automática de datos después de un período de tiempo específico.

Las tablas elásticas se almacenan en Azure Cosmos DB y admiten:

• Datos sin esquema a través de columnas JSON
• Escalado horizontal automático
• Período de vida (TTL) para la eliminación automática de datos obsoletos
• Creación de particiones para la optimización del rendimiento

Las tablas elásticas son más adecuadas para las importaciones masivas con esquema variable.

Tipos de datos recomendados para tablas elásticas durante la migración de datos

Las tablas elásticas son ideales para tipos de datos específicos.

Tipos de datos no adecuados para tablas elásticas

Las tablas elásticas están optimizadas para escenarios flexibles y a gran escala, pero no todos los tipos de datos se ajustan. En esta sección se resaltan los patrones de datos de CRM comunes que se almacenan mejor en otro lugar para garantizar el rendimiento, la rentabilidad y la capacidad de mantenimiento. Obtenga más información sobre las características que no se admiten actualmente con tablas elásticas.

Marco funcional de segmentación y archivado de datos

La planificación técnica eficaz incluye seleccionar las herramientas y la infraestructura adecuadas, alinear los volúmenes de datos de origen y destino y configurar procesos de auditoría y conciliación. Muchas migraciones se vuelven complejas debido a la falta de análisis inicial, especialmente en torno a qué datos deben moverse y dónde pertenece. En esta sección se describen los principios básicos del análisis de datos para apoyar una migración correcta.

Segmentación de datos

La segmentación de datos es un paso clave para migrar de un sistema CRM a Dataverse. Organice las tablas de datos por función empresarial (como ventas, servicio o marketing) para simplificar el planeamiento y la ejecución de la migración.

Segmentación de tablas

Empiece por enumerar todas las tablas aptas para la migración, agrupadas por área de negocio (por ejemplo, ventas, marketing, servicio). A continuación:

• Documente el esquema en Excel o una herramienta similar.
• Ejecute consultas básicas en el sistema de origen para comprobar el uso de columnas.
• Marcar columnas de bajo uso. Si menos de 5% de registros contienen valores, consulte a las partes interesadas de la empresa para decidir si desea conservarlos o descartarlos.

Este análisis sencillo puede reducir significativamente el ámbito de migración. En sistemas CRM de larga duración, es habitual eliminar de 30 a 40% de columnas y hasta 20% de tablas, optimizando el proceso y mejorando el rendimiento.

Relevancia de las columnas

Algunas columnas del sistema de origen se asignan directamente a Dataverse, mientras que otras se convierten en campos calculados. Separe estas columnas y consulte a las partes interesadas de la empresa para decidir si se necesitan trabajos de migración.

Omita las columnas que solo son relevantes en el sistema de origen o que no sean significativas en el destino. Esto incluye muchos campos predefinidos, como Autor, Modificado por o Número de versión de fila, a menos que sirvan para una finalidad específica en la migración.

Datos de tipo de archivo

Si el sistema de origen incluye datos de tipo de archivo, marque estos campos al principio y planee una estrategia de migración independiente. Tenga en cuenta los siguientes tipos de archivo:

• Documentos de Office (por ejemplo, Word, Excel, PowerPoint): para hasta 20 000 archivos, migre a una plataforma colaborativa como SharePoint para habilitar el acceso multiusuario.
• Archivos multimedia (por ejemplo, imágenes, vídeos): elija una plataforma que admita la reproducción. Entre las opciones se incluyen SharePoint, servicios de streaming u otras soluciones de almacenamiento compatibles con medios.
• Grandes volúmenes o tamaños de archivo: si el costo de almacenamiento es un problema, use Azure Blob Storage o la columna de archivo nativo en Dataverse, que usa Azure Blob en segundo plano.
• Protección contra malware: ejecute archivos mediante una herramienta de detección de malware (por ejemplo, Azure Advanced Threat Protection) antes de la migración para garantizar la seguridad.

Después de revisar la relevancia de los archivos, a menudo encuentra que el volumen total de datos cae significativamente( especialmente en sistemas CRM de ejecución prolongada), lo que hace que la migración sea más eficaz.

Estrategias de archivado de datos

Algunos datos, como correos electrónicos antiguos, casos cerrados o clientes potenciales descalificados, siguen siendo importantes, pero rara vez se accede a ellos. Para reducir el volumen de migración sin interrumpir las operaciones empresariales, desarrolle una estrategia de archivado inteligente.

Paso 1: Identificación de datos archivables

Entre los candidatos comunes se incluyen:

• Correos electrónicos anteriores a tres años
• Casos cerrados
• Oportunidades perdidas
• Clientes potenciales descalificados
• Correos electrónicos de marketing, publicaciones y registros de auditoría

Revise el sistema para identificar otras tablas que puede archivar.

Paso 2: Elegir un enfoque de archivado

• Mantenga los datos en el sistema de origen. Conserve algunas licencias de administrador para el acceso mientras desactiva otras para reducir los costos.
• Vaya al almacenamiento externo. Use bases de datos locales, Azure Blob Storage o Tablas de Azure para almacenar registros archivados. Este enfoque reduce los costos de almacenamiento y migración, pero requiere una estrategia de migración independiente.
• Use un entorno de Dataverse independiente. Esta opción es menos común, pero resulta útil si desea aislar los datos archivados. Puede desactivar este entorno más adelante para simplificar la planificación de la transición.

Infraestructura de migración de datos recomendada

Para garantizar una migración de datos rápida y confiable a Dataverse:

• Use una máquina virtual (VM) en la misma región que el entorno de Dataverse para reducir la latencia y mejorar la velocidad de migración.
• Elija una máquina virtual de alto rendimiento. Como mínimo, use una máquina virtual D4 con ocho núcleos, 28 GB de RAM y almacenamiento de 500 GB para controlar grandes volúmenes de datos de forma eficaz.
• Se prefiere una base de datos local en la máquina virtual. Evite las conexiones remotas durante la migración. Si usa Azure Data Factory, impleméntelo en la misma región que el entorno de Dataverse para obtener un rendimiento óptimo.

Paso siguiente