Der Updater wird an einem Donnerstagnachmittag gestartet, zwischen zwei Kundenanrufen. Danach ist die Datenbank in Migration, der Worker steht, die Packtische melden Fehler, und in der Telefonschlange wartet der Versanddienstleister auf die Abholliste. Bis hierhin sind zwanzig Minuten vergangen und niemand weiß, wie man zurückkommt.
Das ist der Normalfall, den wir sehen, wenn wir nach einem Update dazugerufen werden. Nicht ein exotischer Bug, nicht eine kaputte Version — sondern ein Update, das wie ein Klick behandelt wurde und in Wirklichkeit ein Termin mit Vorbereitung, Zeitfenster und Rückweg ist. Bei JTL-Wawi 1.11 gilt das besonders, weil zwei Dinge zusammenkommen: eine harte technische Vorbedingung für Altversionen und eine Reihe von Nachwehen, die sich erst im Betrieb zeigen.
Die Vorbedingung, die viele Altbestände ausbremst
Wer noch auf einer Wawi-Version unterhalb von 1.0.0.0 arbeitet, kommt nicht direkt auf 1.11. Der Weg führt zwingend über 1.0.0.0. Das ist keine Empfehlung, sondern eine Bedingung des Updaters — und sie trifft mehr Betriebe, als man vermutet. Wir übernehmen regelmäßig Installationen, die seit Jahren stabil laufen und deshalb nie angefasst wurden. Genau die stehen jetzt vor zwei Migrationen statt einer.
Praktisch heißt das: Du planst zwei Datenbankmigrationen mit je eigener Laufzeit, eigenem Prüfdurchlauf und eigenem Rückweg. Die erste auf 1.0.0.0, die zweite auf die aktuelle 1.11er-Patchversion. Beide zusammen in ein Feierabendfenster zu quetschen, geht bei kleinen Datenbanken auf. Bei einer Wawi mit langer Historie, vielen Artikeln, Varianten und Jahren an Aufträgen kann die Migration deutlich länger dauern als der Kalendereintrag vorsieht. Die Laufzeit misst man nicht auf dem Produktivsystem — man misst sie vorher an einer Kopie.
Zweiter Punkt, der in dieselbe Kategorie fällt: die Umgebung. SQL-Server-Version, Serverdimensionierung, freier Plattenplatz für Datenbank und Transaktionslog, Version des Betriebssystems auf den Arbeitsplätzen. Ein Update, das an einem zu alten SQL Server scheitert, scheitert früh und laut. Unangenehmer sind die Fälle, in denen es durchläuft und die Performance danach nicht mehr stimmt, weil die Hardware für die alte Version ausgelegt war.
Die Testinstanz, die wirklich eine ist
„Wir haben getestet" bedeutet in Gesprächen ungefähr fünf verschiedene Dinge. Brauchbar ist nur eine Variante: eine Kopie der produktiven Datenbank, auf einer eigenen SQL-Instanz, mit einer Wawi, die als Testinstanz markiert ist — und ohne Verbindung nach draußen.
Der letzte Teil ist der, der übersehen wird. Eine Testinstanz mit den produktiven Zugangsdaten für Shop, Marktplätze und Versanddienstleister ist kein Test, sondern ein zweites Produktivsystem. Sie zieht Aufträge, setzt Status zurück, schreibt Bestände und erzeugt Labels. Wir haben Fälle gesehen, in denen nach einem Testlauf auf der Kopie plötzlich echte Sendungen avisiert waren. Also: Connector-Zugänge entkoppeln, Marktplatz-Credentials entfernen, Mailversand auf eine Sackgasse legen, Zahlungsanbindungen abklemmen.
Was du auf der Testinstanz prüfst, ist nicht die Frage „läuft die Wawi" — die läuft. Prüfe die zehn bis zwanzig Abläufe, an denen dein Tagesgeschäft hängt: Auftrag anlegen, Kommissionierung, Packtisch mit dem realen Drucker- und Scanner-Setup, Versandetikett, Rechnungslauf, Ameise-Importe und -Exporte mit den echten Vorlagen, Workflows, Auswertungen. Jeder dieser Punkte hat bei irgendeinem Update schon einmal geklemmt. Und dokumentiere, wie lange die Migration auf der Kopie gebraucht hat. Diese Zahl ist die Basis für dein Wartungsfenster, nicht ein Gefühl.
Plugins, Worker und alles, was direkt in die Datenbank schreibt
Die Wawi selbst ist bei einem Update selten das Problem. Das Problem ist, was daran hängt.
Erstens die Plugins und Erweiterungen. Wawi-Plugins sind für Versionsstände gebaut. Vor dem Termin gehört jede Erweiterung auf eine Liste, mit der Frage an den Anbieter, ob es eine 1.11-kompatible Version gibt — und wenn ja, ab welcher Patchversion. Zweitens der Worker: Er muss zur Wawi-Version passen, und er läuft in vielen Betrieben auf einem separaten Server, an den bei der Update-Planung niemand denkt. Steht der Worker, stehen Shop-Abgleich, Marktplatzanbindung und Mailversand — nur merkt es keiner sofort, weil die Wawi selbst normal aussieht. Drittens die Shop-Seite: JTL-Shop, Connector und Wawi bilden ein Versions-Dreieck. Wer nur eine Ecke bewegt, produziert Abgleichsfehler, die sich als fehlende Artikel oder falsche Bestände zeigen.
Viertens — und das ist der Punkt mit dem größten Schadenspotenzial — eigene Zugriffe auf die Datenbank. Fast jede gewachsene Wawi-Installation hat sie: SQL-Views für Auswertungen, Skripte, die nachts Daten schieben, ein BI-Tool auf einer Tabelle, ein selbstgebautes Tool, das Felder direkt schreibt. Lesende Zugriffe brechen nach einem Update im schlimmsten Fall weg, das merkt man. Schreibende Zugriffe auf ein geändertes Schema können Daten beschädigen, und das merkt man erst Wochen später. Wenn du eine solche Stelle hast, ist sie der Grund, weshalb der Test kein Nice-to-have ist.
Was nach dem Update typischerweise klemmt
Zur 1.11er-Linie gibt es aus der Community eine Reihe wiederkehrender Meldungen. Das sind Nutzerberichte, keine bestätigte Fehlerliste — aber sie beschreiben genau die Klassen von Problemen, auf die man sich vorbereitet.
Das häufigste Thema ist Performance. Nach der Migration fühlt sich die Wawi an manchen Stellen langsamer an: Listenansichten, Suchen, Auftragsverwaltung. Ein Teil davon ist Datenbankhygiene — Statistiken und Indizes nach einer Migration, Wartungsplan auf dem SQL Server, Kompatibilitätsgrad der Datenbank. Ein Teil ist Dimensionierung. Beides prüft man besser vor dem Update als danach unter Druck.
Zweites Thema: die JTL-App meldet nach dem Update Fehler. Mobile Anwendungen und Wawi hängen an derselben Versionskette, und wenn im Lager mit Handhelds gearbeitet wird, ist eine meckernde App kein Randthema, sondern Stillstand an der Kommissionierung. Wer Apps im Einsatz hat, testet sie im Testlauf mit — mit denselben Geräten, nicht am Bürorechner.
Drittes Thema und das unauffälligste: die Übernahme von Rabatten aus dem Shop. Berichtet wird, dass Rabatte in der Wawi anders ankommen als erwartet, etwa netto statt brutto. Solche Abweichungen fallen nicht im Fehlerprotokoll auf, sondern in der Buchhaltung — und zwar bei Rechnungen, die längst raus sind. Deshalb gehört nach jedem Wawi-Update ein Abgleich in den Ablauf: einige Bestellungen aus dem Shop mit Rabatt, Gutschein und unterschiedlichen Steuersätzen durchziehen und die Beträge in der Wawi gegen den Shop stellen. Das kostet eine halbe Stunde und ist die günstigste halbe Stunde im ganzen Projekt.
Viertens die Schnittstellenlage. Wer eigene Anbindungen betreibt, sollte vor dem Termin klären, welche Zugriffswege in der Zielversion verfügbar sind und wie sie sich verhalten. Rund um API-Verfügbarkeit in On-Premise-Installationen gibt es offene Fragen, und eine Anbindung, die auf einem Weg aufsetzt, der sich verändert, fällt nicht sofort aus, sondern liefert falsche oder gar keine Daten.
Wie ein Update-Termin aussieht, der hält
Drei Dinge machen den Unterschied. Erstens der Zeitpunkt: nicht in der Woche vor dem Saisonpeak, nicht am Monatsende, nicht freitags um 16 Uhr. Am besten an einem Tag, an dem die Leute, die es merken würden, im Haus sind. Zweitens der Rückweg: ein geprüftes Backup heißt, dass jemand die Rücksicherung einmal gemacht hat — nicht, dass die Sicherung nachts durchgelaufen ist. Und es braucht eine klare Abbruchmarke: Wenn wir bis Uhrzeit X nicht am Punkt Y sind, gehen wir zurück. Ohne diese Marke wird jede Migration zu lang, weil man immer noch zehn Minuten weiterprobiert.
Drittens die Reihenfolge. Erst Wawi, dann Worker, dann Connector und Shop, dann Apps und Nebensysteme, und nach jedem Schritt eine kurze Prüfung statt einer großen am Ende. Wenn drei Komponenten gleichzeitig neu sind und etwas nicht funktioniert, verbringst du den Abend mit Eingrenzen.
Auf welche Patchversion du gehst, ist die letzte Frage. Die .0 eines Major-Sprungs ist selten die, mit der man produktiv arbeiten will; die 1.11er-Linie hat inzwischen mehrere Patch-Releases hinter sich, und der Blick in die Release Notes der letzten Stände sagt mehr über den Reifegrad als jede Ankündigung.
Der sinnvolle nächste Schritt ist unspektakulär: Notiere deinen aktuellen Versionsstand, prüfe, ob du unterhalb von 1.0.0.0 liegst, und liste alle Erweiterungen, Worker-Standorte und eigenen Datenbankzugriffe auf. Diese Liste entscheidet, ob dein Update ein Abend ist oder ein Projekt. Alles andere folgt daraus.
KI-generierter Inhalt.