Cómo preparar los datos para una migración de CRM sin trasladar los problemas antiguos al nuevo sistema

Empieza por hacer un inventario de lo que realmente hay

Antes de limpiar nada, documenta los sistemas de origen y los objetos que contienen. Los datos de CRM rara vez se encuentran en una sola tabla bien organizada. Las cuentas, los contactos, las oportunidades, los tickets, las actividades, los responsables, los archivos adjuntos, los objetos personalizados, las hojas de cálculo y las herramientas conectadas pueden aportar registros que requieran una decisión.

Para cada fuente, registra el número de registros, los identificadores clave, los campos obligatorios, los campos personalizados, los valores de las listas de selección, las relaciones, los responsables de los datos y si la información sigue siendo necesaria. Este inventario se convierte en el documento de control de la migración y evita que datos importantes desaparezcan simplemente porque nadie recordaba que existían.

• Enumera todos los sistemas de origen y hojas de cálculo incluidos en el alcance
• Objetos de inventario, campos, relaciones, archivos y historial de actividad
• Anota el número de filas actuales para poder cotejarlas más adelante
• Identifica el responsable de cada campo crítico para el negocio
• Decide qué hay que migrar, archivar, transformar o dejar atrás

Limpia antes de trazar el mapa

Una migración es uno de los peores momentos para conservar datos erróneos por razones sentimentales. Si un contacto está obsoleto, una cuenta está duplicada o un campo no se ha utilizado en tres años, trasladarlo no lo hace más valioso.

En primer lugar, analiza los datos de origen. Evalúa los campos en blanco, las tasas de duplicados, los formatos no válidos, los valores obsoletos, las categorías incoherentes y los registros que no se puedan emparejar con certeza. A continuación, corrige los problemas de mayor riesgo antes de proceder a la asignación. Estandariza los nombres, las fechas, las comunidades autónomas, los países, los formatos de teléfono, los valores de estado y los campos categóricos utilizando reglas explícitas, en lugar de modificaciones puntuales.

DataDabble

Elaborar una matriz de correspondencias de campos

Los campos de origen y destino que parecen similares pueden no tener el mismo significado. Una fase del ciclo de vida, el estado de una cuenta, la fuente de un cliente potencial o la fase de una operación pueden tener una lógica empresarial diferente según el sistema. Por lo tanto, la asignación debe documentar el significado, no solo los nombres de las columnas.

Crea una matriz con el campo de origen, el campo de destino, el tipo de datos, la regla de transformación, los valores permitidos, el comportamiento por defecto, si el campo es obligatorio y quién aprobó la decisión. Incluye los campos que se vayan a retirar para que el equipo sepa que la omisión ha sido intencionada.

Presta especial atención a las listas de selección, los valores de selección múltiple, los formatos de fecha, las divisas, los ID de propietario y los campos personalizados. Se trata de aspectos habituales en los que una importación puede completarse con éxito desde el punto de vista técnico, pero aun así generar registros que no se pueden utilizar.

Proteger los identificadores y las relaciones

Los registros de CRM son relacionales. Un contacto pertenece a una empresa, una operación puede pertenecer a una cuenta, las actividades pertenecen a personas u oportunidades, y los objetos personalizados pueden depender de registros principales. Si se pierden los identificadores estables, resulta difícil reconstruir esas relaciones.

Conserva el ID del registro heredado incluso cuando el nuevo CRM cree su propio ID. Un campo específico para el ID heredado facilita considerablemente la correspondencia, las operaciones «upsert», la resolución de problemas y la conciliación. En el caso de migraciones de varios objetos, planifica el orden de carga de modo que los registros principales existan antes de que se importen los registros dependientes.

No utilices el nombre de una empresa como única clave de relación cuando se disponga de un dominio, un identificador de origen u otro identificador estable. Los nombres cambian y rara vez son lo suficientemente únicos como para garantizar una vinculación fiable.

Realizar una prueba con una muestra representativa

La primera importación no debe ser el conjunto de datos completo de producción. Crea una muestra representativa que contenga registros limpios, duplicados, valores en blanco, texto extenso, valores de listas de selección en casos extremos, múltiples propietarios, relaciones y registros históricos. El objetivo es poner a prueba la asignación, no seleccionar las filas más sencillas.

Tras la prueba, comprueba tanto los recuentos como el significado. Asegúrate de que los registros se hayan almacenado en los objetos previstos, de que las relaciones estén intactas, de que los estados se hayan traducido correctamente, de que se hayan asignado los propietarios, de que las automatizaciones no hayan provocado cambios no deseados y de que los informes necesarios sigan teniendo sentido.

Un mensaje que indique que la carga se ha realizado correctamente no garantiza que la migración se haya llevado a cabo con éxito. La validación debe realizarse dentro del sistema de destino.

Realizar la conciliación antes de la transición

La conciliación es el punto en el que el trabajo de migración se vuelve cuantificable. Compara los recuentos de origen con los de destino por objeto y por segmento importante. Conciliar los totales críticos, los registros sin emparejar, las filas con errores, los recuentos de relaciones y una muestra de cuentas de alto valor.

Define las excepciones aceptables antes de la puesta en marcha. Es posible que algunos registros de origen se archiven, se fusionen o se excluyan de forma intencionada. Documentar esas decisiones evita que el equipo considere cada diferencia en los recuentos como un defecto, al tiempo que permite detectar las diferencias inexplicables.

• Recuento de registros por objeto
• Recuento de duplicados y fusiones
• Filas con errores y rechazadas
• Recuento de relaciones y asociaciones
• Exhaustividad de los campos obligatorios
• Asignaciones de propietarios y valores de estado
• Verificación «de origen a destino» basada en muestras

Planifica la transición como si se tratara de un evento operativo

Una transición de producción requiere un responsable, un periodo de congelación, un plan delta definitivo, criterios de reversión y una lista de comprobación de validación. Decide cuándo dejarán los usuarios de editar en el sistema antiguo, hasta qué momento se registrarán los cambios, quién aprueba la importación final y qué ocurre si falla la conciliación.

Tras la puesta en marcha, supervisa los primeros días de uso real. A menudo, los usuarios detectan problemas de asignación o de flujo de trabajo que pasaban desapercibidos durante las pruebas. Identifica rápidamente esos problemas y corrige la regla subyacente, en lugar de modificar manualmente los registros uno por uno.

La migración más limpia no es aquella en la que se trasladan todos los campos, sino aquella que hace que el nuevo CRM resulte comprensible, trazable y utilizable desde el primer día.