--- title: "Wie migrieren Sie Kontakte aus einem anderen System, ohne unbemerkt Daten zu verlieren?" blueprint: 005 slug: contact-migration-without-data-loss category: Datenmigration published: 2026-09-23 revised: 2026-09-23 platform: Coevera CRM (formerly Pipeliner CRM) canonical: https://blueprints.coevera.com/de/blueprints/contact-migration-without-data-loss/ language: de translation_of: https://blueprints.coevera.com/blueprints/contact-migration-without-data-loss/ author: Lucia Schmidt publisher: Coevera customer_data: none --- # Wie migrieren Sie Kontakte aus einem anderen System, ohne unbemerkt Daten zu verlieren? **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. ## 01 · 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. ## 02 · 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. ## 03 · 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](https://help.coevera.com/en/articles/4190964-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. ## 04 · 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 | ### Tags Tags sind ein mehrwertiges Feld, ein Kontakt behält also alle seine Quell-Tags – aber das **Tag-Vokabular muss im Space existieren, bevor die Kontakte importiert werden**. Drei Details aus diesem Export, die Sie in Ihrem prüfen sollten: Vergewissern Sie sich, dass das Trennzeichen wirklich sicher ist (hier enthielt kein Wert ein Komma, auf das kein Leerzeichen folgte); achten Sie auf typografische Apostrophe, die zwei optisch identische Tags zu verschiedenen machen; und rechnen Sie mit Unbrauchbarem – ein bedeutungsloser Tag stand auf 182 Datensätzen. ### 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](https://blueprints.coevera.com/de/blueprints/ai-fields-read-documents/), 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]`. ## 05 · Die Importreihenfolge Die Reihenfolge zählt, weil mehrere Schritte Voraussetzung für den nächsten sind. 1. **Den vollständigen Export inventarisieren**Jede 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. 2. **In Kohorten aufteilen**Zeilen nach Befüllungsmuster gruppieren. Das bestimmt das Formulardesign und zeigt oft, dass ein Eigentümer einer Kohorte entspricht. 3. **Das Schicksal jeder Spalte ausdrücklich entscheiden**Standardfeld, neues benutzerdefiniertes Feld oder verworfen mit genanntem Grund. Eine Spalte ohne Entscheidung ist eine Spalte, die verloren geht. 4. **Dropdown-Optionen abgleichen**Fü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. 5. **Das Tag-Vokabular anlegen**Bevor irgendein Kontakt importiert wird, sonst werden Tags unbemerkt nicht zugeordnet. 6. **Felder anlegen und auf dem Formular platzieren**Beides, in derselben Änderung. 7. **Einen echten Datensatz von Anfang bis Ende schreiben**Eine tatsächliche Zeile aus dem Export, keine synthetischen Daten. Zurücklesen und jedes Feld vergleichen. Dann löschen. 8. **Importieren, dann anhand der Befüllungsquote prüfen**Die 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. ## 06 · 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. ## 07 · 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. ## Verwandte Blueprints - [Blueprint 003 — Wie modellieren Sie etwas, für das Ihr CRM kein Objekt hat?](https://blueprints.coevera.com/de/blueprints/where-should-this-data-live/) — welche der einundneunzig Spalten überhaupt ein Feld verdienen, entschieden, bevor auch nur eine davon zugeordnet wird. - [Blueprint 013 — Wie fügen Sie Ihrer Website ein Kontaktformular hinzu, das direkt in Ihr CRM schreibt?](https://blueprints.coevera.com/de/blueprints/website-contact-form-into-crm/) — der Upsert, der verhindert, dass ein Formular die Personen neu anlegt, die Sie gerade migriert haben. - [Blueprint 002 — Wie bringen Sie eine KI dazu, ein Dokument zu lesen und CRM-Felder zuverlässig zu befüllen?](https://blueprints.coevera.com/de/blueprints/ai-fields-read-documents/) — die Feldtypen, die sich automatisch befüllen lassen, und die, bei denen das nicht geht – dieselbe Dropdown-Einschränkung, vom anderen Ende her. - [Blueprint 016 — Wie verketten Sie E-Mail-Sequenzen so, dass das Verhalten eines Interessenten entscheidet, was als Nächstes passiert?](https://blueprints.coevera.com/de/blueprints/chaining-email-sequences-on-engagement/) — was eine ungeprüfte Liste beim ersten Kontakt anrichtet. ## 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 wiederverwendbare Muster abstrahiert – keine Kundennamen, keine Kundendaten, keine personenbezogenen Daten.