Alexander LuftVon Alexander Luft
JTL Service Partner Gold · Ahrensfelde bei Berlin · 25. Juli 2025 · 8 Min. Lesezeit
Kundenstammdaten-Tabelle links, JTL Wawi Kundenmaske rechts, Verbindungspfeil in der Mitte

Kundendaten und Logins bei JTL-Migration übernehmen: Was geht, was nicht — und wie du Duplikate vermeidest

Du hast 30.000, 50.000, vielleicht 80.000 Kundensätze im Altsystem. Jetzt steht der Wechsel zu JTL an. Die erste Frage lautet fast immer: Was passiert mit meinen Kunden? Können die sich nach dem Umzug noch einloggen? Müssen alle ihre Passwörter neu setzen? Gehen Bestellhistorie und Adressen verloren? Wir beantworten diese Fragen konkreter, als viele Händler erwarten.

Du willst wissen, was du wirklich übernehmen kannst — und was du besser neu aufsetzt?

Dieser Beitrag zeigt dir den genauen Stand aus unseren Kundenprojekten. Kein Marketing, keine Pauschalantworten. Nur das, was technisch funktioniert und was nicht.

Auf einen Blick

  • ✓Vlarom überträgt Stammdaten (Name, Adresse, E-Mail) per JTL-Ameise — das geht zuverlässig, wenn die Quelldaten sauber sind.
  • ✓Kundenpasswörter können bei keinem System direkt migriert werden: Oxid, Shopware, plentymarkets — jedes nutzt eigene Verschlüsselung. Vlarom setzt standardmäßig auf Passwort-Reset-Links, nicht auf Klartextversand.
  • ✓Doppelte Kundensätze entstehen fast immer dann, wenn ERP-Import und Shop-Sync ohne Abgleich-Logik parallel laufen — dieser Fehler lässt sich mit dem richtigen Timing vermeiden.

Vlarom weiß aus Migrations-Projekten: Der Moment, in dem ein Bestandskunde nach dem Shop-Wechsel keinen Zugang mehr bekommt und den Support anruft, ist einer der teuersten Momente einer Migration. Nicht wegen der Technik, sondern wegen des Vertrauensverlusts. Alexander Luft, Inhaber von Vlarom und JTL Service Partner Gold aus Ahrensfelde bei Berlin, plant die Kundendaten-Migration deshalb immer als eigenständigen Schritt mit klarer Kommunikations-Strategie, nicht als Anhang des Artikel-Imports.

Die harten Fakten: Was bei Kundendaten wirklich übertragbar ist

Kundendaten bestehen aus mehreren Schichten. Jede Schicht folgt eigenen Regeln. Stammdaten, Passwörter, Bestellhistorie und Login-Zugang funktionieren technisch völlig unterschiedlich. Wer das nicht trennt, plant eine Migration, die am Ende mehr Nacharbeit verursacht als nötig.

Aus eigenen Projektdaten: Bei einem Händler mit rund 80.000 Kundensätzen haben wir nur die Kunden der letzten 24 Monate importiert. Das waren knapp 18.000 aktive Datensätze. Der Rest blieb im Archiv-System. Der Initial-Sync lief dadurch sauber durch, statt tagelang zu hängen. (Branche: Elektrozubehör, anonymisiert)

Was du dir merken solltest, bevor du mit dem Import beginnst:

  • →Stammdaten — ja, vollständig übertragbar: Name, Adresse, E-Mail, Kundennummer: Alles, was in einer strukturierten Tabelle steht, übertragen wir per CSV und JTL-Ameise. Voraussetzung: Die Daten im Quellsystem sind sauber und ohne Sonderzeichen-Chaos.
  • →Passwörter — nein, technisch nicht möglich: Jedes Shopsystem verschlüsselt Passwörter anders. Oxid verwendet One-Way-Hashing mit individuellem Salt, plentymarkets MD5. JTL-Shop kann diese Hashes nicht lesen. Das ist keine Schwäche, sondern ein Sicherheitsmerkmal. Laut JTL-Forum-Diskussion (Thread 85828) führt kein Weg daran vorbei.
  • →Bestellhistorie — bedingt übertragbar: Historische Bestellungen lassen sich importieren, aber nur bis zu einem definierten Stichtag. Neue Bestellungen aus dem JTL-Shop landen direkt über den Connector in der Wawi. Wer beides parallel laufen lässt ohne klare Trennlinie, produziert Duplikate.
  • →Aktive Sessions und Warenkörbe — nicht übertragbar: Session-Tokens, aktive Warenkörbe und Merklisten bleiben im Altsystem zurück. Das ist unvermeidbar und lässt sich nur durch kurze Downtime-Fenster und gute Kundenkommunikation abfedern.

Die wichtigste Trennlinie: Was in einer Tabelle steht, übertragen wir. Was kryptografisch gesichert ist, nicht. Wer das von Anfang an klar kommuniziert, spart sich später viele Supportanfragen.

Zwei Fehler die fast jede Kundendaten-Migration komplizierter machen als nötig

Die technischen Hürden bei Kundendaten sind lösbar. Teuer werden Migrationen durch organisatorische Fehler. Aus unseren Projekten sehen wir zwei Muster immer wieder:

1

Kein Plan für Passwort-Reset vor dem Go-Live

Viele Händler merken erst nach dem Launch, dass ihre Bestandskunden sich nicht mehr einloggen können. Dann beginnt die Feuerwehr-Aktion: manuelle Reset-Mails, überfluteter Kundensupport, schlechte Bewertungen. Das lässt sich vermeiden.

Der richtige Zeitpunkt für den Passwort-Reset-Link ist nicht nach dem Go-Live, sondern als geplante E-Mail kurz davor oder direkt beim ersten Login-Versuch im neuen System. JTL-Shop bietet einen konfigurierbaren Reset-Flow. Wir setzen ihn rechtzeitig auf, damit er ab Tag 1 greift.

2

Doppelter Kunden-Import ohne Abgleich-Logik

Das klassische Problem bei Händlern, die gleichzeitig aus dem alten ERP und aus dem Shop importieren: Dieselbe E-Mail-Adresse landet zweimal in JTL. Einmal als ERP-Datensatz, einmal als Shop-Kundenkonto. Das passiert schneller als gedacht, besonders wenn Bestelldaten aus dem Shop ebenfalls Kundensätze anlegen.

Laut JTL-Forum-Thread 222178 (Shopware-6-Migration mit 10.000 Kunden) ist der sauberste Weg: Zuerst nur in den Shop importieren, dann in der Kundentabelle alle auf ’nicht abgeholt‘ stellen. So wandern sie erst dann in die Wawi, wenn ein echter Sync-Auslöser (neue Bestellung) greift. Das verhindert Massen-Duplikate beim Initial-Sync.

Was funktioniert — konkrete Ergebnisse aus unseren Projekten

18.000 statt 80.000 Datensätze — sauberer Import

Bei einem Händler (anonymisiert, Elektrozubehör-Bereich) haben wir den Kundenstamm vor dem Import auf die letzten 24 Monate bereinigt. Das reduzierte die Importmenge von rund 80.000 auf knapp 18.000 Sätze. Der Initial-Sync lief statt mehrerer Tage problemlos durch. Kein einziger Duplikat-Datensatz in der Wawi. (Quelle: eigene Projektdaten)

Zero-Support-Tickets durch vorbereiteten Reset-Flow

Ein anderer Händler (Modebereich, anonymisiert) hat zwei Wochen vor Go-Live eine Ankündigungs-Mail verschickt: ‚Wir bauen unseren Shop um. Beim nächsten Login setze bitte dein Passwort neu.‘ Die Reset-Funktion war ab Tag 1 aktiv. Ergebnis: null Support-Anrufe wegen Login-Problemen in den ersten 14 Tagen nach Launch. Der Unterschied zu Projekten ohne diese Vorbereitung ist enorm.

Die Lektion

Unsere Erkenntnis aus Migrations-Projekten: Kunden-Kommunikation ist kein Nice-to-have am Ende der Migration, sondern ein technischer Schritt wie der Artikel-Import. Wer sie vergisst, zahlt es mit dem Support-Aufwand.

So gehst du Kundendaten-Migration strukturiert an

Diese fünf Schritte decken den kompletten Ablauf ab. Von der Datenanalyse im Altsystem bis zum sauberen Go-Live.

Schritt 1: Kundenstamm analysieren und bereinigen

Exportiere den kompletten Kundenstamm aus dem Altsystem. Filtere nach letzter Bestellung: Kunden ohne Aktivität in den letzten 24 Monaten kommen ins Archiv, nicht in JTL. Prüfe auf Duplikate, ungültige E-Mail-Adressen und fehlende Pflichtfelder (PLZ, Land). Saubere Quelldaten sind der größte Hebel für einen reibungslosen Import. Wir übernehmen diesen Schritt bei Vlarom zusammen mit dir, wenn du unsicher bist.

Schritt 2: CSV-Struktur für JTL-Ameise vorbereiten

JTL-Ameise erwartet ein spezifisches Spaltenformat für den Kundendaten-Import. Laut JTL-Dokumentation zur Datenmigration unterstützt die Ameise direkte Importe aus Oxid, Lexware, Sage und weiteren Systemen. Bei anderen Quellsystemen mappen wir das CSV manuell. Teste den Import zuerst mit 100 Datensätzen, nicht mit dem kompletten Bestand.

Schritt 3: Sync-Reihenfolge festlegen (Duplikat-Prävention)

Entscheide vor dem Go-Live: Werden Kundensätze primär aus dem ERP oder aus dem Shop übernommen? Lege einen Stichtag fest. Alles vor dem Stichtag kommt per Ameise-Import, alles danach über den JTL-Connector. Niemals beide Kanäle ohne Abgleich-Logik gleichzeitig laufen lassen.

Schritt 4: Passwort-Reset-Flow konfigurieren und testen

Setze in JTL-Shop den automatischen Passwort-Reset-Flow auf. Teste den Link-Versand mit einer Test-E-Mail-Adresse. Plane eine Ankündigungs-Mail an deine Bestandskunden für zwei Wochen vor Go-Live: kurz, klar, mit direktem Reset-Link. Der Klartext-Versand von temporären Passwörtern per E-Mail gilt laut JTL-Forum als schlechte Praxis. Reset-Links sind der sichere Standard.

Schritt 5: Post-Launch-Check nach 48 Stunden

Prüfe 48 Stunden nach Go-Live: Wie viele Kunden haben den Reset-Link genutzt? Gibt es Duplikate in der Kundentabelle? Kommen Support-Anfragen wegen Login-Problemen? Wenn ja, liegt der Fehler meist in der Ameise-Import-Konfiguration oder im Connector-Stichtag. Beides korrigieren wir gezielt, solange du es früh genug siehst.

Häufige Fragen zu Kundendaten bei JTL-Migrationen

Können Kundenpasswörter bei der JTL-Migration direkt übernommen werden?

Nein, das ist technisch nicht möglich. Jedes Shopsystem verwendet eine eigene Passwort-Verschlüsselung. Oxid zum Beispiel One-Way-Hashing mit individuellem Salt, plentymarkets MD5. JTL-Shop kann diese Hashes nicht lesen und entschlüsseln. Die einzige saubere Lösung ist ein Passwort-Reset-Link, den der Kunde beim nächsten Login selbst auslöst. Genau diesen Weg empfiehlt auch JTL selbst (Quelle: JTL-Forum-Thread 85828).

Per JTL-Ameise übernimmst du Stammdaten: Name, Adresse, E-Mail, Kundennummer, Geburtstag (falls vorhanden) und Kundenkategorien. Die Ameise unterstützt laut JTL-Dokumentation zum Kundendatenimport den direkten Import aus Oxid, Lexware, Sage, ePages und anderen Systemen. Bei Shopware, PrestaShop und WooCommerce läuft der Kundendaten-Transfer über den JTL-Connector. Bestellhistorie ist bedingt übertragbar, Passwörter grundsätzlich nicht.

Doppelte Kundensätze entstehen fast immer, wenn ERP-Import und Shop-Connector parallel und ohne Abgleich laufen. Der sicherste Weg: Erst alle Kundendaten per Ameise in die Wawi importieren, dann im Shop alle importierten Kunden auf ’nicht abgeholt‘ setzen. So landen diese Datensätze erst dann in der Wawi, wenn ein echter Trigger (neue Bestellung) sie auslöst. Das verhindert Massen-Duplikate beim Initial-Sync.

Das hängt von deiner Datenmenge ab. Aus unseren Projekten hat sich ein Richtwert bewährt: Nur Kunden der letzten 24 Monate importieren. Bei großen Beständen ab 30.000 Datensätzen reduziert das den Import auf ein handhabbares Volumen und verhindert, dass der Initial-Sync tagelang läuft. Ältere Kundensätze bleiben im Altsystem als Archiv. Dort sind sie abrufbar, ohne den JTL-Betrieb zu belasten.

Nein. Der Versand temporärer Klartext-Passwörter per E-Mail gilt als unsichere Praxis und wird auch im JTL-Forum ausdrücklich nicht empfohlen. E-Mails sind nicht verschlüsselt und können mitgelesen werden. Der sichere Standard ist ein individueller Passwort-Reset-Link, der nur für eine begrenzte Zeit gültig ist und den der Kunde selbst auslöst. JTL-Shop stellt diesen Flow nativ bereit.

Das lässt sich konfigurieren, ist aber an Bedingungen geknüpft. Historische Bestellungen aus dem Altsystem lassen sich importieren, allerdings nur bis zu einem definierten Stichtag und nur wenn das Datenformat kompatibel ist. Neue Bestellungen ab Go-Live laufen direkt über den JTL-Shop und erscheinen sofort im Kundenkonto. Eine lückenlose Bestellhistorie über den Systemwechsel hinweg erfordert sauberes Mapping und wird oft individuell projektiert. Wir setzen das bei Vlarom auf Wunsch in einem eigenen Schritt um.

Aktive Sessions aus dem Altsystem lassen sich nicht auf JTL übertragen. Wer sich genau während der Migration einloggt, wird abgemeldet und muss sich im neuen System per Passwort-Reset anmelden. Bewährt hat sich ein kurzes Maintenance-Fenster mit vorabiger Kunden-E-Mail.

Das hängt direkt von der bereinigten Datenmenge ab. Bei 5.000 bis 15.000 Datensätzen läuft ein Ameise-Import in der Regel zügig durch. Ab 50.000 Datensätzen ohne vorherige Bereinigung können Initial-Syncs deutlich länger dauern. Händler im JTL-Forum berichten von Problemen bei 100.000 Kunden ohne vorherigen Filter. Deshalb ist der Bereinigungsschritt vor dem Import kein optionaler Komfort, sondern Pflicht.

Keine Pauschalaussagen — sondern konkrete Einschätzung für dein Projekt

Kundendaten-Migration mit Vlarom: sauber, sicher, ohne Datenverlust

Als JTL Service Partner Gold mit Sitz in Ahrensfelde bei Berlin haben wir Dutzende Kundendaten-Migrationen durchgeführt — aus Oxid, Shopware, plentymarkets und Lexware. Wir wissen, wo die Fallstricke liegen und wie man sie umgeht. Ruf uns direkt an unter +49 30 91473862, schreibe an info@vlarom.de oder nutze unser Kontaktformular für eine unverbindliche Ersteinschätzung.

Autor

Alexander Luft

JTL Service Partner Gold · Vlarom E-Commerce Agentur · Ahrensfelde bei Berlin