CRM-Datenmigration: Wie Kundendaten sicher ins neue System wechseln

Bei einer CRM-Datenmigration wechseln Kundendaten aus einem bestehenden System in ein neues Datenmodell, ohne dass ihre fachliche Bedeutung, ihre Beziehungen oder ihre Bearbeitungshistorie unbemerkt verloren gehen. Ein Export und ein anschließender CSV-Import decken davon nur den sichtbarsten Teil ab. Die eigentliche Arbeit besteht darin, den Bestand zu verstehen, Regeln für jede Information festzulegen und nachzuweisen, dass der Zielbestand vollständig und nutzbar ist.

Ein Kontaktdatensatz ist beispielsweise nicht nur eine Zeile mit Name und E-Mail-Adresse. Er kann zu einem Unternehmen gehören, mehrere Rollen besitzen, mit Verkaufschancen, Aufgaben, Notizen und Einwilligungen verbunden sein und einem bestimmten Nutzer zugeordnet werden. Wenn beim Wechsel nur die sichtbaren Kontaktfelder ankommen, wirkt der Import auf den ersten Blick erfolgreich. Im Arbeitsalltag fehlen jedoch Zusammenhänge, anhand derer Mitarbeitende einen Vorgang verstehen und fortsetzen können.

Ein technischer Export ist noch kein Migrationsumfang

Das Quellsystem bestimmt, welche Daten sich über eine Schnittstelle, einen vollständigen Export oder einzelne Dateien entnehmen lassen. Der fachliche Umfang entsteht aber erst durch eine bewusste Entscheidung: Welche Objekte werden benötigt, welche Historie muss verfügbar bleiben, welche Dateien gehören dazu und welche Daten sollen nicht in das neue CRM übernommen werden? Auch Benutzerkonten, Berechtigungen, Auswahllisten und Automationszustände können für die Interpretation eines Datensatzes entscheidend sein.

Schreibe den Umfang deshalb nicht als „alle CRM-Daten“ auf. Benenne Unternehmen, Kontakte, Leads, Verkaufschancen, Aktivitäten, Aufgaben, Notizen, Anhänge und weitere eigene Objekte einzeln. Halte pro Objekt fest, ob es migriert, archiviert oder bewusst verworfen wird. Diese Liste wird später zur Grundlage für Mapping, Testfälle und den Zählvergleich zwischen Quelle und Ziel.

Die Quelle bleibt während der Vorbereitung maßgeblich

Solange der Cutover nicht erfolgt ist, bleibt das bisherige CRM die führende Quelle. Ein früher Testimport ändert daran nichts. Diese Trennung verhindert, dass bereinigte Daten im Testsystem und neue Änderungen im Altsystem zu zwei konkurrierenden Wahrheiten werden. Korrekturen werden entweder nachvollziehbar in der Quelle vorgenommen oder als reproduzierbare Transformationsregel dokumentiert.

Erfolg muss vor dem ersten Lauf messbar sein

Eine Migration ist nicht erfolgreich, weil das Importwerkzeug „fertig“ meldet. Erfolg bedeutet, dass erwartete Datensätze vorhanden sind, Beziehungen stimmen, relevante Felder ihren Sinn behalten, Zugriffe funktionieren und die wichtigsten Arbeitsvorgänge fortgesetzt werden können. Für jede Objektgruppe braucht es deshalb quantitative Prüfungen und fachliche Stichproben. Unerklärte Abweichungen werden nicht pauschal als Importverlust akzeptiert.

Migration und Einführung sind zwei verbundene Vorhaben

Das neue CRM kann technisch bereitstehen, obwohl der Datenbestand noch nicht freigegeben ist. Umgekehrt kann ein sauber migrierter Bestand unbrauchbar sein, wenn Rollen, Ansichten oder Integrationen nicht einsatzbereit sind. Der Migrationsplan verbindet beide Seiten über gemeinsame Kriterien: Zielmodell fertig, Nutzer und Rechte angelegt, Import geprüft, Schnittstellen umgeschaltet und Verantwortliche erreichbar.

Das Dateninventar beantwortet vor jeder technischen Umsetzung, was im bisherigen CRM tatsächlich vorhanden ist. Es verbindet die sichtbaren Module mit Feldern, Beziehungen, Dateien, Nutzern und angebundenen Systemen. Ohne dieses Inventar entdeckt das Projekt kritische Inhalte erst beim Testimport oder nach dem Go-live – dann, wenn Änderungen am Zielmodell deutlich schwieriger werden.

Objekte und Datensatzmengen getrennt erfassen

Beginne mit allen Objektarten, nicht nur mit Kontakten und Unternehmen. Dazu gehören etwa Leads, Verkaufschancen, Aktivitäten, Aufgaben, Termine, Notizen, Produkte, Angebote, Kampagnenbezüge und eigene Objekte. Ermittle pro Objekt die aktuelle Menge, den Zeitraum der enthaltenen Historie und den Anteil inaktiver oder archivierter Datensätze. Diese Zahlen dienen später als Ausgangspunkt für den Reconcile-Abgleich.

Prüfe dabei auch, ob die Benutzeroberfläche den gesamten Bestand zeigt. Manche Systeme blenden archivierte Einträge aus, speichern gelöschte Datensätze vorübergehend separat oder begrenzen Exporte. Ein Pagination- oder Mengenlimit darf einen Export nicht still verkürzen. Die gezählte Quelle, der erzeugte Export und das tatsächlich eingelesene Zwischenmodell müssen daher unabhängig voneinander verglichen werden.

Felder mit Bedeutung und Herkunft dokumentieren

Für jedes relevante Feld werden technischer Name, sichtbare Bezeichnung, Datentyp, Pflichtstatus und tatsächliche Nutzung festgehalten. Besonders wichtig sind Felder mit ähnlich klingenden Namen. „Status“, „Phase“ und „Ergebnis“ können in unterschiedlichen Modulen völlig verschiedene Bedeutungen haben. Auch Freitextfelder, in denen Teams im Laufe der Jahre versteckte Codes verwendet haben, gehören ins Inventar.

Notiere zusätzlich, ob ein Wert manuell gepflegt, aus einer Integration geschrieben oder automatisch berechnet wird. Ein berechnetes Feld muss im Ziel möglicherweise nicht migriert, sondern neu berechnet werden. Ein Wert aus dem ERP sollte vielleicht nur referenziert statt als zweite Kopie übernommen werden. Die Herkunft verhindert, dass die Migration veraltete Ableitungen als vermeintliche Stammdaten behandelt.

Beziehungen und historische Eigentümer sichtbar machen

Ein einfaches Diagramm zeigt, welche Objekte miteinander verbunden sind: Kontakt zu Unternehmen, Verkaufschance zu Kontaktrollen, Aktivität zu Vorgang und Nutzer, Datei zu Notiz oder Angebot. Prüfe außerdem Mehrfachbeziehungen. Ein Kontakt kann mehreren Unternehmen oder Rollen zugeordnet sein; eine Aktivität kann sich je nach Typ auf unterschiedliche Objekte beziehen. Solche Strukturen gehen verloren, wenn das Ziel nur eine starre Einzelzuordnung vorsieht.

Ehemalige Mitarbeitende dürfen im Inventar nicht fehlen. Ihre Benutzerkonten werden im Ziel oft nicht aktiv benötigt, ihre Namen und historischen Zuordnungen aber sehr wohl. Lege früh fest, wie frühere Eigentümer dargestellt werden, damit Aktivitäten und Entscheidungen nachvollziehbar bleiben.

Dateien, Integrationen und laufende Eingänge ergänzen

Anhänge liegen je nach System nicht im normalen Tabellenexport. Ermittle Speicherorte, Dateigrößen, Verknüpfungen und Zugriffsmöglichkeiten gesondert. Erfasse außerdem alle Datenzuflüsse: Website-Formulare, E-Mail-Synchronisation, Kalender, Telefonie, ERP, Support oder Marketing-Automation. Für jeden Zufluss muss feststehen, ob er während der Migration weiter in die Quelle schreibt und wann er auf das Ziel umgestellt wird.

Das Inventar erhält einen festen Stichtag

Vermerke Zeitpunkt, Exportmethode und verantwortliche Person. Ein Inventar ohne Stichtag altert sofort, weil neue Kontakte und Aktivitäten hinzukommen. Die späteren Delta-Läufe schließen genau diese zeitliche Lücke. So bleibt klar, welche Zahlen zum Vollbestand gehören und welche Änderungen nachträglich übertragen werden müssen.

Eine CRM-Migration ist der richtige Zeitpunkt, Datenqualität sichtbar zu machen, aber nicht jede Korrektur muss manuell vor dem Import abgeschlossen sein. Entscheidend ist eine klare Regel je Fehlerklasse. Eindeutige Formatfehler lassen sich reproduzierbar transformieren, zweifelhafte Dubletten brauchen eine fachliche Entscheidung und nicht mehr benötigte Daten sollten gar nicht erst in das neue System gelangen.

Relevanz und Aufbewahrung zuerst klären

Bevor Namen vereinheitlicht oder Telefonnummern formatiert werden, wird entschieden, welche Datensätze überhaupt noch benötigt werden. Veraltete Testkontakte, fehlgeschlagene Importe, technisch erzeugte Platzhalter und nicht mehr erklärbare Listen belasten das Zielsystem von Beginn an. Gleichzeitig dürfen gesetzlich oder vertraglich relevante Informationen nicht beiläufig gelöscht werden. Lösch- und Aufbewahrungsregeln müssen deshalb mit den intern verantwortlichen Stellen abgestimmt werden; dieser Leitfaden ersetzt keine rechtliche Prüfung.

Für nicht migrierte Historie kann ein schreibgeschütztes Archiv sinnvoll sein. Ein Archiv ist jedoch kein unstrukturierter Rest. Es braucht einen benannten Zweck, geregelte Zugriffe, eine Suchmöglichkeit und einen Zeitpunkt für die spätere Löschung. Sonst bleibt das alte CRM faktisch dauerhaft im Betrieb.

Dubletten anhand mehrerer Signale entscheiden

Gleiche E-Mail-Adressen können auf eine Dublette hinweisen, aber auch auf ein gemeinsames Postfach. Gleiche Namen können verschiedene Menschen bezeichnen. Unternehmen können unter Marke, juristischem Namen und abweichender Domain erscheinen. Eine belastbare Dublettenregel kombiniert daher geeignete Merkmale und unterscheidet zwischen sicherem Treffer, möglichem Treffer und keinem Treffer.

Beim Zusammenführen muss außerdem feststehen, welcher Datensatz führend ist und was mit verbundenen Aktivitäten, Notizen und Verkaufschancen geschieht. Microsoft beschreibt in seiner offiziellen Dataverse-Dokumentation ausdrücklich, dass beim Merge ein primärer Datensatz gewählt wird und verbundene Kinddatensätze berücksichtigt werden. Das zeigt den entscheidenden Punkt: Dublettenbereinigung betrifft Beziehungen, nicht nur doppelte Feldwerte.

Formate normalisieren, Rohwerte aber nachvollziehbar halten

Datumsangaben, Länder, Telefonnummern, Sprachen und Auswahllisten benötigen einheitliche Zielformate. Dokumentiere jede Regel im Transformationsprozess, statt Dateien vor jedem Lauf von Hand zu bearbeiten. Wenn ein Rohwert nicht eindeutig übersetzt werden kann, landet er in einer Prüfliste oder einem dafür vorgesehenen Herkunftsfeld. Er wird nicht still verworfen.

Auch leere Werte müssen sauber unterschieden werden. Leer kann „nicht bekannt“, „nicht zutreffend“, „noch nicht geprüft“ oder „beim Export nicht enthalten“ bedeuten. Wenn das Ziel diese Unterschiede für Entscheidungen benötigt, braucht es eigene Werte oder eine ergänzende Regel. Ein pauschaler Standardwert würde scheinbare Sicherheit erzeugen.

Pflichtfelder nicht mit erfundenen Angaben füllen

Das Zielsystem kann Felder verlangen, die in der Quelle nicht zuverlässig gepflegt wurden. Erfundene Platzhalter lösen zwar einen Importfehler, verschlechtern aber Berichte und Automationen. Besser ist eine bewusste technische Übergangsregel: einen eindeutig gekennzeichneten Wert verwenden, den Datensatz in eine Nachbearbeitungsliste aufnehmen oder die Pflicht im Migrationszeitraum kontrolliert lockern.

Bereinigung als versionierte Regel ausführen

Jede automatische Änderung sollte erneut ausführbar sein und denselben Ausgangswert gleich behandeln. Dazu gehören Regelname, Eingabefeld, Ausgabefeld, Zahl der betroffenen Datensätze und bekannte Ausnahmen. Nach einem Testlauf lässt sich so genau erklären, warum sich Werte verändert haben. Korrekturen werden im nächsten Lauf wiederholt, ohne dass eine neue manuelle Datei entsteht.

Das Mapping verbindet jedes relevante Quellfeld mit einer klaren Behandlung im Ziel: direkt übernehmen, transformieren, zusammenführen, aufteilen, neu berechnen, archivieren oder bewusst verwerfen. Ein bloßes Paar aus zwei Spaltennamen reicht dafür nicht. Das Mapping muss zeigen, ob beide Felder fachlich dasselbe bedeuten und wie mit leeren, ungültigen oder bisher unbekannten Werten umgegangen wird.

Vom Geschäftsbegriff zum technischen Feld

Beginne mit dem fachlichen Begriff und erst danach mit dem technischen Namen. Ein Feld namens „Kunde“ kann in der Quelle eine Person, ein Unternehmen oder bereits einen abgeschlossenen Vertrag bezeichnen. Im Ziel könnten dafür getrennte Objekte vorgesehen sein. Die Mapping-Entscheidung muss diese Bedeutung abbilden, statt einen ähnlich benannten Zielplatz auszuwählen.

Für jedes Mapping gehören Quelle, Ziel, Datentyp, Transformationsregel, erlaubte Werte, Pflichtstatus und Beispielwerte zusammen. Ergänze die verantwortliche Person für die fachliche Freigabe. Gerade bei Status- oder Segmentfeldern kann ein Entwickler die Semantik nicht allein aus den vorhandenen Werten ableiten.

Auswahllisten brauchen eine vollständige Wertematrix

Quell- und Zielsystem verwenden häufig unterschiedliche Statusmodelle. Ein alter Wert darf nur dann auf einen neuen Status abgebildet werden, wenn Bedeutung und zulässiger nächster Schritt übereinstimmen. Mehrere alte Werte können zusammengeführt werden; ein alter Sammelwert kann dagegen eine Aufteilung anhand zusätzlicher Merkmale verlangen. Nicht zugeordnete Werte gehören in eine Fehlerliste und nicht automatisch in „Sonstiges“.

Microsoft weist in seiner offiziellen Importdokumentation darauf hin, dass nicht gemappte Werte eines Imports verworfen werden können und erforderliche Felder vollständig zugeordnet sein müssen. Plattformdetails unterscheiden sich, die allgemeine Lehre bleibt gleich: Unvollständiges Mapping ist kein neutraler Zwischenstand. Es kann Daten still aus dem Zielbestand entfernen oder ganze Datensätze zurückweisen.

Datentypen vor dem Import prüfen

Text ist nicht automatisch Text. Maximale Länge, Zeichensatz, Zeilenumbrüche und erlaubte Sonderzeichen können abweichen. Zahlen brauchen eine eindeutige Dezimal- und Tausenderlogik. Datumswerte benötigen Zeitzone und Format. Kontrollkästchen können in Exporten als Wahr/Falsch, Ja/Nein, Eins/Null oder leer erscheinen. Jede Konvertierung wird mit echten Beispielwerten getestet, einschließlich ungewöhnlicher und leerer Eingaben.

Zusammenführen und Aufteilen nachvollziehbar gestalten

Ein vollständiger Name kann in Vor- und Nachname zerlegt werden, doch Namensstrukturen lassen sich nicht immer sicher automatisch trennen. Mehrere Quellfelder können zu einer Zieladresse zusammengesetzt werden; umgekehrt kann ein großes Notizfeld strukturierte Informationen enthalten, die nicht zuverlässig extrahierbar sind. Unsichere Transformationen werden markiert und anhand ihres Nutzens bewertet. Eine formal schöne Struktur ist wertlos, wenn sie falsche Angaben erzeugt.

Das Mapping ist eine ausführbare Spezifikation

Die freigegebene Matrix sollte direkt in Transformationscode oder Importkonfiguration überführt werden können. Änderungen erhalten eine Version und einen Grund. Der Testbericht nennt anschließend die verwendete Version. Damit lässt sich ein Fehler gezielt korrigieren und der Lauf wiederholen, statt das gesamte Verständnis des Datenbestands neu aufzubauen.

Die schwierigsten Migrationsfehler entstehen selten bei einfachen Stammdaten. Sie entstehen an Verbindungen: Ein Kontakt landet ohne Unternehmen, eine Verkaufschance verliert ihre beteiligten Personen, Aktivitäten gehören zum falschen Vorgang oder ein früherer Eigentümer lässt sich nicht mehr zuordnen. Deshalb werden Beziehungen als eigener Migrationsbestand geplant und geprüft.

Quell-IDs als dauerhafte Brücke speichern

Jeder migrierte Datensatz benötigt eine stabile Kennung aus dem Quellsystem. Diese externe ID wird im Ziel oder in einer separaten Zuordnungstabelle zusammen mit der neuen Ziel-ID gespeichert. Salesforce und Microsoft beschreiben solche externen beziehungsweise alternativen Schlüssel in ihren offiziellen Importhilfen als Mittel, um Datensätze eindeutig zu erkennen und bei erneuten Läufen zu aktualisieren, statt Duplikate anzulegen.

Die Zuordnung dient nicht nur dem Import. Sie erklärt später, welcher Zielkontakt zu welchem Ursprungsdatensatz gehört, ermöglicht gezielte Nachkorrekturen und bildet die Grundlage für Delta-Läufe. E-Mail-Adresse oder Name allein sind dafür zu instabil: Sie können sich ändern, fehlen oder mehrfach vorkommen.

Abhängigkeiten in einer festen Reihenfolge laden

Unternehmen und Benutzer müssen meist vorhanden sein, bevor Kontakte und Verkaufschancen korrekt verbunden werden können. Aktivitäten und Dateien folgen wiederum ihren Bezugsobjekten. Diese Reihenfolge wird pro Objekt dokumentiert. Wo sich Beziehungen gegenseitig referenzieren, hilft ein Zwei-Pass-Verfahren: Im ersten Durchlauf werden die Datensätze mit ihren Quell-IDs angelegt, im zweiten werden die inzwischen bekannten Ziel-IDs als Beziehungen ergänzt.

Das Verfahren verhindert, dass ein ganzer Datensatz nur wegen einer noch fehlenden Verbindung verworfen wird. Eine nicht auflösbare Beziehung wird als Fehler mit Quell-ID, Beziehungstyp und Ursache protokolliert. Je nach fachlicher Bedeutung kann der Datensatz vorläufig ohne Verbindung angelegt oder der Lauf für diese Gruppe gestoppt werden.

Mehrfachrollen nicht auf eine Einzelzuordnung reduzieren

Ein Kontakt kann gleichzeitig Ansprechpartner eines Unternehmens, externer Berater und Beteiligter an einer Verkaufschance sein. Das Zielmodell muss solche Rollen tragen oder eine bewusste Übersetzungsregel erhalten. Eine Migration, die nur das erste gefundene Unternehmen übernimmt, vernichtet Information, obwohl alle Datensätze scheinbar erfolgreich importiert wurden.

Dasselbe gilt für Aktivitäten, die sich auf verschiedene Objekttypen beziehen können. Vor dem Import wird geprüft, welche Beziehungstypen das Ziel unterstützt. Nicht abbildbare Sonderfälle brauchen eine klare Ersatzdarstellung oder ein Archiv, das aus dem Ziel erreichbar ist.

Ehemalige Nutzer als Historie bewahren

Alte Eigentümer werden nicht automatisch als aktive Nutzer angelegt. Für die Historie kann ein deaktiviertes Benutzerprofil, ein separates Herkunftsfeld oder eine Zuordnung auf eine neutrale ehemalige Rolle sinnvoll sein. Wichtig ist, dass ursprüngliche Autorenschaft und damalige Verantwortung lesbar bleiben, ohne unnötige Zugänge zu schaffen.

Beziehungsqualität separat messen

Neben der Zahl importierter Kontakte wird gezählt, wie viele Kontakte ohne erwartetes Unternehmen, wie viele Verkaufschancen ohne Eigentümer und wie viele Aktivitäten ohne Bezugsobjekt angekommen sind. Diese Null- und Broken-Reference-Prüfungen machen Fehler sichtbar, die eine reine Datensatzsumme übersehen würde.

Eine Testmigration ist kein verkleinerter Produktionstermin, sondern ein gezielter Beweis für Export, Transformation, Ladereihenfolge und Prüfverfahren. Sie findet in einer getrennten Zielumgebung statt und verwendet eine repräsentative Auswahl aus normalen Fällen, problematischen Altbeständen und wichtigen Beziehungen. Nur ideale Datensätze zu importieren, prüft den Ablauf genau dort nicht, wo er wahrscheinlich scheitert.

Die Stichprobe nach Fällen statt zufällig wählen

Ein guter Canary-Bestand enthält aktive und inaktive Unternehmen, Kontakte mit mehreren Rollen, offene und abgeschlossene Verkaufschancen, ehemalige Eigentümer, lange Notizen, Anhänge, leere Pflichtfelder und bekannte Dubletten. Ergänze Datensätze aus verschiedenen Entstehungsjahren und Integrationen. So wird sichtbar, ob historische Formatwechsel oder frühere Importquellen eigene Regeln benötigen.

Die Stichprobe bleibt klein genug für eine manuelle Prüfung, deckt aber jede kritische Objekt- und Beziehungsklasse ab. Für jeden Fall wird vorher festgehalten, was im Ziel erwartet wird. Dadurch endet der Test nicht bei einem allgemeinen Eindruck, sondern bei nachvollziehbaren Soll-Ist-Ergebnissen.

Der Lauf muss wiederholbar sein

Führe denselben Import mit unveränderten Daten erneut aus. Ein idempotenter Ablauf erkennt bereits migrierte Quell-IDs und aktualisiert oder überspringt sie nach der festgelegten Regel. Er legt nicht bei jedem Versuch neue Kontakte und Aktivitäten an. Diese Wiederholbarkeit ist entscheidend, weil echte Migrationen nach Korrekturen mehrfach laufen.

Auch Korrekturläufe brauchen Schutzbedingungen. Wenn ein Mappingfehler nur bestimmte Statuswerte betrifft, werden genau diese Datensätze erneut verarbeitet. Bereits richtige Werte dürfen dabei nicht zurückgesetzt werden. Der Importbericht zeigt anschließend, welche Zeilen neu, geändert, übersprungen oder fehlgeschlagen sind.

Fehler müssen einzeln bearbeitbar sein

Ein aussagekräftiges Fehlerprotokoll nennt Objekt, Quell-ID, Feld oder Beziehung, Eingabewert, Regel und konkrete Ursache. „Import fehlgeschlagen“ reicht nicht. Fehler werden nach Klassen gebündelt: ungültiger Wert, fehlendes Pflichtfeld, unbekannter Nutzer, nicht auflösbare Beziehung, technische Unterbrechung oder Berechtigungsproblem. Jede Klasse erhält eine Entscheidung für den nächsten Lauf.

Nutzer prüfen reale Arbeitsvorgänge

Nach den technischen Checks bearbeiten ausgewählte Nutzer einige echte, anonymisierte oder kontrolliert bereitgestellte Vorgänge im Ziel. Sie öffnen Unternehmen, folgen Kontaktbeziehungen, lesen Historie, prüfen Aufgaben und führen einen Statuswechsel aus. Damit wird nicht die CRM-Auswahl neu aufgerollt. Es wird geprüft, ob die migrierten Informationen für die vorgesehene Arbeit verständlich und vollständig vorliegen.

Die Testmigration endet mit einer Freigabeentscheidung

Offene Fehler werden nicht nur gesammelt, sondern gewichtet. Ein falsch formatiertes optionales Telefonfeld kann korrigierbar sein; fehlende Aktivitätsbeziehungen blockieren möglicherweise den Volllauf. Die Freigabe nennt behobene Fehler, akzeptierte Ausnahmen, neue Transformationsversion und verbleibende Blocker. Erst danach wird der vollständige Bestand geladen.

Zwischen dem vollständigen Export und dem tatsächlichen Wechsel entstehen im alten CRM meist neue Kontakte, Aktivitäten und Änderungen. Diese zeitliche Lücke wird mit einer Delta-Migration geschlossen. Das Ziel ist kein dauerhafter Betrieb zweier gleichberechtigter CRM-Systeme, sondern ein begrenzter Übergang mit klarer Datenhoheit und einem definierten Ende.

Den Volllauf aus einem markierten Snapshot starten

Der vollständige Export erhält einen eindeutigen Stichtag. Alle Transformations- und Importläufe beziehen sich auf diesen Snapshot. Dateien, Prüfsummen, Exportparameter und Mengen werden protokolliert. Dadurch ist später bekannt, welcher Quellstand im Ziel enthalten sein sollte und ab welchem Zeitpunkt Änderungen als Delta gelten.

Wenn die Quelle einen Änderungszeitpunkt pro Datensatz bereitstellt, kann das Delta anhand eines Zeitfensters gelesen werden. Dabei braucht es eine kleine kontrollierte Überlappung, damit Vorgänge an der Zeitgrenze nicht verloren gehen. Die externe Quell-ID verhindert, dass überlappende Datensätze doppelt angelegt werden.

Auch abhängige Änderungen berücksichtigen

Ein geänderter Kontakt ist leicht erkennbar. Schwieriger sind neue Aktivitäten, gelöschte Beziehungen, geänderte Eigentümer oder Dateien, die nach dem Vollauszug ergänzt wurden. Die Delta-Definition wird deshalb pro Objekt und Beziehung festgelegt. Wenn das Quellsystem Löschungen nicht als Ereignis exportiert, braucht es einen Vergleich oder eine bewusste Regel, wie entfernte Zuordnungen behandelt werden.

Schreibwege während des Übergangs begrenzen

Während der Vorbereitung arbeiten Nutzer weiterhin im alten CRM. Testnutzer dürfen im Ziel prüfen, aber dort keine produktiven Änderungen erzeugen, die später überschrieben werden oder in der Quelle fehlen. Falls ein begrenzter Parallelbetrieb unvermeidbar ist, muss pro Feld und Objekt feststehen, welches System schreiben darf. Eine bidirektionale Synchronisation nur für wenige Übergangstage erzeugt meist mehr Konflikte, als sie löst.

Importreihenfolge auch im Delta erhalten

Neue Unternehmen müssen vor zugehörigen Kontakten geladen werden, neue Kontakte vor ihren Rollen und Aktivitäten. Geänderte Nutzerzuordnungen benötigen bereits angelegte Zielnutzer. Der Delta-Lauf nutzt daher dieselbe Abhängigkeitslogik wie der Volllauf und erstellt einen eigenen Bericht mit Mengen, Fehlern und nicht auflösbaren Beziehungen.

Mehrere Probeläufe mit realistischem Zeitabstand durchführen

Ein erster Delta-Test zeigt, ob Änderungsfilter und Quell-IDs funktionieren. Ein weiterer Lauf prüft, ob überlappende Zeitfenster keine Duplikate erzeugen und bereits übertragene Datensätze korrekt aktualisiert werden. Das Projekt misst außerdem Laufzeit und manuelle Nacharbeit. Diese Werte helfen, das spätere Cutover-Fenster realistisch zu planen, ohne unbelegte Zeitversprechen abzugeben.

Jeden Lauf als eigenen Batch nachvollziehen

Voll- und Delta-Läufe erhalten jeweils eine Batch-ID, Start- und Endzeit, verwendete Mapping-Version, Objektmengen sowie Fehlerstatus. Eine Zuordnungstabelle verbindet Quell- und Ziel-IDs. Damit lässt sich ein fehlerhafter Lauf gezielt analysieren und wiederholen. Ohne Batch-Grenzen verschwimmen Test, Volllauf und Nachkorrektur zu einem schwer prüfbaren Gesamtbestand.

Der Cutover ist der Zeitpunkt, an dem das neue CRM die führende Arbeitsumgebung wird. Er besteht aus einer festen Folge von Schritten, Verantwortlichkeiten und Prüfpunkten. Die Umschaltung beginnt nicht, solange Datenmodell, Nutzer, Integrationen, Volllauf und Delta-Verfahren offene Blocker enthalten. Ein Termin allein ist kein Go-Signal.

Go- und No-Go-Kriterien schriftlich festlegen

Vor dem Wechsel stehen messbare Mindestbedingungen fest: vollständiger Vollbestand innerhalb erklärter Abweichungen, keine gebrochenen kritischen Beziehungen, erfolgreiche fachliche Stichproben, bereite Nutzerkonten, getestete Zugriffe und ein erfolgreich geprobter Delta-Lauf. Für Integrationen muss bekannt sein, wie sie umgeschaltet und wie eingehende Fehler erkannt werden.

Jedes Kriterium hat eine verantwortliche Person und einen Nachweis. „Sieht gut aus“ wird durch einen Bericht, einen Testfall oder eine ausdrückliche Freigabe ersetzt. Der Projektverantwortliche bündelt diese Nachweise und trifft gemeinsam mit den fachlich Zuständigen die Go- oder No-Go-Entscheidung.

Die letzte Änderungslücke schließen

Zum vereinbarten Zeitpunkt wird die Quelle für normale Bearbeitung gesperrt oder mindestens schreibgeschützt. Danach erfolgt ein letzter Delta-Export. Erst wenn dessen Import und Kernprüfungen erfolgreich sind, wechseln Nutzer und angebundene Systeme auf das Ziel. Neue Formulare, E-Mail-Zuordnungen oder Schnittstellen dürfen nicht vorzeitig in beide Systeme schreiben.

Den Umschaltplan minutengenau in Rollen übersetzen

Der Plan benennt Reihenfolge und Eigentümer: Wer setzt die Quelle schreibgeschützt? Wer erzeugt den Export? Wer startet Transformations- und Ladeläufe? Wer prüft Mengen und Beziehungen? Wer schaltet Integrationen um? Wer informiert Nutzer? Wer entscheidet bei einer Abweichung? Kontaktdaten und Vertretungen liegen vor, bevor der Wechsel beginnt.

Automatisierte Schritte protokollieren ihre Ergebnisse. Manuelle Schritte werden in einer gemeinsamen Checkliste bestätigt. Änderungen am Plan während des Cutovers werden mit Grund festgehalten, damit der tatsächliche Ablauf später nachvollziehbar bleibt.

Rollback als Zustand, nicht als vage Möglichkeit planen

Ein Rollback beantwortet konkret, bis zu welchem Punkt ohne Datenkonflikt zurückgekehrt werden kann. Solange das Ziel noch keine produktiven Schreibvorgänge angenommen hat, ist die Rückkehr zur Quelle vergleichsweise klar. Nach produktiven Änderungen muss entschieden werden, wie diese gesichert und zurückgeführt würden. Deshalb enthält der Plan eindeutige Abbruchschwellen und einen letzten sicheren Rückkehrpunkt.

Quell-CRM, Exportdateien und Migrationsskripte bleiben während der Stabilisierungsphase erhalten. Zugriffe werden kontrolliert, aber nichts vorschnell gelöscht. Rollback bedeutet nicht, fehlerhafte Zielimporte unkoordiniert zu überschreiben. Der aktuelle Lauf wird gestoppt, sein Zustand dokumentiert und das vereinbarte Wiederanlaufverfahren ausgeführt.

Kommunikation gehört zum technischen Plan

Nutzer wissen, wann sie die Quelle nicht mehr bearbeiten dürfen, wann das Ziel freigegeben ist und wo sie Fehler melden. Die erste Anmeldung, zentrale Ansichten und bekannte bewusste Abweichungen werden vorab erklärt. So werden echte Migrationsfehler von Bedienfragen getrennt und kritische Beobachtungen erreichen direkt das verantwortliche Team.

Validierung verbindet technische Mengenprüfungen mit fachlichen Kontrollen. Keine einzelne Methode reicht aus: Gleiche Datensatzanzahlen beweisen keine richtigen Beziehungen, eine gute Stichprobe beweist keine Vollständigkeit und ein erfolgreicher Login beweist keine funktionierenden Automationen. Deshalb wird der Zielbestand auf mehreren Ebenen geprüft und jede Differenz erklärt.

Mengen pro Objekt und Zustand vergleichen

Vergleiche Quelle, Transformationsbestand und Ziel für jede Objektart. Teile große Mengen zusätzlich nach sinnvollen Merkmalen auf, etwa aktiv und inaktiv, Status, Entstehungsjahr oder Eigentümergruppe. Dadurch wird eine Verschiebung sichtbar, die sich in der Gesamtsumme gegenseitig aufheben könnte. Bewusst ausgeschlossene Datensätze erscheinen als eigene dokumentierte Kategorie.

Fehlerhafte und übersprungene Zeilen werden nicht aus der Bilanz entfernt. Der Bericht zeigt Ausgangsmenge, ausgeschlossene Daten, erfolgreiche Imports, aktualisierte Datensätze und Fehler. Die Gleichung muss nachvollziehbar aufgehen.

Referenzen und Pflichtbeziehungen technisch prüfen

Suche nach Kontakten ohne erwartetes Unternehmen, Verkaufschancen ohne gültigen Eigentümer, Aktivitäten ohne Bezugsobjekt und Beziehungen auf nicht vorhandene IDs. Zähle außerdem optionale Nullwerte, wenn ihr Anteil fachlich auffällig sein könnte. Eine Broken-Reference-Abfrage findet systematisch mehr als eine manuelle Sichtprüfung.

Verteilungen und Wertebereiche vergleichen

Statuswerte, Länder, Quellen, Segmente und Abschlussgründe werden vor und nach der Transformation gezählt. Wenn ein seltener Quellstatus plötzlich vollständig fehlt oder ein Standardwert ungewöhnlich häufig vorkommt, deutet das auf ein Mappingproblem hin. Datumsbereiche, Textlängen und ungültige Zeichen helfen zusätzlich, abgeschnittene oder falsch interpretierte Inhalte zu erkennen.

Fachliche Stichproben Ende zu Ende lesen

Wähle Datensätze aus verschiedenen Gruppen und verfolge ihre Geschichte: Stammdaten, Beziehungen, offene Aufgabe, letzte Aktivität, Statuswechsel, Notizen, Dateien und Eigentümer. Die prüfende Person kennt den jeweiligen Vorgang oder kann ihn mit der Quelle vergleichen. Ein Screenshot allein reicht nicht, weil wichtige Informationen in verknüpften Ansichten liegen können.

Arbeitsabläufe und Berechtigungen testen

Nach der Datenprüfung werden zentrale Aktionen ausgeführt: Datensatz suchen, Aufgabe abschließen, Eigentümer ändern, Notiz hinzufügen, Bericht öffnen und eine relevante Integration auslösen. Rollen prüfen jeweils ihre eigene Sicht. Ein technisch vorhandener Datensatz darf nicht versehentlich für zu viele Nutzer sichtbar oder für die zuständige Person unzugänglich sein.

Nachkorrektur als kontrollierten Zyklus führen

Gefundene Abweichungen führen zu einer korrigierten Regel und einem begrenzten Wiederholungslauf. Danach werden dieselben Kontrollen erneut ausgeführt. Der Zyklus lautet messen, Ursache korrigieren, gezielt neu laden und wieder messen. Erst wenn keine neuen unerklärten Differenzen entstehen, ist der Bestand freigabefähig.

Dokumentiere schließlich auch akzeptierte Unterschiede. Wenn Testkontakte, veraltete Auswahlwerte oder bewusst archivierte Historie fehlen, wird der Grund im Abschlussbericht genannt. Dadurch lässt sich später unterscheiden, ob eine Information verloren ging oder nach einer freigegebenen Regel nicht migriert wurde.

Mit der Freigabe des neuen CRM endet der Import, aber noch nicht die Migration. In den ersten Arbeitstagen zeigen reale Suchanfragen, Integrationen und Ausnahmefälle, ob alle Annahmen tragen. Für diese Phase braucht es einen klaren Meldeweg, technische Beobachtung und die Disziplin, das alte System nicht nebenbei wieder zur zweiten Arbeitsumgebung zu machen.

Fehler nach Auswirkung priorisieren

Ein fehlender optionaler Anzeigename ist anders zu behandeln als eine falsch zugeordnete Verkaufschance oder ein Formular, das neue Anfragen nicht übermittelt. Definiere Kategorien für Datenverlust, falsche Beziehung, Zugriff, Integration, Darstellung und Bedienfrage. Kritische Fehler erhalten eine verantwortliche Person und einen klaren Eskalationsweg; kleinere Korrekturen werden gesammelt und in kontrollierten Läufen bearbeitet.

Integrationen und Importkennzahlen beobachten

Prüfe neue Dateneingänge, Synchronisationsfehler, ungewöhnliche Dublettenraten und fehlgeschlagene Automationen. Die erwarteten Mengen nach dem Go-live liefern eine Vergleichsbasis, ohne starre Erfolgsgarantien zu erfinden. Ein Audit-Log pro Schnittstelle zeigt, wann Daten gelesen, geschrieben oder zurückgewiesen wurden und welche ID betroffen ist.

Das Altsystem kontrolliert stilllegen

Das alte CRM bleibt zunächst schreibgeschützt verfügbar, soweit Aufbewahrung, Vertrag und Sicherheitskonzept dies erlauben. Der Zugriff wird auf wenige verantwortliche Personen begrenzt. Bevor es endgültig abgeschaltet wird, müssen Abschlussbericht, Exportarchiv, Mappings, Skripte und relevante Anhänge sicher abgelegt sein. Ein späterer Vergleich darf nicht von einem einzelnen persönlichen Zugang abhängen.

Auch die endgültige Löschung ist ein eigener freizugebender Schritt. Prüfe vorher, ob Schnittstellen, gespeicherte Links oder Berichte noch auf die Quelle zugreifen. Erst wenn Nutzung und Aufbewahrung geklärt sind, kann die alte Umgebung beendet werden.

Migrationswissen in den Betrieb übergeben

Die Betriebsdokumentation erklärt externe IDs, bekannte Transformationsregeln, bewusste Datenlücken und die Behandlung ehemaliger Nutzer. Sie nennt außerdem Eigentümer für Datenqualität und Integrationen. So erkennt das spätere Supportteam, ob ein auffälliger Wert aus der Quelle stammt, während der Migration entstanden ist oder erst im neuen Betrieb erzeugt wurde.

Verbesserungen von Migrationsfehlern trennen

Nach dem Start entstehen schnell Wünsche nach neuen Feldern, Ansichten und Automationen. Führe sie nicht ungeprüft als Migrationskorrektur aus. Ein Fehler verletzt einen freigegebenen Sollzustand; eine Verbesserung verändert diesen Sollzustand. Die Trennung hält die Stabilisierung beherrschbar und verhindert, dass neue Funktionen die Ursachenanalyse erschweren.

Wenn Datenmodell, Migrationslogik und Zielsystem gemeinsam entwickelt werden müssen, kann ein erfahrenes Team deinen CRM-Bestand analysieren, die Übertragung technisch umsetzen und den Wechsel bis in den stabilen Betrieb begleiten. Grundlage bleiben ein prüfbares Inventar, reproduzierbare Regeln und eine Freigabe anhand echter Daten – nicht das Versprechen eines reibungslosen Imports ohne Nachweis.

Den Abschluss mit einem nachvollziehbaren Bericht markieren

Der Abschlussbericht enthält migrierte und ausgeschlossene Mengen, geklärte Abweichungen, offene Nacharbeiten, Aufbewahrungsorte und Verantwortliche. Er nennt außerdem, wann das Altsystem endgültig beendet werden darf. Damit wird aus einem technisch abgeschlossenen Lauf eine belastbare Übergabe an Betrieb und Fachteam.