So gelingt eine Salesforce-Datenmigration wirklich

Kurze Antwort: Eine Salesforce-Datenmigration entscheidet sich in der Datenqualitatsphase, 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. Fehlschlage lassen sich auf fruher umgangene Entscheidungen zuruckfuhren:

• Kein benannter Verantwortlicher fur eine Datendomane, also konnte niemand eine Regel freigeben.
• Dubletten, die alle sahen und zu deren Auflosung 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 dafur, Datenqualitat nach vorn zu ziehen.

Was heisst Profilierung hier konkret?

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

• Fullgrad je Feld. Ein Feld, das in 4% der Datensatze gefullt ist, ist kein Feld, sondern ein Gerucht.
• Eindeutige Werte gegen die Ziel-Auswahlliste. Hier werden "Prospect", "prospect" und "PROSPECT " zu drei Werten und einer Diskussion.
• Dublettenquote auf dem geplanten Abgleichsschlussel. Messen Sie sie, bevor Sie den Schlussel wahlen, nicht danach.
• Waisenquote je Beziehung. Kindsatze ohne auflosbaren Elternsatz bestimmen Ladereihenfolge und Fehlermenge.
• Auflosungsquote der Eigentumer. Welcher Anteil verweist auf einen aktiven Salesforce-Benutzer, und wer bekommt den Rest.
• Datumsbereiche und Ausreisser. Datensatze mit 1900 oder 2099 laufen im ungunstigsten 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 grossten Hebelwirkung und die, die die meisten Plane auslassen. Jeder Datensatz hat vier mogliche Schicksale, und nur eines davon ist teuer:

1. Migrieren. Er wird operativ gebraucht, in Salesforce, von einem benannten Prozess.
2. Zusammenfassen. Die Historie zahlt als Summe, nicht Zeile fur Zeile. Laden Sie einen Rollup, keine zehn Jahre Transaktionen.
3. Archivieren. Im Warehouse oder als Export fur die Compliance aufbewahren, ausserhalb des CRM.
4. Stehen lassen. Das Altsystem fur einen definierten Zeitraum lesend verfugbar halten, damit Leute nachschlagen konnen.

Vernunftige Standards: abgeschlossene Datensatze alter als Ihr Reporting-Horizont werden zusammengefasst, Kontakte ohne Aktivitat und ohne erreichbare E-Mail werden archiviert, und Freitextfelder, uber die niemand berichtet, kommen gar nicht mit. Jeder ausgeschlossene Datensatz spart Mapping-Aufwand, Validierungsfehler, Testfalle und Support nach dem Go-live. Weniger Umfang ist die gunstigste Leistungsverbesserung, die es gibt.

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

Eine Zeile je Zielfeld, und jede Zeile tragt: 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 verlauft:

• Setzen Sie auf jedes geladene Objekt eine External ID. Sie tragt den Altschlussel, lost Eltern-Kind-Beziehungen ohne Salesforce-IDs auf, macht Ladevorgange per Upsert idempotent und einen erneuten Lauf sicher. Ohne sie riskiert jeder Neustart Dubletten.
• Wahlen Sie den Abgleichsschlussel, bevor Sie eine einzige Transformation schreiben. E-Mail, Steuernummer, Altsystem-ID oder ein zusammengesetzter Schlussel. Der Profilbericht sagt, welcher davon in Ihren Daten wirklich eindeutig ist.

Halten Sie danach schriftlich fest, welche Automatisierung wahrend 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 Probelaufe, und was misst man?

Drei mindestens, in einer Sandbox, die der Produktion ahnelt.

1. Formlauf. Ladt es uberhaupt? Feldtypen, Pflichtfelder, Auswahllistenwerte, Datensatztypen.
2. Korrektheitslauf. Prufen Sie Beziehungen statt Zeilenzahlen. Stimmige Summen mit kaputten Elternsatzen 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 geschatzte.

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 gehort in den Cutover-Plan?

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

1. Quellsystem einfrieren und das Einfrieren den Nutzern ankundigen, 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 fur Punkt bestatigen.
6. Abgleichsabfragen laufen lassen: Mengen je Objekt, Waisenprufungen, Stichproben auf Datensatze, die das Business vorab benannt hat.
7. Freigabe des Business auf diesen Datensatzen, danach Go oder No-go.
8. Auftauen, oder das Rollback ausfuhren.

Definieren Sie das Rollback vor der Cutover-Nacht, solange es eine Entwurfsfrage ist und keine Panik. Praktisch heisst das: das Altsystem bis zur Freigabe massgeblich und lesend halten, und auf jedem migrierten Datensatz eine External ID behalten, damit ein gezieltes Loschen oder ein vollstandiges Neuladen moglich bleibt. Besetzen Sie danach die ersten 48 bis 72 Stunden ordentlich, denn die Fragen von Tag eins zeigen, was der Profilbericht ubersehen hat.

Wir fuhren Migrationen in unseren Salesforce-Projekten so durch, und das ist ein Grund, warum wir 16+ 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 Datenqualitatsentscheidungen, weshalb der Zeitlauf und nicht der Plan das Cutover-Fenster setzen sollte.

Sollen wir im Quellsystem oder wahrend des Ladens bereinigen?

Wo moglich in der Quelle, dort wo die Verantwortlichen sitzen. Transformationsregeln in einem Ladeskript sind fur das Business unsichtbar und werden nach dem Go-live neu verhandelt.

Brauchen wir External IDs, wenn wir nur einmal migrieren?

Ja. Sie machen Wiederholungslaufe sicher, losen Beziehungen ohne Salesforce-IDs auf und ermoglichen spater 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 ausserhalb des CRM: Historie ist in solchen Projekten die haufigste Quelle von Scope Creep.