Un caso de éxito de migración de Salesforce a HubSpot debería demostrar cuatro cosas: qué no se transfirió, en qué estado estaba el diccionario de datos antes y después, cuántos workflows se reconstruyeron en lugar de copiarse y si los representantes comerciales siguen usando el sistema tres meses después. Un titular como "terminado en seis semanas, sin interrupción del negocio" no demuestra ninguna de ellas. Le dice a qué velocidad terminó el proyecto, no si lo que salió en vivo funciona.
Leo muchos de estos. El testimonio en la página de inicio de un partner de HubSpot, por ejemplo, dirá que la migración terminó en seis semanas sin interrupciones. Lo creo. También sé que "sin interrupciones" y "nada se rompió" son afirmaciones distintas, y solo la primera aparece en la cita.
Por qué la velocidad es la prueba más débil en un caso de éxito de migración
La velocidad es fácil de reportar y barata de producir. Se pueden mover registros rápido si se omite el trabajo que los hace útiles: deduplicación, decisiones de mapeo de campos, definiciones de etapas, permisos. El calendario luce estupendo. El costo aparece en el tercer mes.
Mi regla general es que un caso de éxito gana confianza en proporción a lo que admite. Si la historia no contiene ninguna pérdida, el autor no miró o no quiso que usted lo hiciera. Por eso, al leer un caso de éxito de migración de Salesforce a HubSpot, ignore el cronograma y busque la columna de pérdidas.
Qué no se transfirió es lo primero que debe pedir
Toda migración deja algo atrás. La pregunta es si el partner sabía qué, lo decidió a propósito y se lo comunicó al cliente antes del go-live.
Los candidatos habituales son el historial de atribución, los archivos y adjuntos, las automatizaciones que dependen de funciones exclusivas de Salesforce, la lógica de los reportes y las estructuras de permisos. El orden de los objetos también importa: la documentación de importación de HubSpot es clara en que las asociaciones dependen de cómo y cuándo se cargan los registros, de modo que una secuencia equivocada elimina en silencio las relaciones entre contactos, empresas y deals.
Esta es la prueba. Pida al partner la lista de "lo que se dejó atrás" de un proyecto anterior. No un resumen: la lista. Una buena lista tiene elementos, cada uno con su motivo (archivado, reconstruido de otra forma, descartado porque nadie lo usaba) y un responsable que lo aprobó. Si la respuesta es "no se perdió nada importante", habrá aprendido algo, aunque no lo que ellos pretendían.
El estado del diccionario de datos en un caso de éxito de migración de Salesforce a HubSpot
El diccionario de datos es el documento que indica qué significa cada campo, quién es su responsable, qué valores se permiten y qué sistemas escriben en él. La mayoría de las orgs de Salesforce con cinco años de antigüedad no tienen ninguno en el que alguien confíe. Cientos de campos, varios que significan lo mismo, un puñado que nadie sabe explicar.
Migrar ese desorden uno a uno es lo que yo llamo un lift and shift, y es la razón más común por la que un portal nuevo se siente como el anterior con otro logotipo. Un caso de éxito sólido indica la cantidad de campos antes y después. Si una empresa pasó de 400 propiedades personalizadas a 150, eso es evidencia de que alguien tomó decisiones. Si pasó de 400 a 400, el proyecto solo cambió los muebles de lugar.
Los duplicados son la misma historia en miniatura. Un cliente con el que hablamos tenía alrededor de 1.300 registros duplicados en su CRM de origen y transiciones de etapas del pipeline sin probar, con una fecha límite encima. Esos dos hechos son el proyecto. El cambio de plataforma es la parte fácil. Dado que las dos plataformas gestionan los duplicados de manera distinta, como explica la guía de deduplicación de HubSpot, un caso de éxito debería decir cuándo se hizo la limpieza y quién decidió qué registro prevalecía.
Reconstrucción de workflows: cuéntelos y pregunte qué se retiró
Las automatizaciones no se migran. Se reconstruyen, y en la reconstrucción es donde está el criterio. Un partner que reconstruye en HubSpot cada flujo de Salesforce ha trasladado su deuda técnica de un sistema a otro.
Pida tres cifras: workflows en el sistema anterior, workflows reconstruidos y workflows retirados. Luego pida un ejemplo de cada uno. Por ejemplo, una regla de asignación de leads que nadie sabía explicar debería retirarse, un recordatorio de renovación del que todos dependen debería reconstruirse, y un disparador de cambio de etapa que alimentaba un dashboard que nadie abre debería descartarse. Si un caso de éxito no puede mostrar esa división, la reconstrucción fue mecánica.
Aquí también se ponen a prueba el enrutamiento y las definiciones de etapas. Nuestro artículo sobre cómo distinguir un portal roto de una cotización de reconstrucción aborda el mismo instinto desde el otro lado.
La adopción posterior al go-live es el único resultado que cuenta
Los resultados de búsqueda sobre este tema casi siempre se detienen en el go-live. Ahí se detiene la factura, y ahí mismo empieza el riesgo. Los representantes vuelven a las hojas de cálculo, los gerentes dejan de confiar en el forecast y marketing reconstruye en silencio sus propios reportes.
No tengo un benchmark limpio del sector sobre la adopción por parte de los representantes noventa días después de una migración de CRM, y desconfío de quien cita uno. Lo que le pediría a un caso de éxito es sencillo: inicios de sesión y actividad registrada por representante a los 30, 60 y 90 días, precisión del forecast frente al trimestre anterior y la fecha en que el sistema antiguo se apagó definitivamente. También el reporte que finanzas y ventas firmaron. Si la atribución formaba parte de la configuración anterior, revise qué ocurrió con ella; buena parte del tráfico influido por IA y sin etiquetar ya aparece como directo en HubSpot, como explicamos en referidos de IA clasificados como tráfico directo.
¿El caso de éxito de migración de Salesforce a HubSpot trata de una empresa como la suya?
Un caso de éxito solo es evidencia si el protagonista se parece a usted. Pregunte cuatro cosas: volumen de registros, cantidad de custom objects, cantidad de integraciones activas y cantidad de usuarios. Un equipo de 15 licencias sin custom objects y un equipo de 300 licencias con CPQ son proyectos distintos que casualmente comparten título.
Luego pregunte cuánto costó en total. La cotización es una sola cifra. Sume los honorarios del partner, la superposición de licencias mientras funcionan ambos sistemas, el tiempo de los representantes perdido en recapacitación y el retrabajo. Ejemplo con supuestos únicamente: si 40 representantes pierden dos horas a la semana durante seis semanas, son 480 horas de venta, antes de cualquier retrabajo. Los buenos partners repasarán esto con usted, porque es la versión honesta del precio.
Una lista de verificación breve para cualquier caso de éxito de migración de Salesforce a HubSpot
Antes de firmar, pida al partner que le muestre, de un proyecto real:
- La lista de lo que se dejó atrás, con responsables
- Cantidad de campos y propiedades antes y después
- Workflows reconstruidos frente a retirados
- Cifras de adopción y de forecast a los 30, 60 y 90 días
- Costo total frente a la cotización original
Son cinco documentos. Un equipo que los tiene se los entregará en minutos, porque nosotros también nos enorgullecemos de documentar nuestros proyectos, por raro que suene. Un equipo que no los tiene le ha dicho lo que necesitaba saber.
Si desea ver cómo es esa evidencia en nuestro propio trabajo, comience por nuestro caso de éxito de migración de CRM y el scope de nuestro servicio de migración de Salesforce a HubSpot. Júzguenos con la misma lista. El mismo hábito se aplica fuera del trabajo con CRM: las pruebas pesan más que el posicionamiento, que es el argumento de SEO rankings frente a citas en IA y de por qué añadir AEO a una consultora de implementación se queda corto.