--- title: "¿Cómo migra contactos desde otro sistema sin perder datos sin darse cuenta?" blueprint: 005 slug: contact-migration-without-data-loss category: Migración de datos published: 2026-09-23 revised: 2026-09-23 platform: Coevera CRM (formerly Pipeliner CRM) canonical: https://blueprints.coevera.com/es/blueprints/contact-migration-without-data-loss/ language: es translation_of: https://blueprints.coevera.com/blueprints/contact-migration-without-data-loss/ author: Lucia Schmidt publisher: Coevera customer_data: none --- # ¿Cómo migra contactos desde otro sistema sin perder datos sin darse cuenta? **Respuesta corta.** Los fallos de migración son **silenciosos por defecto**. Los problemas estructurales (una fila irregular, un correo electrónico mal formado) se detectan. Los problemas de valor no: un valor de desplegable sin una opción coincidente en el destino queda **vacío**, sin ningún error. Según el recuento sobre una exportación antes de importar, un solo campo habría dejado vacíos **579 de 3432 registros, un 17 %**. Dos reglas hacen la mayor parte del trabajo. **Haga el inventario de la exportación completa, nunca de una muestra**: una muestra de 71 filas mostraba 59 columnas vacías donde el archivo completo tenía 26, y un campo que aparecía relleno al 0 % lo estaba en realidad al 100 %. Y **concilie el conjunto de valores de cada desplegable con las opciones del destino antes de importar**, no después. ## 01 · El problema de negocio Una organización traslada su base de datos de contactos de un sistema al CRM. A primera vista es un ejercicio de mapeo: alinear las columnas, ejecutar la importación y tenerlo terminado antes de comer. Lo que realmente tiene que conseguir: - **Completitud**: cada columna que contiene datos reales acaba en algún sitio, o se descarta por una decisión explícita y no por accidente; - **Atribución**: cada registro llega con el propietario correcto, porque la propiedad determina la visibilidad y los informes; - **Integridad del consentimiento**: la aceptación de comunicaciones de marketing y los indicadores del RGPD llegan intactos, ya que equivocarse aquí tiene consecuencias legales y no solo molestas; - **Idempotencia**: la importación puede ejecutarse dos veces sin producir dos copias de todo, porque *se ejecutará* dos veces; - **Procedencia**: después sigue siendo posible saber de dónde vino cada registro y cuándo se creó originalmente. La exportación de este proyecto tenía 91 columnas de ancho y 3432 registros de fondo. Era estructuralmente limpia: sin filas irregulares, sin direcciones de correo mal formadas o en blanco, sin identificadores de origen duplicados. Todos los problemas que merece la pena contar estaban escondidos dentro de datos por lo demás válidos. ## 02 · Por qué falla el enfoque obvio ### Diseñar el esquema de destino a partir de una exportación de muestra > **La muestra miente, y miente en ambas direcciones.** Una muestra de 71 filas del sistema de > origen mostraba **59 columnas completamente vacías**. La exportación completa de 3432 filas solo > tenía **26** realmente vacías. > > Una columna aparecía **rellena al 0 %** en la muestra y **rellena al 100 %** (los 3432 > registros) en el archivo completo. Si se construye a partir de la muestra, esa columna no tiene > ningún destino. El motivo es prosaico y se puede generalizar: una muestra suele ser un corte reciente, y los registros recientes usan campos distintos de los históricos. Los bloques de dirección, los campos del programa de partners, la atribución de campañas y los datos de referidos probablemente estaban rellenos en los registros antiguos y simplemente no aparecían en una ventana de cuatro semanas. La misma trampa tiene un filo más cortante. En la muestra, todas las direcciones de correo eran únicas, lo que sugería el correo como clave natural de deduplicación. En la exportación completa había **direcciones de correo duplicadas en 10 registros**. Una estrategia de deduplicación elegida a partir de la muestra habría fusionado sin avisar a personas distintas. ### Tratar la exportación como una única lista homogénea Rara vez lo es. Esta exportación contenía varias cohortes distintas de contactos (registros procedentes de un sitio de contenidos, altas en pruebas del producto, prospectos de marketing y un puñado de consultas puntuales) y **el patrón de cumplimentación seguía a la cohorte, no al contacto**. Cada cohorte rellenaba un subconjunto distinto de columnas, y cada una tenía su propio propietario. La consecuencia es de diseño, no de datos: **no construya un único formulario plano**. Dieciocho campos nuevos repartidos entre tres cohortes significan que un único formulario combinado aparece vacío en aproximadamente un 70 % en cada registro, sea cual sea la cohorte a la que pertenezca. ### Mapear las columnas y pulsar importar Aquí es donde se produce la pérdida silenciosa, y merece su propia sección. ## 03 · El fallo silencioso: los valores de los desplegables > **Los campos desplegables se importan por el identificador de la opción, no por la etiqueta.** > Un valor de origen sin una opción coincidente en el destino no da error, no avisa y no detiene > la importación. El campo queda **vacío**. > > **Fuente, y la laguna que contiene.** El centro de ayuda de Coevera, [Importing data into > Coevera — tips on data > preparation](https://help.coevera.com/en/articles/4190964-importing-data-into-coevera-tips-on-data-preparation), > establece el requisito: «no podrá importar registros que contengan valores que no coincidan con > los que tiene en Coevera», y le indica que cree primero las opciones que faltan. Lo que no dice > es qué ocurre realmente si se salta ese paso: el registro se importa y solo se pierde ese campo. > Esa diferencia es todo el contenido de esta sección. Medido en esta exportación, antes de cualquier corrección: | Campo | Quedaría en blanco | Causa | |---|---|---| | Estado del contacto | **579 de 3432 · 17 %** | Cinco valores presentes en el origen no tenían ninguna opción creada, entre ellos un estado que llevaban 335 registros y otro que llevaban 128. | | Nivel de producto | **117 de 418 · 28 %** | Sobre todo **variantes de mayúsculas y minúsculas** de opciones que sí existían, más dos valores numéricos que eran realmente basura. | | Tramo de tamaño del equipo | 39 | Una opción que faltaba, más **fechas corruptas por la hoja de cálculo**. | | Versión del producto | 1 | Una sola variante de mayúsculas y minúsculas. | ### Tres causas distintas, tres soluciones diferentes - **Opciones que nunca se crearon.** El caso obvio, y el más fácil de resolver una vez que ha contado los valores distintos del origen en lugar de suponer el conjunto a partir de la documentación. - **Variantes de mayúsculas y minúsculas.** El mismo valor llega como `Unlimited` y como `unlimited`. No son opciones nuevas: crearlas fragmentaría sus informes. Normalícelas en el momento de la importación. - **Corrupción por la hoja de cálculo.** Valores de rango como `2-4` y `5-10` habían sido convertidos sin avisar en fechas por una hoja de cálculo en algún punto anterior, y llegaban como `4-Feb` y `10-May`. No es culpa del sistema de origen ni del CRM; es lo que ocurre cuando un CSV pasa por una hoja de cálculo. Se detecta contando los valores distintos y leyendo la lista con sus propios ojos. Las tres son invisibles a posteriori. Un campo en blanco tiene exactamente el mismo aspecto que un campo que estaba legítimamente vacío en el origen. ## 04 · Configuración a nivel de campo De 91 columnas de origen, el resultado fue 8 mapeadas a campos estándar existentes, 18 campos personalizados nuevos, y el resto o bien realmente vacías o bien descartadas de forma explícita. ### Qué descartar deliberadamente Algunas columnas con datos no valen nada, e identificarlas forma parte del trabajo: - **Constantes.** Una columna que tiene el mismo valor en todas las filas suele ser el identificador de tenant del sistema de origen o un discriminador de tipo implícito en su mapeo. No aporta ninguna información por registro. - **Artefactos de la exportación.** Una columna era idéntica byte a byte al identificador del registro allí donde estaba rellena, y vacía en el resto: un duplicado producido por la exportación, no un campo que alguien mantuviera. - **Códigos sin tabla de consulta.** Los códigos numéricos no significan nada sin la leyenda, y la leyenda a menudo no se puede exportar. Mejor descartarlos que importar números que nadie sabe interpretar. ### Normalización que debe hacer la importación | Síntoma en la exportación | Corrección antes de importar | |---|---| | Booleanos exportados como `1.00` / `0.00` | Convertir a verdadero/falso | | Identificadores enteros exportados como `104857.00` | Eliminar el sufijo decimal, o se importarán como texto con una cola espuria | | País como códigos ISO-2 en minúsculas | Expandir a los nombres que espera el CRM | | Números de teléfono con espacios y paréntesis incoherentes | Normalizar | | Variantes de mayúsculas y minúsculas en desplegables | Unificar en la opción canónica; no crear una segunda opción | ### Etiquetas Las etiquetas son un campo multivalor, así que un contacto conserva todas sus etiquetas de origen, pero el **vocabulario de etiquetas debe existir en el espacio antes de importar los contactos**. Tres detalles de esta exportación que conviene comprobar en la suya: verifique que el delimitador es realmente seguro (aquí, ningún valor contenía una coma que no fuera seguida de un espacio); vigile los apóstrofos tipográficos, que hacen distintas dos etiquetas visualmente idénticas; y cuente con basura: una etiqueta sin sentido aparecía en 182 registros. ### Pertenencia al formulario > **Cada campo nuevo debe colocarse en el formulario, no solo crearse.** En Coevera, un campo que > existe en el esquema pero no está en el formulario queda inerte; consulte el [Blueprint > 002](https://blueprints.coevera.com/es/blueprints/ai-fields-read-documents/), donde la misma > restricción desactiva sin avisar los campos de IA y los calculados. > > Como la exportación tiene forma de cohortes, divida el formulario en secciones por cohorte en > lugar de listar dieciocho campos en un solo bloque. Tenga en cuenta que las columnas de los > formularios de Coevera deben usar una de las cinco divisiones válidas de cuatro unidades: `[4]`, > `[2,2]`, `[1,1,2]`, `[2,1,1]`, `[1,1,1,1]`. ## 05 · La secuencia de importación El orden importa, porque varios pasos son requisito previo del siguiente. 1. **Haga el inventario de la exportación completa**Cada columna: número de valores rellenos, número de valores distintos y los valores distintos reales de todo lo que vaya a convertirse en desplegable. No la muestra: el archivo entero. 2. **Divida en cohortes**Agrupe las filas por patrón de cumplimentación. Esto determina el diseño del formulario y a menudo revela que un propietario corresponde a una cohorte. 3. **Decida explícitamente el destino de cada columna**Campo estándar, nuevo campo personalizado o descartada con un motivo declarado. Una columna sin decisión es una columna que se perderá. 4. **Concilie las opciones de los desplegables**Para cada desplegable, compare los valores distintos del origen con las opciones del destino. Cree lo que falte de verdad; normalice las variantes de mayúsculas y minúsculas; corrija la corrupción en el origen. 5. **Cree el vocabulario de etiquetas**Antes de importar ningún contacto, o las etiquetas no se asignarán y no habrá aviso. 6. **Cree los campos y colóquelos en el formulario**Ambas cosas, en el mismo cambio. 7. **Escriba un registro real de principio a fin**Una fila real de la exportación, no datos sintéticos. Vuelva a leerlo y compare cada campo. Después elimínelo. 8. **Importe y luego verifique por tasa de cumplimentación**Compare la tasa de cumplimentación de cada campo tras la importación con el número de valores rellenos del origen. Una discrepancia es la única señal de la que dispone. El paso 7 es el que la gente se salta y el que detecta la mayoría de los problemas. Los datos de prueba sintéticos son limpios por construcción; una fila real trae las variantes de mayúsculas y minúsculas, los sufijos decimales y los apóstrofos tipográficos. ## 06 · Límites y compromisos ### Los campos gestionados por el sistema no se pueden importar La marca de tiempo de creación del registro la fija la plataforma. No puede importar en ella la fecha de creación del sistema de origen, así que conservar la procedencia requiere un **campo de fecha personalizado aparte**; decídalo de antemano, porque después no se puede recuperar sin volver a importar. La fecha del último contacto también la gestiona el CRM y no se puede importar. En esta exportación esa columna estaba rellena en **los 3432 registros**, y sin un decimoquinto campo personalizado no habría tenido ningún sitio adonde ir. ### Los campos URL reescriben un dominio al escribirse > **En los valores escritos en un campo de tipo `url`, la cadena `pipelinersales.com` se sustituye > por `coevera.com` en el momento de almacenarse.** Verificado en un espacio en producción el > 2026-09-03 con un control emparejado: el mismo valor escrito simultáneamente en un campo `url` y > en un campo de texto en una misma petición volvió reescrito en el primero y literal en el > segundo. > > Es una sustitución de subcadena aplicada en cualquier parte del valor, **también dentro de las > cadenas de consulta**, de modo que un parámetro de seguimiento o de redirección que haga > referencia al dominio antiguo se redirige sin avisar. El esquema, el subdominio y la ruta se > conservan, y los dominios no relacionados no se tocan. En la migración original esto afectó a 28 > de 29 valores de URL. Si sus datos de origen contienen este tipo de URL y las necesita > literales, use un campo de texto simple en lugar de un campo `url`. ### El propietario es obligatorio, y los nombres no son claves Cada registro requiere un propietario válido, así que las cuentas de usuario deben existir en el destino antes de ejecutar la importación. Mapee por la **dirección de correo electrónico del usuario de origen, no por su nombre visible**: en esta exportación el nombre de un comercial correspondía a dos direcciones de correo distintas, 2432 registros con una y 15 con la otra. Mapear por nombre habría eliminado una distinción real. ### Elija la clave de deduplicación de forma deliberada Importe el identificador de registro propio del sistema de origen en un campo personalizado dedicado. Es único en el origen, se mantiene estable entre reexportaciones y hace que una importación repetida sea idempotente. El correo electrónico es la opción intuitiva y no es seguro: esta base de datos contenía direcciones realmente duplicadas que una muestra no reveló. ### Lo que la exportación no le dirá - **La ausencia de un valor no prueba su ausencia en el sistema de origen.** Todos los estados de aceptación de esta exportación decían *Subscribed*, lo que casi con seguridad significa que la exportación estaba filtrada a los suscriptores, no que nadie se hubiera dado de baja. Importarla como si fuera el panorama completo habría descartado sin avisar la lista de bajas, que es el único error de todo este artículo con consecuencias legales. - **Los problemas reales de calidad de datos viajan con los datos.** Esta exportación traía registros sin nombre, sin apellido o sin ninguno de los dos. La migración no es el momento de corregirlos, pero sí el momento de contarlos. ## 07 · Verificación El modo de fallo es el silencio, así que la verificación no puede ser «¿informó la importación de que todo había ido bien?»: lo hizo. - **Número de campos antes y después.** La entidad Contact pasó de 83 campos a 98. Un simple recuento confirma que cada campo previsto se creó realmente, y detecta el que silenciosamente no se creó. - **Cada opción de desplegable confirmada como presente, con los nombres y el orden correctos**, antes de importar, no después. - **Un registro real escrito de principio a fin**, usando una fila real de la exportación, releído a través de *ambas* API, la REST y la de administración, y comparado campo por campo. Esto es lo que sacó a la luz la reescritura de URL: todos los demás valores se conservaron exactamente y uno no. El registro de prueba se eliminó después. - **Tasa de cumplimentación por campo tras la importación, comparada con el número de valores rellenos del origen.** Esta es la comprobación que detecta el vaciado silencioso de desplegables a escala: un campo que debería tener 3432 valores y muestra 2853 ha perdido 579 registros, y nada más se lo dirá. - **Unicidad de la clave de deduplicación verificada de nuevo en el destino**, no supuesta a partir del origen. - **Asignación de etiquetas comprobada por muestreo** en contactos que deberían llevar varias, ya que las etiquetas fallan en silencio si el vocabulario estaba incompleto. **Qué indicaría una regresión:** un campo desplegable cuyo número de valores rellenos baja tras una reimportación; registros duplicados que aparecen en una segunda ejecución, lo que significa que la clave de deduplicación no está coincidiendo; URL en el destino que difieren del origen; o un indicador de consentimiento con una distribución distinta de la de la exportación. ## Blueprints relacionados - [Blueprint 003 — ¿Cómo modela algo para lo que su CRM no tiene un objeto?](https://blueprints.coevera.com/es/blueprints/where-should-this-data-live/) — cuáles de las noventa y una columnas merecen siquiera un campo, decidido antes de mapear ninguna. - [Blueprint 013 — ¿Cómo añade a su web un formulario de contacto que escriba directamente en su CRM?](https://blueprints.coevera.com/es/blueprints/website-contact-form-into-crm/) — el upsert que impide que un formulario vuelva a crear a las personas que acaba de migrar. - [Blueprint 002 — ¿Cómo consigue que la IA lea un documento y rellene los campos del CRM de forma fiable?](https://blueprints.coevera.com/es/blueprints/ai-fields-read-documents/) — los tipos de campo que se pueden rellenar automáticamente y los que no: la misma restricción de los desplegables, desde el otro extremo. - [Blueprint 016 — ¿Cómo encadena secuencias de correo para que lo que hace un cliente potencial decida lo que ocurre después?](https://blueprints.coevera.com/es/blueprints/chaining-email-sequences-on-engagement/) — lo que hace una lista sin validar en el primer contacto. ## Preguntas frecuentes ### ¿Por qué las importaciones al CRM pierden datos sin avisar en lugar de fallar? Porque los fallos más habituales afectan a los valores y no a la estructura. Un campo desplegable se importa por el identificador de la opción, de modo que un valor de origen sin una opción coincidente en el destino no provoca ningún error: el campo simplemente queda vacío. En una migración, un recuento sobre la exportación antes de importar encontró 579 de 3432 registros, aproximadamente un 17 por ciento, que habrían quedado vacíos en un único campo de estado. Entre las causas había opciones que nunca se crearon, variantes de mayúsculas y minúsculas de opciones existentes, valores basura y hojas de cálculo que convertían sin avisar valores de rango como 2-4 en fechas. ### ¿Se puede diseñar el esquema del CRM de destino a partir de una exportación de muestra? No, y hacerlo es el error más caro posible. En una migración, una muestra de 71 filas mostraba 59 columnas completamente vacías; la exportación completa de 3432 filas solo tenía 26 realmente vacías. Un campo aparecía relleno al cero por ciento en la muestra y al cien por cien en el archivo completo. Las direcciones de correo electrónico eran únicas en la muestra y contenían duplicados en la exportación completa, lo que invalida el correo electrónico como clave de deduplicación. Haga siempre el inventario de la exportación completa antes de diseñar los campos. ### ¿Qué campos del CRM no se pueden rellenar mediante una importación? Los campos gestionados por el sistema. En Coevera, la marca de tiempo de creación del registro la fija la plataforma y no se puede suministrar, así que conservar la fecha de origen del sistema de procedencia requiere un campo de fecha personalizado aparte. La fecha del último contacto también la gestiona el CRM y no se puede importar, lo que significa que una columna de origen totalmente rellena no tiene adónde ir a menos que añada un campo personalizado para ella. Identifíquelos antes de mapear, porque cada uno es o un nuevo campo personalizado o una columna que usted decide descartar. ### ¿Qué se debe usar como clave de deduplicación al importar contactos? El identificador de registro propio del sistema de origen, importado en un campo personalizado dedicado. Está garantizado que es único en el origen, se mantiene estable entre reexportaciones y hace que una importación repetida sea idempotente en lugar de duplicarlo todo. La dirección de correo electrónico es la opción intuitiva y no es segura: las bases de datos de contactos reales contienen direcciones de correo duplicadas, y una muestra puede no revelarlas. La asignación del propietario también debe mapearse por el correo electrónico del usuario de origen y no por su nombre visible, porque la relación entre nombre y correo no es de uno a uno de forma fiable. --- Publicado por Coevera. Abstraído al patrón reutilizable: sin nombres de clientes, sin datos de clientes, sin datos personales.