Die meisten Salesforce-zu-HubSpot-Migrationen werden als Mapping-Übung gescoped. Jemand exportiert die Salesforce-Field-Liste, fügt sie neben die HubSpot-Property-Liste, zieht Linien zwischen beiden und bucht ein Import-Fenster. Das ist keine Migration; es ist eine Übersetzung der bestehenden Tech-Schulden in einen neuen Dialekt. Die eigentliche Arbeit, von Salesforce nach HubSpot zu wechseln, ist feldlevel-Triage, Eine Zeile nach der anderen entscheiden, ob ein Feld ein HubSpot-Zuhause bekommt, zuerst transformiert wird oder den Cutover nicht überlebt. Das Mapping-Spreadsheet ist der Output dieser Entscheidung. Es ist nicht die Entscheidung selbst.
Warum das jetzt wichtig ist
Salesforce-Instanzen ab Series B tragen Hunderte von Custom-Feldern, und der Field-Count ist der kleinere Teil des Problems. Der größere Teil ist, dass weniger als die Hälfte der strukturierten Daten auf diesen Feldern aktiv in irgendeiner Entscheidung genutzt wird, ein Befund, der in der Daten-Strategie-Arbeit der Harvard Business Review dokumentiert ist und der in den Jahren seitdem gut gealtert ist. Ein feldweiser Lift nach HubSpot portiert die ungenutzte Hälfte mit der nützlichen Hälfte hinüber, und dann trägt das Team das tote Gewicht in die neue Plattform mit. Das Migrations-Fenster ist der einzige Moment im Lebenszyklus des CRM, in dem das Löschen eines Felds günstig ist. Überspringen Sie es, und die nächste Person, die das Schema berührt, kämpft gegen die Erbschaft, statt nach vorne zu bauen.
Das Triage-Spreadsheet, kein Mapping-Doc
Das Artefakt, das eine Salesforce-zu-HubSpot-Migration treibt, ist ein Spreadsheet mit einer Zeile pro Salesforce-Feld und drei Entscheidungsspalten: Keep, Edit, Delete. Das ist derselbe Keep / Edit / Delete-Frame, der das breitere Brownfield-Audit auf einer geerbten Instanz governt, aber auf ein engeres Ziel gerichtet, das Feld, nicht den Workflow oder Report. Die instanzweite Version desselben Frames lebt in unserem Begleitbeitrag zur Übernahme einer HubSpot- oder Salesforce-Instanz. Pro Feld erfasst die Zeile den Salesforce-API-Namen, den Field-Typ, die Befüllungsrate gegen Records, die in den letzten neunzig Tagen modifiziert wurden, die vorgeschlagene HubSpot-Property, die Transformation und die benannte Eigentümerin, die die Zeile abzeichnet.
Eine typische Mid-Stage-Salesforce-Instanz triagiert ungefähr zu einem Drittel gelöscht, einem Viertel editiert und der Rest unverändert behalten. Die Zahlen sind weniger wichtig als die Disziplin, Jedes Feld ist eine Entscheidung, und jede Entscheidung hat einen Namen daneben.
Salesforce-Field-Typen vs. HubSpot-Property-Typen
Die beiden Systeme teilen kein Typ-System, und die Mismatches sind, wo die meisten feldlevel-Migrationsfehler gemacht werden. Die Kategorien, die tatsächlich zählen:
Picklists vs. Dropdown / Radio / Checkbox
Salesforce-Multi-Select-Picklists haben kein sauberes HubSpot-Äquivalent. HubSpot-Multi-Checkbox-Properties decken den strukturellen Fall, aber record-typ-spezifische Picklist-Werte in Salesforce expandieren oft zu separaten Properties auf HubSpot, wenn die Werte nicht tatsächlich geteilte Semantik sind. Der Migrations-Moment ist der Moment zur Konsolidierung. Picklists mit mehr als zwanzig Werten, von denen die Hälfte in den letzten sechs Monaten nicht ausgewählt wurde, werden auf die Werte heruntereditiert, die auf echten Records erscheinen.
Formula-Felder
Salesforce-Formula-Felder migrieren nicht. Sie werden in HubSpot in eines von drei Dingen aufgedröselt: eine Calculation Property, wenn die Formel eine reine Funktion anderer Properties auf demselben Record ist, ein Workflow, der bei einem Trigger in eine reguläre Property schreibt, oder eine Löschung, wenn die zugrundeliegende Logik nicht mehr gebraucht wird. Die Diagnose, Liest die Formel aus Feldern, die selbst Keeps, Edits oder Deletes sind? Ein Formula-Feld, dessen Inputs alle auf Delete gehen, ist transitiv ein Delete.
Lookup- und Master-Detail-Beziehungen
Salesforce-Lookups übersetzen zu HubSpot-Verknüpfungen, aber die Übersetzung ist nicht 1:1. HubSpot-Association-Labels tragen Semantik, „primary signer" vs. „economic buyer" vs. „champion": , die Salesforce oft als Custom-Lookup-Feld mit einer Rollen-Picklist daneben kodiert. Die saubere Migration konsolidiert das Lookup-plus-Rolle-Pattern in eine einzelne gelabelte Verknüpfung, die kürzer zu warten und weniger brüchig zu reporten ist. Master-Detail-Beziehungen flaggen eine andere Frage, ob das Child-Objekt überhaupt ein HubSpot-Custom-Object sein sollte oder ob die Records auf einem anderen Standard-Objekt mit dem Parent als Verknüpfung gehören.
Owner-, Queue- und Sharing-Rule-Felder
Salesforce-Sharing-Rules und Queue-Ownership verstecken oft Sichtbarkeitslogik in Feldern, die auf dem Papier harmlos aussehen. „Account Region", „Deal Pod" und „Owner Role" existieren häufig nicht, um darauf zu reporten, sondern um eine Sharing-Rule drei Schichten tiefer zu treiben. Bevor Sie eines davon löschen, tracen Sie den Sharing-Rule-Blast-Radius. HubSpots Permission-Modell ist flacher und deklarativer; einige dieser Felder verschwinden im neuen System in Team-Mitgliedschaft und Partition-Rules, aber erst, nachdem die Abhängigkeit gemappt ist.
Die Frage der historischen Daten
Jede Salesforce-zu-HubSpot-Migration läuft in die Frage, wie viel Historie übergeführt werden soll. Die ehrliche Antwort ist selten alles. Der Default, an dem wir festhalten, sind die letzten neunzig Tage Aktivitätshistorie, der volle Lebenszyklus jeder offenen Opportunity unabhängig vom Alter und der Closed-Won-Record jedes Deals, der noch in einem Renewal-Zyklus ist. Alles andere bleibt in einem Salesforce-Read-only-Archiv, das das Team referenzieren, aber nicht editieren kann. Der Grund, die Linie eng zu ziehen, Historische Aktivitätsdaten sind der größte Beitrag zur Migrations-Zeit und der kleinste Beitrag zu vorausschauenden Entscheidungen. Ein Team, das fünf Jahre Aktivitäts-Tasks von ehemaligen Reps importiert, bekommt eine langsamere HubSpot-Instanz und ungefähr dieselbe Forecast-Genauigkeit.
Muster aus der Praxis
Ein B2B-SaaS-Team in EMEA in Series B kam mitten in der Migration auf uns zu, mit einer Salesforce-Instanz, die etwas über sechshundert Custom-Felder über die Account-, Contact- und Opportunity-Objekte trug. Der ursprüngliche Scope war ein 1:1-Field-Map: jedes Salesforce-Feld bekommt eine HubSpot-Property, der Import läuft, das Team trainiert um. Der erste Triage-Durchlauf markierte ungefähr fünfunddreißig Prozent der Felder zur kompletten Löschung, die meisten davon Custom-Felder, die vor Jahren auf einer Handvoll Records für eine Kampagne befüllt wurden, an die sich niemand im aktuellen Team erinnerte. Weitere fünfundzwanzig Prozent waren Edits: Picklist-Konsolidierungen, Formula-Aufdröselungen, Lookup-zu-Association-Übersetzungen und eine Handvoll Datumsfelder, die in HubSpots strikteres Zeitzonen-Handling landen mussten. Die verbleibenden vierzig Prozent blieben unverändert. Das HubSpot-Portal ging mit etwa zweihundertvierzig Custom Properties live: eine Oberfläche, die das Team tatsächlich warten konnte, und das erste Quartal Forecasting darauf war das erste seit zwei Jahren, das vor dem Call keinen manuellen Daten-Integritäts-Durchlauf brauchte.
Auflösung, das Triage-Playbook
Für jedes Team, das eine Salesforce-zu-HubSpot-Migration fahren will:
- Ziehen Sie das Field-Inventory, bevor Sie irgendwelche Mapping-Linien zeichnen. Eine Zeile pro Salesforce-Custom-Feld auf jedem Standard- und Custom-Objekt. Beinhalten Sie API-Namen, Field-Typ, Befüllungsrate auf Records, die in den letzten neunzig Tagen modifiziert wurden, und die abhängige Metadaten: Workflow-Rules, Validation-Rules, Formula-Referenzen, Sharing-Rules.
- Fahren Sie den Keep / Edit / Delete-Durchlauf. Jede Zeile bekommt eine Entscheidung und eine benannte Eigentümerin. Felder mit einer Befüllung unter zehn Prozent auf neueren Records gehen per Default auf Delete, es sei denn, jemand verteidigt sie schriftlich.
- Konsolidieren Sie Picklists vor dem Mapping. Editieren Sie Picklist-Werte herunter auf das, was auf echten Records erscheint, dann mappen Sie die konsolidierte Liste nach HubSpot. Importieren Sie keine toten Werte.
- Dröseln Sie Formula-Felder in Calculations, Workflows oder Deletes auf. Kein Formula-Feld migriert as-is. Jedes wird re-implementiert, re-routed oder gestrichen.
- Übersetzen Sie Lookups in HubSpot-Association-Labels. Lookup-plus-Rolle-Patterns kollabieren in gelabelte Verknüpfungen. Custom Objects verdienen die Reise nur, wenn das Datenmodell sie auf der HubSpot-Seite tatsächlich braucht.
- Mappen Sie den Sharing-Rule-Blast-Radius vor dem Löschen jedes sichtbarkeitstragenden Felds. Owner-, Region-, Pod- und Rollen-Felder, die Salesforce-Sharing-Rules treiben, können nicht einfach verschwinden; sie übersetzen in HubSpot-Teams, Partition-Rules oder rollenbasierte Permissions, und die Übersetzung wird pro Feld dokumentiert.
- Zeichnen Sie das Spreadsheet ab, bevor der Import läuft. Das Triage-Spreadsheet ist das Cutover-Artefakt. Der HubSpot-Import ist eine Funktion dieses Spreadsheets, keine parallele Übung. Wenn ein Feld nicht abgezeichnet ist, bewegt es sich nicht.
Schritte eins bis sieben sind achtzig Prozent des Projekts. Der eigentliche Import ist ein Freitagnachmittag.
Wo Checkpoint ins Spiel kommt
Feldlevel-Triage ist die Arbeit, die entscheidet, ob eine Salesforce-zu-HubSpot-Migration sauber ausliefert oder dieselbe Instanz unter neuem Logo ausliefert. Wir fahren diese Übung auf jeder CRM-Migration, die wir berühren, und sie ist das Rückgrat dafür, wie wir HubSpot-Implementations nachgelagert eines Legacy-Systems angehen. Wenn die Triage das Projekt ist, ist das Operating Model, das die resultierende Instanz nutzt, was sie dauerhaft macht, das ist die Revenue-Operations-Arbeit, die folgt. Wenn Sie einen Salesforce-zu-HubSpot-Wechsel scopen und das Gespräch mit einem Mapping-Spreadsheet startet, sprechen Sie mit uns, bevor das Import-Fenster gebucht ist.
Quellen
- „What's Your Data Strategy?" Harvard Business Review, Mai–Juni 2017. hbr.org
- Lemkin, Jason. „Which CRM Should You Use in 2026/2027? Follow the Agents." SaaStr, April 2026. saastr.com