Die meisten Fehlschläge bei HubSpot-Salesforce-Integrationen liegen nicht an Tools oder APIs – sie entstehen, weil Teams Daten synchronisieren, ohne Ownership, Governance oder Verhaltensregeln zu definieren. Wenn Systeme verbunden werden, bevor die Datenhoheit geklärt ist, entstehen Dubletten, fehlerhafte Datensätze, ungenaue Reports und Vertrauensverlust zwischen Abteilungen. Dieser Artikel erklärt, warum Integrationen Governance-Projekte sind – keine rein technischen – und skizziert ein 5-Schritte-Framework von Cremanski & Company, um Fehler zu vermeiden: echtes Datenmodell mappen, Ownership definieren, Sync-Verhalten festlegen, einen einzigen Integration Owner benennen und vor dem Go-live in einer sicheren Umgebung testen. Das Ergebnis sind weniger Konflikte, saubere Daten, schnellere Abstimmung und erfolgreiche Migrationen. Drei Tage nach dem HubSpot-Salesforce-Sync bemerkt der VP of Sales 8.000 doppelte Kontakte. Marketing findet die Hälfte seiner Leads nicht mehr. RevOps erhält panische Slack-Nachrichten über „kaputte“ Workflows.
Kommt Dir das bekannt vor?
Folgendes ist passiert: Das Unternehmen hat voll auf Lizenzen und Setup-Kosten gesetzt. Aber niemand hat vorher die entscheidende Frage gestellt: Wer besitzt welche Daten – und wann?
Wir haben mit Hunderten von Unternehmen an HubSpot-Integrationen gearbeitet. Bevor sie zu uns kommen, sehen wir immer das gleiche Muster: Teams verknüpfen zuerst Systeme und überlegen sich die Regeln erst danach. Sie diskutieren über Tools und API-Limits, während sie die Entscheidungen ignorieren, auf die es wirklich ankommt.
Das eigentliche Problem ist nicht technischer Natur. Es geht um Kontrolle. Integrationen sind Governance-Herausforderungen im Gewand von Tool-Projekten. Solange Du das nicht erkennst, wirst Du monatelang damit beschäftigt sein, teures Chaos aufzuräumen.
Warum die meisten Integrationen von hinten aufgezäumt werden
Die Tool-First-Falle
Integrationsprojekte starten fast immer mit der falschen Frage: „Nutzen wir Zapier oder native Connectors?“
Das ist nicht der richtige Ansatzpunkt.
Teams verschwenden Wochen damit, Tools zu testen. Sie probieren Zapier. Dann Workato. Dann Make.com. Währenddessen fragt niemand: Welche Daten müssen eigentlich bewegt werden? Wer darf sie ändern? Und was passiert, wenn Systeme widersprüchliche Daten liefern?
Das Ergebnis ist vorhersehbar: Zapier läuft bei großen Datensätzen ins Timeout. Der native Connector kommt mit Custom Objects nicht klar. Deine API-Lösung ignoriert Feldberechtigungen. Und plötzlich wechselst Du mitten im Projekt die Tools und verbrennst Budget.
Niemand besitzt die Datenhoheit
„Welches System ist die Source of Truth – HubSpot oder Salesforce?“
Diese Frage killt jede Produktivität. Zweistündige Meetings enden mit: „Lass uns das offline besprechen.“
Warum? Du stellst die falsche Frage.
Stattdessen musst Du zuerst für Alignment und klare Verantwortlichkeiten sorgen. Dann definierst Du die Prozesse. Erst danach geht es an die entscheidenden Fragen: Welches System führt welche Daten? Und wann wird die Hoheit übergeben?
Ohne klare Ownership-Regeln wird jeder Sync-Konflikt zur Krise. Sales aktualisiert Salesforce. Marketing ändert HubSpot. Der Sync läuft. Daten werden überschrieben. Teams streiten. Vertrauen geht verloren.
Die „Wir finden das später raus“-Katastrophe
„Brauchen wir wirklich eine Testumgebung? Können wir in der Live-Umgebung nicht einfach vorsichtig sein?“
Wenn Du Dir diese Frage stellst, hast Du Dich für den harten Weg entschieden.
In der Produktivumgebung zu testen bedeutet: Dein erster Sync erzeugt 50.000 Duplikate. Sales findet keine Accounts mehr. Marketing-Mails gehen an die falschen Empfänger. Du verbringst sechs Wochen damit, Probleme zu beheben, während das Vertrauen des Managements schwindet.
Fünf Entscheidungen, die Desaster verhindern
Vergiss Tools erst einmal. Du brauchst zuerst fünf Entscheidungen. Diese verhindern 90 % aller Integrationsfehler.
Entscheidung 1: Bilde Dein echtes Datenmodell ab
Dein Datenmodell ist ein Vertrag zwischen Systemen. Es definiert, wie Informationen zusammenhängen.
Kannst Du aufzeichnen, wie Kontakte, Unternehmen und Deals zusammenhängen? Nicht nach HubSpots Schema. Nach DEINEM.
Das ist entscheidend, weil Systeme unterschiedlich denken. Salesforce nutzt Accounts, HubSpot Companies. Dein Feld „Account-Typ“, das den Vertrieb steuert? HubSpot hat womöglich nichts Vergleichbares.
Mappe diese Punkte, bevor Du Daten migrierst:
Wie Objekte miteinander verknüpft sind
Welche Felder sind Pflicht vs. optional
Datentypen und Validierungsregeln
Custom Objects und Beziehungen
Welche historischen Daten Du wirklich brauchst
Überspringst Du das, holt Dich das Problem später ein. Etwa wenn Deine Opportunity Stages nicht zur HubSpot-Pipeline passen. Dann bricht jeder Sales-Report zusammen.
Entscheidung 2: Lege fest, wer was kontrolliert
Hör auf zu fragen: „Welches System ist die Source of Truth?“
Stelle stattdessen diese Frage: Wer kontrolliert welche Daten in jeder einzelnen Phase?
Klare Ownership-Regeln können so aussehen (das variiert von Unternehmen zu Unternehmen):
Salesforce übernimmt Accounts, sobald sie zu Customers werden
HubSpot steuert alle Leads bis zur MQL-Phase
Salesforce verwaltet die Deal-Stages 3–5
Nur HubSpot kann E-Mail-Adressen ändern
Nur Salesforce kann Vertragswerte bearbeiten
Was passiert, wenn jemand denselben Datensatz in beiden Systemen ändert? Deine Regeln entscheiden, wer gewinnt. Ohne feste Regeln spielst Du mit Deinen Daten russisches Roulette.
Ein Software-Kunde machte es sich einfach: HubSpot übernahm alles bis zum MQL. Dann übernahm Salesforce. Klarer Übergabepunkt. Keine Reibereien. Saubere Daten.
Entscheidung 3: Bestimme, wie sich Daten verhalten
Felder zu mappen ist der einfache Teil. Der schwere Teil ist das Verhalten.
„Die Hälfte unserer Kontakte wurde synchronisiert, aber die Deals nicht. Was ist passiert?“
Ganz einfach: Parent-Datensätze synchronisieren vor Child-Datensätzen. Kontakte existieren vor Deals. Unternehmen existieren vor Kontakten. Verwechsle die Reihenfolge, und alles bricht im Hintergrund zusammen.
Definiere Folgendes für jeden Sync:
Unidirektional oder bidirektional?
In Echtzeit oder getaktet?
In welcher Reihenfolge synchronisieren Objekte?
Was passiert, wenn übergeordnete Datensätze fehlen?
Wie führst Du ein Matching von Duplikaten durch?
Kläre das jetzt – oder lerne es später auf die schmerzhafte Tour.
Entscheidung 4: Benenne einen klaren Owner
„Wer verantwortet die Integration – IT, RevOps, Marketing oder Sales?“
Eine Person. Mit Namen. Auf der Dokumentation.
Nicht „das Team“. Nicht „IT und Marketing gemeinsam“. Ein Mensch, der die Sync-Integrität verantwortet.
Sie brauchen:
Technische Fähigkeiten zum Lesen von Error-Logs
Die Befugnis, Teams auch mal ein klares „Nein“ zu erteilen
Vertrauen durch Sales und Marketing
Leidenschaft für Dokumentation
Kein klarer Owner bedeutet eine verwahrloste Integration. Probleme bleiben wochenlang unbemerkt. Dokumentation veraltet. Wissen geht verloren, wenn Mitarbeiter das Unternehmen verlassen.
Entscheidung 5: Teste in einer sicheren Umgebung
„Wir haben mit der Synchronisierung begonnen und jetzt 50.000 Duplikate. Können wir das rückgängig machen?“
Nein. Du kannst nur aufräumen. Langsam. Schmerzhaft. Öffentlich.
Testing bewahrt Dich vor:
Feststellen, dass Dein ERP keine Beziehungen exportieren kann
Learning: Sonderzeichen bringen die Synchronisation zum Absturz
Feststellen, dass Deine Deduplizierungslogik in einer Endlosschleife feststeckt
Zusehen müssen, wie Two-Way-Syncs Daten zerschießen
Minimale Testumgebung:
Echte Datenstruktur spiegeln
Teste mehr als 100 Datensätze pro Objekt
Dinge bewusst auf die Probe stellen
Custom-Beziehungen prüfen
Zwei Wochen lang parallel laufen lassen
Dabei können völlig unterschiedliche Szenarien herauskommen: Unternehmen A testet 3 Wochen lang, findet einige gravierende Probleme und behebt sie sauber. Unternehmen B überspringt das Testing, um „Zeit zu sparen“, und räumt neun Monate später immer noch auf. Wir haben schon Kunden erlebt, die nach einem katastrophalen Launch ganz ohne Tests zu uns kamen.
Wann zwei Systeme sinnvoll sind
„Sollten wir sowohl Salesforce als auch HubSpot behalten?“
Manchmal ja. Wenn jedes System etwas kann, was das andere nicht leisten kann.
Vielleicht bildet Salesforce komplexe Enterprise-Deals ab, HubSpot steuert das Marketing – oder HubSpot managt einfache Sales-Prozesse, während Dein ERP das Fulfillment übernimmt.
Zwei Systeme können funktionieren. Aber nur mit klaren Ownership-Regeln. Andernfalls kämpfen zwei Versionen der Wahrheit gegeneinander.
Echte Success Story:
Ein Hersteller hatte Deals über 1 Mio. € in Salesforce. Das Marketing brauchte Automatisierung.
Die Lösung: HubSpot führt die Kontakte bis zur Qualifizierung. Danach übernimmt Salesforce. Einfacher Handoff. Klare Regeln.
Das Ergebnis: 40 % besseres Lead-Tracking. Null Konflikte. Zufriedene Teams.
Wie? Sie haben vier Wochen lang konzipiert, bevor irgendetwas angebunden wurde. Cremanskis Framework war dabei der Leitfaden für jede Entscheidung.
Die Phase, die jeder überspringt (aber niemand überspringen sollte)
„Wie lange dauert eine Migration?“
Falsche Frage. Die richtige lautet: „Wie lange dauert eine ERFOLGREICHE Migration?“
Plane drei zusätzliche Wochen ein, bevor Du auch nur ein einziges Datum anfasst. Für Planung. Für Design. Für Entscheidungen.
Ja, es fühlt sich langsam an. Ja, die Leute werden sich beschweren. Aber schau Dir die Zahlen an:
Planungsaufwand: 3 Wochen strukturierte Arbeit
Die Kosten fehlender Planung: 3–6 Monate Aufräumarbeit und verärgerte Nutzer
Planung bedeutet keine Verzögerung. Sie ist Schadensprävention. Du dokumentierst Entscheidungen jetzt, statt sie mitten in einer Krise treffen zu müssen.
Red Flags: Wann Du stoppen solltest
Lieber zweimal prüfen, bevor es kracht: Mehr als drei Red Flags? Dann noch nicht synchronisieren.
Datenmodell-Warnungen:
Kannst Deine Datenbeziehungen nicht schnell aufzeichnen
Noch unentschlossen bezüglich Data Cleaning
Du weißt nicht, ob HubSpot zu Deinen Anforderungen passt?
Ownership-Warnungen:
Diskutiert Ihr noch über die „Single Source of Truth“?
Kein Plan zur Unterbindung manueller Änderungen
Mehrere Teams beanspruchen dieselben Daten für sich
Warnsignale für das Management:
Kein Owner benannt
„Dokumentieren wir später“-Mentalität
Kein Plan für einen Audit-Trail
Test-Warnhinweise:
Gedanken zum Testen in der Live-Umgebung
Keine Testumgebung bereit
Kein schriftlicher Testplan
Das sind keine Empfehlungen. Es sind Frühwarnindikatoren für Fehlentwicklungen.
Dein 30-Tage-Erfolgsplan
Keine Lust auf ein weiteres gescheitertes Projekt? Hier ist Dein Monatsplan:
Woche 1–2: Mappe Deine Daten
Objektbeziehungen abbilden
Feldanforderungen auflisten
Custom Objects finden
Entscheide, was Du behältst
Woche 2–3: Ownership zuweisen
Definiere, wer was steuert
Übergabepunkte markieren
Konfliktregeln definieren
Hole das Commitment aller Beteiligten ein
Woche 3–4: Die technischen Komponenten aufsetzen
Sync-Diagramme erstellen
Verhaltensregeln definieren
Testumgebung aufbauen
Testszenarien planen
Woche 4: Alles validieren
Führe vollständige Tests durch
Probleme dokumentieren
Bilde Deinen Owner aus
Runbooks erstellen
Brauchst Du Unterstützung? Das HubSpot-Team von Cremanski macht aus komplexen Migrationen reibungslose Übergänge.
Zuerst konzipieren. Danach verbinden. Später danken.
Dein zukünftiges Ich wird Dir für die vermeintlich mühsame Planungsarbeit von heute danken. Dein Team wird dem System vertrauen. Deine Daten bleiben sauber.
Die Wahl liegt bei Dir. Jetzt überstürzen, später büßen. Oder jetzt planen und dauerhaft erfolgreich sein.
Triff die smarte Entscheidung.
