Revisar clientes duplicados antes de migrar datos
Un ejemplo de cotejo distingue nombres iguales de clientes realmente idénticos. Compruebe la identidad, la dirección actual y los pedidos vinculados antes de migrar.

Antes de migrar datos, determine qué registros representan al mismo cliente. Un nombre de empresa idéntico es una pista de búsqueda, pero no una prueba suficiente de identidad. Una dirección nueva puede pertenecer a un cliente existente; dos empresas homónimas pueden seguir siendo clientes distintos.
Microsoft Dataverse distingue los posibles duplicados de su posterior fusión. Los campos que generan una coincidencia dependen de las reglas configuradas. Una búsqueda por similitud no sustituye su decisión de negocio sobre la correspondencia.
Distinga tres registros con identidades verificadas
El ejemplo es completamente ficticio. Los tres registros de origen tienen el nombre Beispiel Technik GmbH. Sus referencias de organización ya se han verificado para el ejemplo; no son identificadores oficiales. También se ha confirmado el traslado de la organización desde la antigua dirección Nordweg a Parkweg. La tabla presenta decisiones esperadas de migración, no resultados de una importación realizada.
Registro de origen | Dirección del registro | Organización verificada | Decisión en destino |
|---|---|---|---|
|
|
| Vincular al cliente |
|
|
| Mantener separado y vincular a |
|
|
| Vincular también a |
Las dos primeras filas permanecen separadas pese a compartir nombre. La primera y la tercera pertenecen a la misma organización pese a tener direcciones diferentes. En el ejemplo, Parkweg 6 se adopta como dirección actual del cliente K-900. Esto no debe modificar silenciosamente una dirección de entrega anterior de un pedido existente.
Registre pruebas y casos inciertos antes de importar
Revise las correspondencias con pruebas de identidad adecuadas y aceptadas en el proyecto. Pueden servir referencias fiables y documentación trazable de datos maestros. Los identificadores de la tabla representan el resultado de esa revisión. No deben deducirse simplemente de un nombre parecido.
Sin pruebas fiables, la correspondencia queda pendiente. Registre posibles coincidencias, el motivo de aclaración y el rol responsable. Crear un registro nuevo requiere una decisión confirmada sobre el cliente; no debe evitar la comprobación de identidad que falta. Una fusión también puede afectar a registros relacionados: revise la función concreta del producto antes de usarla.
Reutilice la correspondencia confirmada
Guarde el vínculo entre origen y destino para que una transferencia posterior reconozca el mismo registro. En nuestro diseño, (sourceSystem, sourceId) es la referencia única de origen. Se vincula al identificador de destino confirmado. Los nombres de campos describen nuestro ejemplo, no la API de Dataverse.
Dataverse documenta claves alternativas formadas por una combinación única de valores de columnas. Compruebe durante la revisión técnica qué claves y restricciones admiten sus sistemas. Una lista de correspondencias no impone por sí sola la unicidad en destino.
Compruebe también repetición y relaciones
Transfiera primero los datos de ejemplo a un entorno de prueba adecuado. Compruebe los dos clientes de destino separados, la correspondencia común de la organización trasladada y su dirección actual. Vuelva a enviar las mismas referencias de origen: no debe crearse otro cliente.
Compruebe también a qué cliente de destino se vinculan los pedidos trasladados y si se conservan las direcciones de los documentos históricos. Si una correspondencia confirmada cambia después, deben revisarse por separado sus efectos sobre los vínculos existentes.
Fuentes
Seguir leyendo
Todos los artículos





APIs e integración con ASES
ERP, CRM y tienda bien conectados

