Daten zwischen Formaten konvertieren — ohne verrückt zu werden
Ein praktischer Leitfaden für Datenmigration zwischen CSV, JSON, YAML und XML — die echte Pipeline für Migrationen und Integrationen.
Man kennt das. Der Datenbank-Export liefert CSV. Die neue API will JSON. Die Deployment-Konfiguration braucht YAML. Das Legacy-System versteht nur XML. Und irgendwie ist man derjenige, der alles miteinander verbinden soll.
Datenformat-Konvertierung klingt einfach — bis man es tatsächlich macht. So baut man eine echte Pipeline, die nicht auseinanderfällt.
Das Szenario: Eine echte Migration
Angenommen, man migriert Nutzerdaten von einem alten System in ein neues. Die Ausgangslage:
- Quelle: CSV-Export aus der alten Datenbank (10.000 Zeilen, 15 Spalten)
- API-Schicht: Das neue System akzeptiert JSON über REST API
- Config-Dateien: Deployment-Einstellungen in YAML
- Legacy-Integration: Ein Partnersystem, das weiterhin XML-Feeds erwartet
Vier Formate. Ein Datensatz. Los geht's.
Schritt 1: CSV zu JSON — Vom Export zur API
Die CSV sieht so aus:
id,name,email,plan,created
1,Alice,alice@example.com,pro,2024-03-15
2,Bob,bob@example.com,free,2024-06-22
In JSON konvertiert erhält man strukturierte Daten, die die API verarbeiten kann:
[
{
"id": 1,
"name": "Alice",
"email": "alice@example.com",
"plan": "pro",
"created": "2024-03-15"
}
]
Aufpassen bei: Felder mit Kommas in Anführungszeichen, leere Werte die null sein sollten statt leere Strings, und Datumsformate die sich von Zeile zu Zeile unterscheiden. Diese Bugs tauchen bei Zeile 4.738 auf, wenn man dachte, alles funktioniert.
Schritt 2: JSON zu YAML — Für Konfigurationsdateien
Das Deployment braucht YAML-Konfiguration. Die Datenstruktur ist dieselbe — nur die Syntax ist anders:
users:
- id: 1
name: Alice
email: alice@example.com
plan: pro
created: "2024-03-15"
YAML ist besser lesbar für Config-Dateien — deshalb nutzen es Kubernetes, Docker Compose und CI/CD-Pipelines. Aber es ist Whitespace-sensitiv: ein falscher Einzug und das Deployment crasht um 2 Uhr nachts.
Schritt 3: JSON zu XML — Für Legacy-Systeme
Das Partnersystem von 2015 braucht XML. Nein, die upgraden ihre API nicht. Ja, man muss es trotzdem unterstützen.
<users>
<user>
<id>1</id>
<name>Alice</name>
<email>alice@example.com</email>
</user>
</users>
Die Konvertierung ist unkompliziert, aber XML hat Eigenheiten — Attribute vs. Elemente, Namespace-Anforderungen, Schema-Validierung. Der XML-Konverter übernimmt die strukturelle Transformation; die Geschäftslogik liegt bei einem selbst.
Schritt 4: Alles mit dem JSON-Formatter validieren
In jeder Phase: JSON formatieren und validieren. Eine falsche Klammer, ein überflüssiges Komma, ein nicht-escaptes Anführungszeichen — und der Import verschluckt stillschweigend Datensätze oder crasht komplett.
Bevor konvertierte Daten an eine API gesendet werden: formatieren und die Struktur visuell prüfen. Fünf Sekunden Formatierung sparen fünf Stunden Debugging von "warum fehlen 200 Datensätze."
Häufige Stolperfallen bei Datenmigrationen
Encoding-Probleme: CSV aus Excel unter Windows ist möglicherweise Windows-1252, nicht UTF-8. Deutsche Umlaute in Kundennamen werden zu Fragezeichen. Immer zuerst das Encoding prüfen.
Typkonvertierung: CSV behandelt alles als Strings. 001 in CSV wird zu 1 in JSON. Postleitzahlen, Telefonnummern und ID-Felder mit führenden Nullen sind die üblichen Opfer.
Verschachtelte Daten: CSV ist flach. JSON ist verschachtelt. Man muss entscheiden, wie address_street, address_city, address_zip in CSV zu einem address-Objekt in JSON wird.
Null vs. leer: Ist eine leere CSV-Zelle null, "", oder soll der Key ganz weggelassen werden? Vor dem Start definieren, nicht wenn man den Bug findet.
Das Pipeline-Muster
Für jede Datenmigration sieht der Workflow so aus:
- Export — aus dem Quellsystem (meist CSV oder SQL-Dump)
- Konvertieren — ins Arbeitsformat (CSV zu JSON)
- Transformieren — Struktur anpassen (Felder umbenennen, Objekte verschachteln, Typen korrigieren)
- Validieren — Ausgabe prüfen (formatieren und prüfen)
- Konvertieren — ins Zielformat (YAML oder XML)
- Import — ins Zielsystem
Die Tools übernehmen Schritte 2, 4 und 5. Schritte 1, 3 und 6 sind eigener Code. Die Trennung von "Konvertierung" und "Transformation" hält alles handhabbar.
Datenmigrationen sind nie so einfach, wie sie im Planungsdokument aussehen. Aber mit zuverlässigen Konvertierungstools bei jedem Schritt verbringt man seine Zeit mit den echten Problemen — Geschäftslogik, Sonderfälle und Datenqualität — statt mit Format-Syntax zu kämpfen.