Felder zwischen alten und neuen Systemen zuordnen

Von Victor Hoang · Aktualisiert am 2. März 2026

Die Feldzuordnung ist ein zentraler Schritt jedes ETL-Prozesses (Extract, Transform, Load), und bei CRM-Migrationen im Besonderen ist sie der Teil, der einfach aussieht, bis er es nicht mehr ist. „Vorname wird Vorname", klar. Aber was passiert, wenn Ihr Quellsystem nur ein einziges Feld „Full Name" hat und Ihr Zielsystem Vor- und Nachnamen getrennt verlangt? Oder wenn der Lead Status in Salesforce 8 Werte hat und das Zielsystem nur 5 unterstützt? Oder wenn der Jahresumsatz als Textfeld statt als Währungsfeld importiert wird und damit am ersten Tag jeden Umsatzbericht unbrauchbar macht?

Dieses letzte Szenario ist nicht hypothetisch. Es passiert ständig. Und es ist vermeidbar, wenn Sie das Dokument zur Feldzuordnung vor dem ersten Import-Lauf erstellen und nicht erst währenddessen.

Dieser Leitfaden führt Sie durch den gesamten Prozess der Feldzuordnung: zuerst die Zuordnung auf Objektebene, dann die Standardfelder, dann die schwierigen Fälle (benutzerdefinierte Felder, Picklist-Werte, Beziehungsfelder, Typkonflikte). Arbeiten Sie diese Schritte der Reihe nach ab, bevor Sie das Ziel-CRM anfassen. Falls Sie die vorgelagerten Schritte noch nicht erledigt haben, beginnen Sie zuerst mit der Vorbereitung Ihrer Daten vor der Migration und der Datenbereinigung und Deduplizierung.

Schritt 1: Zuerst die Zuordnung auf Objektebene

Bevor Sie ein einziges Feld zuordnen, ordnen Sie die Objekte zu. Jedes CRM verwendet für dieselben Konzepte leicht abweichende Begriffe, und eine fehlerhafte Objektzuordnung beschädigt Beziehungsdaten in großem Umfang.

Zuordnung der Standardobjekte

Das Problem der Lead-Konvertierung in Salesforce: Salesforce kennt sowohl Leads als auch Kontakte. Leads sind Datensätze vor der Konvertierung, Kontakte solche danach. Die meisten anderen CRMs haben nur Kontakte (mit Lifecycle-Stufen). Entscheiden Sie, bevor Sie irgendetwas zuordnen: Migrieren Sie Salesforce Leads als Kontakte mit der Lifecycle-Stufe „Lead", oder migrieren Sie nur konvertierte Kontakte? Diese Entscheidung betrifft Tausende von Datensätzen. Der Wechsel von Salesforce zu Rework erklärt, wie diese Konvertierung von Lead zu Kontakt speziell im Rework-Datenmodell abläuft. Und falls die Deduplizierung dieser Leads noch nicht stattgefunden hat, sollte die Datenbereinigung und Deduplizierung laufen, bevor Sie die Objektzuordnung finalisieren.

Wenn das Objektmodell nicht passt: Hat Ihre Quelle ein benutzerdefiniertes Objekt ohne Entsprechung im Zielsystem, dokumentieren Sie das ausdrücklich. Pressen Sie die Daten benutzerdefinierter Objekte nicht in ein Standardobjekt, das schafft nur Verwirrung. Migrieren Sie sie entweder als benutzerdefiniertes Objekt ins Zielsystem, oder entscheiden Sie, dass sich die Migration gar nicht lohnt.

Schritt 2: Zuordnung der Standardfelder

Standardfelder wirken unkompliziert. Das sind sie oft nicht.

Vorname / Nachname vs. Full Name: Salesforce speichert Vor- und Nachname getrennt. Manche Systeme speichern nur ein einziges Feld „Full Name". Migrieren Sie aus einer Quelle mit nur einem Full-Name-Feld in ein System, das getrennte Vor- und Nachnamen verlangt, brauchen Sie eine Aufteilungs-Transformation, und die ist unvollkommen (was machen Sie mit „Dr. María José García-López"?).

Mehrere Telefonfelder: Salesforce Contacts haben Phone, MobilePhone, OtherPhone, HomePhone und AssistantPhone, also fünf separate Telefonfelder. Die meisten CRMs haben ein primäres und ein sekundäres Telefonfeld. Legen Sie vor dem Import fest, welche Quellfelder auf welche Zielfelder abgebildet werden. Verwerfen Sie keine Telefonnummern, ohne diese Entscheidung zu dokumentieren.

Mehrere E-Mail-Adressen: Dasselbe Problem. Salesforce hat Email und eine sekundäre E-Mail-Adresse über Kontaktmethoden. HubSpot unterstützt mehrere E-Mail-Adressen pro Kontakt. Unterstützt das Zielsystem nur eine primäre E-Mail-Adresse, brauchen Sie eine Regel, welche gewinnt.

Website-Feld: Uneinheitliche URL-Formate verursachen Validierungsfehler. Manche Datensätze enthalten „example.com", andere „https://www.example.com", wieder andere „www.example.com/products/page". Legen Sie ein Zielformat fest und ergänzen Sie es als Transformationsregel.

Schritt 3: Inventur der benutzerdefinierten Felder

Hier bleiben die meisten Migrationen hängen. Jedes ausgereifte CRM hat Dutzende benutzerdefinierter Felder, die sich über Jahre wechselnder Prozesse angesammelt haben. Die meisten davon sind eine Migration nicht wert.

Exportieren Sie alle benutzerdefinierten Felder aus Ihrer Quelle:

• Salesforce: Setup > Object Manager > Objekt auswählen > Fields & Relationships. Als Liste exportieren. Die Dokumentation zum Salesforce Data Loader beschreibt, wie der Data Loader das Feldschema zusammen mit den Datensätzen exportiert, was beim Aufbau der Inventur neben Ihrem Export hilfreich ist.
• HubSpot: Settings > Properties. Filtern Sie nach „Created by" = Ihr Team, um benutzerdefinierte Properties zu sehen. Die HubSpot-Importdokumentation listet auf, welche Properties beim Import erforderlich sind: Gleichen Sie das ab, wenn Sie entscheiden, welche Zielfelder zuerst angelegt werden.
• Pipedrive: Settings > Data Fields. Benutzerdefinierte Felder sind pro Objekt aufgeführt.
• Zoho CRM: Setup > Customization > Fields.

Wenden Sie auf jedes benutzerdefinierte Feld den Drei-Fragen-Test an. Der Leitfaden zu benutzerdefinierten Feldern geht tiefer auf Namenskonventionen, die Wahl des Feldtyps und den Governance-Prozess für die Anlage benutzerdefinierter Felder im Zielsystem ein und ist lesenswert, bevor Sie in der Produktivumgebung Felder anlegen:

1. Berichten Sie darauf? Gibt es keinen Bericht, der dieses Feld verwendet, liefert es vermutlich keinen Geschäftswert.
2. Segmentieren Sie danach? Verweist kein Workflow, keine Sequenz und kein Listenfilter auf dieses Feld, ist es womöglich ungenutzt.
3. Automatisieren Sie darüber? Nutzt kein Automatisierungs-Trigger dieses Feld, überlegen Sie, ob es migriert werden muss.

Lautet die Antwort auf alle drei Fragen Nein, archivieren Sie das Feld im Quellsystem. Legen Sie es nicht im Zielsystem an.

Dokumentieren Sie die Entscheidung „behalten oder überspringen" für jedes benutzerdefinierte Feld. Wenn ein Vertriebsmitarbeiter in Woche drei fragt, warum sein Feld „Partner Type" verschwunden ist, möchten Sie eine schriftliche Begründung vorlegen können und nicht nur mit den Schultern zucken.

Vorlage für die Inventur benutzerdefinierter Felder

Schritt 4: Transformation von Picklist-Werten

Picklist-Felder sind der risikoreichste Feldtyp jeder Migration. Sie wirken einfach, verbergen aber Komplexität: Quellwerte passen oft nicht zu den Zielwerten, und nicht zugeordnete Werte werden entweder leer importiert oder lösen einen Fehler aus.

Das Vorgehen:

1. Exportieren Sie alle distinkten Werte jedes Picklist-Felds aus der Quelle
2. Exportieren Sie alle zulässigen Werte des entsprechenden Felds im Zielsystem
3. Erstellen Sie eine explizite Zuordnung von Wert zu Wert
4. Entscheiden Sie, was mit Quellwerten ohne Entsprechung im Ziel geschieht

Vorlage für die Picklist-Zuordnung

Beispiel: Lead Status / Lifecycle-Stufe

Was mit Werten ohne Entsprechung im Ziel zu tun ist: Lassen Sie sie nicht leer. Ordnen Sie sie entweder dem nächstliegenden Zielwert zu (mit einem Vermerk im Transformationsdokument) oder legen Sie im Zielsystem ein benutzerdefiniertes Feld an, um die Unterscheidung zu erhalten. Leere Werte in der Lifecycle-Stufe bedeuten, dass diese Datensätze von Automatisierungen, die nach der Lifecycle-Stufe filtern, nicht erfasst werden.

Schritt 5: Zuordnung von Beziehungsfeldern

Beziehungen sind der Teil der Feldzuordnung, der am häufigsten bricht und sich im Nachhinein am schwersten reparieren lässt.

Account → Contact-Verknüpfungen (Salesforce): Jeder Contact in Salesforce ist über das Lookup AccountId mit einem Account verknüpft. In den meisten Ziel-CRMs wird daraus eine Verknüpfung von Kontakt zu Unternehmen. Das Importwerkzeug muss diese Beziehung auflösen, in der Regel, indem es den Unternehmensnamen aus dem Kontaktdatensatz mit einem vorhandenen Unternehmensdatensatz abgleicht.

Die Reihenfolge ist entscheidend: Importieren Sie zuerst die Unternehmen, dann die Kontakte. Importieren Sie Kontakte, bevor die Unternehmen im Zielsystem existieren, lässt sich die Beziehung nicht herstellen.

Deal → Contact-Verknüpfungen: Ein Deal in Salesforce (Opportunity) hat einen Primary Contact und kann über die Opportunity Contact Role weitere Kontakte haben. Prüfen Sie, ob Ihr Ziel-CRM mehrere Kontaktverknüpfungen pro Deal unterstützt, und entscheiden Sie, welche Kontakte Sie migrieren.

Datensätze mit mehreren Beziehungen: Manche Kontakte sind mehreren Unternehmen zugeordnet (Berater, Beiratsmitglieder). Die meisten CRMs gehen damit anders um als Salesforce. Dokumentieren Sie, wie diese importiert werden, und testen Sie einige dieser Datensätze gezielt in Ihrem Shadow Import.

Hierarchien aus übergeordneten und untergeordneten Accounts: Salesforce Accounts können übergeordnete Accounts haben (für Beteiligungsstrukturen). Nicht jedes Ziel-CRM unterstützt das nativ. Wissen Sie vor der Zuordnung, ob Parent-Child-Hierarchien die Migration überstehen.

Schritt 6: Konflikte bei Feldtypen

Konflikte bei Feldtypen sind das gefährlichste Zuordnungsproblem, weil sie oft ohne Fehler importiert werden: Der falsche Typ beschädigt die Daten still und leise. Die Forschung von Gartner zum Master Data Management nennt inkonsistente Feldtypen als eine der häufigsten Ursachen für Datenintegritätsfehler bei Systemmigrationen.

Referenztabelle für Typkonvertierungen

Das Problem mit dem Annual Revenue: Das kommt ständig vor. Laut dem Wikipedia-Überblick zur Datenmigration gehören Typkonflikte bei Währungs- und Zahlenfeldern zu den am häufigsten genannten Ursachen für Datenverlust bei Migrationen. Salesforce speichert Annual Revenue als Währungsfeld. Manche Ziel-CRMs speichern es als einfache Zahl. Importieren Sie eine formatierte Währungszeichenkette wie „$1,250,000.00" in ein Zahlenfeld, schlägt der Import fehl. Entfernen Sie vor dem Import das Dollarzeichen und die Kommas: Wandeln Sie $1,250,000.00 in 1250000 um. Einen breiteren Blick darauf, wie sich CRM-Datenmodelle zwischen Plattformen unterscheiden, einschließlich des Umgangs mit Feldtypen, bietet Rework vs. HubSpot CRM, eine nützliche Referenz, bevor Sie die Regeln zur Typkonvertierung finalisieren.

Checkbox-Felder: Verschiedene Systeme stellen boolesche Werte unterschiedlich dar. Salesforce exportiert True/False. Manche CRMs importieren 1/0. Andere verlangen „Yes"/„No". Wissen Sie, was Ihr Importwerkzeug erwartet, und transformieren Sie entsprechend.

Schritt 7: Das Dokument mit den Transformationsregeln

Schreiben Sie für jedes Feld, das nicht direkt übernommen wird, die Transformationsregel ausdrücklich auf. Dieses Dokument wird zu Ihrer Importanleitung: Die Person, die den Import durchführt, folgt ihm, ohne spontan Entscheidungen treffen zu müssen.

Notation für Transformationen

Verwenden Sie für alle Transformationsregeln ein einheitliches Format:

IF [source_field] = "[source_value]"
THEN [destination_field] = "[destination_value]"
ELSE [default_behavior]

Beispiele:

IF lead_status = "Dead" OR "Not Interested"
THEN lifecycle_stage = "Disqualified"

IF annual_revenue = text format "$N,NNN,NNN.NN"
THEN annual_revenue = REPLACE("$","") + REPLACE(",","") [numeric only]

IF phone = any format
THEN phone = E.164 format (+CC + subscriber number, no separators)

IF close_date = NULL
THEN close_date = [leave blank, do not default to any date]

IF contact.account_id IS NOT NULL
THEN [resolve AccountId → Company via company_name match in destination]
ELSE [create standalone contact with no company association]

Schreiben Sie für jede nicht triviale Zuordnung eine Regel. Können Sie die Regel nicht formulieren, haben Sie die Entscheidung noch nicht getroffen, und genau das Problem wollen Sie vermeiden.

Schritt 8: Die Feldzuordnung mit 100 Testdatensätzen validieren

Bevor Sie den vollständigen Import ausführen, validieren Sie jede Zuordnungsentscheidung anhand Ihrer Stichprobe von 100 Testdatensätzen.

Führen Sie den Testimport mit exakt Ihrem Werkzeug durch. Testen Sie nicht mit einer anderen Importmethode als der, die Sie am Tag der Umstellung verwenden. Ziel ist es, Fehler in Ihrem Zuordnungsdokument aufzudecken, nicht in Ihrem Importwerkzeug.

Prüfen Sie jedes zugeordnete Feld im Ergebnis:

• Haben die Textfelder die richtigen Werte?
• Zeigen die Picklist-Felder Zielwerte (nicht Quellwerte)?
• Werden Datumsfelder im richtigen Format angezeigt?
• Werden Währungs- und Zahlenfelder als Zahlen importiert, nicht als Text?
• Lösen sich die Beziehungsfelder zu den richtigen Unternehmens- und Deal-Datensätzen auf?

Suchen Sie nach stillen Fehlern: Ein Importlauf, der ohne Fehler endet, ist nicht dasselbe wie ein korrekter Importlauf. Öffnen Sie 10 Datensätze manuell und vergleichen Sie sie Feld für Feld mit der Quelle. Automatisierte QA übersieht die stillen Fehler bei der Typkonvertierung, die im Importprotokoll sauber aussehen.

Finden Sie im Testimport Fehler, korrigieren Sie zuerst das Zuordnungsdokument. Korrigieren Sie Datensätze nicht manuell im Zielsystem. Das behandelt das Symptom und lässt die Ursache in Ihrer Zuordnungsdatei, wo sie bei den nächsten 10.000 Datensätzen denselben Fehler verursacht.

Häufige Fehler

Benutzerdefinierte Felder zuordnen, ohne zu entscheiden, ob sie noch gebraucht werden. Der Schritt der Feldinventur hat seinen Grund. Die Migration eines Felds, das niemand nutzt, bringt Rauschen ins Ziel-CRM und verwirrt Vertriebsmitarbeiter, die Felder sehen, die sie nicht kennen.

Feldtyp-Konflikte ignorieren. „Wird schon passen" ist der Weg, auf dem Annual Revenue zu einem Textfeld wird, das am ersten Tag Ihre Umsatz-Dashboards zerstört. Prüfen Sie jeden Typkonflikt ausdrücklich.

Transformationsregeln nicht dokumentieren und dann vergessen. Sie verbringen 90 Minuten damit, die Zuordnung der Lifecycle-Werte auszuarbeiten. Drei Wochen später, wenn jemand fragt, warum Leads in einem Bericht als „Unknown" erscheinen, brauchen Sie dieses Dokument. Schreiben Sie es auf, solange es frisch ist. Als Ankerpunkt für die Definition der Lifecycle-Stufen bei dieser Zuordnung behandeln die Lead-Lifecycle-Stufen den üblichen Verlauf und die Stellen, an denen die meisten Teams davon abweichen.

Lookup- und Verknüpfungsfelder wie normale Felder behandeln. Beziehungsfelder setzen voraus, dass der verknüpfte Datensatz im Zielsystem bereits existiert. Importieren Sie Kontakte vor den Unternehmen, schlagen alle Unternehmensverknüpfungen still fehl. Die Importreihenfolge ist Teil der Entscheidung zur Feldzuordnung. Der Leitfaden zum Shadow-Import-Test zeigt, wie Sie die Auflösung der Beziehungen vor der Umstellung verifizieren.

Nur mit sauberen Datensätzen testen. Ihre Teststichprobe muss Randfälle enthalten: Datensätze mit Nullwerten, mit maximaler Feldlänge, mit ungewöhnlichen Zeichen. Eine Zuordnung, die mit sauberen Daten funktioniert, scheitert an echten Daten, wenn Sie die unsauberen Fälle auslassen. Der Leitfaden zum Shadow-Import-Test legt genau fest, wie Sie einen repräsentativen Testdatensatz mit der richtigen Mischung aus Randfällen aufbauen.

Wie es weitergeht

Exportieren Sie diese Woche die Schemata Ihrer Quellobjekte. Die meisten CRMs bieten eine Möglichkeit, eine Feldliste mit Typinformationen herunterzuladen:

• Salesforce: Schema Builder (visuell) oder describe()-Aufrufe über Salesforce Workbench: Workbench liefert in einem Export eine vollständige Feldliste mit API-Namen und Typen
• HubSpot: Settings > Properties > Export
• Pipedrive: Settings > Data Fields

Erstellen Sie eine Tabelle mit jedem Quellfeld und beginnen Sie, die Spalte für das Zielfeld auszufüllen. In diesem Stadium ist selbst ein grober erster Durchgang wertvoll: Sie entdecken die schwierigen Fälle (die Picklist-Abweichungen, die Typkonflikte, die Felder ohne Entsprechung im Ziel) und können Entscheidungen treffen, bevor sie zu Krisen am Umstellungstag werden. Sobald die Feldzuordnung abgeschlossen und getestet ist, zeigt CRM-Rollout und Adoption, wie Sie das Team auf Tag eins vorbereiten, denn ein sauberer Import garantiert noch keine reibungslose Einführung.

Weiterführende Ressourcen

• Daten vor der Migration vorbereiten
• Datenbereinigung: Deduplizierung, Normalisierung, Anreicherung
• Die Migration mit einem Shadow Import testen
• Leitfaden zu benutzerdefinierten Feldern für das Ziel-CRM
• CRM-Rollout und Adoption nach dem Go-live