Was bei einer Shop-Migration mit den Kundenpasswörtern passiert

Es gibt eine Frage, die in Migrationsprojekten regelmäßig zu spät gestellt wird: Können sich unsere Kunden nach dem Umzug noch anmelden? Wird sie erst kurz vor dem Go-Live gestellt, bleibt oft nur die unangenehme Antwort — alle Passwörter zurücksetzen, am Tag der Umschaltung, mit allem, was das für den Support bedeutet.

Passwörter kann niemand „mitnehmen"

Ein Shop speichert keine Passwörter, sondern Prüfsummen davon — sogenannte Hashes. Aus einem Hash lässt sich das Passwort nicht zurückrechnen; beim Login wird die Eingabe erneut durch dasselbe Verfahren geschickt und das Ergebnis verglichen. Das ist genau so gewollt.

Für eine Migration heißt das: Man kann Passwörter nicht „umziehen", sondern nur die Hashes übernehmen — und das funktioniert ausschließlich dann, wenn das Zielsystem dasselbe Verfahren nachvollziehen kann, mit dem sie im Altsystem erzeugt wurden.

Wenn dir jemand anbietet, im Zuge der Migration allen Kunden „ihr Passwort" per E-Mail zuzuschicken, ist etwas grundsätzlich falsch: Dann wurden die Passwörter im Klartext oder umkehrbar verschlüsselt gespeichert. Das ist kein Migrationsthema mehr, sondern ein Sicherheitsvorfall.

Magento 1 auf Magento 2: in der Regel unproblematisch

Magento 2 speichert zu jedem Passwort-Hash mit, nach welchem Verfahren er erzeugt wurde, und kann deshalb auch ältere Verfahren aus Magento-1-Zeiten prüfen. Meldet sich ein Kunde nach dem Umzug zum ersten Mal an, wird sein Passwort gegen den alten Hash geprüft und anschließend im aktuellen Verfahren neu gespeichert.

Das Ergebnis ist der Idealfall: Deine Kunden merken vom Systemwechsel nichts, und der Bestand modernisiert sich nach und nach von selbst. Voraussetzung ist, dass die Hashes samt ihrer Verfahrenskennung vollständig übernommen werden — genau das ist beim Datenmapping festzulegen.

Systemwechsel zu Shopware: kommt darauf an

Wechselst du die Plattform, verwenden Quell- und Zielsystem in aller Regel unterschiedliche Verfahren. Shopware 6 kennt für diesen Fall einen Mechanismus für Alt-Hashes: Der ursprüngliche Hash wird in ein eigenes Feld übernommen, beim ersten erfolgreichen Login geprüft und danach durch einen aktuellen ersetzt.

Ob dieser Weg offensteht, hängt davon ab, ob für das Verfahren des Quellsystems eine passende Prüfung vorhanden ist. Das ist eine der ersten Fragen, die wir in der Bestandsaufnahme klären — und zwar bevor der Zeitplan steht, weil die Antwort den Ablauf des Go-Live verändert.

Wenn zurückgesetzt werden muss

Manchmal führt kein Weg daran vorbei. Dann entscheidet die Umsetzung darüber, ob es eine Randnotiz bleibt oder zum Ärgernis wird. Was sich bewährt hat:

• Vorher informieren, nicht hinterher. Eine Ankündigung ein paar Tage vor dem Umzug nimmt der Sache die Überraschung.
• Nicht alle Kunden gleichzeitig anschreiben. Zehntausende Mails in einer Stunde landen zuverlässig im Spam-Ordner und ruinieren nebenbei den Ruf deiner Absenderadresse. Besser in Etappen über mehrere Tage.
• Den Weg dort anbieten, wo er gebraucht wird: Wer sich mit dem alten Passwort anzumelden versucht, sollte nicht „Zugangsdaten falsch" lesen, sondern einen Hinweis auf den Umzug und einen direkten Link zur Neuvergabe.
• Aktive Kunden zuerst. Wer in den letzten Monaten bestellt hat, meldet sich als Erstes an — diese Gruppe sollte zuerst informiert sein.
• Den Support vorbereiten. Ein vorformulierter Textbaustein spart am Umzugstag mehr Zeit, als man denkt.

Ein Nebeneffekt, den man ruhig mitnehmen kann: Nach so einem Reset ist der Passwortbestand durchgehend auf aktuellem Stand — inklusive der Konten, die seit Jahren auf einem längst überholten Verfahren lagen.

Kurz gefasst

• Die Frage gehört in die Bestandsaufnahme, nicht in die Woche vor dem Go-Live.
• Innerhalb derselben Plattform lassen sich Hashes meist übernehmen.
• Beim Plattformwechsel hängt es am Verfahren des Quellsystems — das lässt sich vorab prüfen.
• Ein Reset ist kein Drama, wenn er vorbereitet, gestaffelt und verständlich kommuniziert wird.

Häufige Fragen