CRM-Konsolidierung nach M&A: Checkliste für RevOps

Wie führt man zwei CRM-Systeme nach einer Fusion zusammen?

Es gibt keine Standardabfolge, die für jede Fusion funktioniert, aber es gibt eine Reihenfolge, die sich in der Praxis bewährt hat: Erst die Datenmodelle beider Systeme vergleichen, dann Dubletten identifizieren, dann Prozesse und Pipelines vereinheitlichen, und erst danach die technische Migration starten. Wer diese Reihenfolge umdreht und zuerst migriert, um Zeit zu sparen, importiert die Unordnung aus System A unverändert in System B. Das Problem verschwindet nicht, es wandert nur mit um.

CRM-Konsolidierung nach M&A unterscheidet sich von einem gewöhnlichen Systemwechsel durch drei Faktoren: Zeitdruck aus dem Integrationsplan der Fusion, politische Fragen darüber, wessen System als Zielsystem gilt, und zwei historisch gewachsene Datenmodelle, die selten kompatibel sind.

Das Grundproblem: zwei Datenmodelle, eine Wahrheit

Jedes CRM-System bildet ab, wie ein Unternehmen über seine Kunden denkt. Firma A nutzt vielleicht Lifecycle Stages mit sieben Abstufungen, Firma B kommt mit drei aus. Firma A trennt Company und Account als eigene Objekte, Firma B führt beides in einem Objekt. Pflichtfelder, Validierungsregeln und Pick-List-Werte unterscheiden sich meist ebenso wie die Definition, wann ein Lead zum Kunden wird.

Diese Unterschiede sind selten dokumentiert, weil sie über Jahre gewachsen sind und niemand sie noch als Entscheidung wahrnimmt, sondern als gegeben hinnimmt. Vor jeder Migration braucht es deshalb ein Mapping-Dokument, das jedes Feld, jeden Objekttyp und jede Automatisierung aus beiden Systemen gegenüberstellt. Ohne dieses Mapping lässt sich keine verlässliche Zielarchitektur bauen. Wie ein belastbares Datenmodell für zusammengeführte Systeme aussieht, hängt stark davon ab, wie RevOps-Teams Datensilos grundsätzlich abbauen.

Doppelte Kundenstämme: Deduplizierung vor der Migration, nicht danach

Bei Fusionen zwischen Unternehmen derselben Branche kommt es häufig vor, dass Kunden in beiden Systemen existieren, teils als Lead, teils als aktiver Account, teils mit komplett unterschiedlichem Datensatz. Ein einfacher Abgleich über die E-Mail-Adresse reicht nicht aus, weil Ansprechpartner wechseln und Firmen unter mehreren Schreibweisen oder Domains erfasst sind.

Belastbare Matching-Strategien kombinieren mehrere Kriterien: Firmendomain, Handelsregisternummer oder Steuernummer, Firmenname mit Fuzzy-Matching und, wo vorhanden, externe IDs aus ERP-Systemen. Wer nur auf ein einzelnes Kriterium setzt, produziert entweder zu viele falsche Treffer oder übersieht echte Dubletten. Wichtig ist außerdem, vor dem Merge festzulegen, welcher Datensatz als Master gilt und wie Aktivitätshistorie, offene Deals und Tickets bei der Zusammenführung behandelt werden. Viele Merge-Funktionen in Standard-CRMs verlieren Verknüpfungen, wenn sie ohne Testlauf auf große Datenmengen angewendet werden.

Abweichende Prozesse: Pipelines, Automatisierungen und Lifecycle Stages

Selbst wenn die Datenstruktur angeglichen ist, bleiben die Prozesse dahinter oft unterschiedlich. Eine Vertriebspipeline mit sechs Phasen und eine mit vier Phasen lassen sich nicht einfach übereinanderlegen, ohne dass Deals in falschen Stufen landen. Workflows und Automatisierungen, die auf bestimmten Property-Werten feuern, funktionieren nach der Migration oft nicht mehr, weil die auslösenden Werte im Zielsystem gar nicht existieren.

Deshalb lohnt es sich, vor der technischen Umsetzung eine Liste aller aktiven Automatisierungen in beiden Systemen zu erstellen und für jede einzeln zu entscheiden, ob sie im Zielsystem nachgebaut, angepasst oder abgeschaltet wird. Eine 1:1-Übernahme aller Workflows aus beiden Altsystemen führt fast immer zu Konflikten, etwa wenn zwei Automatisierungen gleichzeitig dieselbe E-Mail an denselben Kontakt auslösen.

Wer entscheidet über das Zielsystem? Governance vor Technik

Die Frage, welches CRM nach der Fusion als führendes System weitergeführt wird, ist selten rein technisch. Oft hängt daran, welches Team im neuen Unternehmen mehr Einfluss behält, welche Prozesse als Standard gelten und wessen Reporting als Referenz dient. Diese Entscheidung sollte so früh wie möglich und ausdrücklich getroffen werden, statt sich implizit aus dem Projektverlauf zu ergeben.

Genauso wichtig ist die Klärung der Datenverantwortung im neuen System: Wer darf Felder anlegen oder löschen, wer genehmigt neue Automatisierungen, wer ist bei Datenqualitätsproblemen zuständig. Ohne klare Rollen entstehen nach der Konsolidierung neue Silos innerhalb desselben Systems, nur unsichtbarer als vorher. Ein Rollenmodell für Data Ownership im CRM sollte deshalb Teil des Konsolidierungsplans sein, nicht ein nachträglicher Punkt.

Make or buy: Wer führt die Migration durch?

CRM-Konsolidierungen binden über Wochen oder Monate Kapazität, die im Tagesgeschäft oft fehlt. Interne IT-Teams kennen die eigenen Systeme gut, haben aber selten Erfahrung mit Datenmigrationen dieser Größenordnung. Externe Spezialisten bringen diese Erfahrung mit, müssen sich aber erst in die historisch gewachsenen Besonderheiten beider Systeme einarbeiten.

Die Entscheidung zwischen interner Umsetzung, Agentur und Freelancer hängt stark von Projektgröße, Zeitfenster und der Frage ab, ob danach laufender Support gebraucht wird. Eine Übersicht der Vor- und Nachteile findet sich im Artikel CRM-Projekt: Freelancer, Agentur oder Festanstellung?.

Technische Validierung vor dem Go-Live

Vor dem finalen Umzug sollte jede Datenmigration gegen Testregeln laufen, statt erst im produktiven System aufzufallen. Pflichtfelder, Formatvorgaben und Wertebereiche lassen sich vorab gegen die Validierungsregeln des Zielsystems prüfen. Bei HubSpot etwa greifen ab September 2026 verschärfte Validierungsregeln für Schreibzugriffe über die CRM-API, die bei einer Massenmigration ungeprüfter Altdaten zu Fehlern führen können, wie im Beitrag zu HubSpot CRM-API-Validierungsregeln beschrieben. Ein Testlauf mit einer repräsentativen Stichprobe aus beiden Altsystemen deckt solche Konflikte auf, bevor sie den gesamten Datenbestand betreffen.

Checkliste für die CRM-Konsolidierung nach M&A

• Datenmodelle beider Systeme vollständig dokumentieren und gegenüberstellen (Objekte, Pflichtfelder, Pick-Lists)
• Matching-Kriterien für Dubletten festlegen, mindestens zwei unabhängige Merkmale kombinieren
• Masterdaten-Regel definieren: Welcher Datensatz gewinnt bei Konflikten
• Alle aktiven Automatisierungen beider Systeme auflisten und einzeln bewerten
• Zielsystem und Governance-Verantwortung formal festlegen, nicht implizit entstehen lassen
• Testmigration mit repräsentativer Stichprobe vor dem vollständigen Umzug durchführen
• Reporting- und Forecast-Logik nach der Migration gegen Altdaten validieren

Häufig gestellte Fragen

Wie lange dauert eine CRM-Konsolidierung nach einer Fusion?

Das hängt stark von Datenmenge, Anzahl der Automatisierungen und dem Grad der Abweichung zwischen beiden Systemen ab. Reine Datenmigrationen mit sauberem Mapping lassen sich in wenigen Wochen umsetzen, bei stark abweichenden Prozessen und großen Dublettenbeständen sind mehrere Monate realistisch.

Sollte man immer das größere der beiden Systeme als Zielsystem wählen?

Nicht zwangsläufig. Entscheidend ist, welches System die besseren Automatisierungen, die sauberere Datenstruktur oder die passendere Lizenzform für das fusionierte Unternehmen bietet. Die Größe der Nutzerbasis ist nur eines von mehreren Kriterien.

Wie vermeidet man Datenverlust bei der Zusammenführung zweier CRM-Systeme?

Durch eine Testmigration vor dem eigentlichen Go-Live, eine klare Masterdaten-Regel bei Dubletten und eine vollständige Dokumentation aller Felder und Verknüpfungen, die migriert werden müssen. Wer direkt im Produktivsystem migriert, bemerkt Datenverluste oft erst, wenn sie nicht mehr rückgängig zu machen sind.

Wer sollte die CRM-Konsolidierung nach einer Fusion leiten?

Fachlich sollte die Verantwortung bei RevOps oder einer vergleichbaren funktionsübergreifenden Rolle liegen, nicht allein bei der IT oder allein beim Vertrieb. Beide Perspektiven, Prozess und Technik, müssen in der Konsolidierung zusammenkommen.