Kundenkonten und Adressen in einen eigenen Shop migrieren

Was mit deinen Kunden wirklich passiert, wenn du den Shop wechselst

Wenn jemand beschließt, eine gemietete Plattform zu verlassen und auf einen eigenen Shop umzuziehen, dreht sich die erste sorgenvolle Frage fast nie um Produkte. Sie dreht sich um Menschen. Müssen sich meine Kunden neu registrieren? Verliere ich ihre Adressen, ihre Bestellhistorie, die Punkte, die sie gesammelt haben? Komme ich mit dem Datenschutz in Konflikt, wenn ich vierzigtausend Datensätze von einem System ins andere kopiere?

Die ehrliche Antwort hat zwei Hälften. Der größte Teil eines Kundendatensatzes zieht sauber um, und die Teile, die das nicht tun, sind vorhersehbar, klein und beherrschbar. Eines kann wirklich nicht mitkommen, das Passwort, und ich erkläre weiter unten, warum das kein Scheitern ist, sondern genau das richtige Ergebnis. Das Geld, das ein Kunde bei dir liegen hat, Guthaben, Treuepunkte, ein Gutschein, ist der eine Bereich, in dem Nachlässigkeit echten Schaden anrichtet, also bekommt er die meiste Sorgfalt. Dieser Beitrag ist die vollständige, ehrliche Aufstellung, 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 geht tief auf den Kunden.

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 ganze Sinn der Sache, und es ist der rote Faden durch alles, was folgt.

Die Felder, die sauber mitkommen

Fang mit der guten Nachricht an, denn sie ist der größte Teil des Datensatzes. Ein Kundenprofil ist im Kern eine Sammlung einfacher Felder, und einfache Felder kopieren sich ohne Drama von einem System ins andere. Die Arbeit steckt im richtigen Zuordnen, nicht im Umziehen.

Das kommt bei jeder Migration, die ich mache, sauber mit.

Feld	Kommt mit	Hinweis
Name	Ja	Vorname und Nachname, oder ein einzelnes Namensfeld
Mailadresse	Ja	Der Schlüssel, der alles verbindet
Telefonnummer	Ja	Nummer für Rechnung und für die Lieferung
Rechnungsadresse	Ja	Straße, Ort, PLZ, Land
Lieferadressen	Ja	Oft mehrere pro Kunde
Firma und UID Nummer	Ja	Wichtig für B2B Konten
Bestellzuordnung	Ja	Jede Bestellung hängt am Kunden
Anlagedatum des Kontos	Ja	Hält Treue und Kundendauer ehrlich
Kundengruppen und Tags	Ja	Händler, Großkunde, VIP und so weiter
Status der Werbeeinwilligung	Ja	Mit Zeitstempel und Quelle, siehe unten

Jede Plattform gibt diese Felder heraus, entweder über einen Export als Tabelle oder über ihre Schnittstelle für Entwickler. Der Kundenexport von Shopify enthält Vorname und Nachname, Mailadresse, Telefon, die Standardadresse samt Firmenfeld, den Steuerstatus, die Spalten zur Werbeeinwilligung und die Tags.¹ WooCommerce, das auf WordPress aufsetzt, gibt jeden Kunden über seine Entwicklerschnittstelle heraus, mit Mailadresse, Namen, Anlagedatum, einem Kennzeichen, ob jemals bezahlt wurde, und vollständigen Objekten für Rechnung und Lieferung samt Firma, Straße, Ort, Bezirk, PLZ, Land und Telefon.² Magento und die anderen erzählen dieselbe Geschichte in anderen Worten.

Auf der Seite von Solidus landen diese Daten in zwei Modellen. Der Kunde wird zu einem Benutzerdatensatz, und jede Adresse wird zu einer Spree::Address, die Namen, zwei Straßenzeilen, Ort, PLZ und Telefon speichert und am Benutzer sowie an jeder Bestellung hängt.³ Ein Detail zeigt, wie sehr solche Dinge driften: Das aktuelle Solidus führt ein einzelnes Namensfeld auf der Adresse und hat die getrennten Spalten für Vorname und Nachname stillgelegt,³ also gehört zum Zuordnen die Entscheidung, wie eine Plattform, die den Namen teilt, einen Shop füllt, der ihn zusammenführt. Nichts davon ist schwer. Es ist eine sorgfältige Übersetzung zwischen zwei Datenmodellen, geprüft durch Zählen.

Warum Passwörter nicht mitkommen, und warum das gut so ist

Das Passwort ist das eine Feld, das nicht mit dem Kunden umziehen kann, und es hilft zu verstehen, warum genau.

Ein sauber gebauter Shop speichert nie das Passwort, das du eintippst. Er speichert einen Einweg Hash davon: das Passwort durch eine absichtlich langsame mathematische Funktion geschickt, mit einem eindeutigen zufälligen Salt vermischt, sodass der gespeicherte Wert selbst von denen, die den Shop betreiben, nicht wieder ins Passwort zurückverwandelt werden kann. Die OWASP Leitlinie zur Passwortspeicherung ist da deutlich: Passwörter dürfen nie im Klartext liegen, zu jedem gehört ein eindeutiger Salt, und das Hashen ist genau deshalb der richtige Weg, weil es in nur eine Richtung läuft.⁴ Meldet sich ein Kunde an, hasht der Shop das Eingetippte und vergleicht die beiden Hashes. Das echte Passwort muss er nie kennen, und das ist der Punkt.

Daraus folgen zwei Dinge für eine Migration. Erstens ist der gespeicherte Hash für jedes andere System nutzlos, denn jede Plattform verwendet ihr eigenes Hashverfahren, ihre eigenen Parameter und ihre eigenen Salts. Shopify nutzt einen Ansatz, Magento speichert einen Hash samt Salt und einer Versionsmarke und ist über die Zeit von SHA256 auf Argon2id gewechselt,⁵ ein neueres Verfahren, und ein eigener Shop nutzt wieder etwas Modernes. Ein Hash nach einem Rezept lässt sich mit einem anderen nicht prüfen. Zweitens ist es selbst in dem seltenen Fall, in dem du die Datenbank besitzt und einen Hash kopieren könntest, schlechte Praxis, einen alten schwachen Hash in einen neuen Shop zu schleppen. Der Rat von OWASP für einen alten Hash lautet, ihn beim nächsten Login des Kunden durch einen frischen Hash des echten Passworts zu ersetzen,⁴ was nur geht, sobald er es eintippt.

Der saubere Weg ist also, das Passwort gar nicht umzuziehen. Im neuen Shop existiert jedes Konto mit seinem Profil, seinen Adressen und seiner Bestellhistorie, aber ohne brauchbares Passwort, und der Kunde setzt es beim ersten Besuch neu. Das geht auf zwei Arten: eine kurze Willkommensseite, auf der er ein neues Passwort wählt, oder eine Anmeldung, die ihm einen einmaligen Link schickt und Passwörter ganz überspringt. Shopify sagt klar, dass du Kundenpasswörter nicht aus einem anderen Shop übernehmen kannst und die Kunden einladen musst, neue zu vergeben.¹ Das gilt für jede ehrliche Migration, es ist keine Marotte einer einzigen Plattform.

Als Verlust erzählt, klingt das schlecht. Ehrlich erzählt, ist es ein Geschenk. Es ist der eine Moment, in dem du das alternde Hashverfahren deiner alten Plattform in Rente schicken und deinen ganzen Kundenstamm in einem Schritt auf ein modernes Verfahren heben kannst, ohne dass je jemand sein altes Passwort ins neue System tippt. Richtig machen musst du nicht die Technik, sondern die Ankündigung. Den Kunden muss vor der Umstellung gesagt werden, dass der Shop umzieht und dass sie beim ersten Besuch ein neues Passwort setzen. Ein Zurücksetzen, mit dem niemand rechnet, fühlt sich wie ein Einbruch an. Ein angekündigtes Zurücksetzen fühlt sich wie eine Neueröffnung an.

Guthaben, Treuepunkte und Gutscheine sind Geld, keine Metadaten

Wenn mich an einer Kundenmigration ein Teil nachts wachhält, dann sind es nicht Adressen oder 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 haben jedes Recht, zu erwarten, dass es den Umzug unangetastet übersteht. Lass eine Lieferadresse fallen, und der Kunde tippt sie in zehn Sekunden neu. Lass zweitausend Treuepunkte im Wert von zwanzig Euro fallen, und du hast jemandem Geld genommen, der dir vertraut hat, was beides ist, eine Beschwerde und, je nachdem, wie das Guthaben verkauft wurde, eine Verbindlichkeit, die du weiter schuldest.

Guthaben bekommen deshalb ihr 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. Zähl es zusammen. Importiere jedes Guthaben in den neuen Shop als Gutschrift auf das passende Konto. Zähl den neuen Shop zusammen. Die beiden Summen müssen vor dem Livegang auf den Cent stimmen, und jede Abweichung wird bis zum einzelnen Konto verfolgt, nie weggerundet oder ignoriert. Wo ein Guthaben nicht mitkommen kann, etwa ein Gutschein, der an ein Programm gebunden ist, das dir nicht folgt, wird es mit dem Kunden abgerechnet, nicht stillschweigend gelöscht. Dann sagst du es den Leuten: Deine Punkte, dein Guthaben und deine Gutscheine sind mitgekommen, hier ist dein Stand, so gibst du ihn aus. Geld, das leise und korrekt umzieht, bringt dir trotzdem Wohlwollen, wenn du es laut aussprichst.

Bewertungen und was Kunden geschrieben haben

Kunden hinterlassen mehr als Geld und Adressen. Sie hinterlassen Bewertungen, Sterne, Fragen und Antworten, Merklisten und manchmal 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 Kundenkennung zuordnet, sodass eine Bewertung ihren Verfasser, ihr Datum und ihre Sterne behält. Der einzige Haken sind Bewertungen an Produkten, die es nicht mehr gibt, die dieselbe Entscheidung brauchen wie alte Bestellungen: dem Nachfolgeprodukt zuordnen oder in Rente schicken. Diese Inhalte wieder zu verknüpfen lohnt sich, 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

Von allen Feldern, die sauber mitkommen, verdient eines eine eigene Erwähnung, denn es leise zu verlieren ist der Fehler, der aus einer Migration ein rechtliches Problem 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 aufzubewahren: 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 weg, den du bräuchtest, falls eine Behörde oder der Kunde je fragt. Nimm also den ganzen Einwilligungsnachweis mit, den Status, den Zeitstempel, die Quelle und den Wortlaut, nicht bloß den Schalter. Jede Plattform, die die Einwilligung hält, hält auch diese Angaben, und deine Aufgabe bei der Migration ist, sie am Kunden zu belassen, statt sie auf ein Kennzeichen zu plätten. Richtig gemacht, stärkt der Umzug sogar deine Lage, denn der Einwilligungsnachweis, der über eine Plattform und drei Marketing Apps verstreut war, liegt nun an einem Ort, der dir gehört.

Das Recht zieht mit den Daten um, es beginnt nicht neu

Kundendaten von einem System ins andere zu verschieben fühlt sich an, als müsste es eine frische Runde an Einwilligungen und Hinweisen auslösen. Meist tut es das nicht, und zu verstehen, warum, hält den Umzug rechtmäßig und ruhig zugleich.

Du bist weiter dasselbe Unternehmen, bedienst dieselben Kunden, aus denselben Gründen. Im Datenschutz bleibst du der Verantwortliche, der Zweck der Verarbeitung hat sich nicht geändert, und damit ändert sich auch die Rechtsgrundlage für die Daten nicht.⁷ Bestellhistorie, die du führst, um Verträge zu erfüllen und steuerliche Pflichten zu wahren, bleibt auf dieser Grundlage. Eine Werbeeinwilligung bleibt eine Einwilligung. Was sich ändert, ist die Software, und die Software ist ein Auftragsverarbeiter, der auf deine Weisung handelt, weshalb deine Plattform, dein Hoster und ich jeweils einen schriftlichen Vertrag zur Auftragsverarbeitung mit dir brauchen.⁸ Vier Punkte machen den Umzug sauber. Minimiere beim Umziehen: Das ist der Moment, Felder fallen zu lassen, 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öschbegehren, das mitten in der Migration eintrifft, damit ein Kunde, der vergessen werden wollte, nicht leise im neuen Shop wiedergeboren wird.¹⁰ Aktualisiere den Datenschutzhinweis dort, 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, dass die alte Kopie gelöscht wird.

Dahinter steckt ein tieferer Vorteil, und er ist der eigentliche Grund, den eigenen Shop zu besitzen. Auf einer gemieteten Plattform liegen deine Kundendaten über die Plattform und eine Reihe von Apps verteilt, jede davon eine eigene Firma mit einer eigenen Kopie. Ein eigener Solidus Shop hält sie bei dir, in einer Datenbank, die du kontrollierst, in Österreich 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 bevor du zu einer Migration kommst, gilt dieselbe Disziplin schon bei der Wahl, wem du die Daten überhaupt anvertraust, was ich in Dienstleister prüfen, bevor sie deine Compliance untergraben behandle.

Der praktische Weg, Schritt für Schritt

Zusammengesetzt ist eine Kundenmigration eine kurze, gut geprobte Abfolge, keine einzelne beängstigende Umstellung.

Zuerst exportieren. Zieh die Kunden aus der alten Plattform, über einen Tabellenexport oder über ihre Entwicklerschnittstelle. Hast du einen großen Stamm, rechne damit, dass diese Schnittstellen gedrosselt sind: Die Plattform lässt deine Anfragen mit einer festen Rate ab und bremst dich jenseits davon,¹¹ also kommen vierzigtausend Kunden in geplanten Gruppen über Stunden heraus, nicht in einem ungeduldigen Schwung. Zweitens zuordnen. Entscheide, wie jedes alte Feld ein Feld im neuen Shop füllt, samt der Namensfrage von oben und 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 irgendetwas 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 falten, als wäre es eine weitere Spalte. Ist es nicht.

Ein durchgerechnetes Beispiel: ein Linzer Wohnhandel mit 40.000 Kunden

Lass es mich an einem erfundenen Unternehmen greifbar machen. Haberl Wohnen verkauft Wohnaccessoires aus Linz unter haberlwohnen.example, auf Shopify, und ist dem entwachsen. Es hat 40.000 Kundenkonten, davon halten etwa 9.000 Treuepunkte, und es führt ein Guthabenprogramm für Retouren. Elke führt den Laden 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.

Elke 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 einmal. 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 Elke hat das von Anfang an eingeplant.

Die Guthaben werden als eigene Inventur behandelt. 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, deren Retouren noch liefen. Beide Summen werden auf die einzelnen Konten exportiert, in den neuen Shop als Gutschrift 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 Elkes Team findet es und korrigiert es, statt mit den Schultern zu zucken, denn vierzig Cent falsch auf einem Konto heißt, dass die Methode auf allen nicht vertrauenswürdig ist.

Die Einwilligung kommt vollständig 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 Elke die Einwilligung auch nach dem Umzug nachweisen kann. Die anderen 16.400 behalten ihren Status ebenso, sodass niemand, der widersprochen hat, leise wieder aufgeweckt 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 Elke 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 Willkommensseite, auf der der Kunde ein Passwort setzt oder einen einmaligen Anmeldelink anfordert, und landet in einem Konto, das ihn schon kennt. Das Supportpostfach bleibt ruhig, weil nichts von dem, was passiert ist, überraschend war.

Was du den Kunden sagst, und wann

Der Unterschied zwischen einer Migration, die Kunden kaum bemerken, und einer, die dein Postfach flutet, liegt fast ausschließlich in der Kommunikation, und sie hat zwei strenge Regeln.

Die erste Regel ist, die Servicenachricht von jeder Werbung zu trennen. Kontoinhabern zu sagen, 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 "schau dir unser neues Sortiment an" ist Werbung, und das darf nur an jene gehen, deren Einwilligung du sorgsam mitgenommen hast. Faltest du den Gutschein in die Servicenachricht, hast du aus einer Nachricht, die alle bekommen dürfen, eine gemacht, die die meisten nicht bekommen dürfen, und das ist die Art selbstverschuldeter Wunde, die ein Unternehmen zur Anzeige bringt.

Die zweite Regel ist, es den Leuten vorher zu sagen, nicht hinterher. Die Willkommensseite, die ein Passwort setzt, soll etwas sein, das die Kunden erwartet haben, weil du es ihnen eine Woche früher gesagt hast, keine verschlossene Tür, gegen die sie laufen, wenn sie sich anmelden wollen. Im Voraus gesagt, liest sich ein Passwort Reset als sorgfältige Neuerö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 ganze 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 danebenliegen darf. Sorg 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.

Footnotes

1. Shopify Help Center, Kundenlisten importieren und exportieren (Kundenpasswörter lassen sich nicht per CSV übernehmen, Kunden müssen eingeladen werden, neue zu vergeben, CSV Spalten für Name, Mailadresse, Telefon, Standardadresse, Firma, Steuerstatus, Werbeeinwilligung und Tags), geprüft November 2026, https://help.shopify.com/de/manual/customers/import-export-customers ↩ ↩² ↩³ ↩⁴

2. WooCommerce, REST API Dokumentation, Customers (Kundeneigenschaften wie email, first_name, last_name, date_created, is_paying_customer und die Objekte billing und shipping, die Eigenschaft password ist als write only markiert), geprüft November 2026, https://developer.woocommerce.com/docs/apis/rest-api/v3/customers/ ↩

3. Solidus, core/app/models/spree/address.rb (Spree::Address speichert Name, Adresszeilen, Ort, PLZ und Telefon für Benutzer und Bestellungen, firstname und lastname sind als ignored columns stillgelegt), solidusio/solidus auf GitHub, geprüft November 2026, https://github.com/solidusio/solidus/blob/main/core/app/models/spree/address.rb ↩ ↩² ↩³

4. OWASP, Password Storage Cheat Sheet (Passwörter nur als gesalzene Einweghashes speichern, nie im Klartext, Argon2id als erste Wahl, einen alten Hash beim nächsten Login durch einen frischen ersetzen), geprüft November 2026, https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html ↩ ↩²

5. Magento Open Source, lib/internal/Magento/Framework/Encryption/Encryptor.php (Passwort gespeichert als Hash, Salt und eine Versionsmarke, verbunden durch ein Trennzeichen, Hashversionen umfassen SHA256 und Argon2id), magento/magento2 auf GitHub, geprüft November 2026, https://github.com/magento/magento2/blob/2.4-develop/lib/internal/Magento/Framework/Encryption/Encryptor.php ↩

6. DSGVO, Artikel 7 (Bedingungen für die Einwilligung: der Verantwortliche muss nachweisen können, dass die betroffene Person eingewilligt hat), EUR-Lex, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679 ↩ ↩²

7. DSGVO, Artikel 6 (Rechtmäßigkeit der Verarbeitung), EUR-Lex, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679 ↩

8. DSGVO, Artikel 28 (Auftragsverarbeiter: die Verarbeitung durch einen Auftragsverarbeiter muss auf einem schriftlichen Vertrag beruhen), EUR-Lex, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679 ↩

9. DSGVO, Artikel 5 (Grundsätze, darunter die Datenminimierung: personenbezogene Daten müssen dem Zweck angemessen und auf das notwendige Maß beschränkt sein), EUR-Lex, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679 ↩

10. DSGVO, Artikel 17 (Recht auf Löschung), EUR-Lex, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679 ↩

11. Shopify, API usage: rate limits (die Limits der Admin API werden mit einem Leaky Bucket Verfahren durchgesetzt, Anfragen werden jenseits der dauerhaften Rate gedrosselt), geprüft November 2026, https://shopify.dev/docs/api/usage/rate-limits ↩ ↩²