Migración de CRM: qué se rompe cuando el dato se mueve pero el proceso no

Una migración de CRM se cotiza como una exportación de datos y una importación, y ahí es donde ocurre casi todo el daño. Los registros se mueven. Lo que no se mueve solo es el significado detrás de ellos: por qué un trato llevaba seis semanas en una etapa, quién es el dueño real de un territorio cuando dos vendedores tocaron la misma cuenta, y cuáles de los cuarenta campos personalizados alguien todavía lee.

Nada de eso aparece en un conteo de filas. Aparece tres meses después, en un forecast que no coincide con lo que el piso de ventas ya sabe.

Lo que una copia directa realmente pierde

Contactos y empresas migran limpio casi siempre. Todo lo que depende de ellos es donde una copia directa deja de ser segura.

Dato	¿Copia limpio?	Necesita una decisión antes
Contactos y empresas	Sí	Reglas de deduplicación, porque los dos sistemas rara vez coinciden en "misma cuenta"
Tratos y oportunidades	Casi siempre	Un mapa de etapas entre el pipeline viejo y el nuevo, por escrito
Historial de actividad	Rara vez completo	Comprimir en una línea de tiempo, o aceptar la pérdida y decirlo
Campos personalizados	No	Cuáles todavía lee un vendedor antes de una llamada
Reportes y tableros	No	Se reconstruyen contra el nuevo esquema, nunca se copian

El mapa de etapas es el ítem de esa lista que la gente se salta por parecer obvio. No lo es. "Negociación" en un pipeline de cinco etapas y "Negociación" en uno de ocho no son la misma etapa, y mapearlas 1 a 1 cambia en silencio lo que significa cada reporte histórico de conversión.

El corte que no te cuesta un trimestre de pipeline

Dos enfoques, y el equivocado depende de cuánto pipeline hay en curso, no de preferencia.

Un corte de una sola vez funciona cuando el pipeline es lo bastante chico para que un vendedor reingrese lo perdido en un día. Pasadas unas cientos de oportunidades abiertas, no funciona: la ventana de congelamiento necesaria para reconciliar datos crece más de lo que ventas tolera, y los vendedores empiezan una hoja de cálculo paralela apenas empieza el congelamiento, lo que arruina la migración antes de que termine.

Una ejecución en paralelo, donde ambos sistemas siguen vivos y el nuevo se vuelve el sistema de registro solo después de un período de verificación definido, cuesta más tiempo de calendario pero no obliga a congelar nada. Es el mismo razonamiento detrás de una migración por partes para un sistema heredado: reemplazar carga de a poco, mantener el camino viejo funcionando hasta probar el nuevo, y nunca apostar el negocio a un solo fin de semana de corte.

Las disputas de dueño son un problema de migración, no del CRM

Un desacuerdo de territorio o de dueño de cuenta que ya existía en el sistema viejo no se resuelve solo por cambiar de sistema; simplemente se recodifica, casi siempre mal, porque quien corre la migración tiene que elegir un dueño para cada registro ambiguo y rara vez tiene el contexto para elegir bien. Resuelve las reglas de dueño antes de migrar, no durante, la misma disciplina que aplica al integrar alrededor de un ERP heredado sin tocar su modelo de datos.

Corremos migraciones de CRM como parte de nuestra práctica de CRM y Operaciones de Ingresos, con la misma disciplina que cualquier proyecto de modernización: un inventario antes de mover un solo registro, y un mapa de etapas por escrito que ventas aprueba. Cómo protegemos el dato en tránsito, incluido bajo un BAA firmado cuando hay datos de salud, está en nuestras prácticas de seguridad.