Angenommen, der Import meldet bei 8.000 CSV-Datensätzen keinen Fehler. Im neuen System fehlen trotzdem Ansprechpartner, Postleitzahlen haben ihre führende Null verloren und Aufträge stehen beim falschen Kunden. Der Import braucht neben einem Mengenvergleich auch eine Prüfung der Inhalte und Zuordnungen.

Ein Import überträgt Daten in ein bestehendes System. Bei einer Migration ändern sich oft zusätzlich Struktur und Bedeutung der Felder. Plane dafür einen wiederholbaren Probelauf, dessen Ergebnis fachlich verglichen werden kann. Der erste Versuch gehört in eine isolierte Testumgebung.

Erst das Dateiformat, dann die Feldzuordnung

Kläre Zeichencodierung, Trennzeichen und Anführungszeichen. Ein Komma innerhalb einer Anschrift darf keine neue Spalte beginnen. Ein Zeilenumbruch in einer Notiz darf keinen zusätzlichen Kontakt erzeugen. Die PostgreSQL-Dokumentation zu COPY beschreibt, wie CSV-Werte, Trennzeichen und leere beziehungsweise fehlende Inhalte behandelt werden. Andere Importwerkzeuge müssen auf ihre eigenen Regeln geprüft werden.

Importiere Postleitzahlen und Artikelnummern als Text, damit führende Nullen erhalten bleiben. Kontrolliere bereits die Quelldatei: Ein Tabellenprogramm kann diese Werte beim Öffnen in Zahlen umgewandelt haben.

Lege für jede Zielspalte die Herkunft fest. Wenn aus „Vorname“ und „Nachname“ ein Anzeigename entsteht, ist das eine Umwandlungsregel. Wenn ein unbekannter Status auf „offen“ gesetzt werden soll, ist das eine fachliche Entscheidung. Ungeklärte Werte sollten zunächst im Fehlerbericht landen, statt still passend gemacht zu werden.

Beziehungen müssen den Umzug mitmachen

Fiktives Beispiel: 300 Kunden und 900 Aufträge wechseln in ein neues Werkzeug. Die Kunden erhalten dort neue interne IDs. Der Import speichert deshalb die Beziehung zwischen alter und neuer Kundenkennung und verwendet sie beim Übertragen der Aufträge. Ein Vergleich nach Firmennamen würde schon bei zwei gleichnamigen Betrieben scheitern.

Prüfe nach dem Probelauf die Mengen pro Datentyp. Wie viele Datensätze wurden übernommen, übersprungen oder zurückgewiesen? Addiert muss das zum vorgesehenen Quellbestand passen. Kontrolliere zusätzlich Beziehungen und ausgewählte Inhalte: Gehören die Aufträge zum richtigen Kunden? Sind lange Notizen vollständig? Bleiben Zeitpunkte in der beabsichtigten Zeitzone verständlich?

Wähle Stichproben gezielt aus den schwierigen Fällen. Umlaute, leere Felder und historische Statuswerte sind dafür nützlicher als zehn fast identische Musterdatensätze. Für unveränderte Felder lassen sich zusätzlich automatisierte Vergleiche einrichten.

Wiederholen, ohne den Bestand zu verdoppeln

Ein korrigierter Import muss erneut laufen können. Vereinbare, ob dafür die Testdaten vollständig neu aufgebaut werden oder ob das Script vorhandene Datensätze anhand stabiler Schlüssel aktualisiert. Ein halber erster Lauf darf beim zweiten Versuch nicht zur unbemerkten Verdopplung führen.

Vor einem späteren produktiven Wechsel braucht es einen festgelegten Zeitpunkt und eine Entscheidung über zwischenzeitliche Änderungen. Wer darf im alten System noch schreiben? Werden diese Änderungen nachgezogen? Was ist der Rückweg, falls die Prüfung nach dem Wechsel scheitert?

Teste den Wiederherstellungsweg vor dem produktiven Wechsel. Die PostgreSQL-Dokumentation zur SQL-Sicherung erklärt das Erstellen und Einspielen solcher Sicherungen. Halte fest, wie lange der Rückweg dauert und welche seit dem Backup hinzugekommenen Daten dabei fehlen würden.

Die Leistung Daten importieren & migrieren enthält einen begrenzten Probelauf und einen Ablaufplan. Muss erst die Zielstruktur entstehen, ist Datenbank aufbauen & erweitern gesondert zu klären. Eine dauerhafte Synchronisation ist wiederum ein eigener Prozess, kein endlos wiederholter einmaliger Import.