La maggior parte dei team che parla di una «migrazione CRM» in realtà non sta cambiando piattaforma. Sta ereditando un'istanza HubSpot o Salesforce costruita da qualcun altro, mai del tutto documentata, e consegnata insieme ai numeri di fatturato del trimestre. L'istanza funziona, a stento, e il modello operativo è ormai vincolato a essa. Questa è una migrazione CRM brownfield. È una categoria di progetto diversa da un'installazione pulita, e fingere il contrario è l'errore più costoso che possa commettere nei primi trenta giorni.
Perché conta proprio adesso
I costi di switch sui CRM non sono più quelli di una volta. Come ha scritto Jason Lemkin ad aprile: con due o tre agenti AI cambiare CRM è fastidioso; con dieci diventa costoso; con venti è funzionalmente impossibile. Il sistema che oggi tollera è il sistema in cui sarà bloccato per la prossima generazione di agenti. Il pezzo della Harvard Business Review di febbraio sul perché gli investimenti digitali non creano valore puntava la stessa causa da un'altra angolazione, il fallimento non è negli strumenti. È nel non riuscire a ridisegnare il modo in cui l'organizzazione commerciale genera realmente insight, prende decisioni e coordina l'azione. In pratica, una migrazione brownfield è il momento in cui questo ridisegno avviene oppure viene rimandato per altri due anni.
La regola brownfield, non c'è tabula rasa, quindi costruisca l'audit prima dell'architettura
Una migrazione greenfield parte da uno schema vuoto. Lei decide quali oggetti esistono, quali campi vivono su di essi, quali associazioni sono permesse, cosa significano le fasi del pipeline. Una migrazione brownfield parte da diversi anni di decisioni di altri, cementate dentro un sistema di revenue in produzione. La maggior parte di quelle decisioni aveva senso allora e non ce l'ha più adesso. Alcune non sono mai state ben pensate. Un numero sorprendente di esse risulta portante, in modi che nessuno ha documentato.
La regola che applichiamo a ogni progetto brownfield è, non cambi nulla nell'architettura dati prima di aver triagato ogni decisione esistente. Il triage non è opzionale, e il triage è il progetto. La ri-piattaformizzazione è solo ciò che accade alla fine.
Il framework keep / edit / delete
Per ogni dato esistente, ogni campo esistente, ogni fase di pipeline esistente, ogni automazione esistente, ogni report esistente, la risposta è una di tre:
- Keep. Serve ancora un caso d'uso commerciale attuale. Non ha bisogno di rilavorazioni. È documentato, cablato correttamente, e rimuoverlo romperebbe un report o un workflow a valle che qualcuno sta usando attivamente.
- Edit. Serve un caso d'uso attuale ma l'implementazione è sbagliata, il tipo di dato è sbagliato, i valori sono incoerenti, oppure il workflow è parzialmente rotto. Gli edit vengono inquadrati, assegnati per nome e schedulati prima di qualsiasi merge.
- Delete. Serviva un caso d'uso che non esiste più, non è mai stato usato, oppure duplica qualcos'altro. I delete vengono verificati per impatto a valle, poi vanno via.
Sulla carta il framework sembra leggero. Il costo è nella disciplina. Ogni proprietà, ogni workflow, ogni record type passa per i tre bucket. Una tipica istanza HubSpot di un'azienda B2B SaaS in mid-stage porta tra diverse centinaia e diverse migliaia di decisioni di triage individuali. Il team che dice «lo capiamo strada facendo» è il team che spedisce la migrazione con il debito intatto.
Dove il framework diventa concreto
Tre punti in cui il frame keep / edit / delete si affila in fretta nella pratica:
Fasi della pipeline e loro definizioni
La maggior parte delle pipeline ereditate ha fasi che significano cose diverse per persone diverse. «Closed Won» a volte significa contratto firmato; a volte kickoff schedulato; a volte revenue riconosciuto. La migrazione è il momento per forzare la definizione. Edit, non delete, ma ogni fase riceve una definizione di una frase, un criterio di ingresso, un criterio di uscita e un owner.
Proprietà personalizzate su Deal, Contact, Company
Le istanze brownfield accumulano proprietà personalizzate più o meno alla velocità con cui il team accumula idee. Un audit serio ne cancella di solito il 30–50%. La domanda diagnostica per ognuna, chi l'ha letta negli ultimi 90 giorni, e quale decisione ne ha tratto? Se la risposta è nessuno e niente, va via.
Workflow e automazioni
La fonte di gran lunga più comune di debito brownfield sono i workflow che si attivano su trigger ormai deprecati, che impostano campi che nessuno usa, oppure che notificano persone non più in azienda. Ogni workflow viene letto end-to-end, lo stato finale mappato e triagato. I workflow che sopravvivono vengono rinominati secondo una convenzione; gli altri vengono messi in pausa prima di qualsiasi spostamento di dati.
Schema dal campo
Un team B2B SaaS dell'area DACH in Series B si è rivolto a noi di recente con due portali HubSpot e un'istanza Salesforce da unire in un unico sistema. L'istinto era la ri-piattaformizzazione: spostare tutto, depositare in un nuovo portale, consegnare in otto settimane. La forma reale del progetto, dopo il triage, era diversa. Circa il 38% delle proprietà personalizzate legacy è stato marcato delete al primo passaggio di audit. Un altro 24% richiedeva edit, cambi di tipo, consolidamento di picklist, ricablaggio di workflow. Il 38% rimanente è stato tenuto invariato. L'istanza unificata è andata in produzione con circa un terzo della superficie di proprietà personalizzate dei sistemi legacy combinati, e il primo trimestre di reporting su di essa è stato il primo in due anni a non richiedere uno step manuale di pulizia pre-pull. La migrazione non è stata lo speed-to-platform che avevamo inquadrato all'inizio. È stata la pulizia.
Risoluzione, un playbook per la migrazione brownfield
Per ogni team che sta per ereditare o fondere un'istanza HubSpot o Salesforce:
- Congeli l'architettura. Niente nuove proprietà, niente nuovi workflow, niente nuove fasi di pipeline finché l'audit non è completo. L'audit dura di più se continua ad aggiungere superficie.
- Esegua il passaggio keep / edit / delete su ogni oggetto. Proprietà, pipeline, workflow, record type, appartenenze a liste, etichette di associazione. Documenti la decisione in un foglio di calcolo che qualcuno sia disposto a difendere.
- Riconcili con il sistema che effettivamente guida il fatturato. Se ha dati in due sistemi, ne tratti uno come fonte di verità e conformi l'altro a esso. La migrazione non è il momento di dibattere quale sistema vinca.
- Sistemi i workflow prima di muovere i dati. Dati brownfield sopra automazioni ereditate sono il peggio dei due mondi. Metta in pausa ogni automazione che tocca una proprietà che sta editando o cancellando; riscriva i sopravvissuti contro lo schema post-audit.
- Inscena la fusione in una sandbox. Le migrazioni in produzione vengono prima testate in sandbox, validate contro un workload di reporting reale, e solo dopo schedulate.
- Formi sul sistema post-audit, non su quello legacy. Una migrazione brownfield è un cambiamento di comportamento per il team. La documentazione scritta contro il sistema legacy fissa il debito legacy.
Se segue i passi da uno a sei, la migrazione dei dati vera e propria è un venerdì pomeriggio. Se li salta, la migrazione sono i prossimi dodici mesi.
Dove entra in gioco Checkpoint
La ragione per cui il framework keep / edit / delete tiene sotto pressione è che non è un poster di metodologia, è il lavoro. Le migrazioni brownfield sono la maggior parte del lavoro CRM che facciamo da Checkpoint, e abbiamo girato il ciclo di audit su abbastanza eredità HubSpot, Salesforce e Pipedrive da sapere quali decisioni si presentano ogni volta e quali sono davvero uniche del Suo stack. Se la Sua migrazione brownfield parte da debito ereditato anziché da uno schema vuoto, ne parli con noi prima di scegliere la piattaforma, la decisione giusta di piattaforma cade fuori dall'audit, non viceversa.
Fonti
- Sinha, Shastri, Lorimer. «Why Your Digital Investments Aren't Creating Value». Harvard Business Review, 16 febbraio 2026. hbr.org
- Lemkin, Jason. «Which CRM Should You Use in 2026/2027? Follow the Agents». SaaStr, 6 aprile 2026. saastr.com