Shopware Kundendaten Migration: planen und durchführen (Operations Guide)

Problem Statement

```mermaid graph LR A[Input] --> B[Process] B --> C[Output] ``` ```typescript // Configuration Example export const config = { environment: 'production', apiEndpoint: 'https://api.example.com', timeout: 5000, retries: 3 }; ```

Shopware Kundendaten Migration klingt im Pitch oft nach „Export/Import“. In der Praxis ist es ein Operations-Thema. Weil Kundendaten in Shopware nicht nur aus customer bestehen. Da hängen Adressen, Salutations, Länder/States, Newsletter-Opt-ins, Passwort-Hashes, Gastbestellungen, Kundenrollen, B2B-Felder, Duplicate-Matching und DSGVO-Löschkonzepte dran. Und dann kommt der Klassiker: Der Shop bleibt live, während du migrierst. Also brauchst du eine Delta-Strategie. Sonst verlierst du Registrierungen, Adressänderungen oder Newsletter-Abmeldungen.

Ich sehe drei typische Fehlerbilder. Erstens: man migriert „alles“ in einem Rutsch ohne Messpunkte. Zweitens: man unterschätzt die Referenzen (z. B. address_id zeigt ins Leere). Drittens: man macht die Validierung nur auf Datensatzanzahl. Das ist zu wenig. In Operations zählt Konsistenz, Performance und Auditierbarkeit. Und ja, auch die Ladezeit im Account-Bereich kann nach einer Migration plötzlich kippen, wenn Indizes fehlen oder Datenqualität schlecht ist.

Warum ist das wichtig? Weil Kundendaten die Grundlage für Login, Checkout, Support und CRM-Sync sind. Wenn nach Go-Live 3–5% der Kunden nicht einloggen können, hast du kein „Bug“, du hast ein Umsatz- und Trust-Problem. Das lässt sich vermeiden. Aber nur, wenn du Migration wie ein Deployment behandelst: mit Staging, Deltas, Checks, Rollback-Plan und Metriken.

Technical Background

Shopware (v6) basiert auf Symfony und Doctrine, mit einem relationalen Datenmodell. Kundendaten werden über Entity-Definitionen abgebildet und landen in Tabellen wie customer, customer_address und diversen Mapping-/Index-Tabellen. Interessanterweise ist nicht die reine Datenmenge der Stressor, sondern die Kombination aus Referenzen, Constraints und Laufzeitpfaden (Login, Checkout, Account, Admin-Listing, API-Reads).

Ein Detail, das ich bei Migrationen immer wieder sehe: UUIDs. Shopware nutzt UUIDs als Primärschlüssel (binary(16) in MySQL/MariaDB). Wenn du aus einem System mit Integer-IDs kommst, brauchst du eine saubere ID-Abbildung. Sonst bricht dir das später in Integrationen (ERP/CRM) oder beim Debugging das Genick. Ich empfehle eine Mapping-Tabelle, die alte IDs auf neue UUIDs mappt, dauerhaft. Nicht nur temporär während der Migration.

Dann DSGVO. Kundendaten sind nicht „nur Daten“. Du musst nachweisbar sein: Welche Felder importierst du? Welche Rechtsgrundlage? Wie gehst du mit Opt-in/Opt-out um? Und: Migration heißt oft, dass du historische Daten zusammenziehst, die im Altsystem in Schattenfeldern lagen. Wenn du die blind importierst, hast du ein Compliance-Risiko. Das ist kein juristischer Vortrag hier. Aber operativ heißt das: Feldliste, Transformationslog, Lösch-/Anonymisierungsstrategie.

Performance-seitig sind Kundendaten relevant, weil viele Queries an ihnen hängen. Benchmarks, die ich als gesund empfinde: Login-Flow (API/Storefront) sollte serverseitig im Bereich <200–300ms bleiben, wenn Cache warm ist. Admin-Listing für Kunden darf bei größeren Datenbeständen ruhig länger sein, aber wenn Pagination plötzlich Sekunden braucht, fehlen meist Indizes oder du hast extreme Duplikate in Adressen. Bei Migrationen habe ich schon mehrfach gesehen, dass ein fehlender Index auf einem Foreign Key die DB-CPU dauerhaft hochzieht. Übrigens: Das fällt oft erst nach Go-Live auf, weil Staging-Daten zu klein waren.

Zur Orientierung, hier eine vereinfachte Migrations-Flow-Skizze als Mermaid-Diagramm. Sie zeigt die operative Reihenfolge: Extract, Transform, Load, Validierung, Delta, Cutover. (Im echten Leben hängt noch viel mehr dran.)