Migració de CRM
Migrar de Salesforce a HubSpot sense perdre l’històric
Leads convertits, historial d’etapes, arxius i lògica en Flows o Apex: on es torcen les migracions des de Salesforce i com fer-les repetibles.
Per migrar de Salesforce a HubSpot sense perdre l’històric necessites tres coses: un mapatge documentat de cada objecte i camp, l’identificador de Salesforce desat a cada registre de HubSpot i una càrrega de prova completa abans del tall. Amb això, comptes, oportunitats, activitats i adjunts arriben amb les seves dates originals i les seves relacions, i pots repetir el procés tantes vegades com calgui sense duplicar res.
A continuació tens el mètode que seguim a cada migració a HubSpot, amb els punts on les migracions des de Salesforce se solen torçar: els leads convertits, l’historial d’etapes, els arxius i la lògica que viu en Flows i Apex.
Què vol dir «no perdre l’històric» a Salesforce
Quan algú demana conservar l’històric, gairebé mai no es refereix només als registres. Vol obrir la fitxa d’un client i veure què s’hi va parlar fa tres anys, quina oportunitat es va perdre i per què, qui la portava i quin contracte s’hi va adjuntar. A Salesforce aquesta informació està repartida en molts objectes: Task i Event per a activitats, EmailMessage per a correus, ContentDocument i ContentVersion (o l’antic Attachment) per a arxius, OpportunityHistory per als canvis d’etapa i les taules de Field History per als camps amb seguiment.
Abans de mapar, fes inventari: quants registres hi ha per objecte, quins camps tenen dades de debò, quins objectes personalitzats es fan servir i quines automatitzacions en depenen. En orgs amb anys d’ús és normal trobar camps que ningú no emplena des de fa temps i objectes creats per a un projecte que ja no existeix. No tot mereix viatjar, i el que no viatja no cal validar-lo.
Com es mapen els objectes de Salesforce a HubSpot
La correspondència bàsica és coneguda, però cada fila amaga decisions que convé deixar per escrit abans de programar res.
| Salesforce | HubSpot | Decisió que cal prendre |
|---|---|---|
| Account | Empresa | Jerarquies (ParentId) com a associació empresa matriu i filial |
| Contact | Contacte | Contactes vinculats a diversos comptes: associacions amb etiqueta i empresa principal |
| Lead sense convertir | Contacte (fase del cicle de vida) o objecte Leads | Els leads ja convertits no es migren com a registres a part |
| Opportunity | Negoci | Pipelines, etapes, motiu de pèrdua, divisa |
| OpportunityContactRole | Associació contacte–negoci | Rols com a etiquetes: decisor, influenciador, signant |
| Product2 i OpportunityLineItem | Productes i línies de pressupost | Llistes de preus i descomptes per línia |
| Case | Tiquet | Cues de casos com a equips o regles d’assignació |
| Task, Event, EmailMessage | Tasques, trucades, reunions, correus | Data original de l’activitat i associacions |
| Objectes personalitzats | Objecte personalitzat o propietats | Els objectes personalitzats de HubSpot requereixen una edició Enterprise |
Els leads convertits són la font de duplicats més freqüent. Quan Salesforce converteix un lead, el registre de Lead continua existint amb IsConverted marcat i la seva informació passa a Contact, Account i, de vegades, Opportunity. Si migres tots els leads sense filtrar, dupliques cada client. El correcte és migrar només els no convertits i, si interessa, traslladar del lead convertit les dades d’origen (font, campanya, data d’alta) a propietats del contacte.
L’altre parany són els contactes relacionats amb diversos comptes. HubSpot permet associar un contacte a diverses empreses i etiquetar cada associació, així que no cal triar-ne només una, però sí decidir quina és la principal, perquè és la que faran servir informes i workflows.
Activitats, correus i arxius: la part que més pesa
Les activitats són el gruix del volum i el motiu pel qual moltes migracions queden a mitges. A HubSpot cada activitat és un objecte (nota, trucada, correu, reunió, tasca) amb una propietat de data d’activitat que pots emplenar amb la data original. Si no la informes, HubSpot hi posa la data de la càrrega i la cronologia del client queda aixafada en un sol dia.
A Salesforce, Task barreja trucades, correus registrats i tasques reals: cal llegir-ne el subtipus per enviar cadascuna al seu objecte a HubSpot. Els Event passen a reunions. Els EmailMessage poden portar cossos HTML molt llargs, i cal decidir si es migra el cos complet o un resum amb l’original adjunt.
Els arxius demanen un pas més: descarregar-los de Salesforce, pujar-los a l’eina d’arxius de HubSpot i associar-los al registre, normalment a través d’una nota que els conté. És lent i ocupa espai, així que acorda un criteri: només contractes i propostes, només clients actius o només els darrers anys.
Les propietats de HubSpot que registren quan un negoci va entrar a cada etapa són de només lectura i es calculen amb els moviments dins de HubSpot. L’historial d’etapes de Salesforce no s’hi pot bolcar: desa les dates que importin (entrada a proposta, data original de tancament) en propietats pròpies o en un registre d’historial a part.
Propietaris i usuaris: qui portava cada compte
El propietari d’un registre a HubSpot ha de ser un usuari del compte. Abans de carregar res, crea els usuaris i prepara una taula d’equivalències entre l’Id d’usuari de Salesforce i el propietari de HubSpot. Els comercials que ja no són a l’empresa són el cas típic: assigna els seus registres a un responsable actual i desa el propietari original en una propietat de text per no perdre qui va portar la relació.
Amb els casos passa una cosa semblant. Si a Salesforce es repartien per cues, decideix si a HubSpot això es resol amb equips, amb el propietari del tiquet o amb regles d’assignació en workflows.
N’hi ha prou amb l’eina de HubSpot o cal un script?
HubSpot ofereix Smart Transfer, una eina guiada per portar dades des d’altres aplicacions, Salesforce inclòs. Segons la seva documentació, converteix comptes en empreses, contactes i leads en contactes, oportunitats en negocis i casos en tiquets, trasllada tasques, esdeveniments, notes, correus i usuaris, i mou els adjunts en una transferència puntual posterior. També deixa clars els seus límits: no admet objectes personalitzats ni camps de tipus referència o calculats, i està pensada per a una migració única. Si continuaràs fent servir Salesforce, recomana la integració nativa i adverteix que combinar-les totes dues crea duplicats. El detall és a la llista oficial d’aplicacions compatibles.
Per a una org estàndard amb poca personalització, Smart Transfer o l’importador de HubSpot poden ser suficients. Quan hi ha objectes personalitzats, relacions de diversos nivells, historial d’etapes que cal conservar o molts arxius, l’habitual és un script contra les API dels dos sistemes: extreure amb l’API de Salesforce o Data Loader, transformar amb les regles del mapatge i carregar amb l’API de HubSpot, deixant l’Id de Salesforce a cada registre.
El mètode: identificadors, càrregues de prova i delta
- 01Inventari de l’org
- 02Mapatge validat
- 03Càrrega de prova completa
- 04Validació amb usuaris
- 05Delta i tall
El que fa el procés repetible és l’identificador d’origen. Crea a cada objecte de HubSpot una propietat «ID Salesforce» que exigeixi valors únics i fes-la servir com a clau en carregar. Si la segona càrrega de prova porta un registre que ja existeix, s’actualitza en lloc de duplicar-se, i les associacions es resolen buscant per aquest ID. De passada, qualsevol fitxa de HubSpot queda traçada fins al seu origen.
La càrrega de prova ha de ser completa, no una mostra de cent registres. És l’única manera de veure els errors que apareixen amb el volum real: telèfons amb formats estranys, valors de picklist retirats, correus no vàlids, oportunitats sense compte. Després es valida amb recomptes per objecte i amb usuaris clau que obren fitxes que coneixen bé.
El dia del tall es congela Salesforce, es carrega el delta (el que s’ha creat o modificat des de l’última càrrega, filtrant per LastModifiedDate) i l’equip comença a treballar a HubSpot. Aquest pas mereix un pla de tall propi, amb data acordada, responsables i un pla de marxa enrere per si la validació final falla.
El que no són dades: Flows, Apex i validacions
Salesforce sol acumular lògica: Flows, triggers d’Apex, regles de validació, camps de fórmula i resums acumulats. Res d’això no viatja amb les dades. Cal inventariar-ho i decidir com es reconstrueix: workflows, propietats calculades, regles de validació de propietats, accions de codi personalitzat o serveis de desenvolupament a mida quan la lògica és complexa.
En una SaaS fintech que vam migrar des de Salesforce, aquesta lògica va acabar repartida en uns 12 microserveis: numeració seqüencial, ARR i tipus de compte calculats diàriament, renovacions encadenades, historial d’etapes per al data warehouse i la connexió amb la seva eina de gestió de contractes, amb un backfill de 1.615 fluxos. Tens el cas complet al web. No totes les orgs en necessiten tant, però convé saber-ho abans de pressupostar.
Si encara estàs decidint si el canvi compensa, la comparativa HubSpot vs Salesforce t’ajuda a veure què hi guanyes i què deixes enrere.
