Wo Datenarchitektur auf die Wirklichkeit trifft

🌐 Auch in 19 Sprachen

English · Español · 日本語 · Português (Brasil) · Français · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)

Von KI übersetzt. Noch nicht von der Community geprüft. Auf Englisch lesen Dieser Abschnitt hat sich im Englischen geändert und wurde noch nicht neu übersetzt. (21)

Kapitel 10 von Data Architect, Teil 2: Architektur im großen Maßstab. Zurück: Integration und Datenbewegung.

Bei der Migration trifft Datenarchitektur auf die Wirklichkeit. Jede Entscheidung zu Modellierung, Qualität, Stammdaten und Volumen, die wir getroffen haben, wird an dem Tag geprüft, an dem Millionen Datensätze auf einmal ankommen. Und eine Migration, die „erfolgreich geladen“ hat, kann trotzdem ein Fehlschlag sein: falsche Eigentümer, gebrochene Beziehungen, duplizierte Kunden, eine Million Willkommens-E-Mails, gesperrte Datensätze oder ein Umstellungswochenende, dem die Zeit ausgeht.

Image generated with AI. ⟲

Every CTA scenario has a legacy system to bring across, and the candidate has to say how the data comes in, how it’s cleaned and how it’s de-duplicated. This chapter is that answer, from the source extract to the moment the old system stops mattering, and then the copies that keep going. ⟲

One example runs through all five modules: Steve Trucking retiring RouteDesk, its old dispatch tool, with eight years and about 5 million deliveries. What comes into Salesforce, how it’s prepared, how it loads, what the automation does about it, and the weekend it all happens. Then the other direction: Salesforce, now the system of record, keeping Snowflake’s copy in step. ⟲

Die Ideen in diesem Kapitel

• Migration is a quality project first, and a migration is an integration with an end. ⟲
• Migrate, archive or discard, and know why every class of data moves, or doesn’t. ⟲
• Prepare outside, then load the result: a preparation data store, the raw source kept, no step that loses fidelity, and three sets of keys (the source’s, the transformations, Salesforce’s). ⟲
• The model sets the load order, and every child finds its parent by a key, never by a name. ⟲
• The Bulk API is the loading dock behind the bank, and the dock still needs a plan: insert before upsert, sort by parent, the load user, and the IDs brought back. ⟲
• Any time you turn automation off, you own that business logic not happening. The bypass is part of the original design, tested on and off and deployed long before it’s needed. ⟲
• Production cutover should be boring: rehearsed, run from a runbook, loaded early and hidden by sharing, with go/no-go and a rollback clock decided in advance. ⟲
• Beweisen Sie es auf vier Arten: Anzahlen, Summen, Stichproben und aggregierte Berichte.
• Getting data out isn’t leaving Salesforce. Migration has a defined start and end; synchronization is ongoing, and the mirror is never the master. ⟲

Der Weg durch dieses Kapitel

Fünf Module, jedes steht für sich.

1. Migration Is a Quality Project First. RouteDesk on the landscape; migrate, archive or discard; the preparation data store; Steve’s five steps; loading by keys; merged records and their children; three sets of keys. ⟲
2. Loading at Volume. The teller window and the loading dock; Bulk API 2.0 and 1.0; insert, update or upsert; sorting by parent; the load user; bringing the keys back; rehearsing the whole run. ⟲
3. Automation During the Load. The arrows a load sets off; don’t need it, simulate it, defer it; what a bypass looks like in Apex, flows and validation rules; sharing; the automation inventory. ⟲
4. Cutover Weekend. The runbook; Day −7, Day −1, Day 0 and the rollback point; locking users out; the four proofs; authority moves on Day 0. ⟲
5. Getting Data Out: Keeping Another System in Step. Salesforce stays the system of record; Snowflake needs a mirror. The ways out, PK chunking, keeping it current, a copy once or a copy forever. ⟲

Was Architekt:innen hier entscheiden

• Was überhaupt bewegt wird: migrieren, archivieren oder verwerfen, und warum.
• Wie die Daten tauglich gemacht werden, bevor sie ankommen, und wie jeder Datensatz bis zu seiner Quelle nachverfolgbar bleibt.
• Der Ladeplan: Reihenfolge, Schlüssel, Nebenläufigkeit, Identität und Eigentümerschaft.
• Was das Laden auslösen darf, und wie der Normalbetrieb zurückkommt.
• Wie die Umstellung durchgeführt und bewiesen wird, und wann Rollback keine Option mehr ist.
• Where migration ends, what keeps another system’s copy in step afterward, and who owns each value. ⟲

Über die Prüfung hinaus: KI beschleunigt die Analysehälfte einer Migration: Profiling, Zuordnung, Anomalieerkennung, das Schreiben der Skripte. Nutzen Sie sie Schritt für Schritt, mit jedem erzeugten Befehl nachverfolgt. Validierung, Abgleich und Go/No-Go bleiben deterministisch und in menschlicher Verantwortung. Jedes Modul endet damit, was KI ändert.

Weiterlesen

• Salesforce, General Guidelines for Data Loads (öffnet in einem neuen Tab) and Bulk API and Bulk API 2.0 Limits and Allocations (öffnet in einem neuen Tab), checked 2026-11-01. ⟲
• Salesforce, Best Practices for Deployments with Large Data Volumes (öffnet in einem neuen Tab), Winter ‘27, checked 2026-11-01. ⟲
• Der Kurs Integration Architect: Bulk (coming soon).

Next: Transactions, Concurrency, and Reliability ⟲