Wie migrieren Sie Kontakte aus einem anderen System, ohne unbemerkt Daten zu verlieren?

Die kurze Antwort

Migrationsfehler sind standardmäßig stumm. Strukturelle Probleme – eine ungleich lange Zeile, eine fehlerhafte E-Mail-Adresse – werden erkannt. Probleme auf Werteebene nicht: Ein Dropdown-Wert ohne passende Option im Ziel kommt leer an, ohne Fehler. Gezählt an einem Export vor dem Import, hätte ein einziges Feld 579 von 3.432 Datensätzen, 17 %, geleert.

Zwei Regeln erledigen den Großteil der Arbeit. Inventarisieren Sie den vollständigen Export, nie ein Beispiel – ein Beispiel mit 71 Zeilen zeigte 59 leere Spalten, wo die vollständige Datei 26 hatte, und ein Feld, das zu 0 % befüllt schien, war tatsächlich zu 100 % befüllt. Und gleichen Sie die Wertemenge jedes Dropdowns vor dem Import mit den Optionen des Ziels ab, nicht danach.

Das Geschäftsproblem

Eine Organisation zieht ihre Kontaktdatenbank aus einem System heraus und ins CRM um. Auf den ersten Blick ist das eine Mapping-Aufgabe: Spalten zuordnen, Import starten, bis zum Mittag erledigt.

Was tatsächlich erreicht werden muss:

Vollständigkeit – jede Spalte, die echte Daten trägt, landet irgendwo oder wird durch eine ausdrückliche Entscheidung verworfen, nicht aus Versehen;
Zuordnung – jeder Datensatz landet beim richtigen Eigentümer, weil die Eigentümerschaft Sichtbarkeit und Berichte steuert;
Integrität der Einwilligungen – Marketing-Opt-ins und DSGVO-Flags kommen unversehrt an, denn Fehler hier haben rechtliche Folgen und sind nicht bloß ärgerlich;
Idempotenz – der Import kann zweimal laufen, ohne alles doppelt zu erzeugen, denn er wird zweimal laufen;
Herkunft – Sie können auch danach noch erkennen, woher jeder Datensatz stammt und wann er ursprünglich angelegt wurde.

Der Export in diesem Aufbau war 91 Spalten breit und 3.432 Datensätze tief. Er war strukturell sauber – keine ungleich langen Zeilen, keine fehlerhaften oder leeren E-Mail-Adressen, keine doppelten Quell-IDs. Jedes Problem, über das es sich zu schreiben lohnt, steckte in ansonsten gültigen Daten.

Warum der naheliegende Ansatz scheitert

Das Zielschema nach einem Beispielexport entwerfen

Das Beispiel täuscht, und zwar in beide Richtungen. Ein Beispiel mit 71 Zeilen aus dem Quellsystem zeigte 59 Spalten als vollständig leer. Der vollständige Export mit 3.432 Zeilen zeigte nur 26 tatsächlich leere.

Eine Spalte war im Beispiel zu 0 % befüllt und in der vollständigen Datei zu 100 % befüllt – alle 3.432 Datensätze. Wer nach dem Beispiel baut, hat für diese Spalte überhaupt kein Ziel.

Der Grund ist banal und lässt sich verallgemeinern: Ein Beispiel ist meist ein aktueller Ausschnitt, und aktuelle Datensätze nutzen andere Felder als historische. Adressblöcke, Partnerprogrammfelder, Kampagnenzuordnung und Empfehlungsdaten waren auf älteren Datensätzen plausibel befüllt und fehlten in einem Vier-Wochen-Fenster schlicht.

Dieselbe Falle hat eine schärfere Kante. Im Beispiel war jede E-Mail-Adresse eindeutig – was E-Mail als natürlichen Deduplizierungsschlüssel nahelegte. Im vollständigen Export gab es doppelte E-Mail-Adressen in 10 Datensätzen. Eine Deduplizierungsstrategie, die nach dem Beispiel gewählt wurde, hätte unterschiedliche Personen unbemerkt zusammengeführt.

Den Export als eine einheitliche Liste behandeln

Das ist er selten. Dieser Export enthielt mehrere verschiedene Kohorten von Kontakten – Registrierungen über ein Content-Angebot, Anmeldungen zu Produkttests, Marketing-Interessenten und eine Handvoll einmaliger Anfragen –, und das Befüllungsmuster folgte der Kohorte, nicht dem Kontakt. Jede Kohorte befüllte eine andere Teilmenge von Spalten, und jede hatte ihren eigenen Eigentümer.

Die Folge betrifft das Design, nicht die Daten: Bauen Sie nicht ein einziges flaches Formular. Achtzehn neue Felder, verteilt auf drei Kohorten, bedeuten, dass ein einziges kombiniertes Formular auf jedem Datensatz zu rund 70 % leer ist, gleich welcher Kohorte er angehört.

Spalten zuordnen und auf Import drücken

Hier passiert der stumme Verlust, und er verdient einen eigenen Abschnitt.

Der stumme Fehler – Dropdown-Werte

Dropdown-Felder werden über die Options-ID importiert, nicht über die Bezeichnung. Ein Quellwert ohne passende Option im Ziel erzeugt keinen Fehler, keine Warnung und bricht den Import nicht ab. Das Feld kommt leer an.

Quelle und ihre Lücke. Coevera-Hilfecenter, Importing data into Coevera — tips on data preparation, nennt die Anforderung: Sie können „keine Datensätze importieren, die Werte enthalten, die nicht mit denen übereinstimmen, die Sie in Coevera haben“, und rät, die fehlenden Optionen zuerst anzulegen. Was dort nicht steht, ist, was tatsächlich passiert, wenn Sie diesen Schritt auslassen – der Datensatz wird importiert, und nur dieses eine Feld geht verloren. Dieser Unterschied ist der ganze Inhalt dieses Abschnitts.

Gemessen an diesem Export, vor jeder Korrektur:

Feld	Würde geleert	Ursache
Kontaktstatus	579 von 3.432 · 17 %	Für fünf Werte, die in der Quelle vorkamen, war überhaupt keine Option angelegt – darunter ein Status, den 335 Datensätze trugen, und ein weiterer mit 128.
Produktstufe	117 von 418 · 28 %	Überwiegend Schreibvarianten von Optionen, die durchaus existierten, dazu zwei tatsächlich unbrauchbare Zahlenwerte.
Teamgrößenband	39	Eine fehlende Option, dazu Datumsverfälschung durch die Tabellenkalkulation.
Produktversion	1	Eine einzelne Schreibvariante.

Drei verschiedene Ursachen, drei verschiedene Lösungen

Optionen, die nie angelegt wurden. Der offensichtliche Fall und am leichtesten zu beheben, sobald Sie die unterschiedlichen Werte in der Quelle gezählt haben, statt die Menge aus der Dokumentation anzunehmen.
Schreibvarianten. Derselbe Wert kommt sowohl als Unlimited als auch als unlimited an. Das sind keine neuen Optionen – sie anzulegen, würde Ihre Berichte zersplittern. Normalisieren Sie sie stattdessen beim Import.
Verfälschung durch die Tabellenkalkulation. Bereichswerte wie 2-4 und 5-10 waren irgendwo weiter oben in der Kette von einer Tabellenkalkulation unbemerkt in Datumsangaben umgewandelt worden und kamen als 4-Feb und 10-May an. Das ist weder die Schuld des Quellsystems noch die des CRM; es passiert, wenn eine CSV-Datei durch eine Tabellenkalkulation läuft. Erkennen Sie es, indem Sie die unterschiedlichen Werte zählen und die Liste mit eigenen Augen lesen.

Alle drei sind im Nachhinein unsichtbar. Ein leeres Feld sieht genauso aus wie ein Feld, das in der Quelle legitimerweise leer war.

Konfiguration auf Feldebene

Von 91 Quellspalten wurden 8 auf bestehende Standardfelder abgebildet, 18 als neue benutzerdefinierte Felder angelegt, und der Rest war entweder tatsächlich leer oder wurde ausdrücklich verworfen.

Was Sie bewusst verwerfen

Manche befüllten Spalten sind wertlos, und sie zu erkennen, gehört zur Aufgabe:

Konstanten. Eine Spalte, die in jeder Zeile denselben Wert enthält, ist meist die Mandanten-ID des Quellsystems oder ein Typ-Unterscheidungsmerkmal, das sich bereits aus Ihrem Mapping ergibt. Sie trägt keine Information pro Datensatz.
Export-Artefakte. Eine Spalte war überall, wo sie befüllt war, byte-identisch mit der Datensatz-ID und sonst leer – ein Duplikat, das der Export erzeugt hat, kein Feld, das jemand gepflegt hätte.
Codes ohne Nachschlagetabelle. Numerische Codes sind ohne Legende bedeutungslos, und die Legende lässt sich oft nicht exportieren. Besser verwerfen, als Zahlen zu importieren, die niemand deuten kann.

Normalisierung, die der Import leisten muss

Symptom im Export	Korrektur vor dem Import
Boolesche Werte exportiert als `1.00` / `0.00`	In true/false umwandeln
Ganzzahlige IDs exportiert als `104857.00`	Die Dezimalstellen entfernen, sonst werden sie als Text mit einem falschen Anhang importiert
Land als ISO-2-Code in Kleinbuchstaben	In die Namen ausschreiben, die das CRM erwartet
Telefonnummern mit uneinheitlichen Leerzeichen und Klammern	Normalisieren
Schreibvarianten in Dropdowns	Auf die kanonische Option zusammenführen – keine zweite Option anlegen

Zugehörigkeit zum Formular

Jedes neue Feld muss auf dem Formular platziert werden, nicht nur angelegt. Ein Feld, das im Schema existiert, aber im Formular fehlt, ist in Coevera wirkungslos – siehe Blueprint 002, wo dieselbe Einschränkung KI- und berechnete Felder unbemerkt außer Kraft setzt.

Weil der Export kohortenförmig ist, gliedern Sie das Formular nach Kohorten, statt achtzehn Felder in einem Block aufzulisten. Beachten Sie, dass Formularspalten in Coevera eine von fünf gültigen Aufteilungen in vier Einheiten verwenden müssen – [4], [2,2], [1,1,2], [2,1,1], [1,1,1,1].

Die Importreihenfolge

Die Reihenfolge zählt, weil mehrere Schritte Voraussetzung für den nächsten sind.

Den vollständigen Export inventarisierenJede Spalte: Befüllungszahl, Anzahl unterschiedlicher Werte und die tatsächlichen unterschiedlichen Werte für alles, was ein Dropdown werden soll. Nicht das Beispiel – die ganze Datei.
In Kohorten aufteilenZeilen nach Befüllungsmuster gruppieren. Das bestimmt das Formulardesign und zeigt oft, dass ein Eigentümer einer Kohorte entspricht.
Das Schicksal jeder Spalte ausdrücklich entscheidenStandardfeld, neues benutzerdefiniertes Feld oder verworfen mit genanntem Grund. Eine Spalte ohne Entscheidung ist eine Spalte, die verloren geht.
Dropdown-Optionen abgleichenFür jedes Dropdown die unterschiedlichen Werte der Quelle mit den Optionen des Ziels vergleichen. Anlegen, was wirklich fehlt; Schreibvarianten normalisieren; Verfälschungen an der Quelle beheben.
Das Tag-Vokabular anlegenBevor irgendein Kontakt importiert wird, sonst werden Tags unbemerkt nicht zugeordnet.
Felder anlegen und auf dem Formular platzierenBeides, in derselben Änderung.
Einen echten Datensatz von Anfang bis Ende schreibenEine tatsächliche Zeile aus dem Export, keine synthetischen Daten. Zurücklesen und jedes Feld vergleichen. Dann löschen.
Importieren, dann anhand der Befüllungsquote prüfenDie Befüllungsquote jedes Felds nach dem Import mit der Befüllungszahl der Quelle vergleichen. Eine Abweichung ist das einzige Signal, das Sie bekommen.

Schritt 7 ist der, den man überspringt, und der, der die meisten Probleme aufdeckt. Synthetische Testdaten sind konstruktionsbedingt sauber; eine echte Zeile trägt die Schreibvarianten, die Dezimalanhänge und die typografischen Apostrophe.

Grenzen & Kompromisse

Vom System verwaltete Felder lassen sich nicht importieren

Der Anlagezeitstempel des Datensatzes wird von der Plattform gesetzt. Sie können das Anlagedatum des Quellsystems nicht dorthin importieren; um die Herkunft zu erhalten, ist daher ein separates benutzerdefiniertes Datumsfeld nötig – entscheiden Sie das vorab, denn später lässt es sich ohne erneuten Import nicht nachholen.

Das Datum des letzten Kontakts wird ebenfalls vom CRM verwaltet und ist nicht importierbar. In diesem Export war diese Spalte auf allen 3.432 Datensätzen befüllt, und ohne ein fünfzehntes benutzerdefiniertes Feld hatte sie überhaupt kein Ziel.

URL-Felder schreiben beim Speichern eine Domain um

In Werten, die in ein Feld vom Typ url geschrieben werden, wird die Zeichenkette pipelinersales.com beim Speichern durch coevera.com ersetzt. Verifiziert in einem Live-Space am 2026-09-03 mit einer gepaarten Kontrolle: Derselbe Wert, gleichzeitig in einem Request in ein url-Feld und in ein Textfeld geschrieben, kam im ersten umgeschrieben und im zweiten wörtlich zurück.

Es ist eine Ersetzung einer Teilzeichenkette, die an jeder Stelle des Werts greift, auch innerhalb von Query-Strings – ein Tracking- oder Weiterleitungsparameter, der auf die alte Domain verweist, wird also unbemerkt umgelenkt. Schema, Subdomain und Pfad bleiben erhalten, und andere Domains bleiben unberührt. In der ursprünglichen Migration betraf das 28 von 29 URL-Werten. Wenn Ihre Quelldaten solche URLs enthalten und Sie sie wörtlich brauchen, verwenden Sie ein einfaches Textfeld statt eines url-Felds.

Der Eigentümer ist Pflicht, und Namen sind keine Schlüssel

Jeder Datensatz braucht einen gültigen Eigentümer, daher müssen die Benutzerkonten im Ziel existieren, bevor der Import läuft. Ordnen Sie über die E-Mail-Adresse des Quellbenutzers zu, nicht über seinen Anzeigenamen – in diesem Export entsprach der Name eines Vertriebsmitarbeiters zwei verschiedenen E-Mail-Adressen, mit 2.432 Datensätzen auf der einen und 15 auf der anderen. Eine Zuordnung über den Namen hätte einen echten Unterschied eingeebnet.

Wählen Sie den Deduplizierungsschlüssel bewusst

Importieren Sie die eigene Datensatz-ID des Quellsystems in ein eigens dafür angelegtes benutzerdefiniertes Feld. Sie ist in der Quelle eindeutig, über erneute Exporte hinweg stabil und macht einen wiederholten Import idempotent. E-Mail ist die naheliegende Wahl und ist unsicher – diese Datenbank enthielt echte doppelte Adressen, die ein Beispiel nicht gezeigt hat.

Was Ihnen der Export nicht verrät

Das Fehlen eines Werts ist kein Beleg für sein Fehlen im Quellsystem. Jeder Opt-in-Status in diesem Export lautete Subscribed – was mit ziemlicher Sicherheit bedeutet, dass der Export auf Abonnenten gefiltert war, nicht, dass sich niemand abgemeldet hatte. Ihn so zu importieren, als wäre er das vollständige Bild, hätte die Abmeldeliste unbemerkt verworfen – und das ist der einzige Fehler in diesem ganzen Artikel mit rechtlichen Folgen.
Echte Probleme der Datenqualität wandern mit den Daten. Dieser Export enthielt Datensätze ohne Vornamen, ohne Nachnamen oder ohne beides. Die Migration ist nicht der Moment, sie zu beheben, aber der Moment, sie zu zählen.

Verifizierung

Das Fehlerbild ist Stille, daher kann die Prüfung nicht lauten: „Hat der Import Erfolg gemeldet?“ – das hat er.

Feldanzahl vorher und nachher. Die Entität Contact wuchs von 83 auf 98 Felder. Eine einfache Zählung bestätigt, dass jedes vorgesehene Feld tatsächlich angelegt wurde, und entdeckt das eine, bei dem das unbemerkt nicht geschah.
Jede Dropdown-Option als vorhanden bestätigt, mit korrekten Namen und korrekter Sortierung – vor dem Import, nicht danach.
Ein echter Datensatz von Anfang bis Ende geschrieben, mit einer tatsächlichen Zeile aus dem Export, über beide APIs – REST und Admin – zurückgelesen und Feld für Feld verglichen. Genau so kam die URL-Umschreibung ans Licht: Jeder andere Wert blieb exakt erhalten, einer nicht. Der Testdatensatz wurde danach gelöscht.
Befüllungsquote pro Feld nach dem Import, verglichen mit der Befüllungszahl der Quelle. Das ist die Prüfung, die das stumme Leeren von Dropdowns in großem Maßstab erkennt – ein Feld, das 3.432-mal befüllt sein sollte und 2.853 zeigt, hat 579 Datensätze verloren, und nichts anderes sagt Ihnen das.
Eindeutigkeit des Deduplizierungsschlüssels im Ziel erneut geprüft, nicht aus der Quelle angenommen.
Zuordnung der Tags stichprobenartig geprüft bei Kontakten, die mehrere tragen sollten, denn Tags scheitern stumm, wenn das Vokabular unvollständig war.

Was auf eine Regression hindeuten würde: ein Dropdown-Feld, dessen Befüllungszahl nach einem erneuten Import sinkt; doppelte Datensätze nach einem zweiten Lauf, was bedeutet, dass der Deduplizierungsschlüssel nicht abgeglichen wird; URLs im Ziel, die von der Quelle abweichen; oder ein Einwilligungs-Flag mit einer anderen Verteilung als im Export.

Häufige Fragen

Warum verlieren CRM-Importe unbemerkt Daten, statt fehlzuschlagen?

Weil die häufigsten Fehler auf Werteebene liegen und nicht struktureller Art sind. Ein Dropdown-Feld wird über die Options-ID importiert, sodass ein Quellwert ohne passende Option im Ziel keinen Fehler auslöst – das Feld bleibt einfach leer. In einer Migration ergab eine Zählung am Export vor dem Import 579 von 3.432 Datensätzen, rund 17 Prozent, die auf einem einzigen Statusfeld geleert worden wären. Zu den Ursachen gehörten Optionen, die nie angelegt wurden, Varianten bestehender Optionen in anderer Groß-/Kleinschreibung, unbrauchbare Werte und Tabellenkalkulationen, die Bereichswerte wie 2-4 unbemerkt in Datumsangaben umwandelten.

Können Sie das Zielschema des CRM anhand eines Beispielexports entwerfen?

Nein, und genau das ist der teuerste Fehler, den man machen kann. In einer Migration zeigte ein Beispiel mit 71 Zeilen 59 Spalten als vollständig leer; der vollständige Export mit 3.432 Zeilen zeigte nur 26 tatsächlich leere. Ein Feld war im Beispiel zu null Prozent befüllt und in der vollständigen Datei zu hundert Prozent. E-Mail-Adressen waren im Beispiel eindeutig und enthielten im vollständigen Export Dubletten, was E-Mail als Deduplizierungsschlüssel ausschließt. Inventarisieren Sie immer den vollständigen Export, bevor Sie Felder entwerfen.

Welche CRM-Felder lassen sich durch einen Import nicht befüllen?

Vom System verwaltete Felder. In Coevera wird der Anlagezeitstempel eines Datensatzes von der Plattform gesetzt und kann nicht mitgeliefert werden; um das Ursprungsdatum aus dem Quellsystem zu erhalten, ist daher ein separates benutzerdefiniertes Datumsfeld nötig. Das Datum des letzten Kontakts wird ebenfalls vom CRM verwaltet und ist nicht importierbar, sodass eine vollständig befüllte Quellspalte kein Ziel hat, wenn Sie kein benutzerdefiniertes Feld dafür anlegen. Identifizieren Sie diese Felder vor dem Mapping, denn jedes davon ist entweder ein neues benutzerdefiniertes Feld oder eine Spalte, die Sie bewusst verwerfen.

Was sollten Sie beim Import von Kontakten als Deduplizierungsschlüssel verwenden?

Die eigene Datensatz-ID des Quellsystems, importiert in ein eigens dafür angelegtes benutzerdefiniertes Feld. Sie ist in der Quelle garantiert eindeutig, über erneute Exporte hinweg stabil und macht einen wiederholten Import idempotent, statt alles zu duplizieren. Die E-Mail-Adresse ist die naheliegende Wahl und ist unsicher: Echte Kontaktdatenbanken enthalten doppelte E-Mail-Adressen, und ein Beispiel zeigt sie womöglich nicht. Auch die Zuordnung des Eigentümers sollte über die E-Mail-Adresse des Quellbenutzers erfolgen statt über seinen Anzeigenamen, weil Name und E-Mail einander nicht zuverlässig eins zu eins entsprechen.

Herausgegeben von Coevera · auf das Muster abstrahiert, keine KundendatenBlueprint 005 · veröffentlicht 2026-09-23