Welche Altdaten gehören überhaupt in den neuen Shop?

„Wir migrieren alles" klingt zunächst nach der sichersten Entscheidung. Keine Bestellung geht verloren, jedes Kundenattribut bleibt erhalten und niemand muss später noch auf das alte System zugreifen.

In der Praxis kann eine vollständige Übernahme genau das Gegenteil bewirken: Das neue System startet mit großen Mengen unklarer, veralteter und teilweise datenschutzrechtlich nicht mehr erforderlicher Informationen. Das Zielmodell wird an historische Sonderfälle angepasst, die operativ längst keine Rolle mehr spielen. Migration, Tests und Betrieb werden aufwendiger.

Die bessere Frage lautet nicht:

Sondern:

Daten besitzen unterschiedliche Zwecke

Historische Commerce-Daten können mehrere Aufgaben erfüllen:

• aktueller operativer Prozess,
• Kundenservice,
• gesetzliche Aufbewahrung,
• Analyse und Reporting,
• Nachweis einer Einwilligung oder Vertragsbeziehung,
• Wiederbestellung,
• Personalisierung,
• Betrugs- oder Risikoprüfung,
• rein technische Historie.

Diese Zwecke erfordern nicht automatisch dieselbe Ablage.

Eine alte Bestellung kann für den Kundenservice relevant sein, muss aber nicht als vollständig bearbeitbarer Auftrag im neuen Shop erscheinen. Steuerrelevante Belege müssen aufbewahrt werden, gehören aber nicht zwingend in die operative Shopdatenbank. Ein aufgegebenes Trackingattribut besitzt möglicherweise überhaupt keinen legitimen künftigen Zweck.

Vier sinnvolle Migrationsklassen

1. Operativ vollständig migrieren

Daten werden als reguläre, weiter nutzbare Objekte in das neue System übernommen.

Geeignet für:

• aktive Produkte,
• aktuelle Kundenkonten,
• offene Bestellungen,
• laufende Abonnements oder Verträge,
• aktive Gutscheine,
• aktuelle Preis- und Bestandsinformationen.

2. Reduziert migrieren

Nur die für einen definierten Zweck erforderlichen Informationen werden übernommen.

Beispiel historische Bestellung:

• Bestellnummer,
• Datum,
• Gesamtbetrag,
• Positionen,
• Beleglink,
• Status.

Interne technische Events oder inzwischen irrelevante Zwischenstände bleiben draußen.

3. Read-only archivieren

Die Daten bleiben zugänglich, werden aber nicht in das operative Modell des neuen Shops übertragen.

Mögliche Formen:

• separates Archivsystem,
• schreibgeschützte Datenbank,
• exportierte Belege und strukturierter Index,
• API-Zugriff auf einen historischen Datenservice.

4. Bewusst löschen oder nicht übernehmen

Daten ohne weiteren Zweck, mit abgelaufener Aufbewahrung oder unklarer Rechtsgrundlage werden nicht migriert und nach einem kontrollierten Verfahren gelöscht.

Diese vier Klassen können pro Datentyp und Zeitraum unterschiedlich angewendet werden.

Historische Bestellungen sind ein gutes Beispiel

Kunden erwarten häufig, frühere Bestellungen im neuen Konto zu sehen. Daraus folgt jedoch nicht, dass jede historische Bestellung vollständig in das neue Shopware-Auftragsmodell importiert werden muss.

Zu klären ist:

• Wie viele Jahre sollen sichtbar sein?
• Braucht der Kunde nur Belege und Positionen oder auch alte Prozessdetails?
• Soll eine Wiederbestellung möglich sein?
• Was passiert, wenn alte Produkte nicht mehr existieren?
• Müssen Erstattungen auf alte Zahlungen noch möglich sein?
• Welche Informationen benötigt der Support?
• Wo liegen rechtssichere Originalbelege?

Oft ist eine reduzierte historische Ansicht sinnvoller als die Simulation eines vollständig lebendigen Altauftrags im neuen System.

Kundenkonten benötigen eine Identitätsstrategie

Bei alten Kundenkonten stellen sich zusätzliche Fragen:

• Sind E-Mail-Adressen noch aktuell?
• Existieren Dubletten aus mehreren Shops?
• Dürfen Passworthashes übernommen werden?
• Muss ein Passwort-Reset erzwungen werden?
• Welche Einwilligungen sind nachweisbar?
• Welche inaktiven Konten werden überhaupt noch benötigt?
• Wie werden Gastbestellungen behandelt?

Ein technisch möglicher Import aller Konten kann zu einer großen Zahl unzustellbarer E-Mails, doppelter Identitäten und unklarer Einwilligungsstände führen.

Eine saubere Strategie kann beispielsweise vorsehen:

• nur aktive Kunden der letzten Jahre operativ zu übernehmen,
• ältere Bestellhistorien über E-Mail-Verifikation zugänglich zu machen,
• Dubletten vor oder während der Aktivierung zusammenzuführen,
• Passwörter kontrolliert neu setzen zu lassen,
• Marketingeinwilligungen nur mit belastbarem Nachweis zu übernehmen.

Nicht jedes alte Feld braucht ein neues Feld

Altsysteme enthalten oft hunderte Zusatzattribute, deren Zweck nicht mehr bekannt ist. Der Reflex, für jedes Feld eine Entsprechung im Zielsystem anzulegen, konserviert technische Unklarheit.

Für jedes Attribut sollten vier Fragen beantwortet werden:

1. 1Welcher fachliche Zweck bestand ursprünglich?
2. 2Wird dieser Zweck heute noch benötigt?
3. 3Ist das Feld für aktuelle Prozesse oder nur für Historie relevant?
4. 4Muss der Wert im neuen System strukturiert verfügbar sein?

Mögliche Entscheidungen:

• in ein standardisiertes Zielfeld mappen,
• in ein neues bewusst modelliertes Feld übernehmen,
• nur im Archiv speichern,
• in einen lesbaren Hinweis transformieren,
• nicht übernehmen.

Aufbewahren heißt nicht operativ verfügbar halten

Rechtliche Aufbewahrungspflichten werden häufig als Begründung genutzt, sämtliche Daten in das neue operative System zu laden. Aufbewahrung und operative Nutzung sind jedoch unterschiedliche Anforderungen.

Ein Archiv kann für bestimmte Daten besser geeignet sein, weil es:

• Änderungen verhindert,
• Originalzustände nachvollziehbar hält,
• Zugriffe stärker begrenzt,
• Löschfristen differenziert abbildet,
• das operative Shopmodell nicht belastet.

Die konkrete rechtliche Bewertung muss zum Unternehmen und Datentyp passen. Technisch sollte die Architektur jedenfalls ermöglichen, Aufbewahrung, Kundenansicht und operative Verarbeitung getrennt zu behandeln.

Datenminimierung verbessert auch die Architektur

Weniger Daten zu migrieren ist nicht nur ein Datenschutzvorteil. Es reduziert:

• Mappingaufwand,
• Importzeit,
• Testumfang,
• Speicher- und Suchlast,
• Sicherheitsrisiko,
• Zahl der Sonderfälle,
• Abhängigkeit vom alten Datenmodell.

Das bedeutet nicht, wertvolle Historie leichtfertig zu löschen. Es bedeutet, jeden Datentyp seinem tatsächlichen künftigen Zweck zuzuordnen.

Ein Migrationskatalog schafft Klarheit

Für größere Migrationen empfiehlt sich ein expliziter Datenkatalog.

Beispiel:

Dieser Katalog verbindet Fachbereich, Datenschutz, Migration und Betrieb.