La maggior parte delle migrazioni da Salesforce a HubSpot viene impostata come un esercizio di mapping. Qualcuno esporta la lista dei campi Salesforce, la incolla accanto alla lista delle property HubSpot, traccia delle linee tra le due e prenota una finestra di import. Quella non è una migrazione: è la traduzione del debito tecnico esistente in un nuovo dialetto. Il vero lavoro per passare da Salesforce a HubSpot è il triage a livello di campo, decidere, una riga alla volta, se un campo trova una casa in HubSpot, viene trasformato prima, oppure non sopravvive al cutover. La spreadsheet di mapping è l'output di quella decisione. Non è la decisione.
Perché conta adesso
Le istanze Salesforce dalla Series B in poi portano centinaia di custom field, e il numero di campi è la parte minore del problema. La parte più grande è che meno della metà dei dati strutturati su quei campi viene effettivamente usata in qualche decisione, un risultato documentato nel lavoro di Harvard Business Review sulla data strategy, e che è invecchiato bene negli anni successivi. Un trasferimento campo per campo verso HubSpot porta con sé la metà inutile insieme a quella utile, e da quel momento il team si trascina il peso morto dentro la nuova piattaforma. La finestra di migrazione è l'unico momento nel ciclo di vita del CRM in cui cancellare un campo costa poco. Saltarla significa che la prossima persona che metterà mano allo schema combatterà l'eredità invece di costruire in avanti.
La triage spreadsheet, non il mapping doc
L'artefatto che guida una migrazione da Salesforce a HubSpot è una spreadsheet con una riga per ogni campo Salesforce e tre colonne di decisione: keep, edit, delete. È lo stesso schema keep / edit / delete che governa l'audit brownfield più ampio su un'istanza ereditata, ma puntato su un target più ristretto, il campo, non il workflow o il report. La versione a livello di istanza dello stesso schema vive nel nostro pezzo complementare sull'eredità di un'istanza HubSpot o Salesforce. Per ogni campo la riga registra l'API name Salesforce, il tipo, il tasso di popolamento sui record modificati negli ultimi novanta giorni, la property HubSpot proposta, la trasformazione e il responsabile nominativamente assegnato che firma la riga.
Una tipica istanza Salesforce di stadio intermedio finisce con circa un terzo dei campi marcati delete, un quarto edit e il resto keep così com'è. I numeri contano meno della disciplina, ogni campo è una decisione, e ogni decisione ha un nome accanto.
Tipi di campo Salesforce vs tipi di property HubSpot
I due sistemi non condividono un sistema di tipi, e i mismatch sono il punto in cui si fanno la maggior parte degli errori di migrazione a livello di campo. Le categorie che contano davvero:
Picklist vs dropdown / radio / checkbox
Le picklist multi-select di Salesforce non hanno un equivalente pulito in HubSpot. Le property multi-checkbox di HubSpot coprono il caso strutturale, ma i valori di picklist specifici per record-type in Salesforce spesso si espandono in property separate su HubSpot quando i valori non condividono davvero la stessa semantica. Il momento della migrazione è il momento per consolidare. Le picklist con più di venti valori, metà dei quali non sono stati selezionati negli ultimi sei mesi, si modificano fino ai valori che effettivamente compaiono sui record reali.
Formula field
I formula field di Salesforce non migrano. Si scompongono in una di tre cose in HubSpot, una calculation property se la formula è una funzione pura di altre property dello stesso record, un workflow che scrive su una property regolare al verificarsi di un trigger, oppure una cancellazione se la logica sottostante non serve più. La diagnostica è capire se la formula legge da campi che a loro volta sono keep, edit o delete. Un formula field i cui input sono tutti destinati a delete è un delete per transitività.
Relazioni lookup e master-detail
I lookup di Salesforce si traducono in association di HubSpot, ma la traduzione non è 1:1. Le association label di HubSpot portano semantica, "primary signer" vs "economic buyer" vs "champion", che Salesforce spesso codifica come un custom lookup field con una picklist di ruolo accanto. La migrazione pulita consolida il pattern lookup-più-ruolo in una singola association etichettata, più facile da mantenere e meno fragile su cui fare reporting. Le relazioni master-detail segnalano una domanda diversa, se l'oggetto figlio debba essere un custom object HubSpot, oppure se i record appartengano a un altro standard object con il padre come association.
Owner, queue e campi delle sharing rule
Le sharing rule e le queue di Salesforce spesso nascondono logica di visibilità dentro campi che sulla carta sembrano innocui. "Account Region", "Deal Pod" e "Owner Role" esistono spesso non per fare reporting, ma per pilotare una sharing rule tre livelli sotto. Prima di cancellare uno qualsiasi di questi campi, traccia il blast radius della sharing rule. Il modello dei permessi di HubSpot è più piatto e più dichiarativo; alcuni di questi campi spariscono dentro team membership e partition rule nel nuovo sistema, ma solo dopo che la dipendenza è stata mappata.
La domanda dei dati storici
Ogni migrazione Salesforce → HubSpot incontra la domanda di quanto storico portare con sé. La risposta onesta è raramente tutto. Il default che teniamo è gli ultimi novanta giorni di activity history, l'intero ciclo di vita di qualsiasi opportunity aperta indipendentemente dall'età, e il record closed-won di qualsiasi deal ancora su un ciclo di rinnovo. Tutto il resto resta in un archivio Salesforce read-only che il team può consultare ma non modificare. Il motivo per tirare la riga stretta è che i dati di activity storica sono il maggior contributore al tempo di migrazione e il minore alle decisioni guardando avanti. Un team che importa cinque anni di activity task da rappresentanti che non sono più in azienda ottiene un'istanza HubSpot più lenta e all'incirca la stessa accuratezza di forecast.
Un caso reale
Un team B2B SaaS in EMEA in stadio Series B è arrivato da noi a metà migrazione con un'istanza Salesforce che portava poco più di seicento custom field tra Account, Contact e Opportunity. Lo scope iniziale era un mapping 1:1 dei campi: ogni campo Salesforce ottiene una property HubSpot, l'import parte, il team viene riformato. Il primo pass di triage ha marcato circa il trentacinque percento dei campi per cancellazione, molti dei quali custom field popolati su qualche centinaio di record anni prima per una campagna che nessuno nel team attuale ricordava. Un altro venticinque percento erano edit, consolidamenti di picklist, scomposizioni di formule, traduzioni lookup-association e una manciata di date field che dovevano atterrare nella gestione più rigida dei fusi orari di HubSpot. Il restante quaranta percento è rimasto così com'era. Il portale HubSpot è andato live con circa duecentoquaranta custom property, una superficie che il team poteva davvero mantenere, e il primo trimestre di forecasting su quella istanza è stato il primo in due anni a non richiedere un pass manuale di pulizia dati prima della call.
Resoluzione, il playbook di triage
Per qualsiasi team che sta per fare una migrazione da Salesforce a HubSpot:
- Tira fuori l'inventario dei campi prima di tracciare qualsiasi linea di mapping. Una riga per ogni custom field Salesforce su ogni standard e custom object. Includi API name, tipo, tasso di popolamento sui record modificati negli ultimi novanta giorni, e i metadata dipendenti: workflow rule, validation rule, riferimenti formula, sharing rule.
- Esegui il pass keep / edit / delete. Ogni riga riceve una decisione e un responsabile nominativamente assegnato. I campi con popolamento sotto il dieci percento sui record recenti finiscono di default su delete a meno che qualcuno non li difenda per iscritto.
- Consolida le picklist prima di mappare. Riduci i valori di picklist a quelli che compaiono sui record reali, poi mappa la lista consolidata su HubSpot. Non importare valori morti.
- Scomponi i formula field in calculation, workflow o delete. Nessun formula field migra così com'è. Ognuno viene re-implementato, re-instradato o eliminato.
- Traduci i lookup in association label HubSpot. I pattern lookup-più-ruolo collassano in association etichettate. I custom object si guadagnano il viaggio solo se il modello di dati ne ha davvero bisogno sul lato HubSpot.
- Mappa il blast radius della sharing rule prima di cancellare qualsiasi campo che porta visibilità. I campi owner, region, pod e role che pilotano sharing rule Salesforce non possono semplicemente sparire; si traducono in team HubSpot, partition rule o permessi role-based, e la traduzione è documentata per ogni campo.
- Firma la spreadsheet prima che parta l'import. La triage spreadsheet è l'artefatto di cutover. L'import HubSpot è una funzione di quella spreadsheet, non un esercizio parallelo. Se un campo non è firmato, non si muove.
I passi da uno a sette sono l'ottanta percento del progetto. L'import vero è un venerdì pomeriggio.
Dove entra Checkpoint
Il triage a livello di campo è il lavoro che decide se una migrazione Salesforce → HubSpot esce pulita o esce come la stessa istanza con un logo nuovo. Eseguiamo questo esercizio in ogni CRM migration che tocchiamo, ed è la spina dorsale di come affrontiamo le HubSpot implementation a valle di un sistema legacy. Se il triage è il progetto, l'operating model che usa l'istanza risultante è ciò che la rende durevole, è il lavoro di revenue operations che segue. Se sta valutando un passaggio da Salesforce a HubSpot e la conversazione parte da uno spreadsheet di mapping, ci parli prima di prenotare la finestra di import.
Fonti
- "What's Your Data Strategy?" Harvard Business Review, maggio–giugno 2017. hbr.org
- Lemkin, Jason. "Which CRM Should You Use in 2026/2027? Follow the Agents." SaaStr, aprile 2026. saastr.com