Im CRM steht eine neue Telefonnummer. Im Shop liegt noch die alte. Ein nächtlicher Abgleich schreibt den alten Wert zurück ins CRM. Technisch hat die Übertragung funktioniert. Fachlich hat sie die richtige Angabe überschrieben.

Lege für die Telefonnummer fest, wo sie künftig gepflegt wird. Darf der Shop Änderungen ins CRM schreiben, das CRM zurück in den Shop oder beides? Bei zwei erlaubten Richtungen brauchst du zusätzlich eine Regel für widersprüchliche Angaben.

Lege die Richtung pro Feld fest

Du kannst mit einer Übertragung von Quelle A zu Ziel B beginnen und nur die vereinbarten Felder einbeziehen. Notizen, die das Team ausschließlich im CRM pflegt, bleiben dabei unangetastet.

Fiktives Beispiel für einen kleinen Shop: Die Kundennummer kommt aus dem Shop und dient im CRM als externe Referenz. Die zuständige Vertriebsmitarbeiterin wird ausschließlich im CRM gepflegt. Lieferadressen aus einzelnen Bestellungen überschreiben nicht automatisch die allgemeine Kontaktanschrift. Für jedes dieser Felder gelten andere Regeln.

Schreibe diese Regeln in eine Feldzuordnung. Neben Quell- und Zielname gehören Format, Leerwert und Änderungsberechtigung hinein. „Leer“ kann bedeuten, dass eine Information fehlt, oder dass sie ausdrücklich gelöscht wurde. Ohne diese Unterscheidung löscht der Abgleich entweder zu viel oder stellt bewusst entfernte Angaben immer wieder her.

Namen sind keine stabilen Kennungen

Zwei Kontakte können gleich heißen. Eine Firma kann umbenannt werden. Verwende deshalb, soweit vorhanden, die unveränderliche Kennung des Quellsystems und speichere deren Beziehung zur Zielkennung. Das gilt auch für Produktvarianten: Der Produktname allein unterscheidet keine Größen oder Ausführungen.

Die PostgreSQL-Dokumentation zu Constraints beschreibt, wie eindeutige Schlüssel und Beziehungen in einer Datenbank abgesichert werden. Für die Planung folgt daraus die Frage, welche Eindeutigkeit dein Zielsystem tatsächlich durchsetzt. Ein bloßes Textfeld mit einer Nummer verhindert noch keine doppelte Zuordnung.

Wenn der Bestand bereits Dubletten enthält, starte nicht sofort einen Vollabgleich. Lege zuerst fest, wie unklare Zuordnungen in einer Prüfliste landen. Ein Namensvergleich mit hoher Ähnlichkeit ist noch keine Freigabe, zwei Kundenvorgänge zusammenzuführen.

Erstlauf und spätere Änderungen

Beim Erstlauf geht es um den vorhandenen Bestand, danach um Änderungen. Prüfe, ob die Schnittstelle Ergebnisse über mehrere Seiten liefert. Ein erfolgreicher Abruf der ersten Seite sagt nichts darüber, ob alle Datensätze angekommen sind. Mengenabgleich und Stichproben gehören zum Probelauf.

Bei Begrenzungen der API darf der Prozess nicht pausenlos neu anfragen. Die HTTP-Antwort 429 weist auf zu viele Anfragen hin und kann eine Wartezeit enthalten. Der Wiederanlauf muss am bekannten Stand fortsetzen, statt den gesamten Bestand immer wieder anzulegen.

Lass jeden Lauf nach neu angelegten, geänderten, unveränderten und ungeklärten Datensätzen aufschlüsseln. Vergleiche die Summe mit dem abgearbeiteten Bestand und weise die ungeklärten Fälle einer Person zur Prüfung zu.

Die Leistung Daten zwischen Systemen abgleichen setzt vorhandene Schnittstellen und eine vereinbarte Richtung voraus. Für einen einmaligen Systemwechsel ist Datenmigration die passendere Aufgabe. Ein dauerhafter Abgleich braucht zusätzlich Pflege, wenn sich Felder oder Schnittstellen ändern.