En este paso defines a dónde va cada objeto del CRM viejo —cuentas, contactos, negocios, actividades, archivos— y, sobre todo, cómo viajan las relaciones entre ellos. El entregable es una matriz de equivalencias aprobada donde cada registro llega con su historial colgado y ningún dato queda huérfano. Es el paso técnico que decide si el CRM nuevo cuenta historias o acumula fichas sueltas.
La tabla de equivalencias: cada objeto tiene destino
Los CRMs no usan los mismos nombres ni el mismo modelo. La primera hoja de tu matriz es la traducción objeto a objeto. Para el caso más común, migrar de Salesforce a HubSpot:
- Account → Empresa. Directo. Ojo con las jerarquías padre-hija: existen en ambos, pero hay que migrarlas explícitamente.
- Contact → Contacto. Directo, asociado a su empresa.
- Lead → Contacto con etapa de ciclo de vida. HubSpot no tiene objeto Lead separado: el lead es un contacto en etapa "lead". Decide qué leads viejos entran (los trabajados) y cuáles se archivan (los fríos de 2022).
- Opportunity → Negocio. Con su pipeline, etapa, monto, fecha de cierre y asociaciones a empresa y contactos.
- Case → Ticket. Si usas servicio; si no, decide si se archivan.
- Objetos custom → objeto estándar, custom object o propiedad. La pregunta correcta no es "¿cómo lo copio?" sino "¿qué resolvía?". Muchos objetos custom de Salesforce nacieron para esquivar límites que HubSpot no tiene, y colapsan bien en propiedades o asociaciones.
Desde Zoho el mapa es análogo (Accounts/Contacts/Deals/Leads); desde Pipedrive es más simple —Organización → Empresa, Persona → Contacto, Deal → Negocio— con una advertencia: Pipedrive gira alrededor del deal y HubSpot alrededor del contacto, así que define el ciclo de vida del contacto al llegar o el equipo va a sentir el cambio como burocracia.
Asociaciones: lo que hace que el historial cuente una historia
Acá se ganan o se pierden las migraciones. Una asociación es el vínculo entre registros: este contacto trabaja en esta empresa, este negocio involucra a estos tres contactos, esta llamada pertenece a este negocio. En el export estándar, cada objeto sale en su propio archivo y los vínculos son columnas de IDs. Si importas los archivos sin reconstruir esos vínculos, tienes los datos y perdiste la información.
El mecanismo para no perder nada es uno y es simple: cada registro migrado conserva el ID del sistema viejo en una propiedad dedicada ("ID origen Salesforce", por ejemplo). Con esa llave externa, las asociaciones se reconstruyen en el destino, la validación del paso 5 puede rastrear cualquier registro hasta su origen, y los errores se corrigen re-procesando en lugar de adivinando. Es la misma disciplina de llaves que usamos para integrar sistemas en la matriz de mapeo campo a campo de la guía de integración de datos.
Un contacto sin su historial no es un dato migrado: es un nombre suelto en una base nueva.
Actividades, correos y adjuntos: el historial propiamente dicho
Lo que tu equipo llama "el historial" son las actividades: correos, llamadas, reuniones, notas y tareas que cuelgan del timeline de cada registro. Tres reglas para que lleguen enteras:
- Mígralas como actividades, no como texto. Volcar mil correos en un campo de notas técnicamente "no pierde datos" y prácticamente los entierra. Cada actividad llega con su tipo, su fecha original y sus asociaciones.
- Preserva la fecha original. Una llamada de marzo de 2024 tiene que aparecer en marzo de 2024, no en la fecha de la migración. Sin cronología no hay historia.
- Los adjuntos se migran aparte y se verifican aparte. Propuestas y contratos suelen requerir extracción vía API, no export estándar. Cuéntalos en origen y cuéntalos en destino: es el objeto que más silenciosamente se pierde.
Propiedades, pipelines y dueños
Tres mapeos menores que causan dolores mayores. Propiedades: aplica la auditoría del paso 2 y mapea solo los campos vivos; los desplegables (picklists) necesitan tabla de valores origen → destino, porque "En negociación" y "Negociación" son dos etapas distintas para una máquina. Pipelines: no copies las 11 etapas del CRM viejo si ya sabes que 4 nunca se usaron; migrar es la mejor oportunidad para simplificar el pipeline, y las etapas viejas se traducen a las nuevas en la matriz. Dueños: mapea cada usuario del origen a su usuario del destino, y decide qué pasa con los registros de vendedores que ya no están: ¿se reasignan por cartera o van a un dueño genérico de históricos?
Errores comunes en este paso
- Importar objetos sin asociaciones. El clásico "están todos los contactos pero no sé de qué empresa son". Es el error que esta guía existe para evitar.
- No guardar el ID de origen. Sin llave externa no hay validación rastreable ni corrección posible: solo fe.
- Copiar el pipeline viejo tal cual. Si las etapas no reflejaban tu proceso en el CRM viejo, tampoco lo van a reflejar en el nuevo.
- Olvidar los correos conectados. El historial de correo que vivía en la conexión Gmail/Outlook del CRM viejo no siempre entra en el export: verificalo antes del cutover, no después.
Checklist antes de pasar al siguiente
- Tabla de equivalencias objeto a objeto completa, incluyendo custom objects con decisión explícita.
- Propiedad de "ID origen" creada en cada objeto del destino.
- Plan de asociaciones: contacto–empresa, negocio–contactos, actividad–registro padre.
- Actividades mapeadas por tipo con fecha original preservada; adjuntos con método de extracción probado.
- Tabla de valores para picklists y etapas de pipeline, aprobada por ventas.
- Mapeo de dueños cerrado, incluyendo la regla para ex-empleados.
Con la matriz aprobada, ya se puede planear la mudanza en serio: paso 4, el plan: etapas, paralelo y punto de no retorno. El panorama completo vive en la guía de migración de CRM.