Sauberer Export aus Salesforce: Der migrationsgerechte Export-Leitfaden

Ein Sales Ops-Team in einem Mid-Market-SaaS-Unternehmen verbrachte sechs Wochen mit der Vorbereitung der CRM-Migration. Sie exportierten Kontakte und Accounts, prüften einige Datensätze stichprobenartig und erklärten den Export für abgeschlossen. Drei Tage nach go-live zeigte das neue CRM für 4.200 Kontakte keinerlei Aktivitätshistorie. Das Team hatte Tasks und Events nicht exportiert, die zwei Salesforce-Objekte, in denen jedes Anrufprotokoll, jede E-Mail und jedes Meeting gespeichert war. Drei Jahre Interaktionshistorie, weg.

Der Export selbst dauerte 20 Minuten. Die Wiederherstellung dauerte drei Wochen manueller Rekonstruktion aus E-Mail-Archiven und aus dem Gedächtnis der Reps. Nicht alle Datensätze kamen zurück.

Dieser Leitfaden beschreibt den Salesforce-Exportprozess, der wirklich alles erhält: Objekte, Beziehungen, benutzerdefinierte Felder und Aktivitätshistorie. Befolgen Sie ihn in der angegebenen Reihenfolge. Die Reihenfolge ist entscheidend.

---

Was auf was in Salesforce abgebildet wird

Bevor Sie die Export-Tools anfassen, müssen Sie verstehen, was Sie extrahieren. Salesforce organisiert Daten in Objekte. Die meisten Teams kennen die offensichtlichen. Die, die Teams übersehen, sind die, die Probleme verursachen. Diese Zuordnungsarbeit hängt direkt mit der Feldzuordnung zwischen Legacy-System und neuem System zusammen. Sie können kein zuverlässiges Feldmapping aufbauen, ohne vorher zu wissen, welche Objekte Sie extrahieren.

Laut Gartner-Forschung zur CRM-Datenqualität kostet schlechte Datenqualität Unternehmen durchschnittlich 12,9 Millionen US-Dollar pro Jahr. CRM-Migrationen sind dabei einer der kritischsten Momente für Datenqualitätsverschlechterung.

Objekte, die Sie exportieren müssen:

Der Beziehungsgraph läuft Account zu Contact zu Opportunity, mit Tasks und Events, die an alle drei anhängen. Wenn Sie Contacts ohne Accounts exportieren, verliert jeder Contact seine Unternehmensverknüpfung. Wenn Sie Tasks und Events überspringen, verlieren Sie die Aktivitäts-Timeline vollständig.

Schreiben Sie alle Objekte auf, die Ihre Org nutzt, bevor Sie beginnen. Fragen Sie Ihren Salesforce-Admin, wenn Sie sich nicht sicher sind.

---

Schritt 1: Data Export oder Data Loader nutzen, und wann welches das Richtige ist

Salesforce bietet Ihnen zwei primäre Export-Tools. Sie sind nicht austauschbar.

Data Export (Setup, Data Export)

• Wöchentlich geplant oder über die UI auf Abruf ausgeführt
• Exportiert alles in einer einzigen Zip-Datei nach Objekt
• Hartes Limit: ca. 512 MB pro Datei; große Orgs erreichen das bei Contacts oder Opportunities
• Keine Filterung: Sie erhalten jeden Datensatz in jedem Objekt
• Geeignet für: Kleine bis mittelgroße Orgs, initialer Vollexport, Teams ohne tiefe Salesforce-Admin-Kenntnisse

Data Loader

• Eigenständige Desktop-Anwendung (Windows/Mac)
• Verarbeitet große Volumina: getestet bis zu Zehnmillionen von Datensätzen
• Erfordert SOQL-Abfragen. Sie steuern exakt, welche Felder ausgegeben werden
• Erlaubt das Filtern nach Datumsbereich, RecordType oder beliebigem Feldwert
• Geeignet für: Große Orgs, selektive Exporte, Custom Objects mit komplexen Beziehungen

Für die meisten Migrationen ist Data Loader die richtige Wahl. Data Export ist für Orgs mit weniger als 50.000 Datensätzen pro Objekt geeignet, aber sobald Sie es mit komplexen Feldbeziehungen oder großen Aktivitätshistorien zu tun haben, gibt Ihnen Data Loader die nötige Kontrolle. Wenn Sie nicht sicher sind, ob Ihre Org als komplexe Migration gilt, hilft Ihnen Ihre Daten vorbereiten, bevor Sie irgendetwas migrieren dabei, die Arbeit zu dimensionieren, bevor der Export beginnt.

Hinweis zu API-Rate-Limits: Data Loader nutzt Salesforces API. Wenn Ihre Org gleichzeitig andere Integrationen betreibt, können Sie mitten im Export Rate-Limits erreichen. Planen Sie große Exporte außerhalb der Geschäftszeiten oder klären Sie mit Ihrem Salesforce-Admin Ihre API-Zuweisung. Die Salesforce Data Loader Entwicklerdokumentation behandelt die Batch-Größenkonfiguration und API-Nutzungslimits im Detail.

---

Schritt 2: In der richtigen Reihenfolge exportieren

Objektabhängigkeiten in Salesforce bedeuten, dass manche Datensätze nicht sinnvoll in ein neues System importiert werden können, es sei denn, die Datensätze, auf die sie verweisen, existieren dort bereits. In der falschen Reihenfolge exportieren und Sie haben CSV-Dateien voller verwaister Datensätze.

Erforderliche Exportreihenfolge:

1. Account
2. Contact (verweist auf Account)
3. Lead (unabhängig, aber früh exportieren)
4. Opportunity (verweist auf Account)
5. OpportunityContactRole (das Junction-Objekt, das Opportunities mit Contacts verknüpft)
6. Task (verweist auf Contact, Lead, Opportunity, Account)
7. Event (wie Task)
8. EventRelation (wenn Ihre Org gemeinsame Meetings mit mehreren Teilnehmern nutzt)
9. Case (falls genutzt)
10. Custom Objects (in ihrer eigenen Abhängigkeitsreihenfolge exportieren)

Warum kommt Account zuerst? Weil Contacts auf AccountId verweisen. Wenn Sie ins Zielsystem importieren, müssen Contacts auf vorhandene Account-Datensätze verweisen. Exportieren Sie Accounts zuerst, importieren Sie sie zuerst, dann kümmern Sie sich um Contacts mit den korrekten Account-Verknüpfungen.

OpportunityContactRole ist der stille Killer. Es ist ein Junction-Objekt, das speichert, welche Contacts mit welchen Opportunities verknüpft sind. Überspringen Sie es, und Ihre Opportunities kommen im neuen CRM ohne Kontaktbeziehungen an. Die meisten Teams vergessen, dass es existiert. Dasselbe Prinzip gilt für Umgang mit historischen Aktivitäten, Notizen und E-Mails. Beziehungsdaten und Aktivitätshistorie erfordern beide bewusste Exportentscheidungen, nicht nur ein standardmäßiges „alles exportieren".

---

Schritt 3: Lookups und IDs handhaben

Hier wird der Export technisch wichtig. Jedes Lookup-Feld in Salesforce enthält eine Salesforce-Datensatz-ID, eine 18-stellige alphanumerische Zeichenfolge, die außerhalb von Salesforce nichts bedeutet. Wenn Sie einen Contact-Datensatz öffnen, enthält das AccountId-Feld etwas wie 001A000001B2cDEFAB. Diese ID existiert in Ihrem neuen CRM nicht.

Was zu tun ist:

Exportieren Sie für jedes Lookup-Feld den aussagekräftigen Bezeichner des zugehörigen Datensatzes neben der Salesforce-ID. Für Contacts bedeutet das, sowohl AccountId als auch Account.Name in derselben Zeile zu exportieren. Für Opportunities exportieren Sie sowohl AccountId als auch Account.Name sowie OwnerId und Owner.Name.

In Data Loader sieht Ihre SOQL-Abfrage so aus:

SELECT Id, FirstName, LastName, Email, Phone, AccountId, Account.Name,
       OwnerId, Owner.Name, LeadSource, CreatedDate
FROM Contact

Die Punkt-Notation (Account.Name) zieht das zugehörige Feld inline. Das gibt Ihren Bereinigungs- und Importschritten eine lesbare Referenz neben der Salesforce-ID.

Externe IDs: Wenn Ihre Org benutzerdefinierte externe ID-Felder verwendet (häufig in Orgs, die mit ERP oder Billing-Systemen integriert sind), exportieren Sie auch diese Felder. Sie werden zum Join-Schlüssel im Zielsystem.

ID-Übersetzungs-Referenztabelle:

Exportieren Sie diese Beziehungsnamen neben jeder ID. Sie verwenden sie bei der Feldzuordnung im nächsten Schritt.

---

Schritt 4: Aktivitäten korrekt exportieren

Tasks und Events befinden sich in ihren eigenen Objekten. Sie sind nicht in Contact- oder Opportunity-Datensätze eingebettet. Und sie haben ihre eigenen Beziehungsfelder, die dieselbe Behandlung wie die oben beschriebenen Lookup-Felder benötigen.

Für Tasks (SOQL über Data Loader):

SELECT Id, Subject, Description, Status, Priority, ActivityDate,
       WhoId, Who.Name, Who.Type,
       WhatId, What.Name, What.Type,
       OwnerId, Owner.Name, CreatedDate
FROM Task
WHERE ActivityDate >= 2022-01-01

Die WhoId ist die Person, auf die sich die Task bezieht (Contact oder Lead). Die WhatId ist der zugehörige Datensatz (Opportunity, Account oder Case). Exportieren Sie sowohl die IDs als auch die Namen.

Für Events:

SELECT Id, Subject, Description, StartDateTime, EndDateTime, Location,
       WhoId, Who.Name, WhatId, What.Name, OwnerId, Owner.Name, CreatedDate
FROM Event
WHERE StartDateTime >= 2022-01-01T00:00:00Z

Datumsbereich-Filterung: Die meisten Teams benötigen nicht jeden Task und jedes Event seit dem Beginn aller Zeiten. Filtern Sie auf die letzten 2 bis 3 Jahre, es sei denn, es gibt einen spezifischen Geschäftsgrund für einen längeren Zeitraum. Ungefilterte Aktivitätsexporte aus gereiften Salesforce-Orgs können Millionen von Datensätzen umfassen, viele davon automatisch generierte Systemereignisse ohne eigentlichen Inhalt. Den Entscheidungsrahmen dafür, was zu migrieren und was zu archivieren ist, finden Sie in Umgang mit historischen Aktivitäten, Notizen und E-Mails.

Das Feld WhoId.Type teilt Ihnen mit, ob die Task mit einem Contact oder einem Lead verknüpft ist. Exportieren Sie es, damit Sie beim Import korrekt routen können.

---

Schritt 5: Export prüfen, bevor Sie Salesforce schließen

Beginnen Sie nicht mit der Bereinigung, bevor Sie verifiziert haben, dass der Export vollständig ist. Dieser Check dauert 30 Minuten und fängt Probleme auf, die sonst sechs Wochen nach go-live auftauchen würden.

Datensatzanzahl-Validierung:

Stichproben-Prozess:

Wählen Sie 20 zufällige Contact-Datensätze aus Ihrem Export. Für jeden:

1. Öffnen Sie den Datensatz in Salesforce
2. Prüfen Sie, dass die Schlüsselfelder mit der CSV-Zeile übereinstimmen
3. Prüfen Sie, dass Account.Name befüllt ist
4. Prüfen Sie, dass mindestens ein Task oder Event in der zugehörigen Aktivitäts-Timeline erscheint
5. Wenn ein Datensatz nicht stimmt, untersuchen Sie das, bevor Sie fortfahren

Vollständigkeit benutzerdefinierter Felder:

Rufen Sie die Feldliste Ihrer Org aus Setup, Object Manager, Objekt, Felder und Beziehungen ab. Vergleichen Sie sie mit Ihren Export-Spaltenüberschriften. Fehlende Spalten bedeuten, dass Sie den Export mit zusätzlichen Feldern in Ihrer SOQL-Abfrage wiederholen müssen.

---

Die Salesforce-Export-Checkliste

Nutzen Sie diese, bevor Sie den Export für abgeschlossen erklären:

• Alle erforderlichen Objekte identifiziert und aufgelistet
• Exportreihenfolge folgt Account zu Contact zu Lead zu Opportunity zu OpportunityContactRole zu Task zu Event
• Jedes Lookup-Feld enthält neben der Salesforce-ID den lesbaren Namen des zugehörigen Datensatzes
• WhoId- und WhatId-Felder bei Tasks und Events enthalten .Name und .Type
• Datensatzanzahlen gegen Salesforce-Reports oder Developer-Console-Abfragen validiert
• 20 zufällige Datensätze pro Objekt stichprobenartig geprüft
• Benutzerdefinierte Felder gegen die Objektfeldliste verifiziert
• Aktivitätshistorie auf einen angemessenen Datumsbereich gefiltert
• Exportdateien an einem kontrollierten Ort gespeichert, mit auf das Migrationsteam beschränktem Zugang

---

Häufige Fehler

Nur Contacts exportieren und Accounts vergessen. Contacts verweisen auf Accounts. Ohne Accounts verliert jeder Contact beim Import seine Unternehmensverknüpfung. Exportieren Sie Accounts immer zuerst.

Formelfeld-Werte verlieren. Salesforce-Formelfelder berechnen sich dynamisch, sie speichern keinen Wert. Wenn Sie sie exportieren, erhalten Sie den berechneten Wert zum Exportzeitpunkt. Wenn die Formel auf ein anderes Objekt verweist, das sich ändert, wird der exportierte Wert nicht aktualisiert. Exportieren Sie Formelfelder unverändert und notieren Sie in Ihrem Feldmapping, welche Felder das sind.

Record Types vergessen. Wenn Ihre Org Record Types nutzt (verschiedene Seitenlayouts und Auswahllistenwerte für verschiedene Datensatzkategorien), muss das Feld RecordType.Name in Ihrem Export enthalten sein. Record-Type-Unterscheidungen beeinflussen häufig, wie Datensätze im Zielsystem kategorisiert werden sollten.

API-Rate-Limits mitten im Export erreichen. Data Loader führt API-Aufrufe in Batches durch. Ein großer Export, zum Beispiel 2 Millionen Tasks, kann Ihre tägliche API-Zuweisung aufbrauchen. Überwachen Sie den Batch-Fortschritt und exportieren Sie große Objekte über Nacht, falls nötig.

Gelöschte Datensätze nicht exportieren. Wenn Sie Datensätze migrieren müssen, die soft-deleted wurden (im Papierkorb), benötigen Sie eine separate Abfrage mit ALL ROWS in SOQL. Die meisten Teams benötigen das nicht, aber es lohnt sich, das mit Stakeholdern zu bestätigen, bevor der Export beginnt. Die NIST-Richtlinien zur Datenintegrität bieten einen nützlichen Rahmen zur Definition, welche Datensätze bei Systemwechseln erhalten werden müssen. Datensätze, die Sie nicht migrieren, aber trotzdem aufbewahren müssen, gehören in ein Langzeit-Archiv Ihrer Legacy-CRM-Daten, nicht ins Zielsystem und nicht einfach vergessen.

---

Wie Sie weitermachen

Ihr validierter Export ist das Rohmaterial für alles Folgende. Aber rohe Exportdateien sind nicht importbereit: Sie müssen bereinigt, dedupliziert und mit Feldmapping versehen werden, bevor Sie das Zielsystem anfassen.

Der nächste Schritt ist Datenbereinigung: Deduplizierung, Normalisierung und Anreicherung. Führen Sie Ihre exportierten CSVs durch diesen Prozess, bevor Sie das Import-Tool in Ihrem neuen System öffnen. Ein McKinsey-Bericht zur Datenstrategie ergab, dass Unternehmen mit starker Datenqualitätsdisziplin eine 23-mal höhere Kundengewinnungsrate erzielen. Mit sauberen, validierten Exporten in die Migration zu starten ist das Fundament dieser Disziplin.

Wenn Sie noch kein abgeschlossenes Feldmapping haben, beschreibt Felder zwischen Legacy-System und neuem System abbilden die Entscheidungen, die vor der Bereinigung getroffen werden müssen.

Und wenn Sie noch nicht entschieden haben, was mit all diesen Tasks und Events zu tun ist, behandelt Ihre Daten vorbereiten, bevor Sie irgendetwas migrieren die strategischen Entscheidungen, die alle nachfolgenden Export- und Importentscheidungen prägen.

---

Mehr erfahren

• Datenbereinigung: Deduplizierung, Normalisierung, Anreicherung
• Felder zwischen Legacy-System und neuem System abbilden
• Ihre Daten vorbereiten, bevor Sie irgendetwas migrieren
• Testen der Migration mit einem Schattenimport
• CRM-Datenmodell-Design: benutzerdefinierte Felder, Objekte und Beziehungen
• Pipeline-Hygiene-Kultur: Ihr CRM nach go-live sauber halten