Datentabelle mit Artikeln, Kunden und Bestellungen, Pfeile zeigen Migration zu JTL-Wawi

JTL Migration Daten übernehmen: Was geht, was schwierig ist — und was du vergessen kannst

Die Frage kommt in jedem Migrations-Erstgespräch: Was kann ich aus meinem alten System rüberziehen? Artikel, Kunden, Bestellungen — klingt einfach. Ist es aber nicht. JTL unterstützt Migrationen aus über 15 Quellsystemen, von Afterbuy über Lexware bis Shopware und WooCommerce. Der Migrationspfad läuft entweder über die JTL-Ameise mit CSV-Import oder über passende JTL-Konnektoren. Was wirklich übernommen wird, hängt an der Datenqualität im Quellsystem — und daran, wie sauber die Vorbereitung gemacht wird.

Du willst wissen, womit du in JTL startest — und was du neu aufbauen musst?

Dieser Beitrag gibt dir den direkten Überblick: Was kommt mit, was ist aufwendig, was bleibt im alten System.

Auf einen Blick

  • Wir begleiten Migrationen aus 15+ Quellsystemen: Artikel, Varianten, Preise, Kunden und Lagerbestände lassen sich in JTL übernehmen — bei guter Datenlage nahezu vollständig.
  • Schwierig wird es bei Bestellhistorie, Shopbewertungen und individuellen Feldern: Das geht nicht automatisch, sondern braucht Mapping, Bereinigung und manchmal manuelle Nacharbeit.
  • Passwörter von Endkunden sind niemals übertragbar — das ist kein JTL-Problem, sondern ein Sicherheitsstandard. Wir lösen das mit einem sauberen Reaktivierungs-Workflow.

Alexander Luft, Inhaber von uns und JTL Service Partner Gold aus Ahrensfelde bei Berlin, stellt in jedem Migrations-Erstgespräch eine Gegenfrage: „In welcher Qualität liegen deine Daten gerade vor?“ Denn die Frage „Was kann ich mitnehmen?“ ist die falsche Einstiegsfrage. Eine Migration kopiert nicht nur Datensätze, sie deckt jeden Daten-Fehler auf, der im alten System jahrelang unbemerkt mitlief. Wer das früh weiß, hat einen klaren Vorteil.

Was bei der JTL Migration Daten übernehmen wirklich bedeutet — die drei Kategorien

JTL unterscheidet in der offiziellen Dokumentation drei Datentypen: Daten die per JTL-Ameise direkt importierbar sind, Daten die über Konnektoren übernommen werden und Daten die sich systembedingt nicht übertragen lassen. Diese Unterscheidung ist in der Praxis entscheidend und bestimmt, ob ein Projekt drei Tage oder drei Wochen braucht. Der JTL Guide zur Datenmigration liefert dazu die offizielle Grundlage.

Quelle unseren Projektdaten (Migrationen aus Lexware, Afterbuy, Shopware, plentymarkets und anderen): In den Migrationen, die wir begleitet haben, liegt der unkritische Anteil — also alles was ohne Nachbearbeitung übernommen werden kann — typisch bei 60 bis 80 Prozent des Datenbestands. Die restlichen 20 bis 40 Prozent brauchen Mapping, Bereinigung oder manuellen Eingriff. Genau dieser Teil entscheidet, wie viel ein Projekt kostet und wie lange es läuft.

Die drei Datenkategorien im Überblick:

  • Was gut geht (Kategorie 1): Artikelstammdaten mit Bezeichnung, EAN, SKU, Preisen und Beschreibungen. Variantenartikel mit Kombinationsmatrix. Lieferanten und Einkaufspreise. Kundenstammdaten mit Adresse, E-Mail, Kundennummer. Aktuelle Lagerbestände zum Stichtag. Das alles überträgt die JTL-Ameise per CSV-Import, wenn die Quelldaten sauber vorliegen.
  • Was aufwendig ist (Kategorie 2): Bestellhistorie aus den letzten Jahren: technisch machbar, aber aufwendig zu mappen. Individuelle Zusatzfelder aus dem Altsystem: müssen in JTL-Freifelder übersetzt werden. Shopbewertungen und Produktbilder: brauchen eigene Prozesse. Staffelpreise, Kundengruppen-Preise und Sonderkonditionen: gehen, aber nur mit sauberem Mapping vor dem Import.
  • Was nicht geht (Kategorie 3): Kundenkonto-Passwörter sind aus Sicherheitsgründen nicht übertragbar. Das gilt für alle Systeme, nicht nur JTL. Interne Workflow-Logik aus dem Altsystem (etwa Automatisierungsregeln) musst du in JTL neu aufbauen. Individuelle Reportings und Auswertungsansichten gibt es in JTL in anderer Form, aber nicht als Direktimport.

Die Kernregel aus unserer Projektpraxis: Die Qualität der Migration steht und fällt mit der Vorbereitung der Quelldaten. Wer erst beim Exportversuch merkt, dass Artikelnummern inkonsistent sind oder Kundendaten doppelt gepflegt wurden, verliert Zeit und Budget.

Warum scheitern Migrationen — die zwei häufigsten Fehlerquellen

Nicht jede schwierige Migration hat dieselbe Ursache. Aus unserer Projektpraxis kristallisieren sich zwei Muster heraus, die den Unterschied machen:

1

Schlechte Datenbasis im Quellsystem

Das alte System hat jahrelang Daten angesammelt: Duplikate, veraltete Adressen, Artikel ohne EAN, Bestellungen mit nicht mehr existenten Kundennummern. All das kommt beim Export ans Licht.

In einem Projekt mit einem Modehändler (anonymisiert) hatten 22 Prozent aller Artikel keine eindeutige SKU. Das bedeutete manuelle Nacharbeit für rund 800 Artikel, bevor der erste Import in JTL starten konnte. Wer das nicht einplant, läuft in eine Zeitfalle. (Quelle: unseren Projektdaten)

2

Unterschätztes Datenmapping

Ein CSV-Export aus Lexware oder Afterbuy hat andere Spaltenbezeichnungen, als JTL sie erwartet. Das klingt trivial, ist es aber nicht. Jedes Feld muss bewusst zugeordnet werden, und bei Sonderfeldern, Variantenkombinationen oder Preisstaffeln braucht das ein eigenes Konzept.

Bei komplexen Anforderungen — etwa wenn Systeme wie Shopware oder WooCommerce mit individuellen Produkt-Attributen arbeiten — reicht die Standard-Ameise nicht mehr. Dann bauen wir bei uns maßgeschneiderte Konnektoren. Das Projekt innocigs.com zeigt das gut: Dort übernimmt ein eigener API-Konnektor den gesamten Datentransfer.

Was du gewinnst, wenn du die Migration richtig aufstellst

Sauberer Datenbestand von Anfang an

Eine Migration ist die beste Gelegenheit, Datenschrott loszuwerden. Aus unserer Projektpraxis: Händler die vor dem Import bereinigen, starten in JTL mit einem Artikelstamm, der tatsächlich wartbar ist. Ein Elektronikhändler (anonymisiert) reduzierte seinen Artikelstamm von 12.400 auf 9.800 aktive Artikel. Ergebnis: sauberere Auswertungen und schnellere Suchen. (Quelle: unseren Projektdaten)

Keine Doppelpflege mehr

Viele Händler betreiben vor der Migration parallel ihr Altsystem und notbehelfsmäßige Zwischenlösungen. Nach der Migration läuft alles in JTL: Artikel, Kunden, Lager, Marktplätze. Das spart in der Praxis mehrere Stunden täglich. In unseren Projekten sehen wir regelmäßig Einsparungen von 2 bis 4 Stunden pro Arbeitstag.

Die Lektion

Unsere Erkenntnis aus 10 und mehr Migrationen: Eine Migration ist kein Copy-Paste-Vorgang, sondern eine strukturierte Übergabe — mit Mapping, Bereinigung, Testlauf und Abnahme. Wer das als Projekt begreift und nicht als Knopfdruck, kommt ohne böse Überraschungen durch.

Dein Plan für die JTL-Datenmigration in 5 Schritten

Dieser Plan basiert auf dem Ablauf, den wir bei jeder Migration mit unseren Kunden durchgehen — unabhängig davon, ob das Quellsystem Lexware, Afterbuy, Shopware oder ein anderes ist.

Datenbestand analysieren (Woche 1)

„Exportiere alle relevanten Daten aus dem Altsystem: Artikel, Kunden, Bestellungen, Lieferanten. Prüfe Vollständigkeit und Konsistenz. Der häufigste Fehler hier ist zu viel Tempo. Wer den Export nicht systematisch prüft, findet Lücken erst beim Import in JTL. Als Orientierung nutzen wir die offizielle JTL-Dokumentation: guide.jtl-software.com/jtl-wawi/datenmigration.“

Datenmapping erstellen (Woche 1-2)

„Lege fest, welches Feld im Altsystem welchem Feld in JTL entspricht. Besonders bei Varianten, Preisstaffeln und Freifeldern braucht das ein eigenes Mapping-Dokument. Individuelle Felder aus dem Altsystem, die kein JTL-Pendant haben, legst du als Freifelder oder Attribute an.“

Daten bereinigen und aufbereiten (Woche 2-3)

„Duplikate entfernen, fehlende EANs ergänzen, inkonsistente Kundendaten korrigieren. Bei großen Artikelstämmen (ab ca. 5.000 Artikel) rechne mit 3 bis 5 Werktagen. Das ist keine Verschwendung, sondern die Grundlage dafür, dass der Import sauber durchläuft.“

Testmigration und Abnahme (Woche 3-4)

„Spiele die bereinigten Daten in eine JTL-Testumgebung ein. Prüfe Stichproben: Stimmen Preise, Varianten, Zuordnungen? Gerade bei Kundendaten und Bestellhistorie ist ein manueller Stichproben-Check nicht verhandelbar. Erst nach Abnahme der Testmigration beginnt der Live-Umzug.“

Live-Migration und Reaktivierung (Woche 4-5)

„Import in die Produktionsumgebung zum definierten Stichtag. Kundenkonto-Passwörter kannst du nicht übertragen — informiere deine Kunden proaktiv und richte einen Passwort-Zurücksetzen-Flow ein. Marktplatz-Anbindungen (Amazon, eBay) über eazyAuction binden wir nach der Grundmigration an. Details dazu liefert der JTL Guide: guide.jtl-software.com/jtl-wawi/datenmigration.“

Häufige Fragen zur JTL Migration Daten übernehmen

Artikel mit Varianten, Preisen und Beschreibungen, Kundenstammdaten, aktuelle Lagerbestände sowie Lieferantendaten lassen sich gut übernehmen. Bestellhistorie ist technisch möglich, braucht aber aufwendiges Mapping. Shopbewertungen und Kundenkonto-Passwörter sind nicht übertragbar. Die genaue Datenlage hängt immer vom Quellsystem und der Datenqualität ab.
Ja, grundsätzlich geht das, nur ist es aufwendig. Die Bestellhistorie muss aus dem Altsystem exportiert, auf das JTL-Format gemappt und bereinigt werden. Ob sich das lohnt, hängt davon ab, wie weit die Historie zurückreichen soll und wie sauber sie im alten System strukturiert ist. Viele Händler nehmen die letzten 12 Monate mit und archivieren ältere Daten im Altsystem.
Nein. Kundenkonto-Passwörter kannst du aus Sicherheitsgründen nicht in ein neues System übertragen. Das gilt für alle Shopsysteme, nicht nur JTL. Der Standardweg ist eine proaktive Kommunikation an die Kunden mit einem Passwort-Zurücksetzen-Link. Diesen Workflow richten wir bei jeder Migration mit ein.
Shopbewertungen lassen sich nicht direkt in den JTL-Shop übertragen. Du kannst bestehende Bewertungen auf der Quellplattform archivieren und referenzieren, ein automatischer Import in den neuen JTL-Shop ist aber nicht vorgesehen. Den Punkt unterschätzen viele Händler — daher früh kommunizieren.
Das hängt vom Quellsystem ab. Für Systeme wie Lexware, Afterbuy, OXID, Sage oder XT-Commerce nutzen wir die JTL-Ameise mit CSV-Import. Für Shopware, WooCommerce und PrestaShop gibt es JTL-Konnektoren. Bei komplexeren Anforderungen — etwa wenn Felder individuell gemappt werden müssen oder das Quellsystem keine Standard-Exporte liefert — bauen wir eigene Konnektoren, wie beim Projekt innocigs.com.
Ein einfacher Artikelstamm mit sauberen Daten lässt sich in wenigen Tagen migrieren. Ein vollständiges Projekt mit Kunden, Bestellhistorie, Lagerbeständen und Marktplatz-Anbindung dauert typisch 4 bis 8 Wochen, gerechnet vom ersten Datenexport bis zum stabilen Live-Betrieb. Der größte Zeitfresser ist fast immer die Datenbereinigung im Quellsystem.
Individuelle Felder, die es in JTL nicht direkt gibt, mappst du auf JTL-Freifelder oder Attribute. Das braucht eine bewusste Entscheidung im Mapping-Schritt. Automatisierungsregeln und Workflow-Logik aus dem Altsystem musst du in JTL neu aufbauen. JTL bietet dafür eigene Mechanismen, aber kein direkter Import ist möglich.
Nein. Aus unserer Projektpraxis hat sich eine Parallelphase von 4 bis 6 Wochen bewährt. In dieser Zeit läuft JTL produktiv, das Altsystem bleibt lesend zugänglich. So kannst du bei Rückfragen zu historischen Bestellungen oder Buchungen noch ins alte System schauen, ohne Druck. Danach wird es archiviert oder abgeschaltet.

Migrierst du von einem konkreten System? Für die häufigsten Quellsysteme haben wir eigene Erfahrungsberichte:

Lexware zu JTLAfterbuy zu JTLplentymarkets zu JTLShopware zu JTLAlle Migrationspfade

Du willst wissen was aus deinem System übernommen werden kann — konkret, nicht theoretisch?

Vlarom analysiert deine Datenlage — bevor du eine Entscheidung triffst.

Als JTL Service Partner Gold mit Sitz in Ahrensfelde bei Berlin begleiten wir Migrationen aus Lexware, Afterbuy, Shopware, plentymarkets, Magento und weiteren Systemen. Wir schauen uns deine Daten an und sagen dir direkt, was geht, was schwierig wird und wo du aufpassen musst. Ruf uns an unter +49 30 91473862, schreibe an info@vlarom.de oder nutze unser Kontaktformular für ein unverbindliches Erstgespräch.