So gelingt eine Salesforce-Datenmigration wirklich

Kurze Antwort: Eine Salesforce-Datenmigration entscheidet sich in der Datenqualitätsphase, Wochen vor dem Ladetag. Profilieren Sie die Quelldaten, entscheiden Sie bewusst, was nicht mitkommt, mappen Sie jedes Feld mit einer External ID dahinter, und proben Sie den Cutover, bis er langweilig ist. Das Laden ist der einfache Teil und fast nie die Ursache des Scheiterns.

Warum scheitern Salesforce-Datenmigrationen wirklich?

Selten am Laden. Data Loader, die Bulk-API und die ETL-Werkzeuge funktionieren. Fehlschläge lassen sich auf früher umgangene Entscheidungen zurückführen:

• Kein benannter Verantwortlicher für eine Datendomäne, also konnte niemand eine Regel freigeben.
• Dubletten, die alle sahen und zu deren Auflösung sich niemand bekannte.
• Ein Quellfeld, dessen Bedeutung vor Jahren abgedriftet ist und das nach seinem Label gemappt wurde.
• Ein Umfang, der still zu "alles" wurde, weil nichts wegzulassen sicherer wirkte als zu entscheiden.

Alle vier sind in Woche zwei billig zu beheben und in der Cutover-Nacht brutal. Das ist das ganze Argument dafür, Datenqualität nach vorn zu ziehen.

Was heißt Profilierung hier konkret?

Profilierung ist Messen, nicht Betrachten. Bevor jemand eine Mapping-Zeile schreibt, liefern Sie Zahlen je Quellobjekt:

• Füllgrad je Feld. Ein Feld, das in 4% der Datensätze gefüllt ist, ist kein Feld, sondern ein Gerücht.
• Eindeutige Werte gegen die Ziel-Auswahlliste. Hier werden "Prospect", "prospect" und "PROSPECT " zu drei Werten und einer Diskussion.
• Dublettenquote auf dem geplanten Abgleichsschlüssel. Messen Sie sie, bevor Sie den Schlüssel wählen, nicht danach.
• Waisenquote je Beziehung. Kindsätze ohne auflösbaren Elternsatz bestimmen Ladereihenfolge und Fehlermenge.
• Auflösungsquote der Eigentümer. Welcher Anteil verweist auf einen aktiven Salesforce-Benutzer, und wer bekommt den Rest.
• Datumsbereiche und Ausreißer. Datensätze mit 1900 oder 2099 laufen im ungünstigsten Moment in eine Validierungsregel.

Das Ergebnis ist ein kurzer Profilbericht. Seine eigentliche Aufgabe ist, Meinungen in Zahlen zu verwandeln, damit Umfangsdiskussionen mit einer Entscheidung enden statt mit einem Termin.

Was sollte man bewusst nicht migrieren?

Das ist die Entscheidung mit der größten Hebelwirkung und die, die die meisten Pläne auslassen. Jeder Datensatz hat vier mögliche Schicksale, und nur eines davon ist teuer:

1. Migrieren. Er wird operativ gebraucht, in Salesforce, von einem benannten Prozess.
2. Zusammenfassen. Die Historie zählt als Summe, nicht Zeile für Zeile. Laden Sie einen Rollup, keine zehn Jahre Transaktionen.
3. Archivieren. Im Warehouse oder als Export für die Compliance aufbewahren, außerhalb des CRM.
4. Stehen lassen. Das Altsystem für einen definierten Zeitraum lesend verfügbar halten, damit Leute nachschlagen können.

Vernünftige Standards: abgeschlossene Datensätze alter als Ihr Reporting-Horizont werden zusammengefasst, Kontakte ohne Aktivität und ohne erreichbare E-Mail werden archiviert, und Freitextfelder, über die niemand berichtet, kommen gar nicht mit. Jeder ausgeschlossene Datensatz spart Mapping-Aufwand, Validierungsfehler, Testfälle und Support nach dem Go-live. Weniger Umfang ist die günstigste Leistungsverbesserung, die es gibt.

Wie baut man ein Mapping, das den Kontakt mit den Daten überlebt?

Eine Zeile je Zielfeld, und jede Zeile trägt: Quellfeld, Transformationsregel, Standardwert, Verantwortlicher, die zu bestehende Validierung und das Datum der Freigabe. Eine Zeile ohne Verantwortlichen ist kein Mapping, sondern eine Hoffnung.

Zwei technische Entscheidungen bestimmen, wie ruhig der Rest des Projekts verläuft:

• Setzen Sie auf jedes geladene Objekt eine External ID. Sie trägt den Altschlüssel, löst Eltern-Kind-Beziehungen ohne Salesforce-IDs auf, macht Ladevorgänge per Upsert idempotent und einen erneuten Lauf sicher. Ohne sie riskiert jeder Neustart Dubletten.
• Wählen Sie den Abgleichsschlüssel, bevor Sie eine einzige Transformation schreiben. E-Mail, Steuernummer, Altsystem-ID oder ein zusammengesetzter Schlüssel. Der Profilbericht sagt, welcher davon in Ihren Daten wirklich eindeutig ist.

Halten Sie danach schriftlich fest, welche Automatisierung während des Ladens ausgesetzt ist und wer sie wieder einschaltet: Validierungsregeln, Trigger, Flows, Zuweisungsregeln, Dublettenregeln und E-Mail-Benachrichtigungen. Eine unbeabsichtigte Willkommensmail an 40.000 migrierte Kontakte ist die klassische Variante dieses Fehlers.

Wie viele Probeläufe, und was misst man?

Drei mindestens, in einer Sandbox, die der Produktion ähnelt.

1. Formlauf. Lädt es überhaupt? Feldtypen, Pflichtfelder, Auswahllistenwerte, Datensatztypen.
2. Korrektheitslauf. Prüfen Sie Beziehungen statt Zeilenzahlen. Stimmige Summen mit kaputten Elternsätzen sind der beruhigendste Fehlermodus dieser ganzen Disziplin.
3. Zeitlauf. Volles Volumen, Ende zu Ende gemessen, damit das Cutover-Fenster eine beobachtete Zahl ist und keine geschätzte.

Heben Sie jedes Fehlerprotokoll auf und behandeln Sie die Fehlerquote als Trend. Ist Lauf drei nicht deutlich sauberer als Lauf eins, konvergiert das Mapping nicht und der Go-live-Termin ist Fiktion.

Was gehört in den Cutover-Plan?

Ein Cutover-Plan ist eine Abfolge mit Uhrzeiten und einem Verantwortlichen je Zeile, keine Erzählung:

1. Quellsystem einfrieren und das Einfrieren den Nutzern ankündigen, nicht nur im Projektkanal.
2. Den finalen Delta-Extrakt ziehen.
3. Die Automatisierung von der vereinbarten Liste aussetzen.
4. Eltern vor Kindern laden, in der deklarierten Reihenfolge, in Wellen, die Fehler isolieren.
5. Automatisierung wieder aktivieren und Punkt für Punkt bestätigen.
6. Abgleichsabfragen laufen lassen: Mengen je Objekt, Waisenprüfungen, Stichproben auf Datensätze, die das Business vorab benannt hat.
7. Freigabe des Business auf diesen Datensätzen, danach Go oder No-go.
8. Auftauen, oder das Rollback ausführen.

Definieren Sie das Rollback vor der Cutover-Nacht, solange es eine Entwurfsfrage ist und keine Panik. Praktisch heißt das: das Altsystem bis zur Freigabe maßgeblich und lesend halten, und auf jedem migrierten Datensatz eine External ID behalten, damit ein gezieltes Löschen oder ein vollständiges Neuladen möglich bleibt. Besetzen Sie danach die ersten 48 bis 72 Stunden ordentlich, denn die Fragen von Tag eins zeigen, was der Profilbericht übersehen hat.

Wir führen Migrationen in unseren Salesforce-Projekten so durch, und das ist ein Grund, warum wir 20+ Organisationen produktiv gebracht haben. Wenn Sie gerade eine planen und vor der Terminzusage eine zweite Meinung zu den Daten wollen, fangen Sie hier an.

FAQ

Wie lange dauert eine Salesforce-Datenmigration?

Das Laden dauert Stunden. Das Projekt dauert so lange wie die Datenqualitätsentscheidungen, weshalb der Zeitlauf und nicht der Plan das Cutover-Fenster setzen sollte.

Sollen wir im Quellsystem oder während des Ladens bereinigen?

Wo möglich in der Quelle, dort wo die Verantwortlichen sitzen. Transformationsregeln in einem Ladeskript sind für das Business unsichtbar und werden nach dem Go-live neu verhandelt.

Brauchen wir External IDs, wenn wir nur einmal migrieren?

Ja. Sie machen Wiederholungsläufe sicher, lösen Beziehungen ohne Salesforce-IDs auf und ermöglichen später ein Rollback oder ein gezieltes Neuladen.

Wie viel Historie sollten wir mitnehmen?

Nur, was ein benannter Prozess oder Bericht nutzt. Fassen Sie den Rest zusammen und archivieren Sie ihn außerhalb des CRM: Historie ist in solchen Projekten die häufigste Quelle von Scope Creep.