7min.
7min.
Migrar de Salesforce a HubSpot da resultado cuando primero se define cómo vende la empresa y recién después se mueven los datos. Las etapas, las propiedades, las reglas de uso y la atribución por canal se diseñan antes del traspaso, para que la plataforma nueva no herede el desorden de la anterior.
Hay dos formas de migrar de Salesforce a HubSpot. La primera traslada los registros tal como están y espera que la plataforma nueva ordene lo que la anterior no ordenó. La segunda usa la migración para rediseñar el proceso comercial y llega al traspaso con las definiciones ya acordadas.
Plan B Immigration, una consultoría migratoria que opera para Canadá, España e Irlanda, hizo el cambio a HubSpot con Ploy. En dieciséis meses sobre la plataforma nueva registró 73.925 contactos y 1.581 clientes, y descubrió que sus consultas por referido convertían al 9,66%, frente a un rango de 0,27% a 0,30% en pauta paga.
Las empresas de servicios que vendían por referido y contacto directo hoy reciben volúmenes de consultas que ningún equipo puede atender con criterio individual. La escala llegó antes que el proceso, y la plataforma que se configuró en otra etapa del negocio empieza a quedar corta para la operación actual.
Los síntomas se repiten. Los reportes de pipeline hay que limpiarlos a mano antes de cada reunión de dirección. Cada vendedor carga los datos a su manera porque las etapas no reflejan lo que realmente pasa en una venta. Las consultas que entran por WhatsApp, por un referido o por una feria quedan fuera del sistema. Y cuando alguien pregunta qué canal trae los clientes que de verdad cierran, la respuesta depende de a quién se le pregunte.
Esta situación no es una falla de Salesforce ni del equipo comercial. Es un problema de diseño: la configuración se armó para un negocio que ya cambió, y nadie tuvo el tiempo ni el respaldo interno para rediseñarla. Una plataforma que le agrega pasos al equipo sin devolverle información deja de usarse, cualquiera sea su marca. El cambio de herramienta resuelve eso solo si viene acompañado del rediseño.
Por eso la decisión de migrar suele aparecer en tres momentos: cuando la empresa suma una línea de servicio o un mercado nuevo, cuando marketing y ventas necesitan trabajar sobre el mismo dato, o cuando el costo de sostener la configuración actual supera el de rehacerla. En los tres, la pregunta de fondo es la misma: qué tiene que mostrar el sistema para decidir mejor. Responderla antes de mover cualquier dato ahorra meses de corrección después.
Una migración que copia los registros tal cual tiene tres costos. El primero es de tiempo: los duplicados, los campos que nadie usa y las etapas que no significan lo mismo para todos viajan a la plataforma nueva, y hay que limpiarlos otra vez del otro lado. El segundo es de adopción: si el equipo encuentra en HubSpot el mismo desorden que tenía antes, vuelve a las planillas en pocas semanas.
El tercero es el que más pesa y el que menos se ve: la empresa pierde la oportunidad de saber, con datos propios, dónde le conviene invertir. Si la atribución por canal no se diseña en el traspaso, el sistema nuevo vuelve a mostrar cuántos contactos entraron, pero no cuáles terminaron en un cliente. Las decisiones de presupuesto se siguen tomando con benchmarks de mercado en lugar de la evidencia de la propia operación.
Para evitarlo, antes de exportar un solo registro —el paso que detallamos en la guía de migración de datos a HubSpot— hace falta acordar qué es un lead, qué es una oportunidad y qué es un cierre; qué propiedades se conservan, cuáles se fusionan y cuáles se descartan; cómo se registra el origen de cada contacto, incluidos los que llegan sin conexión digital; y qué reglas de uso son obligatorias para todo el equipo. Es trabajo de criterio antes que de exportación.
El estado deseado se reconoce rápido. El reporte de pipeline sale sin limpieza previa. Cada contacto conserva su canal de origen y sus interacciones. Y marketing, ventas y dirección leen la misma información en tiempo real, sin pedirle a nadie que la reconstruya. Quien coordina la operación deja de ser la persona a la que todos le preguntan cuando algo no cierra.
Trabajamos la migración con el Ploy Growth Framework, y el traspaso de datos ocupa recién la tercera fase. En Ploy Discover relevamos cómo se vende cada servicio, qué tipos de consulta existen y qué información del sistema anterior vale la pena conservar. En Ploy Design traducimos eso en etapas, propiedades y un modelo de atribución por canal. En Ploy Build configuramos la plataforma, migramos los registros ya ordenados y armamos las automatizaciones. En Ploy Activate capacitamos por rol, porque un equipo adopta lo que entiende para qué sirve. Y en Ploy Grow revisamos cada mes qué muestran los datos y ajustamos.
En Plan B Immigration ese diseño permitió registrar con su origen las consultas presenciales y por referido, que antes no se podían medir. El resultado fue una diferencia de más de treinta veces entre canales: el referido convertía al 9,66% mientras la pauta paga estaba por debajo del 0,30%. Hasta ese momento, nadie sabía qué canal rendía. Ese dato reordenó la estrategia entera.
La transferencia de conocimiento es parte del entregable. Las definiciones acordadas, la lógica de cada automatización y las reglas de carga quedan documentadas, para que el equipo pueda operar y ajustar la plataforma sin depender de una sola persona, tampoco de nosotros. El objetivo declarado es que no nos necesites para operar el día a día.
Este enfoque le sirve a empresas de servicios con volumen alto de consultas, más de un canal de captación y un equipo comercial que ya no puede sostener el proceso a mano. También a las que ya decidieron migrar y quieren que la plataforma nueva sea una única fuente de verdad desde el primer día.
Si tu empresa ya decidió dejar Salesforce y todavía no sabe qué de lo que hay ahí vale la pena llevar, ese es exactamente el punto de partida de un Ploy Discover.