Lista de verificación para importar datos a un CRM: cómo probar un CRM autoalojado antes de trasladar tus registros

Por qué la calidad de la importación importa más que una primera carga correcta

Un botón de importación no es un plan de migración. Una primera carga puede parecer correcta mientras crea silenciosamente contactos duplicados, asigna registros al equipo equivocado, vincula una oportunidad con la organización incorrecta o descarta filas que no superan la validación.

Evalúa la capacidad de importación como un sistema de control. Debes saber qué crea, actualiza, rechaza e informa la aplicación; si puedes corregir los fallos; y si una ejecución repetida es segura. La pregunta relevante no es «¿Puede importar CSV?», sino «¿Podemos generar registros fiables a partir de nuestros datos de origen reales, de forma repetible?».

Los distintos CRM implementan estos controles de formas diferentes. Por ejemplo, EspoCRM documenta los modos de importación Solo crear, Crear y actualizar y Solo actualizar. Sus modos que permiten actualizar requieren que el operador elija campos que identifiquen un registro existente. Esa elección es una decisión de gobierno de datos, no un valor técnico predeterminado. Consulta la [documentación de importación de EspoCRM](https://docs.espocrm.com/administration/import/).

• No apruebes un CRM basándote únicamente en un archivo de demostración limpio.
• Prueba con los mismos tipos de datos, inconsistencias y relaciones que se encuentran en la exportación de producción.
• Registra cada decisión de configuración utilizada en cada ejecución de prueba.
• Define el éxito como registros precisos y utilizables, con excepciones explicables.

Empieza con un inventario de los datos de origen

Crea un inventario antes de asignar una sola columna. Las hojas de cálculo y los CRM de origen suelen guardar información relacionada en pestañas, módulos, notas de texto libre y repositorios de archivos separados. Si el inventario solo cuenta contactos, la migración puede parecer completa mientras se pierde el contexto comercial, la propiedad o el historial operativo.

Para cada tabla o exportación de origen, identifica su propósito empresarial, número de registros, identificador principal, propietario actual, responsable de los datos, entidad de destino y dependencias de relación. Marca qué datos son esenciales el primer día y cuáles pueden aplazarse o archivarse fuera del CRM.

Incluye actividades solo después de confirmar que el modelo de destino admite los registros y paneles pertinentes. En EspoCRM, por ejemplo, los paneles disponibles de Actividades, Historial y Tareas dependen del tipo de entidad configurado. No supongas que cada entidad personalizada mostrará la misma información relacionada que un registro de persona u organización. Consulta la [documentación del Administrador de entidades de EspoCRM](https://docs.espocrm.com/administration/entity-manager/).

• Registros principales: personas, organizaciones, prospectos, oportunidades o entidades equivalentes.
• Relaciones: contacto a organización, oportunidad a contacto, registros padre-hijo y cualquier vínculo de muchos a muchos.
• Contexto operativo: notas, llamadas, reuniones, tareas, correos electrónicos e historial, cuando sea necesario.
• Archivos: adjuntos, documentos, rutas de archivos y enlaces a repositorios externos.
• Datos de configuración: campos personalizados, valores enumerados, etiquetas, equipos, propietarios y estados.
• Identificadores de origen: ID de la hoja de cálculo o del sistema anterior para cada entidad.

Define el modelo de datos de destino antes de asignar campos

La asignación de campos debe seguir un modelo de destino acordado deliberadamente, no el deseo de conservar cada columna de origen. Decide qué entidades de destino existirán, qué campos son obligatorios, cuáles son personalizados, qué valores son listas controladas y qué información debe permanecer fuera del CRM.

Para cada campo de origen, selecciona un resultado: asignar directamente, transformar, dividir, combinar, colocar en un campo personalizado controlado, conservar en un archivo o excluir. Documenta el motivo. Una columna de «estado» de texto libre, por ejemplo, no debe asignarse a un campo de estado restringido hasta que se hayan revisado y normalizado sus distintos valores de origen.

Comprueba la elegibilidad de importación a nivel de campo. La documentación de Studio de SuiteCRM describe la configuración de campos y relaciones, incluida la posibilidad de permitir, no permitir o exigir campos para las importaciones mediante el Asistente de importación. También identifica el tipo de campo, la auditoría y la configuración de fusión de duplicados como propiedades de los campos. Los controles exactos varían según el CRM, así que valida la aplicación de destino en lugar de inferirlos de otro producto. Consulta la [documentación de Studio de SuiteCRM](https://pre-release.docs.suitecrm.com/admin/administration-panel/studio/).

• Entidad de destino y nombre del campo.
• Tabla, columna y tipo de dato de origen.
• Regla de transformación y valores permitidos.
• Estado obligatorio, opcional, sensible o de solo lectura.
• Elegibilidad para importación y comportamiento predeterminado.
• Responsable de la decisión de asignación y del resultado de la prueba.

Crea una importación de prueba representativa en lugar de usar una muestra depurada

Una muestra impecable solo demuestra que se pueden importar datos impecables. Crea un pequeño conjunto de datos de prueba representativo a partir de copias de registros reales, protegiendo los valores sensibles según sea necesario. Conserva los problemas que realmente contienen tus datos de producción para que la prueba revele cómo se comporta el importador.

Incluye registros ordinarios y casos límite deliberados. Prueba valores obligatorios vacíos, valores incompatibles para listas controladas, nombres duplicados, direcciones de correo electrónico duplicadas, ID de origen repetidos, formatos de teléfono inconsistentes, campos de varios valores, puntuación, caracteres no ASCII y fechas escritas en más de un formato.

Los fallos de validación son pruebas valiosas. EspoCRM documenta que una fila que no supera la validación no crea un registro, e incluye entre sus ejemplos valores enum incompatibles y valores vacíos para un enum no vacío. Tu prueba debe confirmar el comportamiento equivalente en el CRM que estás evaluando, incluido lo que ocurre con los campos válidos de una fila parcialmente inválida. Consulta la [documentación de importación de EspoCRM](https://docs.espocrm.com/administration/import/).

• Usa un número conocido de registros para cada archivo de prueba.
• Etiqueta los registros de prueba para poder encontrarlos e inspeccionarlos más tarde.
• Conserva una copia intacta del extracto de prueba original.
• Incluye filas conocidas como válidas, conocidas como inválidas e intencionadamente ambiguas.
• No sustituyas valores de producción por marcadores de posición artificialmente uniformes.

Prueba las decisiones que generan datos deficientes en el CRM: duplicados, valores ausentes, formato, propiedad y permisos

El control de duplicados empieza con una política de coincidencia explícita. Decide qué identificadores de origen son autoritativos, si el correo electrónico es suficientemente único para tu caso de uso y cómo debe tratar el CRM una coincidencia en un campo pero no en otro. Registra los campos de coincidencia exactos seleccionados en cada ejecución.

Los identificadores de origen estables son especialmente importantes para los ciclos de corrección. Odoo documenta que los ID externos coherentes pueden permitir importaciones repetidas sin crear duplicados, mientras que cambiar o eliminar un ID externo puede generar un registro nuevo en lugar de una actualización. Tanto si el CRM elegido utiliza ID externos como otro mecanismo de identificación, verifica que su identificador se conserva durante la reimportación exactamente como se espera. Consulta la [documentación de exportación e importación de Odoo](https://www.odoo.com/documentation/18.0/applications/essentials/export_import_data.html).

No confíes en la detección automática de fechas. Odoo señala que los formatos de fecha pueden reconocerse incorrectamente, incluidas las inversiones de día y mes, y recomienda comprobar o establecer un formato ISO 8601. Incluye fechas ambiguas como 03/04/2024 en el archivo de prueba e inspecciona el valor guardado, no solo la vista previa de importación.

La propiedad exige el mismo nivel de análisis. EspoCRM puede aplicar valores predeterminados, incluidos Usuario asignado y Equipos, a los registros nuevos y actualizados durante la importación. Prueba si se conserva el propietario de origen, se traduce, se sustituye por un valor predeterminado o queda sin asignar. Después decide qué comportamiento es aceptable para cada entidad. Consulta la [documentación de importación de EspoCRM](https://docs.espocrm.com/administration/import/).

Prueba también los permisos con el rol que realizará la operación de producción, no solo con una cuenta de administrador. Para datos sensibles, verifica qué campos puede ver y editar ese rol después de la importación, y si puede reasignar registros. En EspoCRM, los roles pueden restringir las acciones de crear, leer, editar y eliminar; el permiso de asignación puede restringir la reasignación; y la seguridad a nivel de campo puede restringir la lectura y edición de campos específicos. Consulta la [documentación de gestión de roles](https://docs.espocrm.com/administration/roles-management/).

• Crea un registro con un ID de origen existente y datos no clave modificados; prueba la ruta de actualización prevista.
• Crea dos registros con nombres similares pero ID distintos; asegúrate de que no se fusionen accidentalmente.
• Prueba campos vacíos en un archivo de actualización para saber si borran valores existentes, se ignoran o no superan la validación.
• Prueba formatos de fecha, número, moneda, teléfono y selección múltiple.
• Prueba un registro cuyo propietario original ya no existe en el destino.
• Inspecciona los valores de propietario y equipo después de ejecuciones de creación y de actualización.
• Con el rol previsto, comprueba la visibilidad y edición de campos sensibles en registros importados.
• Con el mismo rol, comprueba si la reasignación de propiedad está permitida o restringida según lo previsto.

Verifica las relaciones y el historial: contactos, organizaciones, oportunidades, notas, tareas y adjuntos

La precisión de las relaciones suele ser la diferencia entre un CRM útil y un directorio de registros desconectados. Crea casos de prueba en los que una organización tenga varios contactos, una oportunidad tenga varias personas relacionadas y los registros compartan nombres para mostrar similares o idénticos. Comprueba cada relación desde ambos lados en la interfaz de destino.

Importa las entidades padre antes que las entidades hijo cuando la relación dependa de registros importados previamente. SuiteCRM indica a los usuarios que importen Cuentas antes que los Contactos relacionados para que se pueda establecer la relación. Odoo también documenta la importación previa de objetos relacionados cuando las relaciones se recrean mediante ID externos. Consulta la [documentación de gestión de registros de SuiteCRM](https://docs.suitecrm.com/8.x/user/core-concepts/record-management/) y la [documentación de exportación e importación de Odoo](https://www.odoo.com/documentation/18.0/applications/essentials/export_import_data.html).

Evita basarte en nombres para la coincidencia de relaciones cuando pueda haber ambigüedad. Odoo advierte que, cuando varios registros relacionados tienen el mismo nombre, los datos pueden vincularse con el primer registro coincidente. Usa identificadores estables para los campos de relación cuando el destino los admita y demuestra el resultado con registros de prueba deliberadamente ambiguos.

Los adjuntos y el historial de actividades merecen pruebas de aceptación independientes. Confirma si los archivos se importan, vinculan, omiten o requieren un procedimiento específico del producto. No supongas que el importador CSV utilizado para registros principales también importa adjuntos, notas, tareas o historial. Para cualquier procedimiento compatible, confirma que las fechas, autores, registros padre y permisos sean adecuados.

• Importa organizaciones o cuentas antes que los contactos relacionados.
• Importa oportunidades o casos padre antes que sus notas y actividades dependientes cuando el modelo lo requiera.
• Usa ID de origen para conectar registros en vez de nombres para mostrar cuando sea posible.
• Inspecciona los recuentos de relaciones y los vínculos individuales en la aplicación.
• Abre adjuntos de muestra y verifica su asociación con el registro previsto.
• Comprueba las fechas de actividad, creadores, asignados y visibilidad.

Comprueba cómo informa la aplicación de los registros rechazados o modificados

Un importador que solo informa de un total final es difícil de operar con seguridad. Exige pruebas de cada fila rechazada: su fila o identificador de origen, el motivo del fallo y los valores proporcionados. Exige también una forma de distinguir entre registros recién creados, actualizaciones y filas omitidas.

EspoCRM ofrece un panel de Errores que incluye el motivo del fallo, el índice de fila y los valores de la fila, y puede exportar filas fallidas a CSV para corregirlas y reimportarlas. La documentación de SuiteCRM describe de forma similar una pestaña Errores para revisión y corrección antes de volver a ejecutar una importación. Trátalos como ejemplos útiles de las pruebas que debes buscar, no como una suposición de que todos los CRM exponen informes idénticos. Consulta la [documentación de importación de EspoCRM](https://docs.espocrm.com/administration/import/) y la [documentación de gestión de registros de SuiteCRM](https://docs.suitecrm.com/8.x/user/core-concepts/record-management/).

Ejecuta una prueba que contenga registros válidos, registros inválidos y candidatos a actualización. Concilia el recuento de origen con los resultados de creación, actualización, rechazo y omisión. Cualquier diferencia sin explicación es un criterio de aceptación no superado.

• ¿Puedes exportar las filas fallidas para corregirlas?
• ¿Cada error identifica una fila de origen o un ID de origen estable?
• ¿El informe explica el fallo en términos operativos?
• ¿Puedes distinguir entre creaciones, actualizaciones, rechazos y omisiones?
• ¿Puedes guardar la configuración de asignación y comprobación de duplicados para una ejecución repetible?
• ¿Puedes inspeccionar directamente los registros resultantes desde el informe de importación?

Prueba la corrección y la reimportación sin multiplicar registros ni sobrescribir datos fiables de forma involuntaria

La prueba de importación más importante suele ser la segunda. Corrige un conjunto limitado de filas rechazadas y vuelve a importar el archivo corregido usando el modo de actualización y las reglas de coincidencia previstos. Confirma que los registros corregidos se crean o actualizan una sola vez, que los registros ya importados correctamente no se duplican y que los campos no relacionados siguen siendo fiables.

Separa el comportamiento de creación del comportamiento de actualización en tus criterios de aceptación. En EspoCRM, Solo crear crea registros, mientras que Crear y actualizar y Solo actualizar utilizan los campos de coincidencia seleccionados para encontrar registros que actualizar. Un equipo de producción debe saber qué modo utilizará para la carga inicial, la corrección de errores y las actualizaciones incrementales posteriores. Consulta la [documentación de importación de EspoCRM](https://docs.espocrm.com/administration/import/).

Prueba los valores vacíos y modificados con cuidado. Una reimportación puede sobrescribir información editada después de la primera importación, según el modo y las asignaciones seleccionados. Establece una ventana de transición, identifica el sistema de registro de cada campo durante la migración y define si las ediciones posteriores a la importación se protegen, se sobrescriben o se concilian manualmente.

Conserva el ID de origen estable en cada archivo de corrección. No lo modifiques simplemente para hacer que desaparezca un error; eso puede convertir una actualización prevista en un registro nuevo. Odoo documenta este riesgo para los ID externos. Consulta la [documentación de exportación e importación de Odoo](https://www.odoo.com/documentation/18.0/applications/essentials/export_import_data.html).

• Ejecuta una importación inicial y registra los ID creados y los ID de origen.
• Corrige únicamente las filas fallidas y conserva sus identificadores originales.
• Vuelve a importar y compara los recuentos de registros antes y después.
• Prueba deliberadamente un valor modificado en un registro existente.
• Prueba deliberadamente un valor vacío en un registro existente.
• Comprueba si los campos editados en el CRM después de la primera carga se conservan o se sobrescriben según lo previsto.