JTL-Wawi 2.0: Die Stolperfallen beim Umstieg — und wie du deine Anforderungen richtig definierst

Ich habe längst aufgehört zu zählen, wie viele JTL-Systeme wir über die Jahre betreut haben — und wenn es ein Muster gibt, auf das ich Geld setzen würde, dann dieses: Die Shops, die sich mit einem großen Versionssprung schwertun, sind nicht die mit den kompliziertesten Setups. Es sind die, die an einem Freitagnachmittag auf „Aktualisieren“ geklickt haben, weil eine Meldung das so vorgeschlagen hat. JTL-Wawi 2.0 ist ein richtig gutes Release — aber es ist auch der Moment, in dem sich diese Angewohnheit endgültig rächt.

Reden wir also darüber, was an 2.0 wirklich anders ist, wo die Leute stolpern und — der Teil, den die meisten Artikel überspringen — wie du deine Anforderungen definierst, bevor du irgendetwas anfasst, damit der Umstieg langweilig statt dramatisch wird. Und langweilig ist hier genau das, was du willst.

Warum JTL-Wawi 2.0 kein „ganz normales Update“ ist

Unter der Haube ist 2.0 ein größerer Sprung, als die Versionsnummer vermuten lässt. Ein paar Dinge sind für alle wichtig, die den Umstieg planen:

• Neues Fundament (.NET 8). JTL hat die Wawi auf .NET 8 neu aufgesetzt, mit Performance-Gewinnen von bis zu rund 30 % bei datenintensiven Vorgängen. Das ist echt — aber eine neue Laufzeitumgebung bedeutet auch neue Anforderungen an deinen Server und deine Arbeitsplätze.
• Semantic Versioning — und „Breaking Changes“ als offizielles Konzept. JTL ist auf das Schema MAJOR.MINOR.PATCH umgestiegen. Die „2″ in 2.0 ist eine Major-Version, und das ist JTLs eigene Art zu sagen: Dieses Release darf Dinge kaputtmachen, die vorher funktioniert haben. Lies den Satz ruhig nochmal, denn er ist der ganze Grund für diesen Beitrag.
• Der Start der Hybrid-Cloud-Ära. Deine Wawi bleibt On-Premises, aber 2.0 öffnet die Tür zu JTL Hub, JTL ID und einer ganzen Welle von Cloud-Diensten (Archivierung, die neue Multi-Carrier-Versandplattform und mehr), von denen einige noch in der Beta sind.
• DHL Versenden 4.0 wird zum Standard. Die älteren DHL- — und DPD- — Schnittstellen werden abgeschaltet. Wenn Versand zu deinem Tagesgeschäft gehört, ist das keine optionale Hausaufgabe.

Zusammengenommen ist das kein Patch. Das ist ein Plattformwechsel, der sich als Versionssprung verkleidet. Und damit sind wir bei der ersten — und größten — Stolperfalle.

Stolperfalle #1: Einen Umstieg wie einen Klick behandeln, nicht wie ein Projekt

Der mit Abstand teuerste Fehler, den wir sehen, ist, den Denk-Schritt komplett zu überspringen. Jemand aktualisiert direkt das Live-System, merkt drei Tage später, dass ein Worker-Prozess still gestorben ist, und keiner weiß mehr so genau, welche Aufträge synchronisiert wurden und welche nicht. Ein ERP zurückzurollen, das währenddessen echte Bestellungen entgegengenommen hat, macht keinen Spaß — und die Abgleich-Tabelle danach wünsche ich niemandem.

Hier der Perspektivwechsel, der fast alles löst: Ein Major-Versionssprung ist ein kleines Projekt, und jedes Projekt beginnt mit Anforderungen. Kein Gantt-Diagramm, keine 40-seitige Spezifikation — nur eine ehrliche Bestandsaufnahme, was deine Wawi eigentlich für dein Geschäft leistet und was „funktioniert immer noch“ am Tag danach konkret heißen muss. Wenn du ein umfangreicheres Setup fährst, ist genau das der Fall für unsere Konzeption & Planung — 80 % des Wertes holst du dir aber schon selbst mit einem Nachmittag und einem Notizblock.

So definierst du deine Anforderungen richtig

„Definier deine Anforderungen“ klingt nach Berater-Sprech, also machen wir’s konkret. Bevor du auch nur einen einzigen Migrationsschritt planst, schreib die Antworten auf diese Fragen auf — in ganz normalen Worten, so wie du es einem neuen Kollegen erklären würdest.

1. Kartier, womit deine Wawi eigentlich alles verbunden ist
   Jedes ERP ist im Grunde eine Zentrale mit einem Dutzend Kabeln, die herauslaufen. Schreib sie alle auf: dein Shopsystem (JTL-Shop, Shopware, Shopify, WooCommerce), Marktplätze wie Amazon und eBay, dein Lager bzw. JTL-WMS, Versanddienstleister, Zahlungs- und Buchhaltungs-Exporte sowie jede individuelle Schnittstelle, die dir irgendwann mal ein Entwickler gebaut hat. Wenn du nicht alle benennen kannst, ist das kein Versagen — es ist genau der Grund, diese Übung jetzt zu machen und nicht mitten im Umstieg.
2. 2. Trenne „muss am ersten Tag laufen“ von „wäre nett“
3. Nicht alles ist gleich kritisch. Auftragsimport, Bestandsabgleich und Versandlabels sind meist „das Geschäft steht still, wenn das kaputtgeht“. Ein monatlicher Export, den du von Hand anstößt, ist es nicht. Markier jeden Punkt. Diese eine Unterscheidung bestimmt später deinen kompletten Testplan — und sie bewahrt dich davor, ein Umstiegs-Wochenende mit der Fehlersuche in etwas zu verbrennen, das eh niemand vor dem 30. braucht.
4. 3. Notier deine Plugins, Worker und Eigenentwicklungen — mit Name und Version
5. Das ist die Liste, die Umstiege rettet. Halt für jedes Plugin und jeden Worker-Prozess fest, was er tut und ob er nachweislich mit 2.0 kompatibel ist. Alles Selbstgebaute bekommt eine rote Flagge, bis das Gegenteil bewiesen ist. Warum, dazu kommen wir gleich.
6. 4. Definier, wie „Erfolg“ in konkreten Zahlen aussieht
7. „Fühlt sich gut an“ ist kein Testergebnis. Such dir eine Handvoll Prüfungen, die du wirklich nachvollziehen kannst: Ein Testauftrag läuft vom Shop über die Wawi bis zum gedruckten Label; die Bestände stimmen zwischen Shop und Wawi überein; die letzten 20 Aufträge lassen sich abgleichen; dein Buchhaltungs-Export öffnet sauber. Schreib sie auf, bevor du loslegst — dann werden sie zu deiner Go-live-Checkliste.
8. Das war’s. Vier Fragen. Beantworte sie ehrlich, und der Rest des Umstiegs plant sich fast von selbst — denn jetzt weißt du genau, was du in welcher Reihenfolge testen musst und was „fertig“ bedeutet.

Stolperfalle #2: Deine Altdaten fahren mit

Ein Umstieg verschiebt nicht nur deine Abläufe — er schleppt jahrelange Daten mit, und jede Macke darin kommt gleich mit. Genau hier trennen sich „im Testsystem lief’s“ und „im Live-Betrieb ist Chaos“, weil dein Testsystem selten das volle Gewicht der Historie hinter sich hat.

Die Dinge, die zuverlässig Schmerzen bereiten: Dubletten bei Kundendatensätzen, die sich still angesammelt haben, Artikel mit inkonsistenten oder fehlenden Attributen, halbfertige Workflows und eigene Felder, die vor drei Admins eingerichtet und nie dokumentiert wurden, sowie offene Aufträge, die genau im Moment des Umstiegs in seltsamen Zwischenzuständen hängen. Eine Major-Version ist außerdem der perfekte Anlass, dein JTL-Setup auf GoBD-relevante Belegverarbeitung zu prüfen — gerade mit dem neuen Archivdienst am Horizont.

Zwei Regeln machen das beherrschbar. Erstens: Ein Umstieg ist eine Gelegenheit zum Aufräumen, keine Aufräum-Aufgabe. Versuch nicht, zehn Jahre Datenhygiene am selben Wochenende zu reparieren, an dem du updatest — aber notier, was unsauber ist, damit dich nichts überrascht. Zweitens, und nicht verhandelbar: ein geprüftes, wiederherstellbares Backup, bevor du irgendetwas anfasst. Nicht „irgendwo gibt’s bestimmt ein Backup“. Ein Backup, bei dem du tatsächlich getestet hast, dass du daraus wiederherstellen kannst. Die Zahl der Betriebe, die nach dem Ernstfall merken, dass ihr Backup unvollständig war, ist höher, als irgendjemand zugeben möchte.

Stolperfalle #3: Schnittstellen, Plugins und der stille Worker, der stirbt

Erinnerst du dich an den Satz „Major-Versionen dürfen Dinge kaputtmachen“? Hier zeigt er sich. Aus unserer Erfahrung ist der Ausfall, der am meisten wehtut, nicht der laute Crash — es ist der stille. Ein Worker-Prozess, der ohne Fehlermeldung aufhört zu synchronisieren. Eine Schnittstelle, die noch verbunden aussieht, aber seit sechs Stunden keinen Auftrag mehr übergeben hat. Ein Plugin, das sauber lädt, sich auf der neuen Laufzeitumgebung aber subtil anders verhält.

Weil 2.0 auf einem neuen .NET-Fundament sitzt, muss alles, was sich tief in die Wawi einklinkt — Plugins, Eigenentwicklungen und vor allem maßgeschneiderte Schnittstellen — neu geprüft und nicht einfach vorausgesetzt werden. Konkret, bevor du live gehst:

• Teste jedes angebundene System in einer Staging-Umgebung, die die Produktion so genau wie möglich abbildet — gleiche Plugins, gleiche Schnittstellen, gleiche Worker-Konfiguration.
• Lass dir die Plugin-Kompatibilität vom Anbieter bestätigen, statt zu hoffen. Wenn ein Plugin verwaist ist, findest du das besser jetzt heraus als beim Go-live.
• Schenk selbstgebauten Schnittstellen besondere Aufmerksamkeit. Die wurden für die alte Laufzeitumgebung geschrieben und müssen am ehesten angepasst werden. Wenn sie ein Entwickler gebaut hat, der nicht mehr da ist, plan Zeit ein, damit jemand drüberschaut — genau das deckt ein großer Teil unserer Schnittstellen-Arbeit ab.
• Behalte deine Worker nach dem Go-live aktiv im Blick. Geh nicht davon aus, dass „keine Fehlermeldung“ gleich „alles synchronisiert“ heißt. Prüf in den ersten Tagen, ob Daten tatsächlich fließen.
• Behandle den Umstieg auf DHL 4.0 als eigenen Punkt, damit der Versand nicht an dem Morgen stehen bleibt, an dem die alte Schnittstelle abgeschaltet wird.

Wenn ein guter Teil deines Tagesgeschäfts über individuelle Logik läuft, ist das auch ein natürlicher Moment, dich zu fragen, ob sich davon etwas im Zuge des Umstiegs vereinfachen oder robuster machen lässt — die Art von Sache, die eher mit Automatisierung zu tun hat als mit reinem Umziehen.

Das unspektakuläre Geheimnis: staffeln und Zeit geben

Nichts davon muss dramatisch sein. Die Umstiege, die glattlaufen, haben alle dieselbe langweilige Form: erst in einer Kopie testen, nie direkt im Live-System; sich ein echtes Zeitfenster geben statt einer Freitagabend-Hauruck-Aktion; und eine ruhige Phase im Geschäftskalender wählen, nicht den Anlauf zur umsatzstärksten Saison. JTL unterstützt nur die letzten zwei stabilen Major-Versionen plus die aktuelle Beta, es tickt also eine echte Uhr — aber „vor dem End-of-Life“ heißt immer noch Monate Puffer, nicht ein Grund, das Live-System heute Abend zu überstürzen.

Und wenn du durch bist, behalte die Dinge ein paar Wochen im Auge. Die meisten Umstiegs-Gremlins zeigen sich in den ersten Tagen im echten Betrieb, nicht im Testlauf. Ein bisschen Monitoring und Wartung nach dem Go-live macht aus „hat das jetzt eigentlich geklappt?“ eine Frage, die du mit Daten beantworten kannst statt mit einem Knoten im Bauch.

Das eine, was du mitnehmen solltest

JTL-Wawi 2.0 ist den Umstieg wert. Schnellerer Kern, eine sauberere Versionslogik und ein echter Weg in JTLs Cloud-Dienste — dahin bewegt sich das ganze Ökosystem, und auf einer alten Major-Version zu bleiben ist kein Plan für die Zukunft. Aber der Unterschied zwischen einem reibungslosen und einem schmerzhaften Umstieg hängt fast nie an der Software selbst. Er hängt daran, ob du dir einen Nachmittag genommen hast, um aufzuschreiben, was dein System eigentlich tut, bevor du es verändert hast.

Definier deine Anforderungen, schütz deine Daten und teste deine Schnittstellen, als würdest du erwarten, dass sie kaputtgehen — denn offiziell dürfen sie das. Mach das, und 2.0 wird genau das, was ein guter Umstieg sein sollte: ereignislos.