CRM-Migration abnehmen: Warum eine passende Zeilenzahl nicht reicht

Eine CRM-Migration ist abgenommen, wenn die benötigten Informationen im Zielsystem richtig zugeordnet und im Arbeitsablauf verwendbar sind. Eine passende Zeilenzahl belegt nur, dass zwei Mengen gleich gross sind. Sie beweist weder dieselben Identitäten noch dieselben Beziehungen.

Dieser Leitfaden beschreibt eine eigene Abnahmemethode anhand eines fiktiven Systemwechsels. Er ergänzt den kontrollierten HubSpot-Import um den vollständigen Übergang: Bestand, Beziehungen, Historie, laufende Änderungen und die tatsächliche Arbeit im neuen System.

Den Umfang vor dem ersten Transfer festlegen

Im Beispiel werden 120 aktive Unternehmen, 240 Kontakte und 80 offene Deals übernommen. Abgeschlossene Altvorgänge bleiben in einem lesbaren Archiv. Diese Auswahl ist eine bewusste Projektentscheidung. Sie wird dokumentiert, damit ein später fehlender Altauftrag nicht mit einem technischen Migrationsfehler verwechselt wird.

Für jedes Objekt werden eingeschlossene Felder und Beziehungen festgelegt. Auch bewusst nicht übertragene Informationen stehen im Plan. Eine Aktivitätshistorie, die nur als Archiv verfügbar bleibt, ist keine vollständig migrierte Historie. Die Anwender müssen wissen, wo sie diese Informationen finden.

Die Quelle wird vor Änderungen gesichert. Ein Export mit Fachwerten kann als Vergleichsgrundlage dienen; er ist nicht automatisch ein wiederherstellbares Systembackup. Prüfe konkret, ob Anhänge, Aktivitäten, Beziehungen und Systemeinstellungen enthalten sind. Der Rückkehrplan benennt die tatsächlichen Grenzen.

Identitäten über eine Zuordnungstabelle erhalten

Die alte ID wird nicht einfach als neue System-ID behandelt. Stattdessen entsteht eine Zuordnung von Quellobjekt und Quell-ID zu Zielobjekt und Ziel-ID. Damit lassen sich Kontakte, Unternehmen und Deals nach dem Transfer wieder verbinden, auch wenn das Ziel eigene IDs vergibt.

Die offene Zeile wird nicht gelöscht, nur damit die Tabelle vollständig aussieht. Jede eingeschlossene Quell-ID braucht genau ein dokumentiertes Ergebnis: übertragen, begründet ausgeschlossen oder als Ausnahme zurückgestellt. Zusammengeführte Dubletten benötigen eine eigene nachvollziehbare Regel für mehrere Quell-IDs auf eine Ziel-ID.

Bei HubSpot sind Identifikatoren und Anlagewege bei der Deduplizierung zu beachten. Die hier vorgeschlagene Zuordnungstabelle ist eine zusätzliche Migrationskontrolle. Sie ersetzt nicht die tatsächlichen Import- und Zuordnungsregeln des Zielsystems.

Gleiche Summen können falsche Daten verdecken

Stell dir vor, im Ziel fehlen die Kontakte ALT-77 und ALT-78. Dafür wurden zwei andere Kontakte doppelt angelegt. Die Gesamtzahl bleibt 240. Ein reiner Mengenvergleich meldet Erfolg, obwohl zwei Personen fehlen und zwei zusätzliche Kopien existieren.

Dasselbe gilt für Geldbeträge. Wird ein Deal um 5.000 EUR zu hoch und ein anderer um 5.000 EUR zu niedrig übertragen, stimmt die Gesamtsumme. Deshalb braucht die Abnahme sowohl aggregierte Kontrollwerte als auch den Vergleich auf ID-Ebene.

Normalisierung braucht Grenzen. Unterschiedliche Datumsdarstellungen dürfen für einen Vergleich vereinheitlicht werden. Inhaltlich unterschiedliche Werte dürfen nicht durch grobes Kürzen gleich gemacht werden. Aus zwei ähnlichen Firmennamen entsteht keine bestätigte Identität.

Beziehungen und Historie separat prüfen

Für den Beispieldeal ALT-42 ist ALT-18 der Käufer und ALT-77 die fachliche Kontaktperson. Nach der Migration muss NEU-701 mit NEU-501 und NEU-901 in der richtigen Bedeutung verbunden sein. Eine beliebige Verbindung zu irgendeinem Unternehmen genügt nicht.

Prüfe besonders Mehrfachbeziehungen: mehrere Ansprechpartner, mehrere Unternehmen an einem Vorgang und historische Rollen. Der Artikel zum CRM-Beziehungsmodell zeigt, warum eine Person nicht für jeden Deal neu angelegt werden muss.

Bei Aktivitäten werden Datum, Zuordnung und Verfügbarkeit geprüft. Eine Notiz vom ursprünglichen Kundengespräch soll nicht als neu geführtes Gespräch am Migrationstag erscheinen. Wo das Zielsystem bestimmte historische Eigenschaften nicht abbildet, wird diese Einschränkung dokumentiert. Ein lesbarer Originalnachweis kann notwendig bleiben.

Laufende Änderungen während des Wechsels behandeln

Ein Export ist ein Stichtag. Danach können im Altsystem neue Anfragen eingehen oder Dealwerte geändert werden. Der Übergangsplan legt fest, ob eine Bearbeitungspause, ein zusätzlicher Änderungsabgleich oder ein anderer kontrollierter Weg verwendet wird. Ohne diese Regel entstehen Lücken zwischen Export und produktivem Start.

Im Beispiel wird nach dem Testtransfer ein finales Änderungsfenster abgeglichen. Jede seit dem ersten Export geänderte ID wird erneut geprüft. Eine neue Änderung im Zielsystem darf dabei nicht unbemerkt überschrieben werden. Konflikte erhalten eine fachliche Entscheidung statt einer pauschalen "neuester Zeitstempel gewinnt"-Regel.

Automationen und externe Integrationen werden in die Umschaltung einbezogen. Zwei gleichzeitig aktive Systeme können denselben Vorgang doppelt bearbeiten. Der Plan nennt deshalb, welche Schreibwege wann aktiv sind und wer den Wechsel bestätigt. Ein Datenimport allein schaltet keinen Geschäftsprozess kontrolliert um.

Eine Rückkehr muss vorher ausführbar sein

Der Rückkehrplan definiert einen Auslöser, eine zuständige Person und den letzten gesicherten Stand. Er erklärt auch, wie neue produktive Änderungen aus dem Zielsystem erhalten bleiben. Einfach das Altsystem wieder zu öffnen, kann inzwischen erfasste Arbeit verlieren.

Nicht jede Änderung ist reversibel. Zusammenführungen, externe Nachrichten und ausgelöste Folgeprozesse lassen sich durch einen Datenexport nicht rückgängig machen. Deshalb werden solche Wirkungen im Test begrenzt und erst nach den passenden Prüfungen freigegeben. Der Plan unterscheidet Wiederherstellung von Daten und Behandlung bereits ausgelöster Folgen.

Die fachliche Abnahme mit einer echten Aufgabe abschliessen

Eine Vertriebsmitarbeiterin übernimmt im Beispiel einen offenen Deal. Sie findet den richtigen Ansprechpartner, liest die letzte relevante Vereinbarung und dokumentiert den nächsten Schritt. Eine zweite Person kann diese Arbeit übernehmen. Beide verwenden ihre normalen Berechtigungen, keinen Adminzugang.

Die Abnahme enthält die vollständigen Kontrollzahlen und die offenen Ausnahmen. "80 Deals übertragen" reicht nicht; es müssen die vorgesehenen 80 Dealidentitäten mit passenden Beträgen und Beziehungen sein. Eine begründete Restliste kann akzeptiert werden, wenn sie den vereinbarten Arbeitsumfang nicht blockiert und eine zuständige Person hat.

Im HubSpot-Setup ist das Ergebnis ein belegter Systemübergang: Quell-IDs erklärt, Zielwerte verglichen, Beziehungen geprüft und Vertriebsaufgaben erfolgreich erledigt. Erst dann wird der neue Bestand zur verlässlichen Arbeitsgrundlage.

Quellenprüfung: 5. November 2026. Verlinkte Produktdokumentation belegt die ausdrücklich genannten Funktionen. Methoden, Tabellen und Rechenfälle sind eigene redaktionelle Vorschläge; fiktive Beispiele sind keine Kundenresultate.