CRM-Migration mit Salesforce und HubSpot: Lehren aus der Praxis für die ersten 30 Tage

Ob eine CRM-Migration gelingt, entscheidet sich in den ersten 30 Tagen. Der Datenimport ist selten das eigentliche Problem. Schwierig sind die Entscheidungen, die Teams im ersten Monat aufschieben, nämlich zu Umfang, historischen Daten, Prozessdesign, Entwicklungsstopp, Automatisierung, Zugriffsrechten und Backups. Diese Entscheidungen holen das Projekt in den letzten Wochen wieder ein, wenn jede Änderung am meisten kostet.

In den Salesforce- und HubSpot-Migrationen, die wir durchgeführt haben, wechseln die Tech-Stacks und die Namen der Anbieter. Die Fehler bleiben dieselben. Für einen CEO oder CFO zeigen sich die Kosten in einem Go-live, der sich um ein Quartal verschiebt, in einem Sales-Team, das in zwei Systemen arbeitet, und in einem Forecast, dem während der Umstellung niemand traut. Für die RevOps-Verantwortlichen, die das Projekt leiten, zeigen wir im Folgenden, was immer wieder schiefläuft und was funktioniert.

Die meisten Probleme einer CRM-Migration entstehen in der Analysephase

Was Sie in der ersten Woche aufschieben, bestimmt, wie viel Schaden später im Projekt entsteht. Wenn Sie im dritten Monat noch am Objekt-Mapping sitzen, haben Sie zu spät angefangen. Ein schleichend wachsender Projektumfang ist selten ein Planungsfehler. Er ist das Symptom einer unvollständigen Analyse.

Erstellen Sie vor allem anderen eine vollständige Bestandsaufnahme Ihrer Daten und Reports. Listen Sie jedes Objekt, jedes Custom Field und jeden Report auf, den irgendjemand braucht, jeweils mit Füllgrad und Datum der letzten Nutzung. Markieren Sie Felder, die niemand nutzt, als Löschkandidaten, denn so günstig wie bei einer Migration werden Sie diese Felder nie wieder los. Unser Leitfaden zum CRM-Datenbankdesign beschreibt, was das Zieldatenmodell abbilden muss.

Beantworten Sie danach schriftlich die Frage nach den historischen Daten. Wie weit zurück migrieren Sie Cases, Aktivitäten, Kampagnen, Verträge und Anhänge, und was wird stattdessen archiviert? Diese eine Antwort bestimmt Datenvolumen, Zeitplan und Tool-Auswahl. Legen Sie die Aufbewahrungsfristen je Datensatztyp gemeinsam mit der Rechts- und Finanzabteilung fest, statt einfach alles zu behalten. Machen Sie die Antwort verbindlich, holen Sie die Freigabe ein und gehen Sie zum nächsten Punkt über, denn eine Diskussion darüber im vierten Monat kostet Wochen.

Entscheiden Sie für jeden Prozess, ob Sie ihn unverändert migrieren oder neu gestalten

Das ist die folgenreichste Entscheidung jeder Salesforce- oder HubSpot-Migration. Wer einen komplexen Prozess erst mitten im Projekt neu gestaltet, vervielfacht die Komplexität in alle Richtungen. Neue Felder werfen alte Entscheidungen zur Automatisierung wieder auf, neue Automatisierungen alte Entscheidungen zum Reporting, und unbemerkt wird aus der Migration eine Neuimplementierung.

Unsere Wissensdatenbank in Five Dots beschreibt dafür eine einfache Triage. Gehen Sie die Customer Journey von Anfang bis Ende mit den Menschen durch, die die einzelnen Schritte verantworten, und geben Sie jedem Prozess genau eine Farbe.

• Grüne Prozesse werden unverändert migriert, weil sie funktionieren und die Nutzer zufrieden sind.
• Gelbe Prozesse stimmen im Prinzip und brauchen kleinere Anpassungen, etwa einfachere Record Types, Freigaben oder Felder.
• Rote Prozesse passen nicht zur tatsächlichen Arbeitsweise des Unternehmens und brauchen einen Workshop mit den Nutzern, bevor irgendetwas gebaut wird.
• Graue Prozesse gehören gar nicht ins CRM und wandern ins Produkt oder in ein anderes Tool oder fallen ganz weg.

Arbeiten Sie dann in zwei Strängen. Ein Lift-and-Shift-Strang überführt die grünen und gelben Prozesse zügig und sichert so den Kern. Ein Redesign-Strang gestaltet die roten Prozesse in Workshops mit den Nutzern neu. Manche roten Prozesse lassen sich bis zur Deadline nicht mehr unterbringen. Benennen Sie diese, halten Sie eine Übergangslösung bereit und planen Sie sie für die Zeit nach dem Cutover ein, statt ein schwaches Design durchzudrücken. Halten Sie jede Entscheidung in einem Satz fest, etwa "Lead Routing wird unverändert migriert, die Deal-Phasen werden neu gestaltet, der Renewal-Workflow wird unverändert migriert." Wer harten Entscheidungen ausweicht, sodass am Ende alles gelb ist, verschiebt das Redesign nur in die Umsetzung.

"Das klären wir später" ist der Satz, mit dem aus einem Sechsmonatsprojekt ein Zwölfmonatsprojekt wird.

Legen Sie schriftlich einen Entwicklungsstopp für das alte CRM fest

Sobald die Vorbereitung der Migration beginnt, muss die Weiterentwicklung im Quellsystem ruhen. Das betrifft Custom Fields, Automatisierungen, Layouts, kleine Anpassungen an Integrationen, Validation Rules und Page Layouts. Sonst migrieren Sie ein System, das sich ständig verändert.

Vereinbaren Sie den Stichtag für den Entwicklungsstopp vorab mit allen betroffenen Teams. Was danach gebaut wird, liegt außerhalb der Migration. Taucht eine wirklich dringende Änderung auf, läuft sie über einen Change-Request-Prozess mit einer verantwortlichen Person und einer schriftlich dokumentierten Freigabe. Informelle schnelle Ergänzungen nach dem Stichtag kosten beim Testen mehr Zeit als ihre Umsetzung.

Holen Sie Compliance, Rechts- und Finanzabteilung schon in der Analysephase dazu

Teams, die bei der Festlegung des Umfangs übergangen wurden, melden sich in der letzten Woche, wenn Änderungen am meisten kosten. Finanzabteilung, Rechtsabteilung und Compliance bringen ihre Anforderungen regelmäßig spät ein. Typische Beispiele sind Audit-Abhängigkeiten von Opportunity-Daten, eigene Vertragsobjekte der Rechtsabteilung, ARR-Felddefinitionen, die von den Annahmen des RevOps-Teams abweichen, und Aufbewahrungsregeln, die sich aus regulatorischen Pflichten ergeben. Jeder dieser Punkte lässt sich in Woche zwei günstig lösen und in Woche zwanzig nur noch teuer.

Führen Sie in der Analysephase einen Workshop zu Compliance- und Rechtsanforderungen durch. Erfassen Sie jedes regulierte Datenelement und dokumentieren Sie, wer dafür verantwortlich ist. Pflegen Sie eine Stakeholder-Liste, die auch die stillen Teams enthält, nicht nur die, die zum Kick-off erschienen sind.

Prüfen Sie jede Automatisierung, bevor Sie den ersten Datensatz migrieren

Die meisten CRMs schleppen jahrelang gewachsene, undokumentierte Automatisierungen mit sich. Workflows von Personen, die das Unternehmen vor zwei Jahren verlassen haben, laufen im Produktivsystem weiter und verändern unbemerkt Datensätze.

Erfassen Sie alles, darunter Workflow-Automatisierungen, Zuweisungsregeln, Validation Rules, Scoring-Logik, Feld-Trigger, Sequenz-Enrollments und Integrationen von Drittanbietern. Halten Sie für jede Automatisierung fest, was sie tut, warum es sie gibt, wer sie gebaut hat, wann sie zuletzt geändert wurde und wie kritisch sie ist. Treffen Sie dann je Automatisierung eine Entscheidung.

• Migrieren Sie sie unverändert.
• Bauen Sie sie für die neue Plattform neu.
• Schalten Sie sie ab.

Automatisierungen, die "wahrscheinlich noch etwas Nützliches tun" und deshalb einfach mitmigriert werden, tragen Komplexität von einem System ins nächste, ohne dass sie je aufgelöst wird. Achten Sie auf Automatisierungen, deren Bedingungen bestimmte Record Types nennen, denn jede davon funktioniert nicht mehr, sobald Record Types zusammengelegt werden. Planen und schätzen Sie den Neuaufbau als eigenen Arbeitsstrang. Logik, die sich auf einer Plattform in fünf Minuten konfigurieren ließ, braucht auf einer anderen oft einen ganz anderen Ansatz. Das ist keine Aufgabe für den letzten Sprint. Wenn HubSpot und Salesforce eine Zeit lang parallel laufen, beschreibt unser Leitfaden zur Integration von HubSpot und Salesforce, was Sie vorbereiten sollten, bevor Sie die beiden Systeme verbinden.

Behandeln Sie die Deduplizierung als eigenen Arbeitsstrang, nicht als Aufräumaktion der letzten Woche

Das Dublettenproblem ist immer größer als erwartet, und wenn Sie mehrere Systeme zusammenführen, vervielfachen sich die Dubletten. In Kundenprojekten haben wir sprunghaft gestiegene Dublettenzahlen gesehen, die auf eine frühere Massenmigration und auf hochgeladene Zielkundenlisten zurückgingen. Die Bereinigung beginnt deshalb oft mit den Altlasten des letzten Projekts.

Die Reihenfolge ist entscheidend. Bereinigen Sie zuerst jede Quelle für sich und gleichen Sie danach den zusammengeführten Datenbestand ab. Wer den ersten Schritt überspringt, erzeugt zusammengeführte Dubletten mit widersprüchlichen Feldwerten, die später niemand mehr entwirren kann. Gleichen Sie nicht nur Namen ab. Nutzen Sie Domains und Beziehungen zwischen Unternehmen, und erhalten Sie beim Zusammenführen die Aktivitätshistorie und die Zuordnung von Kontakten zu Accounts.

Machen Sie sich mit dem Importverhalten der Zielplattform vertraut. HubSpot zum Beispiel dedupliziert beim Import Kontakte anhand der E-Mail-Adresse und Unternehmen anhand des Domainnamens. Unternehmen, die über die API angelegt werden, dedupliziert HubSpot dagegen nicht anhand der Domain. Ein Ladeskript, das diesen Unterschied ignoriert, erzeugt genau die Dubletten, die Sie gerade bereinigt haben. Unsere Anleitung, wie Sie ein CRM mit Python aktualisieren, ohne Dubletten zu erzeugen, zeigt die Matching-Logik in der Praxis.

Planen Sie die Deduplizierung als eigenen Arbeitsstrang im Projektplan ein, mit einer verantwortlichen Person, einem Zeitplan und klaren Abschlusskriterien.

Stimmen Sie Sicherheits- und Zugriffsmodelle vor dem Testen ab

Ein stark eingeschränktes Modell auf Basis von Vertriebsgebieten und ein offenes, rollenbasiertes Modell lassen sich nicht einfach zusammenführen. Wer so tut, als ginge das, bekommt eine Testphase, in der die Hälfte der Nutzer ihre eigenen Datensätze nicht sieht und die andere Hälfte alles.

Führen Sie in der Analysephase einen Workshop zum Sicherheitsmodell durch. Stellen Sie die Zugriffsmodelle der beteiligten Systeme nebeneinander, benennen Sie die Konflikte, wählen Sie ein Zielmodell und dokumentieren Sie die Entscheidung und den Migrationspfad. Erledigen Sie das, bevor die Tests beginnen. Das Sharing-Modell beeinflusst auch die Ladegeschwindigkeit. Das Trailhead-Modul zu Large Data Volumes von Salesforce weist darauf hin, dass das Sharing bei einem privaten Sharing-Modell neu berechnet wird, während Datensätze hinzukommen. Das bremst große Ladevorgänge.

Planen Sie die Ladereihenfolge und die Regeln, die Sie abschalten

Daten haben Abhängigkeiten. In Salesforce lassen sich untergeordnete Datensätze erst laden, wenn die übergeordneten existieren, und die Datensatzinhaber müssen angelegt sein, bevor die Daten geladen werden, die ihnen gehören. Importieren Sie übergeordnete vor untergeordneten Datensätzen, pflegen Sie ein Mapping von alten zu neuen Datensatz-IDs, und denken Sie daran, dass automatisch nummerierte Datensätze wie Cases und Verträge ihre Nummern in der Importreihenfolge erhalten. Läuft dabei etwas schief, hat die Nummernfolge Lücken, die sich nur mühsam beheben lassen. Dateien, Anhänge und Knowledge-Artikel sind meist der langsamste Teil. Klären Sie deshalb, ob Sie sie wirklich brauchen, bevor Sie sie migrieren.

Um einen großen Ladevorgang zu beschleunigen, deaktivieren Teams oft Validation Rules, Zuweisungsregeln und Trigger, wie es auch das bereits genannte Trailhead-Modul beschreibt. Das ist in Ordnung, solange das Wiedereinschalten auf der Checkliste steht. Regeln, die während des Ladens deaktiviert waren, müssen systematisch wieder aktiviert werden, und die Daten müssen gegen sie geprüft werden, denn Datensätze, die an der Validierung vorbeigelaufen sind, korrigieren sich nicht von selbst.

Schützen Sie die Testzeit und arbeiten Sie mit einer einzigen UAT-Vorlage

Wenn eine Migration in Verzug gerät, wird zuerst die Testzeit gekürzt. Das sollte nicht passieren. Dauert die Datenmigration länger, verschiebt sich der Go-live-Termin, und die Testzeit bleibt, wie sie ist. Vereinbaren Sie das vor Projektbeginn als Governance-Regel, statt später einen Streit darüber zu verlieren, wenn der Zeitplan bereits rutscht. Planen Sie Nutzerlizenzen und Zeit für den User Acceptance Test (UAT) rechtzeitig vor dem Cutover ein.

Zwei Fallen beim Testen sollten Sie kennen. Erstens ist die Staging-Umgebung nicht die Produktivumgebung. Layouts, Validation Rules, Nutzerprofile und deaktivierte Workflows laufen zwischen den Umgebungen mit der Zeit auseinander. Führen Sie deshalb ein Änderungsprotokoll zwischen Staging- und Produktivumgebung und prüfen Sie es vor jeder Go-live-Checkliste. Zweitens braucht UAT eine einzige Vorlage. Wenn sich herausstellt, dass ein Team eine hervorragende Vorlage hat und alle anderen improvisiert haben, hat die Qualitätskontrolle versagt. Standardisieren Sie die Vorlage beim Kick-off, mit Objekten, Feldern, Automatisierungen, Integrationen und Nutzerrollen, und wenden Sie sie in allen Teams gleich an.

Sichern Sie Daten und Konfiguration mehr als einmal

Ein einzelnes Backup beim Kick-off ist keine Backup-Strategie. Erstellen Sie im Projektverlauf benannte Exporte an festen Kontrollpunkten.

• Ein Ausgangsstand vor der Migration, bei dem Daten und Konfiguration getrennt exportiert werden.
• Ein Export nach der Deduplizierung.
• Ein Export nach dem Laden jeder Objektgruppe.
• Ein letzter Export vor dem Go-live.

Versehen Sie jeden Export mit Datum und Beschreibung. Das sind Ihre Rollback-Punkte, wenn später etwas schiefgeht.

Daten und Konfiguration brauchen getrennte Backups. Ein Datenexport umfasst keine Automatisierungen, Felddefinitionen, Page Layouts oder Berechtigungen. Der native Data Export Service von Salesforce zum Beispiel erzeugt ein ZIP-Archiv mit CSV-Dateien und lässt sich für einen wöchentlichen Export alle 7 Tage oder für einen monatlichen Export alle 29 Tage ausführen. Anhänge sind nur enthalten, wenn Sie sie auswählen. Geplante native Exporte in einem geschützten gemeinsamen Speicher können genügen, wenn Ihre Anforderungen an die Wiederherstellung überschaubar sind. Spezialisierte Backup-Produkte erleichtern vor allem die Wiederherstellung.

Testen Sie die Wiederherstellung. Ein Backup, das Sie nie wiederhergestellt haben, ist ein Backup, das Sie in Wahrheit nicht haben. Stellen Sie deshalb testweise eine Stichprobe aus dem Ausgangsstand wieder her, bevor Sie ihn brauchen. Speichern Sie die Exporte an einem gemeinsamen, zugriffsgeschützten Ort, mit einer Namenskonvention, die auch dann funktioniert, wenn die Projektleitung bei einem Vorfall gerade im Urlaub ist.

Bauen Sie sichtbaren Puffer in den Zeitplan ein und halten Sie Plan B schriftlich fest

Wer Erfahrung mit der Leitung von CRM-Implementierungen hat, ist aus gutem Grund skeptisch gegenüber ehrgeizigen Go-live-Terminen. Wenn das Auslaufen einer Lizenz Ihre Deadline vorgibt, planen Sie von diesem Datum aus rückwärts. Lassen Sie zwischen dem geplanten Cutover und dem Lizenzende Wochen statt Tage für Verzögerungen, Korrekturen und Support. Weisen Sie diesen Puffer im Plan ausdrücklich aus. Versteckter Puffer wird vom Optimismus aufgezehrt, ausgewiesener Puffer bleibt erhalten.

Wählen Sie das Datum für den Cutover mit Blick auf den Vertriebskalender. Stellen Sie um, wenn der Druck im Vertrieb am geringsten ist, oft direkt nach einem Quartalsabschluss, und nicht in den letzten Wochen eines Quartals. Behalten Sie nach dem Cutover für eine gewisse Zeit einige Lizenzen im alten System, mit reinem Lesezugriff, damit die Teams die Historie weiterhin einsehen können, während sich das neue System einspielt.

Halten Sie vor dem Go-live Plan B schriftlich fest. Was passiert, wenn Sie den Entwicklungsstopp verlängern, den Go-live verschieben, unkritische Objekte vorab migrieren und den Rest zurückhalten oder den Umfang kürzen müssen? Legen Sie die Kriterien jetzt fest, schreiben Sie sie auf und teilen Sie sie dem Lenkungsausschuss mit, bevor die Entscheidung ansteht.

Wenn Sie für diese ersten 30 Tage Unterstützung suchen, beginnen unsere Implementierungen von HubSpot und Salesforce mit der Analysephase, dem Datenmodell und dem Migrationsplan, die wir gemeinsam mit Ihrem eigenen Team erarbeiten.

Führen Sie ein einziges Entscheidungsprotokoll und machen Sie es verbindlich

Entscheidungen aus Meetings müssen dokumentiert werden, und alle müssen dafür denselben Ort nutzen. Notion, Confluence, Jira oder ein einziges gemeinsames Dokument erfüllen alle ihren Zweck, denn das Tool ist weniger wichtig als die Disziplin. Wählen Sie eines aus, legen Sie die Regeln beim Kick-off fest und bestimmen Sie eine Person, die auf ihre Einhaltung achtet. Eine Entscheidung gilt erst dann als abgeschlossen, wenn sie dokumentiert ist.

Wenn Entscheidungen über drei Tools, zwei Slack-Threads und den Kopf einer einzelnen Person verstreut sind, werden sie immer wieder neu verhandelt, und an neu verhandelten Entscheidungen scheitern Zeitpläne. Halten Sie außerdem die Entscheidungsbefugnis bei einem kleinen Kernteam. Breite Freigaberunden bremsen jede Entscheidung, und das Entscheidungstempo ist das größte Risiko einer Migration.

Warum Fehler bei der CRM-Migration auf die ersten 30 Tage zurückgehen

Jede Lehre in diesem Beitrag hat dieselbe Ursache. Entscheidungen, die in die ersten 30 Tage gehören, fallen stattdessen in den letzten 30 Tagen. Analyse, Historie und Aufbewahrung, die Wahl zwischen Migration und Neugestaltung, der Entwicklungsstopp, das Automatisierungsinventar, die Stakeholder-Übersicht, das Sicherheitsmodell, die Ladereihenfolge, Backups, Puffer, Plan B und ein einziges Entscheidungsprotokoll gehören alle an den Anfang.

Klären Sie diese Punkte, bevor jemand einen Datensatz anfasst, und die Migration wird einfacher. Wenn Sie die Plattform noch auswählen, hilft Ihnen zuerst unser Vergleich von HubSpot und Salesforce bei dieser Entscheidung. Wenn Sie in diesem Quartal eine Migration starten, vereinbaren Sie ein Gespräch, und wir helfen Ihnen, die ersten 30 Tage zu planen.

FAQ zur CRM-Migration

Was sollte in den ersten 30 Tagen einer CRM-Migration passieren?

In den ersten 30 Tagen sollten Sie Umfang und Historie klären, für jeden Prozess zwischen Migration und Neugestaltung entscheiden, den Entwicklungsstopp festlegen, das Automatisierungsinventar erstellen, Stakeholder und Compliance-Anforderungen erfassen sowie das Sicherheitsmodell und den Backup-Plan festlegen. Aufbau und Datenimport kommen nach diesen Entscheidungen, nicht davor.

Sollten wir alle historischen Daten ins neue CRM migrieren?

Meist nicht. Vereinbaren Sie mit der Rechts- und Finanzabteilung je Datensatztyp einen Stichtag für die Historie, migrieren Sie, was tatsächlich genutzt wird, und archivieren Sie den Rest in einem geschützten Speicher, aus dem er sich weiterhin abrufen lässt.

Sollten wir vor oder nach einer CRM-Migration deduplizieren?

Deduplizieren Sie vor und während der Migration. Bereinigen Sie zuerst jedes Quellsystem und gleichen Sie dann den zusammengeführten Datenbestand ab, damit Sie keine zusammengeführten Dubletten mit widersprüchlichen Werten ins neue CRM laden.

Was ist ein Entwicklungsstopp bei einer CRM-Migration?

Ein Entwicklungsstopp ist der Stichtag, ab dem niemand mehr neue Felder, Automatisierungen, Layouts oder Integrationen im alten CRM baut. Alles Dringende läuft über einen Change-Request-Prozess mit einer verantwortlichen Person und einer schriftlichen Freigabe, damit das Team kein System migriert, das sich laufend verändert.

Wann ist der beste Zeitpunkt für die Umstellung auf ein neues CRM?

Stellen Sie um, wenn der Druck im Vertrieb am geringsten ist, oft direkt nach einem Quartalsabschluss. Lassen Sie vor dem Auslaufen einer Lizenz einige Wochen Puffer und behalten Sie nach dem Go-live noch eine Weile Lesezugriff auf das alte System.

Was sollte ein Backup bei einer CRM-Migration umfassen?

Ein Backup für die Migration sollte Daten und Konfiguration umfassen, getrennt exportiert und an mehreren Kontrollpunkten. Sichern Sie einen Ausgangsstand vor der Migration, erstellen Sie dann Exporte nach der Deduplizierung, nach jedem Ladevorgang und vor dem Go-live, und testen Sie eine Wiederherstellung des Ausgangsstands, bevor Sie sie brauchen.