Auftragsliste im Altsystem links, JTL-Wawi Auftragsverwaltung rechts, Datenpfeil in der Mitte

Bestellhistorie Migration JTL: Was wirklich übernommen werden kann — und was besser im Altsystem bleibt

Wer zu JTL wechselt, will seine Daten mitnehmen. Das ist verständlich. Bei Bestellhistorie und offenen Aufträgen stellt sich aber nicht nur die Frage nach dem „wie“, sondern vor allem nach dem „ob überhaupt — und wenn ja, wie viel davon“. Die JTL-Ameise importiert historische Aufträge, keine Frage. Der Import ist aber der aufwendigste Punkt der gesamten Migration. Und offene Aufträge zum Go-Live-Zeitpunkt bleiben das größte Risiko, das wir aus unseren Projekten kennen.

Du willst beim Systemwechsel keine einzige Bestellung verlieren und weißt noch nicht, wie das konkret aussieht?

In diesem Beitrag zeigen wir dir, welche Strategie in der Praxis funktioniert, welche Fehler beim Import regelmäßig auftauchen und warum das Migrations-Datum als klarer Startpunkt in den meisten Projekten die beste Lösung ist.

Auf einen Blick

  • ✓Unsere Erfahrung aus mehreren JTL-Migrationen zeigt: Offene Aufträge zum Go-Live-Zeitpunkt sind das größte Einzelrisiko. Sicherer ist es, alle laufenden Bestellungen im Altsystem abzuwickeln und JTL als sauberen Startpunkt zu nutzen.
  • ✓Historische Bestelldaten lassen sich per JTL-Ameise importieren, der Aufwand ist aber erheblich: Datenmapping, Testläufe, Präfix-Konfiguration. Wir empfehlen, nur die letzten 12 bis 24 Monate mitzunehmen. Ältere Daten bleiben im Altsystem archiviert zugänglich.
  • ✓Das Timing macht den Unterschied: Wer die Migration in eine umsatzschwache Phase legt (Januar/Februar oder Juli), schafft den Datenschnitt mit deutlich weniger offenen Aufträgen und weniger Stress.

Wir wissen aus Migrations-Projekten: Die Frage „Bestellhistorie mitnehmen ja oder nein?“ ist keine technische, sie ist strategisch. Händler wollen ihre Daten verständlicherweise vollständig übernehmen. In der Praxis sitzt der Schmerz aber nicht im Fehlen alter Daten, sondern im Chaos rund um offene Aufträge, die zum Wechselzeitpunkt weder im alten noch im neuen System sauber abgebildet sind. Genau das lässt sich vermeiden, wenn du früh genug planst. (Quelle: unsere Projektdaten)

Was Händler bei der Auftragshistorie wirklich erwartet

Die JTL-Datenmigration ist technisch machbar. Der Aufwand variiert aber stark: je nach Datenqualität des Quellsystems, Anzahl der historischen Aufträge und gewählter Übernahmestrategie. Aus unseren Projekten mit unterschiedlichen Quellsystemen ziehen wir konkrete Orientierungswerte.

Quelle: unsere Projektdaten: Ein Auftragshistorie-Import via JTL-Ameise braucht im Schnitt 2 bis 4 Wochen Vorbereitungszeit allein für Datenmapping und Testläufe. Bei Händlern mit mehr als 50.000 historischen Bestellungen steigt das auf 6 bis 8 Wochen. Wer nur die letzten 12 Monate übernimmt, reduziert diesen Aufwand um 60 bis 70 Prozent.

Die Dauer und der Aufwand des Auftragsimports hängen von diesen Faktoren ab:

  • →Volumen der historischen Aufträge: 500 Bestellungen pro Monat über 5 Jahre sind 30.000 Datensätze. Jeder einzelne davon braucht ein sauberes Mapping auf JTL-Felder. Das ist keine Kopierarbeit, das ist Datenarchitektur.
  • →Datenqualität im Quellsystem: Fehlende Pflichtfelder, inkonsistente Adressformate, Sonderzeichen in Kundennamen: jede Lücke im Quellsystem wird beim Import zum Problem. Hier zeigt sich, wie sauber ein System in den letzten Jahren gepflegt wurde.
  • →Offene Aufträge zum Migrationszeitpunkt: Das ist die eigentliche Gefahrenzone. Jeder offene Auftrag, der sowohl im alten als auch im neuen System existiert, braucht manuelle Kontrolle. Bei 200 offenen Aufträgen zum Go-Live-Datum wird daraus ein erheblicher manueller Aufwand.
  • →Bestellnummern-Präfixe: Wer vor dem Go-Live keine Präfixe in JTL konfiguriert, riskiert Nummernkollisionen. Vor allem mit PayPal-Zahlungsreferenzen, die auf Bestellnummern verweisen. Ein häufiger und vermeidbarer Fehler.

Die zentrale Regel ist einfach: Je weniger offene Aufträge zum Stichtag, desto sauberer der Wechsel. Das Timing der Migration zählt deshalb mindestens genauso wie das technische Vorgehen beim Import selbst.

Zwei Strategien — und warum eine klarer gewinnt

In der Praxis gibt es zwei grundsätzliche Ansätze für den Umgang mit Bestellhistorie und offenen Aufträgen. Beide haben ihre Berechtigung, einer ist aber deutlich robuster.

1

Strategie A: Alles importieren, sofort live

Historische Bestellungen kommen per Ameise rein, offene Aufträge werden parallel manuell in JTL angelegt oder per Import übertragen. Der Go-Live findet statt, während noch Aufträge im Altsystem laufen.

Das klingt nach dem vollständigen Datenschnitt, ist aber keiner. Zwei parallele Systeme mit aktiven Bestellungen führen in der Praxis fast immer zu Dopplungen, zu Zahlungsreferenz-Konflikten und zu einem erhöhten Fehlerrisiko im Tagesgeschäft. Aus unserer Projektpraxis: Dieser Weg kommt nur infrage, wenn das Quellsystem kurzfristig abgeschaltet werden muss.

2

Strategie B: Sauberer Datenschnitt mit Migrationsdatum

Das Migrationsdatum ist der Startpunkt. Alle neuen Bestellungen ab diesem Tag laufen in JTL. Offene Aufträge aus dem Altsystem werden dort vollständig abgewickelt. Kein Transfer, keine Parallelführung.

Die historischen Bestelldaten wandern in einem separaten Schritt per Ameise nach JTL, ohne Zeitdruck, weil der laufende Betrieb bereits in JTL läuft. Das ist der ruhigere Weg und der, den wir in den meisten Projekten umsetzen. Der Nachteil: Im neuen System fehlen für einige Wochen die Altdaten. Für den operativen Betrieb ist das aber selten ein echtes Problem.

Was Händler nach einem sauberen Datenschnitt berichten

Kein Chaos im Go-Live

Ein Händler (anonymisiert), der von plentymarkets gewechselt hat, hatte zum Stichtag noch rund 180 offene Aufträge. Entscheidung: alle im Altsystem vollständig abwickeln. Das hat 10 Tage gekostet. Der Go-Live lief danach fehlerfrei durch, ohne einen einzigen doppelt gebuchten Auftrag. Unsere Einschätzung: Diese 10 Tage waren die beste Investition des gesamten Projekts. (Quelle: unsere Projektdaten)

Präfix-Konflikt rechtzeitig verhindert

In einem anderen Projekt (anonymisiert, Quellsystem: Afterbuy) waren die Bestellnummern-Präfixe nicht gesetzt. Beim Testlauf mit Ameise zeigte sich, dass JTL-Bestellnummern mit den PayPal-Zahlungsreferenzen kollidierten. Wir haben das im Testlauf gefunden, nicht im Produktivbetrieb. Ein einfacher Konfigurationsschritt, aber einer, der erst im Nachhinein als selbstverständlich gilt.

Die Lektion

Unsere Erkenntnis aus mehreren Migrations-Projekten: Wer offene Aufträge vor dem Go-Live konsequent im Altsystem abwickelt, spart im Schnitt zwei bis drei Tage manuelle Nacharbeit direkt nach dem Start. Und schläft in der Go-Live-Nacht deutlich ruhiger.

Bestellhistorie sauber übernehmen: 5 Schritte aus der Praxis

Dieser Plan basiert auf dem, was wir in Migrations-Projekten mit unterschiedlichen Quellsystemen umgesetzt haben. Er ist kein starres Schema, die Reihenfolge ist aber wichtig. Wer Schritt 2 überspringt, hat spätestens bei Schritt 4 ein Problem.

Datenanalyse im Quellsystem (Woche 1)

„Bevor irgendetwas exportiert wird, schauen wir uns den Datenbestand an: Wie viele historische Aufträge gibt es? Welche Felder sind vollständig befüllt? Welche Kundenkonten fehlen oder sind doppelt angelegt? Diese Analyse dauert einen bis drei Tage und verhindert, dass du hinterher einen Export aufwendig korrigieren musst. Häufigster Fehler: Der Export wird ohne Analyse gestartet, die Fehler zeigen sich erst beim Import-Testlauf. Das kostet dann doppelte Zeit.“

Migrationsdatum und Präfixe festlegen (Woche 1-2)

„Das Migrationsdatum ist der Schnitt: ab hier JTL, davor Altsystem. Dieses Datum muss früh stehen, weil alle folgenden Schritte darauf aufbauen. Gleichzeitig konfigurieren wir in JTL-Wawi die Bestellnummern-Präfixe. Das klingt nach einem Detail, ist aber kritisch: Ohne korrekte Präfixe entstehen Nummernkonflikte mit externen Zahlungsreferenzen (PayPal, Klarna, Stripe). Die Konfiguration findest du in JTL-Wawi unter Einstellungen > Aufträge > Nummernkreise.“

Testmigration mit Ameise (Woche 2-3)

„Der erste Ameise-Import läuft immer in einer Testumgebung, nie direkt ins Produktiv-System. Du importierst einen Teilbestand (z.B. letzten Monat) und prüfst: Stimmen die Kundenzuordnungen? Sind Adressen korrekt? Werden Artikel-EANs richtig verknüpft? Das JTL-Forum dokumentiert typische Import-Fehler, die regelmäßig auftauchen: fehlende Pflichtfelder, Zeichensatz-Probleme, doppelte Bestellnummern. Ein Testlauf ist schnell erledigt — ein Produktiv-Fehler kostet deutlich mehr Zeit. Die Ameise-Importoptionen für Aufträge sind in der offiziellen JTL-Dokumentation beschrieben.“

Offene Aufträge im Altsystem abwickeln (Woche 3-4)

„In den Wochen vor dem Migrationsdatum laufen alle offenen Aufträge konsequent im Altsystem durch. Das heißt: keine neuen Bestellungen mehr im alten System annehmen, falls möglich Bestellannahme vorübergehend pausieren oder auf JTL umleiten. Was nicht rechtzeitig abgewickelt ist, muss manuell transferiert werden. Zeitaufwendig und fehleranfällig. Eine einfache Daumenregel: Wer 10 Tage vor Go-Live noch mehr als 50 offene Aufträge hat, sollte das Migrationsdatum verschieben.“

Go-Live und rückwirkender Historiendaten-Import (Woche 4-6)

„Ab Migrationsdatum laufen alle neuen Bestellungen in JTL. Die historischen Daten kommen jetzt ohne Zeitdruck per Ameise hinterher: in Ruhe, mit Validierung. In unseren Projekten hat sich bewährt, den Import auf die letzten 12 bis 24 Monate zu begrenzen. Das deckt Rückfragen von Kunden ab, ohne den Import unnötig aufzublähen. Ältere Daten bleiben im Altsystem archiviert und sind bei Bedarf dort abrufbar.“

Häufige Fragen zur Bestellhistorie bei JTL-Migration

Kann ich meine komplette Bestellhistorie in JTL importieren?

Ja, technisch geht das, sinnvoll ist es aber nicht immer. Die JTL-Ameise importiert historische Auftragsdaten, wenn sie sauber strukturiert und vollständig exportiert sind. Das Problem ist der Aufwand: Je mehr Jahre Daten, desto mehr Mapping-Arbeit, desto mehr Testläufe, desto länger die Vorbereitungszeit. In der Praxis hat sich ein Import der letzten 12 bis 24 Monate bewährt. Das deckt alle relevanten Kundenanfragen ab, ohne das Projekt unnötig zu verlängern. Ältere Daten bleiben im Altsystem jederzeit archiviert abrufbar.

Offene Aufträge sind das größte Risiko bei der Migration. Viele Händler unterschätzen das beim ersten Gespräch. Die sichere Strategie: Alle offenen Aufträge vor dem Migrationsdatum vollständig im Altsystem abwickeln. Was zum Stichtag noch offen ist, muss manuell in JTL übertragen werden. Zeitaufwendig und fehleranfällig. Wer das Migrationsdatum in eine Phase mit niedrigem Bestellvolumen legt (Januar/Februar oder Juli), hat deutlich weniger offene Positionen zu managen.

Das hängt vom Quellsystem und der Datenqualität ab. Standard-Felder sind: Auftragsnummer, Bestelldatum, Kundendaten (Name, Adresse), Artikel-Positionen mit Menge und Preis, Zahlungsart und Versandmethode. Was oft fehlt oder Probleme macht: interne Statusfelder, Notizen, kundenspezifische Rabatte und Sonderkonditionen sowie externe Zahlungsreferenzen. Vor dem Import machen wir ein Feld-Mapping. Also: welches Quellfeld geht in welches JTL-Feld. Das ist Handarbeit, keine automatische Lösung.

In JTL-Wawi lassen sich Bestellnummern mit einem Präfix versehen, zum Beispiel ‚JTL-‚ oder einen Jahres-Code. Das klingt nach einem optionalen Komfort-Feature, ist es bei einer Migration aber nicht. Wenn das Altsystem Bestellnummern im gleichen Format vergeben hat wie JTL, entstehen Kollisionen. Besonders kritisch: PayPal, Klarna und andere Zahlungsanbieter referenzieren Zahlungen auf Bestellnummern. Wenn eine JTL-Bestellnummer identisch mit einer alten PayPal-Referenz ist, führt das zu falschen Zahlungszuordnungen. Präfixe konfigurierst du in JTL-Wawi unter Einstellungen > Aufträge > Nummernkreise. Das muss vor dem ersten Go-Live-Auftrag erledigt sein.

Der Import selbst dauert je nach Datenmenge Stunden bis wenige Tage. Die Vorbereitung ist das eigentliche Zeitkonto: Datenexport aus dem Quellsystem, Bereinigung, Mapping, Testlauf, Korrektur, zweiter Testlauf. Bei 10.000 bis 30.000 Aufträgen rechnen wir mit 2 bis 4 Wochen Vorbereitungszeit. Wer nur die letzten 12 Monate importiert, reduziert das auf 1 bis 2 Wochen. Wichtig: Der Import findet nach dem Go-Live statt. Der Betrieb läuft in JTL bereits, während die Altdaten in Ruhe nachgepflegt werden.

Für die laufenden Bestellungen nicht. Für die Buchhaltung und steuerliche Archivierung meistens schon. Rechnungen aus dem Altsystem unterliegen der GoBD-Aufbewahrungspflicht (10 Jahre). Das Altsystem muss so lange erreichbar bleiben, bis alle Dokumente aus dem Archivierungszeitraum abgerufen werden können oder digital archiviert sind. Eine gangbare Lösung aus der Praxis: das Altsystem im Read-only-Modus weiterlaufen lassen oder die Daten in ein Archiv-Format exportieren (z.B. CSV oder PDF-Rechnungsexport), bevor die Lizenz ausläuft.

Das variiert stark. Plentymarkets hat einen guten Export, das Format braucht aber Mapping-Arbeit für die JTL-Ameise. Lexware exportiert Auftragsdaten ebenfalls, die Feldstruktur ist aber deutlich flacher als in JTL. Afterbuy-Exports sind oft komplett und gut strukturiert, der Transfer offener Auktionsaufträge bleibt aber komplex. Am schwierigsten sind Eigenentwicklungen ohne Exportfunktion. Hier machen wir einen direkten Datenbankexport. Das ist machbar, braucht aber mehr technische Vorarbeit.

Ja, über die JTL-Wawi REST-API ist ein programmatischer Import möglich. Das ergibt Sinn, wenn sehr viele Daten importiert werden müssen oder wenn das Quellsystem eine API hat, die direkt angesprochen werden kann. Für solche Fälle entwickeln wir maßgeschneiderte Import-Skripte. Aufwendiger als der Ameise-Weg, bei großen Datenmengen aber deutlich zuverlässiger und wiederholbar. Für die meisten mittelgroßen Händler reicht die Ameise vollständig aus.

Du planst einen Wechsel zu JTL und willst wissen, welche deiner Bestelldaten wie übertragen werden?

Mit Vlarom weißt du vor dem Start, was auf dich zukommt.

Als JTL Service Partner Gold mit Sitz in Ahrensfelde bei Berlin haben wir Migrations-Projekte aus verschiedenen Quellsystemen begleitet. Wir schauen uns dein Datenvolumen an, zeigen dir den realistischen Aufwand für den Auftragshistorie-Import und legen mit dir gemeinsam das Migrationsdatum fest. Ruf uns direkt an unter +49 30 91473862, schreib an info@vlarom.de oder nutze das Kontaktformular für eine unverbindliche Ersteinschätzung.