Migrazione CRM
Migrare da Salesforce a HubSpot senza perdere lo storico
Lead convertiti, storico delle fasi, file e logica in Flow o Apex: dove si inceppano le migrazioni da Salesforce e come renderle ripetibili.
Per migrare da Salesforce a HubSpot senza perdere lo storico servono tre cose: una mappatura documentata di ogni oggetto e campo, l’identificativo di Salesforce salvato su ogni record di HubSpot e un caricamento di prova completo prima del cut-over. Così account, opportunità, attività e allegati arrivano con le loro date originali e le loro relazioni, e puoi ripetere il processo tutte le volte che serve senza duplicare nulla.
Di seguito trovi il metodo che seguiamo in ogni migrazione a HubSpot, con i punti in cui le migrazioni da Salesforce tendono a incepparsi: i lead convertiti, lo storico delle fasi, i file e la logica che vive in Flow e Apex.
Cosa significa «non perdere lo storico» in Salesforce
Quando qualcuno chiede di conservare lo storico, quasi mai intende solo i record. Vuole aprire la scheda di un cliente e vedere di cosa si è parlato tre anni fa, quale opportunità è stata persa e perché, chi la seguiva e quale contratto è stato allegato. In Salesforce queste informazioni sono distribuite su molti oggetti: Task ed Event per le attività, EmailMessage per le email, ContentDocument e ContentVersion (o il vecchio Attachment) per i file, OpportunityHistory per i cambi di fase e le tabelle di Field History per i campi tracciati.
Prima di mappare, fai l’inventario: quanti record ci sono per oggetto, quali campi contengono dati veri, quali oggetti personalizzati si usano e quali automazioni dipendono da essi. Nelle org con anni di utilizzo è normale trovare campi che nessuno compila da tempo e oggetti creati per un progetto che non esiste più. Non tutto merita di essere trasferito, e ciò che non viene trasferito non va validato.
Come si mappano gli oggetti di Salesforce in HubSpot
La corrispondenza di base è nota, ma ogni riga nasconde decisioni da mettere per iscritto prima di scrivere una riga di codice.
| Salesforce | HubSpot | Decisione da prendere |
|---|---|---|
| Account | Azienda | Gerarchie (ParentId) come associazione tra azienda madre e controllata |
| Contact | Contatto | Contatti legati a più account: associazioni con etichetta e azienda principale |
| Lead non convertito | Contatto (fase del ciclo di vita) od oggetto Lead | I lead già convertiti non si migrano come record separati |
| Opportunity | Trattativa | Pipeline, fasi, motivo di perdita, valuta |
| OpportunityContactRole | Associazione contatto–trattativa | Ruoli come etichette: decisore, influenzatore, firmatario |
| Product2 e OpportunityLineItem | Prodotti e voci | Listini prezzi e sconti per riga |
| Case | Ticket | Code dei casi come team o regole di assegnazione |
| Task, Event, EmailMessage | Attività, chiamate, riunioni, email | Data originale dell’attività e associazioni |
| Oggetti personalizzati | Oggetto personalizzato o proprietà | Gli oggetti personalizzati di HubSpot richiedono un’edizione Enterprise |
I lead convertiti sono la fonte di duplicati più frequente. Quando Salesforce converte un lead, il record Lead continua a esistere con IsConverted selezionato e le sue informazioni passano a Contact, Account e, a volte, Opportunity. Se migri tutti i lead senza filtrarli, duplichi ogni cliente. La cosa corretta è migrare solo quelli non convertiti e, se serve, trasferire dal lead convertito i dati di origine (fonte, campagna, data di creazione) in proprietà del contatto.
L’altra trappola sono i contatti collegati a più account. HubSpot permette di associare un contatto a più aziende ed etichettare ogni associazione, quindi non serve sceglierne una sola, ma va deciso quale sia la principale, perché è quella che useranno report e workflow.
Attività, email e file: la parte più pesante
Le attività costituiscono il grosso del volume e sono il motivo per cui molte migrazioni restano a metà. In HubSpot ogni attività è un oggetto (nota, chiamata, email, riunione, attività) con una proprietà di data dell’attività che puoi compilare con la data originale. Se non la valorizzi, HubSpot mette la data del caricamento e la cronologia del cliente viene schiacciata su un solo giorno.
In Salesforce, Task mescola chiamate, email registrate e veri e propri promemoria: bisogna leggere il sottotipo per mandare ciascuno al proprio oggetto in HubSpot. Gli Event diventano riunioni. Gli EmailMessage possono avere corpi HTML molto lunghi, e va deciso se migrare il corpo completo o un riassunto con l’originale allegato.
I file richiedono un passaggio in più: scaricarli da Salesforce, caricarli nello strumento file di HubSpot e associarli al record, di solito tramite una nota che li contiene. È un processo lento e occupa spazio, quindi concorda un criterio: solo contratti e proposte, solo clienti attivi o solo gli ultimi anni.
Le proprietà di HubSpot che registrano quando una trattativa è entrata in ogni fase sono di sola lettura e vengono calcolate dai movimenti dentro HubSpot. Lo storico delle fasi di Salesforce non si può riversare lì: salva le date che contano (ingresso in proposta, data di chiusura originale) in proprietà dedicate o in un registro storico separato.
Proprietari e utenti: chi seguiva ogni account
Il proprietario di un record in HubSpot deve essere un utente dell’account. Prima di caricare qualsiasi cosa, crea gli utenti e prepara una tabella di corrispondenza tra l’Id utente di Salesforce e il proprietario in HubSpot. I commerciali che non lavorano più in azienda sono il caso tipico: assegna i loro record a un responsabile attuale e salva il proprietario originale in una proprietà di testo, per non perdere chi ha seguito la relazione.
Con i casi succede qualcosa di simile. Se in Salesforce venivano smistati tramite code, decidi se in HubSpot li gestirai con i team, con il proprietario del ticket o con regole di assegnazione nei workflow.
Basta lo strumento di HubSpot o serve uno script?
HubSpot offre Smart Transfer, uno strumento guidato per importare dati da altre applicazioni, Salesforce compreso. Secondo la documentazione, converte gli account in aziende, contatti e lead in contatti, opportunità in trattative e casi in ticket, trasferisce attività, eventi, note, email e utenti, e sposta gli allegati in un successivo trasferimento una tantum. Chiarisce anche i suoi limiti: non supporta oggetti personalizzati né campi di ricerca o formula, ed è pensato per una migrazione unica. Se continuerai a usare Salesforce, consiglia l’integrazione nativa e avverte che combinare le due cose crea duplicati. I dettagli sono nell’elenco ufficiale delle applicazioni supportate.
Per una org standard con poca personalizzazione, Smart Transfer o lo strumento di importazione di HubSpot possono bastare. Quando ci sono oggetti personalizzati, relazioni su più livelli, uno storico delle fasi da conservare o molti file, di solito si usa uno script che lavora sulle API di entrambi i sistemi: estrazione con l’API di Salesforce o Data Loader, trasformazione con le regole della mappatura e caricamento con l’API di HubSpot, lasciando l’Id di Salesforce su ogni record.
Il metodo: identificativi, caricamenti di prova e delta
- 01Inventario della org
- 02Mappatura validata
- 03Caricamento di prova completo
- 04Validazione con gli utenti
- 05Delta e cut-over
Ciò che rende il processo ripetibile è l’identificativo di origine. Crea su ogni oggetto di HubSpot una proprietà «ID Salesforce» che richieda valori univoci e usala come chiave nei caricamenti. Se il secondo caricamento di prova porta un record che esiste già, questo viene aggiornato invece di essere duplicato, e le associazioni si risolvono cercando per quell’ID. In più, ogni scheda di HubSpot resta tracciata fino alla sua origine.
Il caricamento di prova deve essere completo, non un campione di cento record. È l’unico modo per vedere gli errori che emergono con il volume reale: telefoni in formati strani, valori di picklist dismessi, email non valide, opportunità senza account. Poi si valida con i conteggi per oggetto e con utenti chiave che aprono schede che conoscono bene.
Il giorno del cut-over si congela Salesforce, si carica il delta (ciò che è stato creato o modificato dall’ultimo caricamento, filtrando per LastModifiedDate) e il team inizia a lavorare in HubSpot. Il cut-over va preparato come un piccolo progetto a sé: data concordata, finestra di blocco delle modifiche, verifiche dopo il caricamento e un piano di ritorno se qualcosa va storto.
Ciò che non è dato: Flow, Apex e validazioni
Salesforce tende ad accumulare logica: Flow, trigger Apex, regole di convalida, campi formula e campi di riepilogo. Niente di tutto questo viaggia con i dati. Va inventariato e bisogna decidere come ricostruirlo: workflow, proprietà calcolate, regole di convalida delle proprietà, azioni di codice personalizzato o servizi di sviluppo su misura quando la logica è complessa.
In una SaaS fintech che abbiamo migrato da Salesforce, questa logica è finita distribuita su circa 12 microservizi: numerazione sequenziale, ARR e tipo di account calcolati ogni giorno, rinnovi concatenati, storico delle fasi per il data warehouse e il collegamento con il loro strumento di gestione dei contratti, con un backfill di 1.615 flussi. Trovi il caso completo sul sito. Non tutte le org hanno bisogno di tanto, ma è meglio saperlo prima di fare il preventivo.
Se stai ancora decidendo se il cambio conviene, il confronto HubSpot vs Salesforce ti aiuta a capire cosa guadagni e cosa lasci indietro.
