Migración de CRM: qué se rompe al cambiar, y qué no se transfiere

Por qué la migración de fichas preocupa más de lo que debería

Pregúntale a un líder de ventas qué le asusta de una migración de CRM y casi todos responden alguna versión de "perder los datos de los clientes". En la práctica, la migración de objetos principales, cuentas, contactos, deals, es la parte que las herramientas de migración ya manejan realmente bien. Lo que se rompe de verdad, y lo que los equipos subestiman de forma sistemática, está un nivel por debajo de las fichas: la estructura, la automatización y el reporting construidos alrededor de ellas.

Lo que no mapea limpio: campos, objetos y automatizaciones

Los campos personalizados casi nunca se traducen uno a uno. Un campo desplegable acumulado durante quince años, con la mitad de los valores ya sin uso, o se remapea a mano al equivalente del nuevo sistema, o termina volcado en un campo de texto genérico que pierde toda su estructura. Los objetos personalizados construidos para un flujo específico, un rastreador de renovaciones, un objeto de referidos de partners, muchas veces no tienen equivalente directo y hay que reconstruirlos desde el esquema.

Las automatizaciones y disparadores son peores todavía. Casi nunca se pueden importar tal cual, porque cada CRM construye su lógica de automatización de forma distinta por dentro. Una regla que asigna leads según el territorio, o un disparador que crea una tarea cuando un deal cambia de etapa, hay que recrearla a mano en el constructor de automatizaciones del nuevo sistema, probarla, y validarla contra los casos límite que el sistema anterior venía manejando en silencio durante años.

La actividad histórica: se transfiere, pero no como se espera

Las notas, registros de llamadas e historial de correos generalmente sí migran, pero suelen hacerlo como datos planos en lugar de la línea de tiempo interactiva original. Una nota que hacía referencia a un campo personalizado desde entonces renombrado, o escrita por un usuario que ya dejó la empresa, puede perder el contexto que la hacía útil. Las marcas de tiempo son un dolor de cabeza recurrente: el manejo de zonas horarias difiere entre sistemas, y una actividad que se veía correctamente ordenada en el CRM viejo puede aparecer desplazada varias horas en el nuevo si la herramienta de migración no maneja la conversión con cuidado.

El costo que la mayoría de los equipos no presupuesta: paneles, informes e integraciones

Los informes y paneles guardados casi nunca migran como objetos funcionales. Incluso cuando una herramienta de migración anuncia soporte para reportes, los filtros, agrupaciones y campos calculados subyacentes suelen necesitar reconstrucción manual para realmente igualar lo que la dirección venía consultando. Un panel de forecast que un VP revisa cada lunes por la mañana puede tardar más en reconstruirse bien que toda la migración de contactos.

Las integraciones son el otro costo subestimado. Una plataforma de sales engagement, un dialer, una herramienta de firma electrónica, una plataforma de marketing automation, cada una tiene su propio conector hacia el CRM, y ninguna migra automáticamente solo porque los datos del CRM se movieron. Cada una hay que reconectarla, reautenticarla, y a menudo reconfigurarla para que coincida con los nuevos nombres de campos o estructuras de objetos. Los equipos que planean "la migración" como un evento único suelen descubrir que en realidad es una docena de migraciones más pequeñas ocurriendo en paralelo.

Qué auditar y congelar antes del día de la migración

Antes de mover cualquier dato, audita y documenta tres cosas: cada campo personalizado y su uso actual (elimina los que nadie puede explicar), cada automatización activa y la regla de negocio concreta que aplica, y una lista completa de las integraciones conectadas con un dueño asignado a cada una. Congela los cambios no esenciales en el sistema anterior una o dos semanas antes del corte, porque un campo agregado o un flujo modificado a mitad de la migración es una causa frecuente de fichas que fallan en silencio al mapear.

La estructura de permisos y roles merece su propia revisión. Las reglas de acceso rara vez se traducen limpio, y equivocarse en el nuevo sistema deja a representantes sin acceso a fichas que necesitan o, peor, abre datos que debían seguir restringidos.

Por qué un periodo corto en paralelo gana a un corte total de golpe un viernes

El instinto de migrar todo durante un fin de semana y tener el nuevo sistema totalmente activo el lunes por la mañana es comprensible, y suele ser un error. Un corte total comprime el descubrimiento de cada hueco, un mapeo de campo faltante, una automatización rota, una integración sin reconectar, en un solo fin de semana sin red de contención, y lo que aparece el lunes le cae a un equipo que ya perdió el acceso al sistema anterior.

Correr ambos sistemas en paralelo durante una ventana corta, aunque sean solo unos días, le da al equipo la oportunidad de comparar fichas lado a lado, detectar errores de mapeo mientras los datos viejos siguen siendo consultables, y dejar que los representantes marquen lo que se vea mal antes de que el sistema anterior se apague. Cuesta un poco más de coordinación por adelantado, y evita una semana mucho peor apagando incendios después.

La posición que vale la pena defender

La migración de las fichas principales es la parte de un cambio de CRM que genera más ansiedad y merece menos: la mayoría de las herramientas ya la manejan de forma competente. El costo real está en reconstruir paneles e informes que nunca migran como objetos funcionales, y en reconectar cada integración una por una. Presupuesta tiempo y un responsable específicamente para esos dos puntos, no solo para "mover los datos", y la migración avanzará notablemente mejor de lo que sugieren las historias de terror.