Zoho CRM zu HubSpot migrieren

• Erst das Nutzungsaudit, dann die Feld-Zuordnung: Was du migrieren musst, zeigt nicht das Schema. Das zeigen sechs Monate echter Nutzung.
• Cross-App-Abhängigkeiten getrennt planen: Zoho Desk, Campaigns und Books sind ein eigener Workstream und kein Teil der CRM-Datenmigration.
• Native Sync-Tools für die Standardobjekte, ein begleiteter Import für Custom-Module mit Blueprint-Logik.
• Parallelbetrieb über mindestens einen vollen Berichtszyklus, bevor du Zoho abschaltest. Genau das ist dein Rollback.

Was unterscheidet eine Zoho-Migration von einer Salesforce- oder Dynamics-Migration?

Bei einer Zoho-Migration ist selten die Datenmenge das Problem. Das Problem ist, dass niemand aufgeschrieben hat, was das System eigentlich alles tut. Zoho wurde meist als günstiges, stark anpassbares CRM eingeführt. Über die Jahre haben wechselnde Mitarbeitende eigene Module, Deluge-Skripte und Blueprints ergänzt, und mitgeschrieben hat keiner, was davon heute noch gebraucht wird. Das macht den Wechsel riskanter als bei einem starren Enterprise-System.

Das ist keine Kritik an Zoho. Zoho löst genau das Problem, für das es gebaut wurde: ein CRM mit niedrigem Preis pro Sitz und großer Anpassungstiefe für Teams, die lieber früh selbst konfigurieren, als einen Implementierungspartner zu bezahlen. Dazu kommen Deluge-Skripte, Blueprints und mit Zoho One eine ganze Suite unter einem Vertrag. Diese Stärke ist der eigentliche Grund, warum Zoho-Migrationen anders verlaufen als Wechsel aus starreren Systemen.

Bei Salesforce oder Microsoft Dynamics startest du meist mit einem klar lizenzierten, administrativ verwalteten System und einer dokumentierten Objektstruktur (siehe unseren Leitfaden zur Microsoft-Dynamics-Migration). Zoho wächst dagegen oft informell. Ein Vertriebsleiter baut ein Custom Module für eine Sonderaktion, ein anderer ergänzt eine Blueprint-Regel für eine einmalige Kampagne. Keiner von beiden schreibt auf, ob das Modul zwei Monate oder zwei Jahre später noch gebraucht wird. Behandelst du eine solche Migration als reine Datenübertragung, kopierst du diese informell gewachsene Komplexität 1:1 ins neue System. Und damit verlierst du genau den Grund, warum dein Team wechseln wollte.

Typisch ist ein B2B-Software-Unternehmen, das Zoho in der Frühphase eingeführt hat. Oft reichte damals ein einzelner Mitarbeitender, der das System ohne Implementierungsbudget selbst konfigurieren konnte. Mit dem Team verschiebt sich der Engpass. Nicht mehr die Lizenzkosten sind das Problem, sondern die Zahl der Leute, die verstehen, wie die gewachsene Konfiguration funktioniert. Wirtschaftlich sinnvoll wird der Wechsel zu einem klarer dokumentierten System meist an einem erkennbaren Punkt: Der Vertrieb zählt 20 bis 30 Personen, mehrere GTM-Motions laufen parallel, und die erste RevOps-Rolle ist besetzt.

Das Ziel der Migration ist dabei kein austauschbares CRM, sondern eine vollständige HubSpot-Implementierung, die Vertrieb, Marketing und Service auf einem System zusammenführt. Das ist ein anderer Anspruch als Zohos modulare, oft lose verbundene App-Sammlung. Kurz definiert: Eine CRM-Migration überträgt Kontakte, Firmen und Verkaufschancen samt ihrer Automatisierungen von einem System ins andere. Dabei darf nichts verloren gehen, weder Historie noch Zuordnungen noch aktive Prozesse. Das klingt banal, bis du merkst, dass die „aktiven Prozesse“ bei Zoho nicht im Schema stehen. Du findest sie nur in den Köpfen der Leute, die die Blueprints einst gebaut haben.

Welche Zoho-Objekte entsprechen welchen HubSpot-Objekten?

Die gute Nachricht zuerst: Die Grunddaten deines Vertriebs ziehen ohne Umweg um. Contacts, Accounts und Deals haben in HubSpot eine direkte Entsprechung. Schwierig wird es bei allem, was Zoho über den Standard hinaus kann. Für benutzerdefinierte Module und Zoho-One-Anwendungen wie Desk und Campaigns triffst du eine bewusste Einzelfallentscheidung. Wird daraus ein HubSpot-Standardobjekt, ein eigenes Objekt in HubSpot, oder lässt du es bewusst zurück?

Dieselbe Grundfrage, was du übernimmst und was du zurücklässt, stellt sich bei jedem Wechsel aus einem modularen Budget-CRM. Das gilt auch für den Wechsel von Pipedrive zu HubSpot, obwohl Pipedrive deutlich weniger Custom-Module ansammelt als eine gewachsene Zoho-One-Instanz.

In der Praxis macht die Zeile „Custom Modules“ die meiste Arbeit. Eine gewachsene Zoho-Instanz hat selten weniger als ein Dutzend Custom-Felder pro Modul. Ein Teil davon entstand für einen einmaligen Anlass, der längst vorbei ist. Du kannst in HubSpot für jedes dieser Felder ein eigenes Custom-Property anlegen. Technisch geht das, inhaltlich ist es meist falsch.

Was prüfst du, bevor du das erste Feld zuordnest?

Bevor du ein einziges Feld zuordnest, brauchst du eine ehrliche Antwort auf eine Frage: Was davon nutzt dein Team heute noch? Genau das klärt ein Nutzungsaudit. Es fragt nicht, welche Module, Felder und Blueprint-Regeln im Schema existieren. Es fragt, welche davon aktiv genutzt werden.

Ein Schema-Audit zählt Felder. Ein Nutzungsaudit zählt, wie oft ein Feld in den letzten sechs Monaten befüllt oder eine Blueprint-Transition ausgelöst wurde. Von diesem Unterschied hängt ab, ob am Ende zehn oder vierzig Custom Properties in HubSpot landen.

• Feldnutzung exportieren: Zoho Analytics oder ein Reports-Export zeigt dir den Befüllungsgrad je Custom-Feld über die letzten sechs Monate. Felder unter 5 % Befüllung sind Kandidaten zum Zurücklassen. Sofort löschen musst du sie deshalb nicht.
• Blueprint-Transitionen zählen: Wie oft wurde jede Transition in den letzten 90 Tagen ausgelöst? Eine Regel, die niemand mehr durchläuft, musst du nicht als HubSpot-Workflow nachbauen, auch wenn sie im System noch aktiv aussieht.
• Cross-App-Abhängigkeiten auflisten: Dokumentiere jede Verbindung vom CRM zu Desk, Campaigns oder Books einzeln. Das ist ein eigener Workstream und kein Nebeneffekt der CRM-Datenmigration, deshalb planst du ihn im nächsten Abschnitt getrennt.
• Verantwortliche pro Modul benennen: Wer nutzt das Modul heute im Tagesgeschäft, und wer darf entscheiden, ob es bleibt oder zurückbleibt? Ohne benannte Verantwortliche wird aus Vorsicht meist alles migriert. Genau das soll das Audit verhindern.
• Cutoff-Datum für die Zählung festlegen: Saisonale Module, etwa für ein Jahresevent, wirken bei einer Zählung über sechs Monate fälschlich inaktiv. Ist dein Geschäft stark saisonal, ist ein Fenster von zwölf Monaten die realistischere Grundlage.

Wie migrierst du Zoho-CRM-Daten Schritt für Schritt nach HubSpot?

Die Reihenfolge entscheidet, ob am Ende ein schlankeres System steht oder eine Zoho-Kopie mit HubSpot-Oberfläche. Für die Standardobjekte senken native Synchronisationswerkzeuge das Risiko gegenüber selbstgebauten Skripten. Diese Werkzeuge kennen Feldtypen und Zuordnungen bereits und müssen sie nicht bei jedem Sync neu interpretieren.

1. Schließ das Nutzungsaudit ab (vorheriger Abschnitt) und halte schriftlich fest, welche Module du migrierst, welche du zusammenführst und welche du bewusst zurücklässt. Dieses Dokument ist die Grundlage für jeden weiteren Schritt. Ohne es fängt jede Diskussion über den Umfang wieder von vorn an.
2. Leg die Zielarchitektur in HubSpot fest: zuerst die Standardobjekte, Custom Objects nur für Module, die das Audit als aktiv bestätigt. So baust du kein Custom Object, bevor klar ist, ob du es überhaupt brauchst.
3. Bereinige die Daten vor dem Export: Pflichtfelder (vor allem E-Mail-Adressen), Duplikate und inkonsistente Werte korrigierst du in Zoho selbst und nicht erst nach dem Import in HubSpot. Im Quellsystem ist dieselbe Bereinigung günstiger als in einem neuen System, das dein Team noch nicht kennt.
4. Wähl das Sync-Werkzeug: Für Standardobjekte eignet sich ein natives Sync-Tool aus dem HubSpot-Marketplace, etwa der Eintrag Zoho CRM Data Sync. Für Custom-Module mit Blueprint-Logik ist ein begleiteter, mehrstufiger Import realistischer als ein einziger Big-Bang-Sync. Wie dabei die Verknüpfungen sauber bleiben, zeigt unser HubSpot-Datenimport-Leitfaden.
5. Bau Blueprints und Workflow-Regeln einzeln nach. Prüf jede Regel gegen HubSpot-Workflows, Sequences oder Playbooks, statt alle pauschal zu importieren. Eine Blueprint-Regel mit drei Bedingungen wird in HubSpot selten zu genau einem Workflow. Meist wird daraus eine Kombination aus Workflow und Property-basierter Liste.
6. Führ den Cross-App-Workstream parallel, nicht hinterher: Die Abhängigkeiten zu Zoho Desk, Campaigns und Books bekommen einen eigenen Zeitplan, damit sie den CRM-Cutover nicht verzögern. Startest du diesen Workstream erst nach dem Cutover, fehlt in der Übergangszeit die Ticket- oder Kampagnenhistorie im Kontaktverlauf.
7. Lass beide Systeme parallel laufen: Zoho bleibt über einen festgelegten Validierungszeitraum aktiv, bevor du es abschaltest. Der Zeitraum sollte mindestens einen vollständigen Reporting-Zyklus abdecken. Nur dann siehst du Abweichungen auch in aggregierten Kennzahlen und nicht bloß in einzelnen Datensätzen.

Was bricht bei einer Zoho-Migration am häufigsten, und wie behebst du es?

Die meisten Fehler fallen in drei Klassen: Feldtyp-Konflikte, verwaiste Automatisierungen und Cross-App-Lücken. Beim Export zeigt sich keiner davon. Sichtbar werden sie erst später, wenn ein Vertriebsmitarbeiter eine fehlende Information bemerkt oder eine Automatisierung ausbleibt, die vorher zuverlässig lief.

Fast alle diese Fehler entstehen an derselben Stelle: an der Nahtstelle zwischen zwei Systemlogiken und nicht in fehlerhaften Einzeldaten. Deshalb findest du sie früh mit einem Testimport: eine kleine, aber repräsentative Stichprobe von 50 bis 100 Datensätzen über alle betroffenen Objekte. So tauchen die Fehler auf, bevor sie im vollständigen Sync deutlich teurer zu beheben sind.

Der größte Einzelfaktor ist dabei die Datenqualität, nicht die Zielplattform. Bloor Research ist eine auf IT- und Datenmigrationsprojekte spezialisierte Analystenfirma, deren Auswertungen seit Jahren branchenübergreifend zitiert werden. Die Migrationsstudien der Firma zeigen bei Datenmigrationsprojekten durchschnittliche Kostenüberschreitungen von rund 30 % und Terminverzögerungen von rund 41 %. Der Hauptgrund ist praktisch nie die Zielplattform selbst. Es sind unklare Ausgangsdaten und ein Umfang, der erst während der Migration sichtbar wird, weil vorher niemand systematisch geprüft hat, was noch gebraucht wird.

Genau hier setzt das vorgezogene Nutzungsaudit an. Es zeigt dir den echten Umfang deines Zoho-zu-HubSpot-Wechsels, bevor er zum Terminrisiko wird. Sonst entdeckst du ihn erst beim Testimport oder, schlimmer, nach dem produktiven Cutover, wenn jede Korrektur laufende Vertriebsprozesse stört. Übertragen auf Zoho heißt das: Die Standardobjekte Contacts, Companies und Deals verursachen die Kostenüberschreitung nicht, sie sind gut dokumentiert. Teuer werden die Custom Modules und Blueprint-Regeln, deren Nutzungsgrad nur ein Audit zeigt und kein Schema.

Lässt sich eine Zoho-zu-HubSpot-Migration zurückrollen?

Ja, solange Zoho während des parallelen Testlaufs aktiv bleibt und du den Vertrag nicht vorzeitig kündigst. Ein Rollback heißt dann: Vertrieb und Service arbeiten weiter in Zoho, und HubSpot pausiert als Zielsystem, bis die offenen Probleme behoben sind.

Deshalb ist der Validierungszeitraum kein optionaler Puffer. Er ist der eigentliche Sicherheitsmechanismus der ganzen Migration. Verkürzt du ihn aus Zeitdruck, streichst du genau die Phase, in der ein Zurückrollen überhaupt noch möglich ist.

Wie validierst du die Migration nach dem Cutover?

Nach dem Cutover zählt nicht, ob alle Datensätze angekommen sind. Es zählt, ob sie im HubSpot-Alltag funktionieren. Automatisierungen lösen aus, und Berichte zeigen konsistente Zahlen. Dein Vertrieb findet dieselbe Information schneller als vorher und nicht bloß an derselben Stelle wie vorher.

• Vergleich Stichproben von mindestens 50 Datensätzen je Objekt mit der Zoho-Quelle, statt nur die Gesamtsumme zu zählen. Eine korrekte Gesamtsumme sagt nichts darüber, ob die Einzelwerte richtig zugeordnet sind.
• Lös jede migrierte Automatisierung mit einer echten Testtransaktion aus, statt nur die Konfiguration anzusehen.
• Vergleich das Reporting: Zieh dieselbe Kennzahl (z. B. offene Deals nach Stage) parallel in Zoho und HubSpot, bis beide über zwei Berichtszyklen übereinstimmen.
• Frag im Vertriebsteam nach: Findet das Team dieselbe Information schneller als vorher? Eine technisch korrekte Migration, die dein Team als langsamer empfindet, bleibt ein ungelöstes Adoptionsproblem.
• Teste die Berechtigungen je Rolle stichprobenartig. Sieht eine Testperson pro Rolle genau die Datensätze, die sie sehen soll, nicht mehr und nicht weniger?
• Schalte Zoho erst endgültig ab, wenn die Validierung über mindestens einen vollen Berichtszyklus bestanden ist.

Ein Punkt wird dabei regelmäßig unterschätzt: Die Validierung ist auch eine Kommunikationsaufgabe und keine rein technische. Während des Testlaufs sieht dein Vertrieb beide Systeme offen. Dann braucht er eine klare Ansage, welches System für welche Aktivität verbindlich ist. Sonst entstehen genau in dieser Phase neue Dubletten, weil ein Teil des Teams schon in HubSpot arbeitet und der andere sicherheitshalber weiter in Zoho pflegt.

Was solltest du anders machen als bei einer reinen 1:1-Kopie?

Der teuerste Fehler bei einer Zoho-Migration ist, jedes Custom-Modul und jede Blueprint-Regel unbesehen zu übernehmen. Damit baust du Zohos gewachsene Komplexität in HubSpot neu auf, samt der Module, die schon in Zoho niemand mehr brauchte. Das Nutzungsaudit vor der Feld-Zuordnung ist deshalb kein Zusatzschritt. Es macht den Unterschied zwischen einem schlankeren System und einer teureren Zoho-Kopie mit HubSpot-Lizenzkosten.

• Das Audit kommt vor der Feld-Zuordnung, nicht danach.
• Desk, Campaigns und Books bekommen einen eigenen Workstream und laufen nicht als Anhängsel der CRM-Migration mit.
• Standardobjekte synchronisierst du nativ, Custom-Module mit Blueprint-Logik importierst du begleitet.
• Zoho bleibt an, bis die Validierung einen vollen Berichtszyklus bestanden hat.
• Für jedes Modul steht von Anfang an ein Verantwortlicher fest, damit nicht aus Vorsicht alles migriert wird.

Für dich heißt das: Räum zuerst auf, was niemand mehr nutzt, und migrier dann. So wechselst du nicht bloß das System, sondern baust genau die Komplexität ab, die der Wechsel beheben sollte. Der nächste Schritt ist selten eine weitere Checkliste. Meist ist es ein Gespräch über deine konkrete Zoho-Instanz: Welche Module bleiben, welche Cross-App-Abhängigkeiten gibt es, und wie lang muss der Validierungszeitraum für deine Datenlage sein?

Kostenloses Erstgespräch: 60 Minuten, kein Pitch und eine ehrliche Einschätzung, ob unser Vorgehen zu deiner Zoho-Migration passt.

SalesPlaybook ist HubSpot Diamond Solutions Partner mit 39+ 5-Sterne-Bewertungen im HubSpot Solutions Directory. Den internen Aufwand solcher Wechsel halten wir bewusst klein: Bei MAIA by Prodlane lief die Migration in weniger als 2 Monaten bei unter 20 Stunden CEO-Aufwand.