More in
Datenmigrations-Leitfaden
Sauberer Export aus Salesforce: Der migrationsfertige Export-Leitfaden
Apr. 18, 2026
Sauberer Export aus HubSpot: Was der native Export übersieht
Apr. 18, 2026
Sauberer Export aus Pipedrive: Deals, Kontakte und Aktivitätsverlauf
Apr. 18, 2026
Raus aus Tabellen: Die 5-Schritte-Migration in ein echtes CRM
Apr. 18, 2026
Historische Aktivitäten, Notizen und E-Mails bei der CRM-Migration übertragen
Apr. 18, 2026
Datenmigrations-Audit nach der Migration: Was wann geprüft werden muss
Apr. 18, 2026 · Currently reading
Benutzerzugriff bei der CRM-Migration: Der Least-Privilege-Ansatz
Apr. 18, 2026
Die CRM-Migration dem Vertriebsteam kommunizieren
Apr. 18, 2026
Rollback-Planung für CRM-Migrationen: Hoffentlich brauchen Sie es nicht
Apr. 18, 2026
Langfristige Archivierung von Legacy-CRM-Daten: Was behalten und wie
Apr. 18, 2026
Post-Migrations-Audit: Was überprüfen und wann
Ein RevOps-Team gab an einem Freitagnachmittag seine Migration frei. Der Import war ohne Fehler abgeschlossen. Die Datensatzanzahlen sahen ungefähr richtig aus. Das Team ging nach Hause.
Sechs Wochen später wurde eine Marketingkampagne gestartet und 14.000 E-Mails versandt. Bounce-Rate: 11 %. Der Grund: 11 % der Kontakte hatten leere E-Mail-Felder im neuen CRM. Der Import hatte still und leise versagt bei Datensätzen, bei denen die Quelldaten E-Mail-Adressen in einem leicht abweichenden Spaltenformat enthielten. Das Fehlerprotokoll hatte sie markiert, aber niemand hatte es gelesen.
Sechs Wochen lang hatten Mitarbeiter Anrufe protokolliert, Deals aktualisiert und eine Pipeline aufgebaut, die auf 11 % fehlerhaften Kontaktdatensätzen basierte. Die Bereinigung dauerte zwei Wochen, erforderte die manuelle De-Duplizierung korrigierter Datensätze und sorgte für so viel Verwirrung, dass die Pipeline-Prognosen von drei Mitarbeitern komplett neu aufgebaut werden mussten.
Ein 30-minütiger Audit am Tag der Migration hätte das verhindert.
Dieser Leitfaden gibt Ihnen den dreistufigen Audit-Prozess, der dieses Szenario verhindert, strukturiert nach Zeitplan mit spezifischen Prüfungen in jedem Intervall. Er baut direkt auf Cutover Day: die Checkliste, die Katastrophen verhindert auf: Die Prüfungen während der Migration sind das, was dieser Audit in den folgenden Stunden misst.
Wann den Audit durchführen
Stunde 1. Führen Sie diesen Audit durch, bevor das Vertriebsteam Zugang hat. Sie prüfen auf kritische Fehler: fehlende Datensätze, leere Pflichtfelder, kaputte Beziehungen. Das sind die Probleme, die das CRM ab Minute eins unbrauchbar oder irreführend machen.
Stunde 24. Nachdem das System einen Tag live war, sind tiefgreifendere Integritätsprüfungen möglich. Beziehungen hatten Zeit, sich aufzulösen. Die Duplikaterkennung ist gelaufen. Automatisierungsregeln haben ausgelöst. Jetzt können Sie prüfen, ob die Daten korrekt funktionieren, nicht nur ob sie vorhanden sind.
Stunde 72. Drei Tage nach dem go-live werden Geschäftslogik-Probleme sichtbar. Pipeline-Berichte stimmen nicht mit den Snapshots vor der Migration überein. Lead Routing funktioniert nicht richtig. Automatisierung feuert falsch auf importierten Datensätzen. Diese Probleme werden erst sichtbar, nachdem das System tatsächlich genutzt wird.
Warum bis „Woche 2" zu warten zu spät ist:
Jeden Tag, an dem das Vertriebsteam das CRM nutzt, legen sie neue Aktivitäten auf die vorhandenen Daten. Gartners Forschung zur Datenqualität schätzt, dass die Kosten für die Behebung eines Datenqualitätsproblems um das Zehnfache steigen für jede Stufe, die es ungeprüft durchläuft: Probleme in der ersten Stunde zu finden ist um Größenordnungen günstiger als sie in Woche zwei zu entdecken. Ein Kontakt mit einem leeren E-Mail-Feld, den ein Mitarbeiter am zweiten Tag anschreibt, hat nun einen Aktivitätsdatensatz, eine Notiz und eine Follow-up-Aufgabe dran. Diesen Kontakt zu bereinigen bedeutet, entweder diese Datensätze zu verlieren oder sie manuell zum korrigierten Datensatz zu migrieren. Je früher Sie Probleme erkennen, desto günstiger ist die Behebung.
Stufe 1: Kritische Prüfungen (Stunde 1)
Diese Prüfungen finden statt, bevor außer dem Migrationsteam jemand Zugang hat.
1. Datensatzanzahl pro Objekt
Rufen Sie die Datensatzanzahl für jedes migrierte Objekt aus dem neuen CRM ab und vergleichen Sie mit Ihrem Quell-Snapshot vor der Migration.
| Objekt | Quellanzahl | Importierte Anzahl | Akzeptable Abweichung |
|---|---|---|---|
| Kontakte | [aus Quellsystem] | [aus CRM] | ± 1 % (Fehlerprotokoll erklärt Rest) |
| Accounts/Unternehmen | [aus Quellsystem] | [aus CRM] | ± 1 % |
| Deals/Opportunities | [aus Quellsystem] | [aus CRM] | ± 0,5 % |
| Aktivitäten | [aus Quellsystem] | [aus CRM] | ± 2 % (höhere Abweichung akzeptabel) |
Wenn Sie bei Kontakten oder Deals mehr als 2 % abweichen, öffnen Sie das System nicht. Lesen Sie zuerst das Fehlerprotokoll. Signifikante Abweichungen, die das Fehlerprotokoll nicht erklären kann, könnten Ihre Rollback-Auslösebedingungen erfüllen: Entscheiden Sie, bevor Sie dem Vertriebsteam Zugang geben.
2. Vollständigkeit der Primärschlüssel
E-Mail ist der Primärschlüssel für Kontakte. Telefon ist sekundär. Prüfen Sie, ob diese Felder in der erwarteten Rate befüllt sind.
Führen Sie einen schnellen Filter aus: Kontakte ohne E-Mail. Wenn das Ergebnis mehr als 2 bis 3 % Ihrer Gesamtkontaktanzahl beträgt, haben Sie einen Import-Fehler oder ein Quelldaten-Problem. Beheben Sie das, bevor das Team mit dem E-Mail-Versand oder Anrufen beginnt.
3. Offene Opportunities vorhanden mit korrekten Stages
Offene Deals müssen im CRM mit korrekten Stage-Werten vorhanden sein. Filtern Sie nach allen offenen Opportunities. Prüfen Sie:
- Gesamtanzahl stimmt mit Quellsystem überein
- Stage-Verteilung entspricht ungefähr dem Stand im Quellsystem
- Keine Deals defaulteten auf eine generische Stage aufgrund einer Stage-Namen-Abweichung
4. Fehlerprotokoll prüfen
Jedes CRM-Import-Tool generiert ein Fehlerprotokoll. Lesen Sie es. Jede Zeile in diesem Protokoll repräsentiert einen Datensatz, der nicht importiert wurde: entweder vollständig fehlgeschlagen oder mit übersprungenen Feldwerten importiert.
Häufige Einträge im Fehlerprotokoll:
- „Datensatz existiert bereits": Duplikaterkennung hat den Import gestoppt; entscheiden Sie, ob zusammenführen oder überspringen
- „Ungültiges E-Mail-Format": Die Quelldaten enthalten fehlerhafte E-Mails
- „Pflichtfeld leer": Der Import hat ein Pflichtfeld übersprungen; der Datensatz ist importiert, aber unvollständig
- „Wert nicht in Auswahlliste": Ein Stage- oder Status-Wert in Ihren Quelldaten stimmt nicht mit den Optionen des CRM überein
Erstellen Sie eine Triage-Liste: wie viele Datensätze, welcher Fehlertyp, kann er per Batch behoben werden oder erfordert er manuelle Prüfung?
Stufe 2: Datenintegritätsprüfungen (Stunde 24)
Nach 24 Stunden führen Sie eine tiefere Ebene von Prüfungen zu Beziehungen und Feldvollständigkeit durch.
1. Beziehungsintegrität
Kontakte ohne Accounts. Deals ohne Kontakte. Deals ohne Accounts. Diese verwaisten Datensätze sind nutzbar, aber unvollständig, und sie akkumulieren Verwirrung, wenn Mitarbeiter versuchen, damit zu arbeiten.
Entscheiden Sie für jeden Verwaisten-Typ:
- War das beabsichtigt (die Quelldaten hatten keinen Account für diese Kontakte)?
- Oder ist es ein Import-Fehler (der Account-Import schlug fehl, sodass der Kontakt nichts hat, womit er verknüpft werden kann)?
Wenn es ein Fehler ist, beheben Sie ihn. Wenn es beabsichtigt ist, dokumentieren Sie es.
2. Feldvollständigkeit benutzerdefinierter Felder bei wichtigen Objekten
Wählen Sie Ihre 5 bis 10 wichtigsten benutzerdefinierten Felder (diejenigen, die der Vertrieb für Berichte oder Filter verwendet). Für jedes:
- Welcher Prozentsatz der relevanten Datensätze hat dieses Feld befüllt?
- Entspricht die Befüllungsrate dem Quellsystem?
Ein benutzerdefiniertes Feld, das im Quellsystem zu 80 % befüllt war, sollte im Zielsystem ebenfalls zu etwa 80 % befüllt sein. Wenn es auf 30 % fällt, wurde das Feld beim Import nicht korrekt zugeordnet.
3. Ergebnisse des Duplikaterkennungsscans
Die meisten CRMs führen beim Import eine automatische Duplikaterkennung durch oder bieten einen integrierten Scan, der manuell ausgelöst werden kann. Führen Sie ihn innerhalb der ersten 24 Stunden aus, bevor Mitarbeiter Daten hinzufügen. Wenn Sie den Shadow Import Test vor dem go-live übersprungen haben, sind Duplikate wahrscheinlicher: Der Shadow Import ist speziell dafür konzipiert, diese vor der Produktion aufzudecken.
Prüfen Sie den Duplikat-Bericht mit diesem Ansatz:
- Exakte E-Mail-Duplikate: sofort zusammenführen
- Gleicher Name, ähnliches Unternehmen: zur Überprüfung durch den Sales Manager markieren, vor dem Zusammenführen
- Mögliche Duplikate (ähnlicher Name, andere E-Mail): zur manuellen Prüfung markieren, nicht auto-mergen
4. Aktivitätsdatensätze mit den richtigen Datensätzen verknüpft
Nehmen Sie 20 zufällige Aktivitätsdatensätze (Notizen, Anrufprotokolle) aus dem Import. Für jeden:
- Ist er mit einem Kontakt verknüpft?
- Ist er mit dem richtigen Kontakt verknüpft (kein Duplikat oder falsche Person)?
- Wird der Inhalt korrekt angezeigt (keine Kodierungsprobleme, keine Kürzungen)?
- Ist das Datumsfeld befüllt und korrekt?
Stufe 3: Geschäftslogik-Prüfungen (Stunde 72)
Diese Prüfungen erfordern, dass das System in Verwendung war. Sie erkennen Probleme im Verhalten des CRM, nicht nur im Inhalt der Daten.
1. Pipeline-Berichte stimmen mit Snapshots vor der Migration überein
Exportieren Sie vor der Migration einen Snapshot Ihrer Pipeline: Gesamtanzahl offener Deals, gesamter Pipeline-Wert, Deal-Anzahl nach Stage, durchschnittliche Deal-Größe. Vergleichen Sie ihn mit demselben Bericht im neuen CRM zum 72-Stunden-Zeitpunkt.
Wenn die Zahlen bedeutend abweichen, mehr als 5 % Abweichung beim gesamten Pipeline-Wert, haben Sie ein Datenproblem. Entweder wurden Deals nicht migriert, oder Deal-Werte kamen falsch an, oder das Stage-Mapping hat die Deal-Verteilung verschoben.
2. Lead-Routing-Regeln feuern korrekt
Wenn Ihr CRM automatisiertes Lead Routing verwendet (neue Leads werden basierend auf Regeln an bestimmte Mitarbeiter oder Gebiete geleitet), testen Sie es mit einem neuen Datensatz. Erstellen Sie einen Test-Lead, der einer Routing-Regel entspricht, und überprüfen Sie, ob er korrekt geleitet wird.
Importierte Datensätze lösen Routing-Regeln oft falsch aus, wenn das Routing datumsbasiert ist oder auf dem Erstellungsdatum des Datensatzes basiert. Ein 2023 erstellter Datensatz, der an Ihrem Migrationsdatum importiert wurde, könnte sein Erstellungsdatum auf das Import-Datum gesetzt bekommen, was Routing-Regeln auslöst, die für historische Datensätze nicht gelten sollten. Prüfen Sie das innerhalb von 72 Stunden, bevor ein Rückstand falsch zugeordneter Datensätze entsteht.
3. Automatisierungsauslöser feuern nicht falsch auf importierten Datensätzen
Das ist eines der häufigsten und schädlichsten Probleme nach der Migration. Wenn Ihr CRM Automatisierungen hat, die beim Erstellen von Datensätzen auslösen (Willkommens-E-Mails, Onboarding-Sequenzen, interne Benachrichtigungen), können importierte Datensätze alle gleichzeitig auslösen. Der Wikipedia-Artikel zur Workflow-Automatisierung bietet nützlichen Kontext dazu, wie triggerbasierte Systeme reagieren, wenn große Mengen neuer Datensätze eingefügt werden, und warum das Unterdrücken von Automatisierungen bei Massenimporten Standard-Praxis ist.
Die meisten CRMs bieten die Option, Automatisierungen beim Import zu unterdrücken. Wenn Sie diese nicht genutzt haben, prüfen Sie, ob Automatisierungen für das gesamte Importvolumen ausgelöst wurden. Wenn ja, haben Sie möglicherweise automatisierte E-Mails an jeden migrierten Kontakt gesendet.
Prüfen Sie Ihr Automatisierungs-Aktivitätsprotokoll innerhalb von 72 Stunden. Bei Fehltriggern müssen Sie entweder zukünftige Auslöser auf importierten Datensätzen unterdrücken oder eine Korrektur-Kommunikation senden.
4. Benutzerzuweisung korrekt
Öffnen Sie 20 zufällige Deals und 20 zufällige Kontakte. Überprüfen Sie für jeden, ob der zugewiesene Mitarbeiter dem Quellsystem entspricht. Falsche Mitarbeiterzuweisung schafft zwei Probleme: Mitarbeiter können keine Datensätze sehen, die sie besitzen, und Mitarbeiter können Datensätze sehen, die sie nicht besitzen.
Häufige Ursachen: Abweichendes Benutzernamen-Format zwischen Quell- und Zielsystem (vorname.nachname vs. vorname_nachname), inaktive Nutzer im Quellsystem, die neu zugewiesen werden müssen, oder eine Catch-all-Zuweisung, die nicht zugeordnete Datensätze an einen Nutzer weiterleitete.
Befunde dokumentieren und priorisieren
Schweregrad-Klassifizierung:
| Schweregrad | Beschreibung | Beispiel | Behebungszeitraum |
|---|---|---|---|
| P1: Datenverlust | Datensätze komplett fehlend oder kritische Felder leer | 500 Kontakte nicht importiert | Vor Vertriebszugang |
| P2: Datenqualität | Datensätze importiert, aber mit falschen oder fehlenden Werten | Benutzerdefiniertes Feld bei 15 % der Kontakte leer | Innerhalb von 24 Stunden |
| P3: Geschäftslogik | Automatisierung oder Routing falsch ausgelöst | Willkommens-E-Mails an alle importierten Kontakte gesendet | Innerhalb von 72 Stunden |
| P4: Kosmetisch | Anzeigeproblem, Formatierung, geringfügige Inkonsistenzen | Telefonformat-Inkonsistenz | Innerhalb von 30 Tagen |
Triage-Vorlage:
Dokumentieren Sie für jeden Befund:
- Beschreibung des Befunds
- Schweregrad
- Anzahl betroffener Datensätze
- Ursache (falls bekannt)
- Behebungsansatz
- Verantwortlicher
- Zieldatum für die Behebung
Halten Sie das als gemeinsames Dokument mit dem Sales Manager und dem IT-Verantwortlichen. P1- und P2-Probleme sollten behoben sein, bevor Sie Stakeholdern gegenüber „Migration abgeschlossen" melden.
Audit-Ergebnisse an Stakeholder kommunizieren
Was Sie dem VP of Sales mitteilen:
Beginnen Sie mit dem, was funktioniert. Nennen Sie die Anzahl der Kontakte, Accounts und offenen Deals, die erfolgreich migriert wurden. Harvard Business Review-Forschung zum Change-Management stellte fest, dass Mitarbeiter Veränderungen widerstehen, die sie nicht verstehen: Transparente, faktenbasierte Kommunikation über den Migrationsstatus reduziert die Skepsis, die die CRM-Akzeptanz in den ersten Wochen verlangsamt, erheblich. Berichten Sie über P1-Befunde mit dem Behebungszeitraum. Geben Sie keine technische Aufschlüsselung aller Prüfungen, sondern kommunizieren Sie den geschäftlichen Einfluss.
Bei bedeutenden Problemen: „Wir haben 220 Kontakte mit fehlenden E-Mail-Feldern identifiziert. Wir beheben das heute, und es betrifft keine offenen Deals. Das Problem lag in den Quelldaten, nicht im Import-Prozess." Die Migration dem Vertriebsteam kommunizieren erklärt, wie diese Gespräche zu führen sind, ohne das Vertrauen der Mitarbeiter in das neue System zu untergraben, bevor die Akzeptanz greift.
Was Sie intern halten:
P3- und P4-Befunde müssen nicht an die Vertriebsleitung kommuniziert werden. Behandeln Sie sie operativ und fügen Sie sie in eine schriftliche Zusammenfassung zum 30-Tage-Zeitpunkt ein.
Erwartungen bei bekannten Problemen managen:
Wenn es Probleme gibt, deren Behebung mehr als einen Tag dauert, informieren Sie das Team proaktiv. „Möglicherweise sehen Sie diese Woche einige Kontakte ohne Telefonnummern. Wir führen einen Batch-Fix durch und das Problem ist bis Donnerstag behoben." Das verhindert, dass Mitarbeiter Support-Tickets anlegen und davon ausgehen, das CRM sei defekt.
Häufige Fehler
Stichprobenartige Prüfung statt systematischer Analyse. 10 zufällige Datensätze zu öffnen und Erfolg zu melden ist kein Audit. Es ist optimistisches Raten. Nutzen Sie die Datensatzanzahl, Feldvollständigkeit und Beziehungsintegritätsprüfungen als strukturierten Prozess.
Die Geschäftslogik-Stufe überspringen. Die meisten Teams führen nur Stunde-1-Prüfungen durch und öffnen dann das System. Automatisierungsfehler und Routing-Fehler, die Stunde-72-Probleme, schädigen oft das Vertrauen der Mitarbeiter und erzeugen anhaltenden Lärm im CRM.
Kein Vergleich mit einem Baseline-Snapshot vor der Migration. Ohne einen direkt vor der Migration erstellten Snapshot des Quellsystems können Sie nicht definitiv überprüfen, was hätte migriert werden sollen. Erstellen Sie vor jeder Migration einen Snapshot. Exportieren Sie Datensatzanzahlen und Pipeline-Gesamtwerte in eine Referenzdatei.
Erfolg vor dem Ende des 72-Stunden-Fensters erklären. Der dreistufige Zeitplan existiert, weil unterschiedliche Problemtypen in unterschiedlichen Intervallen auftreten. Den Audit nach Stunde 1 zu beenden ist wie den Herzschlag eines Patienten zu prüfen und ihn nach Hause zu schicken: eine notwendige Prüfung, aber keine ausreichende.
Nächste Schritte
Planen Sie eine 30-tägige Datenqualitätsprüfung nach dem Ende des 72-Stunden-Audits. Diese Prüfung betrachtet die Datenqualitätskennzahlen, die erst nach einem Monat echter Nutzung sichtbar werden: Feldvollständigkeitsraten, Duplikatansammlung, Datensätze mit fehlenden Beziehungen, um die herum Mitarbeiter arbeiten.
Zur Vermeidung von Problemen vor dem Import lesen Sie Die Migration mit einem Shadow Import testen: Dort erfahren Sie, wie die meisten dieser Probleme in einer Testumgebung vor dem go-live erkannt werden können.
Wenn der Audit Befunde mit Rollback-Überlegungen aufdeckt, zeigt Rollback-Planung: hoffentlich brauchen Sie sie nicht, wann und wie diese Entscheidung zu treffen ist, einschließlich was „Rollback" nach 72 Stunden Livebetrieb tatsächlich bedeutet.
Der Audit selbst ist direkt mit Cutover Day: die Checkliste, die Katastrophen verhindert verbunden: Die während der Migration durchgeführten Prüfungen bestimmen, worauf sich der Audit in den folgenden Stunden konzentrieren sollte.
Mehr erfahren
- Die Migration mit einem Shadow Import testen
- Cutover Day: die Checkliste, die Katastrophen verhindert
- Rollback-Planung: hoffentlich brauchen Sie sie nicht
- Die CRM-Migration dem Vertriebsteam kommunizieren
- CRM-Adoptionskennzahlen: wie Sie erkennen, ob Ihr Rollout wirklich funktioniert
- RevOps-Reifegradmodell: wo Ihr Team nach der Migration steht

Head of Enterprise Solutions