Autor: Paula Hermogenes

La migración de datos a Salesforce funciona mejor cuando parte de una pregunta de negocio en lugar de una hoja de cálculo. ¿Qué hay que mejorar una vez que los nuevos datos estén en el sistema? Para los equipos empresariales, el trabajo va más allá de simplemente trasladar registros desde un CRM o ERP antiguo o desde una empresa adquirida. Te da la oportunidad de replantearte cómo funcionan realmente las relaciones con los clientes, los procesos de ventas, la generación de informes, el cumplimiento normativo y las integraciones. Los riesgos no están lejos. Sin un plan claro, los viejos problemas con los datos pueden trasladarse directamente a la nueva configuración de Salesforce.

Un campo que parezca sin sentido puede que, aun así, impulse procesos de renovación. Dos contactos que parezcan duplicados pueden indicar relaciones reales dentro de una misma cuenta. Las oportunidades históricas pueden no tener mucha importancia para el trabajo diario de ventas, pero siguen siendo fundamentales para la auditoría financiera o las previsiones. Una buena migración de CRM combina la responsabilidad empresarial, la gestión de datos, una ejecución cuidadosa y pruebas reales con los usuarios. El objetivo no es solo trasladar información, sino crear una plataforma en la que la gente pueda confiar.

Lo primero es definir el caso de negocio y el alcance de la migración

Una práctica clave es definir el alcance en función del valor para el negocio. Trasladar todos los registros suele parecer la opción más segura, pero aumenta los costes, alarga los plazos, consume almacenamiento y deja Salesforce lleno de elementos obsoletos y de baja calidad. Empieza, en cambio, por definir los resultados que debe ofrecer el nuevo entorno. Estos podrían ser una visión única y fiable del cliente, informes más precisos sobre el proceso de ventas, una resolución más rápida de las incidencias, traspasos fluidos entre equipos, un mejor seguimiento de los consentimientos o una integración financiera más fluida. Estos resultados determinan qué objetos, campos, actividades, archivos y relaciones se trasladan realmente.

Los equipos tienen que separar los datos operativos activos del material archivado. Un equipo de ventas podría necesitar, dentro de Salesforce, cuentas actuales, contactos activos, oportunidades abiertas y unos cuantos años de historial de oportunidades cerradas con resultado positivo, mientras que los datos más antiguos deben guardarse en un archivo regulado o en una herramienta de análisis. No hay una regla fija de retención. La elección depende de la normativa, las necesidades de presentación de informes, las demandas de los usuarios y el coste que supone conservar el historial.

Elabora un inventario de migración en el que se incluyan todos los sistemas de origen, los propietarios de los datos, los objetos, los campos, los registros, el volumen, los problemas de calidad conocidos y los sistemas de destino. Ten en cuenta desde el principio los sistemas conectados. Una migración puede perder fiabilidad rápidamente si un ERP, una herramienta de marketing o una aplicación personalizada sigue aportando datos incoherentes.

Establece la gobernanza de datos antes de asignar campos

La asignación de campos suele considerarse un simple paso técnico en el que un campo del sistema heredado se convierte en un campo de Salesforce. Un enfoque más sólido plantea tres preguntas: ¿Qué significa este campo? ¿Quién es el responsable de la información? ¿Cómo debería utilizarse en Salesforce?

Los talleres de mapeo necesitan que participen los responsables de los procesos de negocio, los administradores de Salesforce, los especialistas en datos, los equipos de integración, los responsables de seguridad y los representantes de los usuarios finales. Deben ponerse de acuerdo sobre el significado de términos como «cliente activo», «cliente potencial cualificado», «ingresos», «producto», «territorio» y «fase de venta». Si no hay acuerdo, puede que los registros se carguen bien, pero los informes, los flujos de trabajo y los paneles de control no coincidan.

Reglas de transformación de documentos durante la asignación. Ten en cuenta si los valores se van a estandarizar, fusionar, dividir, asignar un valor por defecto, convertir o eliminar. Es posible que varios estados de clientes potenciales heredados se agrupen en una lista de selección de Salesforce más reducida. Las notas de sector en formato de texto libre pueden asignarse a una lista aprobada. Es posible que haya que normalizar los formatos de país y estado para garantizar el cumplimiento de la asignación de territorios y las integraciones.

Asigna responsables claros a áreas clave como los datos maestros de clientes, el proceso de ventas, los productos, los casos de servicio y los registros de consentimiento. Las comprobaciones técnicas pueden detectar problemas, pero la responsabilidad empresarial evita que la calidad baje tras el lanzamiento.

Limpia y prepara los datos antes de la migración

Salesforce no corrige por sí solo los elementos incompletos, duplicados o contradictorios. Limpiar los datos antes de la migración suele causar menos trastornos que pedir al personal que corrija miles de registros más adelante.

Empieza por analizar los datos de origen. Echa un vistazo a los registros duplicados o casi duplicados, los valores que faltan en los campos obligatorios, las fechas no válidas, los correos electrónicos o números de teléfono erróneos, los valores incoherentes en las listas de selección, los registros obsoletos y los vínculos padre-hijo rotos. Los resultados pueden cambiar el alcance y la secuencia del proyecto. Por ejemplo, importar contactos sin vínculos sólidos con cuentas puede hacer que sea difícil navegar por Salesforce, automatizar procesos o generar informes.

La deduplicación necesita tener en cuenta el contexto empresarial. Dos contactos con el mismo correo electrónico pueden ser duplicados, pero las bandejas de entrada compartidas, las empresas familiares, las redes sanitarias o las estructuras corporativas complejas pueden suponer excepciones válidas. Las reglas de coincidencia deben encontrar el equilibrio entre precisión y flexibilidad. Las reglas demasiado estrictas pueden fusionar clientes distintos, mientras que las reglas poco rigurosas dejan a los usuarios con varias versiones de la misma persona o empresa.

Las actividades y los archivos adjuntos históricos también deben revisarse de forma similar. Pasar todos los correos, documentos y llamadas relacionados con las tareas puede crear un historial más completo, pero también puede complicar el uso de Salesforce y aumentar los costes de almacenamiento. Céntrate en el historial que respalde las relaciones activas, las necesidades normativas, la continuidad del servicio y la información comercial útil.

Elabora un plan de migración a Salesforce que se pueda repetir

El plan debe abarcar más que la fecha de lanzamiento final. Debe explicar cómo se trasladarán los registros, cómo se gestionarán los errores, quién validará los resultados y qué pasará si la migración no sale bien.

En configuraciones complejas, un enfoque por fases suele ser más seguro que una migración a gran escala de una sola vez. Primero se pueden trasladar los datos de referencia y, después, las cuentas, los contactos, las oportunidades, los casos, las actividades y los archivos. El orden es importante porque las relaciones en Salesforce dependen de los ID de los registros. Normalmente, los registros principales tienen que existir antes de que se puedan crear los registros secundarios.

Un plan práctico debería incluir una copia de seguridad completa de los datos de origen, un método documentado de recuperación o reversión, un proceso de migración repetible, la conservación segura de los identificadores heredados, reglas de conciliación entre el origen y el destino, personas designadas para dar el visto bueno y criterios de aceptación claros.

La elección de la herramienta debe ajustarse a la escala y la complejidad del proyecto. El Data Loader oficial de Salesforce se encarga de la importación, actualización, exportación y eliminación masiva de datos, incluidos los objetos personalizados. Las API, el middleware, las plataformas ETL o los scripts personalizados pueden ser más adecuados cuando las transformaciones son complejas, los volúmenes son elevados o hay varios sistemas implicados. Sea cual sea la herramienta que elijas, el proceso debe permitir la repetibilidad, la notificación de errores, la auditabilidad y la supervisión.

Pruebe los procesos comerciales, no solo registre recuentos.

Una migración no se considera exitosa simplemente porque todos los registros se cargaron sin errores. El recuento de registros confirma el movimiento, pero no demuestra que los representantes de ventas puedan gestionar las oportunidades, que los agentes de servicio puedan localizar al cliente adecuado o que los ejecutivos puedan confiar en los paneles de control.

Realiza pruebas de migración de datos de Salesforce en un entorno de pruebas representativo, con volúmenes realistas y datos anonimizados cuando sea pertinente. Comprueba las relaciones entre registros, las reglas de visibilidad y de uso compartido, los controles de gestión de duplicados, las reglas de validación, los informes y paneles de control automatizados, los diseños de página y los flujos de trabajo de los usuarios, las integraciones con sistemas externos y los requisitos de seguridad y auditoría.

Las pruebas de aceptación de los usuarios deberían reflejar el trabajo real. Los responsables de ventas pueden comprobar los totales del canal de ventas. Los equipos de finanzas pueden conciliar los ingresos. Los equipos de operaciones pueden probar los traspasos de tareas. Los equipos de atención al cliente pueden confirmar que tienen acceso al historial de los casos relevantes.

Establece unos umbrales de calidad cuantificables antes de empezar las pruebas. Estos pueden incluir los niveles aceptables de duplicados, el grado mínimo de completitud de los campos críticos, las tasas de coincidencia de relaciones y las variaciones permitidas en los totales de ingresos. Salesforce también recomienda probar las operaciones con datos en un pequeño subconjunto antes de realizar una carga completa y hacer una copia de seguridad de la información antes de realizar cambios a gran escala.

Considera la transición y la estabilización como un único proceso

La puesta en marcha es una transición controlada, no el final de la migración. El plan de transición debe coordinar las congelaciones de datos, las extracciones finales, las integraciones de sistemas, las comunicaciones con los usuarios, la cobertura del soporte técnico y los puntos de control de validación. También debe definir las responsabilidades, las dependencias, las vías para escalar y los criterios de reversión.

Tras la puesta en marcha, hay que revisar los registros de errores del monitor, los datos duplicados, la integridad de los datos, la adopción, las excepciones de integración y las variaciones en los informes. Los primeros treinta a sesenta días suelen poner de manifiesto dónde se necesita más formación, automatización, gobernanza o cambios de diseño. Este periodo de estabilización convierte una migración técnica en un modelo operativo sostenible.

Las organizaciones que gestionan sistemas complejos o información confidencial sacan partido de considerar Salesforce como parte de un ecosistema digital más amplio. Cuando todos estos elementos encajan, la migración de datos a Salesforce va más allá de simplemente sustituir un sistema antiguo. Ofrece a los equipos información más clara, procesos más fiables y una base más sólida para crecer.