Kundenkonten und Adressen in einen eigenen Shop migrieren

Was mit deinen Kunden geschieht, wenn der Shop umzieht

Wer eine gemietete Plattform verlässt und auf einen eigenen Shop wechselt, sorgt sich zuerst selten um Produkte. Die Sorge gilt den Menschen. Müssen sich meine Kunden neu anmelden? Gehen ihre Adressen verloren, ihre Bestellungen, die Punkte, die sie über Jahre gesammelt haben? Gerate ich mit dem Datenschutz in Schwierigkeiten, wenn ich vierzigtausend Datensätze von einem System ins nächste trage?

Die ehrliche Antwort hat zwei Seiten. Der weitaus größte Teil eines Kundendatensatzes zieht sauber mit, und die wenigen Teile, die das nicht tun, sind absehbar, klein und beherrschbar. Nur eines kann wirklich nicht mitkommen, das Passwort, und ich lege unten dar, warum das kein Versagen ist, sondern der Ausgang, den du dir wünschen solltest. Das Geld dagegen, das ein Kunde bei dir liegen hat, Guthaben, Treuepunkte, ein Gutschein, ist die eine Stelle, an der Schlamperei echten Schaden anrichtet, und die bekommt die größte Sorgfalt. Dieser Beitrag ist die vollständige, ehrliche Bestandsaufnahme: was mitkommt, was nicht, und der Plan für jeden Fall. Der übergeordnete Beitrag, was sich beim Shopwechsel übertragen lässt und was nicht, zeichnet das große Bild. Dieser hier nimmt sich den Kunden im Detail vor.

Ich baue den neuen Shop auf Solidus, einem quelloffenen Shop Framework auf Ruby on Rails, und der fertige Shop samt seinen Daten gehört der Kundin. Dieses Eigentum ist der eigentliche Zweck der Übung, und es trägt alles, was folgt.

Die Felder, die sauber mitkommen

Beginnen wir mit der guten Nachricht, denn sie macht den Löwenanteil aus. Ein Kundenprofil ist im Kern nichts als eine Reihe schlichter Felder, und schlichte Felder lassen sich ohne Aufhebens von einem System ins andere kopieren. Die Mühe steckt im sauberen Zuordnen, nicht im Verschieben.

Folgendes kommt bei jeder Migration, die ich durchführe, verlässlich mit.

Jede Plattform rückt diese Felder heraus, über einen Export als Tabelle oder über ihre Schnittstelle für Entwickler. Der Kundenexport von Shopify liefert Vorname und Nachname, Mailadresse, Telefon, die Standardadresse mit Firmenfeld, den Steuerstatus, die Spalten zur Werbeeinwilligung und die Tags.¹ WooCommerce, das auf WordPress beruht, gibt jeden Kunden über seine Entwicklerschnittstelle aus, mit Mailadresse, Name, Anlagedatum, einem Kennzeichen, ob je bezahlt wurde, und vollständigen Objekten für Rechnung und Lieferung samt Firma, Straße, Ort, Region, PLZ, Land und Telefon.² Magento und der Rest erzählen dasselbe mit anderen Begriffen.

Bei Solidus landen diese Daten in zwei Modellen. Aus dem Kunden wird ein Benutzerdatensatz, aus jeder Adresse eine Spree::Address, die Name, zwei Straßenzeilen, Ort, PLZ und Telefon speichert und am Benutzer wie an jeder Bestellung hängt.³ Ein kleines Detail zeigt, wie solche Dinge auseinanderlaufen: Das aktuelle Solidus pflegt ein einzelnes Namensfeld auf der Adresse und hat die getrennten Spalten für Vorname und Nachname außer Dienst gestellt,³ also gehört zum Zuordnen die Entscheidung, wie eine Plattform, die den Namen trennt, einen Shop befüllt, der ihn vereint. Schwer ist das nicht. Es ist eine sorgfältige Übersetzung zwischen zwei Datenmodellen, kontrolliert durch Zählen.

Warum Passwörter nicht mitkommen, und warum das richtig ist

Das Passwort ist das eine Feld, das nicht mit dem Kunden umziehen kann, und es lohnt zu verstehen, woran das genau liegt.

Ein sauber gebauter Shop speichert niemals das Passwort, das du eingibst. Er speichert einen Einweghash davon: das Passwort durch eine bewusst langsame mathematische Funktion geschickt, mit einem eindeutigen zufälligen Salt verrührt, sodass der gespeicherte Wert selbst von den Betreibern des Shops nicht wieder zum Passwort wird. Die OWASP Leitlinie zur Passwortspeicherung ist unmissverständlich: Passwörter gehören nie in den Klartext, zu jedem gehört ein eindeutiger Salt, und gehasht wird gerade deshalb, weil der Vorgang nur in eine Richtung läuft.⁴ Meldet sich ein Kunde an, hasht der Shop die Eingabe und vergleicht die beiden Hashes. Das echte Passwort muss er nie kennen, und darauf kommt es an.

Zwei Folgen ergeben sich für die Migration. Erstens ist der gespeicherte Hash für jedes fremde System wertlos, weil jede Plattform ihr eigenes Hashverfahren, ihre eigenen Parameter und ihre eigenen Salts nutzt. Shopify geht einen Weg, Magento speichert einen Hash samt Salt und Versionsmarke und ist mit der Zeit von SHA256 auf Argon2id gewechselt,⁵ ein neueres Verfahren, und ein eigener Shop setzt wieder auf etwas Modernes. Ein Hash nach dem einen Rezept lässt sich mit einem anderen nicht prüfen. Zweitens ist es selbst im seltenen Fall, dass dir die Datenbank gehört und du einen Hash kopieren könntest, schlechte Praxis, einen alten schwachen Hash in einen neuen Shop zu verfrachten. OWASP rät, einen alten Hash beim nächsten Login des Kunden durch einen frischen Hash des echten Passworts zu ersetzen,⁴ was erst geht, sobald er es eingibt.

Der saubere Weg heißt also: das Passwort gar nicht erst umziehen. Im neuen Shop existiert jedes Konto mit Profil, Adressen und Bestellhistorie, aber ohne brauchbares Passwort, und der Kunde vergibt es beim ersten Besuch neu. Dafür gibt es zwei Wege: eine kurze Begrüßungsseite, auf der er ein neues Passwort wählt, oder eine Anmeldung, die ihm einen einmaligen Link schickt und Passwörter ganz umgeht. Shopify stellt klar, dass sich Kundenpasswörter nicht aus einem anderen Shop übernehmen lassen und die Kunden eingeladen werden müssen, neue zu setzen.¹ Das trifft auf jede ehrliche Migration zu und ist keine Eigenart einer einzelnen Plattform.

Als Verlust erzählt, klingt das übel. Ehrlich betrachtet, ist es ein Geschenk. Es ist der Moment, in dem du das in die Jahre gekommene Hashverfahren der alten Plattform verabschieden und deinen gesamten Kundenstamm in einem Zug auf ein modernes Verfahren heben kannst, ohne dass je jemand sein altes Passwort im neuen System eingibt. Richtig hinbekommen musst du nicht die Technik, sondern die Ankündigung. Den Kunden ist vor der Umstellung zu sagen, dass der Shop umzieht und dass sie beim ersten Besuch ein neues Passwort setzen. Ein Zurücksetzen, mit dem niemand gerechnet hat, wirkt wie ein Einbruch. Ein angekündigtes Zurücksetzen wirkt wie eine Wiedereröffnung.

Guthaben, Treuepunkte und Gutscheine sind Geld, keine Metadaten

Wenn mich an einer Kundenmigration etwas nachts beschäftigt, dann sind es nicht Adressen und nicht Passwörter. Es sind Guthaben.

Guthaben, Treuepunkte, Gutscheinwerte und Geldbörsenstände sind keine Profilfelder. Es ist Geld, das deine Kunden bei dir liegen haben, und sie dürfen zu Recht erwarten, dass es den Umzug unberührt übersteht. Fällt eine Lieferadresse weg, tippt der Kunde sie in zehn Sekunden neu. Fallen zweitausend Treuepunkte im Wert von zwanzig Euro weg, hast du jemandem Geld genommen, der dir vertraut hat, und das ist beides, eine Beschwerde und, je nachdem, wie das Guthaben verkauft wurde, eine Verbindlichkeit, die weiter besteht.

Guthaben bekommen deshalb ein eigenes kleines Projekt, getrennt vom Profilimport, und es läuft wie eine Inventur. Exportiere jedes Guthaben aus dem alten System samt dem Kunden, dem es gehört. Bilde die Summe. Importiere jedes Guthaben als Gutschrift auf das passende Konto im neuen Shop. Bilde dort erneut die Summe. Beide Summen müssen vor dem Livegang auf den Cent übereinstimmen, und jede Abweichung wird bis zum einzelnen Konto verfolgt, niemals weggerundet oder übersehen. Wo ein Guthaben nicht mitkommen kann, etwa ein Gutschein an ein Programm gebunden, das dir nicht folgt, wird es mit dem Kunden abgerechnet, nicht klammheimlich gelöscht. Danach sagst du es den Leuten: Deine Punkte, dein Guthaben und deine Gutscheine sind mit umgezogen, hier ist dein Stand, so löst du ihn ein. Geld, das leise und korrekt umzieht, bringt dir trotzdem Wohlwollen, wenn du es ausdrücklich erwähnst.

Bewertungen und was Kunden verfasst haben

Kunden hinterlassen mehr als Geld und Adressen. Sie hinterlassen Bewertungen, Sterne, Fragen und Antworten, Merklisten und bisweilen Fotos. Diese Inhalte hängen meist an einem Kunden und einem Produkt, und sie lassen sich fast immer exportieren und im neuen Shop wieder verknüpfen, indem man über die Mailadresse oder die alte Kundennummer zuordnet, sodass eine Bewertung ihren Verfasser, ihr Datum und ihre Sterne behält. Der einzige Haken sind Bewertungen zu Produkten, die es nicht mehr gibt, und die verlangen dieselbe Entscheidung wie alte Bestellungen: dem Nachfolgeprodukt zuordnen oder ausmustern. Der Aufwand lohnt, denn eine Produktseite mit Jahren echter Bewertungen verkauft besser als eine leere, und diese Bewertungen sind die Arbeit deiner Kunden, nicht das Eigentum der alten Plattform.

Die Werbeeinwilligung ist der Nachweis, den du nicht verlieren darfst

Unter allen Feldern, die sauber mitkommen, verdient eines eine eigene Erwähnung, denn es stillschweigend zu verlieren ist der Fehler, der aus einer Migration ein Rechtsproblem macht.

Die Werbeeinwilligung ist kein Ja Nein Kennzeichen. Nach der DSGVO musst du nachweisen können, dass eine Person eingewilligt hat, und das heißt, den Nachweis zu bewahren: dass sie zugestimmt hat, wann, mit welchem Wortlaut und durch welche Handlung.⁶ Ein nacktes "angemeldet: ja", in den neuen Shop kopiert, wirft genau den Beleg fort, den du im Ernstfall gegenüber einer Behörde oder dem Kunden bräuchtest. Nimm also den gesamten Einwilligungsnachweis mit, Status, Zeitstempel, Quelle und Wortlaut, nicht bloß den Schalter. Jede Plattform, die die Einwilligung hält, hält auch diese Angaben, und deine Aufgabe ist es, sie bei der Migration am Kunden zu lassen, statt sie auf ein Kennzeichen einzudampfen. Richtig gemacht, stärkt der Umzug deine Lage sogar, denn der Nachweis, der über eine Plattform und drei Marketing Apps verteilt war, liegt danach an einem Ort, der dir gehört.

Das Recht zieht mit den Daten um, es fängt nicht neu an

Kundendaten von einem System ins andere zu verschieben fühlt sich an, als müsste es eine neue Runde Einwilligungen und Hinweise auslösen. Meist ist das nicht so, und zu verstehen, warum, hält den Umzug rechtssicher und zugleich entspannt.

Du bist weiterhin dasselbe Unternehmen, bedienst dieselben Kunden aus denselben Gründen. Im Datenschutz bleibst du der Verantwortliche, der Zweck der Verarbeitung ändert sich nicht, und damit bleibt auch die Rechtsgrundlage dieselbe.⁷ Bestellhistorie, die du zur Erfüllung von Verträgen und zur Wahrung steuerlicher Pflichten führst, bleibt auf dieser Grundlage. Eine Werbeeinwilligung bleibt eine Einwilligung. Was sich ändert, ist die Software, und die Software ist ein Auftragsverarbeiter auf deine Weisung, weshalb deine Plattform, dein Hoster und ich jeweils einen schriftlichen Vertrag zur Auftragsverarbeitung mit dir brauchen.⁸ Vier Punkte halten den Umzug sauber. Minimiere unterwegs: Jetzt ist der Moment, Felder loszuwerden, die du nicht mehr brauchst, statt tote Daten in ein frisches System zu schleppen, genau das verlangt der Grundsatz der Datenminimierung.⁹ Erfülle jedes Löschverlangen, das mitten in der Migration eintrifft, damit ein Kunde, der vergessen werden wollte, nicht leise im neuen Shop wieder aufersteht.¹⁰ Bringe den Datenschutzhinweis dort auf Stand, wo er die alte Plattform und den alten Hoster als Empfänger nennt. Und nach dem letzten Export schließt du das alte Konto und verlangst schriftlich die Löschung der alten Kopie.

Dahinter liegt ein tieferer Vorteil, und er ist der wahre Grund, den eigenen Shop zu besitzen. Auf einer gemieteten Plattform liegen deine Kundendaten verteilt über die Plattform und eine Reihe von Apps, jede ein eigenes Unternehmen mit einer eigenen Kopie. Ein eigener Solidus Shop hält sie bei dir, in einer Datenbank, die du kontrollierst, in Deutschland oder der EU. Das ist besser für das Recht und besser für dich, und es ist das Thema von wem deine Geschäftsdaten eigentlich gehören. Lange vor der Migration gilt dieselbe Disziplin schon bei der Frage, wem du die Daten überhaupt anvertraust, die ich in Dienstleister prüfen, bevor sie deine Compliance untergraben behandle.

Der praktische Weg, Schritt für Schritt

Zusammengefügt ist eine Kundenmigration eine kurze, gut geprobte Abfolge, keine einzelne angstbesetzte Umstellung.

Zuerst exportieren. Hol die Kunden aus der alten Plattform, über einen Tabellenexport oder über ihre Entwicklerschnittstelle. Bei einem großen Stamm rechne damit, dass diese Schnittstellen gedrosselt sind: Die Plattform lässt deine Anfragen mit fester Rate ab und bremst dich darüber hinaus,¹¹ also kommen vierzigtausend Kunden in geplanten Gruppen über Stunden heraus, nicht in einem ungeduldigen Schwung. Zweitens zuordnen. Lege fest, wie jedes alte Feld ein Feld im neuen Shop füllt, samt der Namensfrage von oben und der Frage, welche Tags zu Kundengruppen werden. Drittens in die Benutzer und Adressmodelle von Solidus importieren, in Gruppen, mit intaktem Einwilligungsnachweis und intaktem Anlagedatum.³ Viertens durch Zählen prüfen: die Zahl der Kunden, die Zahl der Adressen, die Zahl der eingewilligten Kontakte und vor allem die Guthabensummen müssen zur Quelle passen, bevor etwas live geht. Fünftens den Passwortablauf starten, damit jedes Konto bereit ist, dass sein Besitzer ein neues Passwort setzt oder einen Anmeldelink anfordert. Sechstens die Nachricht senden, die den Kunden sagt, dass der Shop umgezogen ist und was beim ersten Besuch zu tun ist.

Gespeicherte Karten sind etwas anderes als Passwörter und gehören deinem Zahlungsanbieter, nicht dem Shop, also folgen sie eigenen Regeln, und ich behandle sie in Zahlungstoken und gespeicherte Karten migrieren. Lass niemanden "und die gespeicherten Karten" in den Kundenimport mogeln, als wäre es eine weitere Spalte. Ist es nicht.

Ein durchgerechnetes Beispiel: ein Leipziger Wohnhandel mit 40.000 Kunden

Ich mache es an einem erfundenen Unternehmen greifbar. Lindenau Wohnen verkauft Wohnaccessoires aus Leipzig unter lindenauwohnen.example, auf Shopify, und ist dem Laden entwachsen. Es zählt 40.000 Kundenkonten, davon halten rund 9.000 Treuepunkte, und es führt ein Guthabenprogramm für Retouren. Sabine leitet den Betrieb und wechselt auf einen eigenen Solidus Shop, um ihre Daten zu besitzen und eine Händlerseite für Einrichter aufzubauen. Niemand hier ist echt, und jede Zahl ist erfunden, um die Methode zu zeigen.

Sabine exportiert ihre 40.000 Kunden. Weil Shopify begrenzt, wie schnell eine App Daten ziehen darf,¹¹ läuft ihr Export in Gruppen über einen Nachmittag statt auf einen Schlag. Der Export trägt Namen, Mailadressen, Telefonnummern, Adressen, das Firmenfeld, das ihre Händler ausgefüllt haben, die Spalten zur Werbeeinwilligung samt Zeitstempeln, Tags und Steuerstatus.¹ Er trägt kein einziges Passwort, genau wie Shopify es dokumentiert,¹ und Sabine hat das von Anfang an eingeplant.

Die Guthaben behandelt sie als eigene Inventur. Das alte System meldet 2,1 Millionen offene Treuepunkte, einlösbar zu hundert Punkten je Euro, also eine Verbindlichkeit von 21.000 Euro, dazu 6.480 Euro Guthaben bei 540 Kunden mit laufenden Retouren. Beide Summen werden auf die einzelnen Konten exportiert, als Gutschrift in den neuen Shop importiert und abgeglichen. Der neue Shop muss 21.000 Euro Punktewert und 6.480 Euro Guthaben melden, auf den Cent, vor dem Start. Ein Konto liegt wegen eines alten Rundungsfehlers vierzig Cent daneben, und Sabines Team findet es und bessert es aus, statt mit den Schultern zu zucken, denn vierzig Cent falsch auf einem Konto heißen, dass die Methode auf keinem Konto zu trauen ist.

Die Einwilligung kommt lückenlos mit. Die 23.600 Kunden, die E Mails zugestimmt haben, behalten nicht nur das Ja, sondern das Datum und den Wortlaut, dem sie zugestimmt haben,⁶ sodass Sabine die Einwilligung auch nach dem Umzug nachweisen kann. Die übrigen 16.400 behalten ihren Status ebenso, sodass niemand, der widersprochen hat, leise wieder geweckt wird.

Beim Umschalten existieren alle 40.000 Konten im neuen Shop mit ihren Adressen, ihrer Bestellhistorie und ihrem abgeglichenen Guthaben, markiert als noch nicht aktiviert. Eine Woche davor hat Sabine eine Servicenachricht an jeden Kontoinhaber geschickt: Der Shop zieht in ein neues Zuhause, hier ist das Datum, beim ersten Besuch setzt du ein neues Passwort, und deine Punkte und dein Guthaben sind mitgekommen. Die Nachricht ist eine Information über das Konto, also geht sie an alle 40.000, nicht nur an jene, die Werbung angenommen haben. Am Tag selbst führt der erste Besuch auf eine kurze Begrüßungsseite, auf der der Kunde ein Passwort setzt oder einen einmaligen Anmeldelink anfordert, und landet in einem Konto, das ihn bereits kennt. Das Supportpostfach bleibt ruhig, weil nichts von dem, was geschehen ist, überraschend kam.

Was du den Kunden sagst, und wann

Der Unterschied zwischen einer Migration, die Kunden kaum spüren, und einer, die dein Postfach flutet, liegt fast vollständig in der Kommunikation, und sie kennt zwei strenge Regeln.

Die erste Regel lautet, die Servicenachricht von jeder Werbung zu trennen. Kontoinhabern mitzuteilen, dass der Shop umzieht und dass sie ein neues Passwort setzen, ist eine Information über ihr Konto, und sie darf und soll an alle gehen, ob sie Werbung angenommen haben oder nicht. Ein Eröffnungsgutschein oder ein "sieh dir unser neues Sortiment an" ist Werbung, und das darf nur an jene gehen, deren Einwilligung du sorgfältig mitgenommen hast. Faltest du den Gutschein in die Servicenachricht, machst du aus einer Nachricht, die alle bekommen dürfen, eine, die die meisten nicht bekommen dürfen, und das ist die Art selbstverschuldeter Wunde, die ein Unternehmen zur Anzeige bringt.

Die zweite Regel lautet, es den Leuten vorher zu sagen, nicht hinterher. Die Begrüßungsseite, die ein Passwort setzt, soll etwas sein, das die Kunden erwartet haben, weil du es ihnen eine Woche früher angekündigt hast, keine verschlossene Tür, gegen die sie beim Anmelden laufen. Im Voraus gesagt, liest sich ein Passwort Reset als sorgfältige Wiedereröffnung. Ohne Warnung ausgelöst, liest sich dieselbe Mail als Sicherheitsvorfall. Die Technik ist dieselbe. Nur der Zeitpunkt unterscheidet sich, und der Zeitpunkt ist die eigentliche Arbeit.

Resets sind in Ordnung, Guthaben ist heilig

Wenn du zwei Dinge mitnimmst, dann diese. Ein erzwungenes Zurücksetzen des Passworts ist kein Schaden, es ist Hygiene, und mit ein wenig Vorwarnung kostet es dich fast nichts und stellt jeden Kunden auf ein modernes, sichereres Fundament. Guthaben ist das Gegenteil: Es ist Geld, es ist Vertrauen, und es ist das eine, bei dem eine Migration nicht einmal ein kleines bisschen danebengreifen darf. Sorge dafür, dass das Zurücksetzen angekündigt und die Guthaben abgeglichen sind, dann folgt der Rest des Kundendatensatzes, die Namen, die Adressen, die Einwilligung, die Historie, sauber in einen Shop, der endlich dir gehört.