Ein Update der JTL-Wawi ist kein Knopfdruck, sondern ein kleiner Vorgang mit fester Reihenfolge. Wer diese Reihenfolge kennt, erledigt den Versionswechsel an einem Morgen. Wer sie nicht kennt, steht im schlimmsten Fall mit einem Lager voller Aufträge und einer Warenwirtschaft da, in die sich niemand mehr einloggen kann. Dieser Beitrag beschreibt, worauf es ankommt.
Warum ein JTL-Update anders funktioniert
JTL-Wawi ist eine On-Premise-Anwendung. Auf jedem Arbeitsplatz läuft ein eigener Client, alle greifen auf dieselbe Datenbank auf einem Microsoft SQL Server zu. Ein Update verändert die Struktur dieser Datenbank — und ein Client mit älterem Stand kann mit der neuen Struktur nichts anfangen.
Daraus folgt die wichtigste Regel: Alle Arbeitsplätze müssen gemeinsam auf dieselbe Version. Ein einzelner vergessener Rechner im Lager oder im Homeoffice blockiert dort die Arbeit, bis er nachgezogen ist. Das ist kein Fehler, sondern gewolltes Verhalten — es schützt die Datenbank vor inkonsistenten Zugriffen.
Hinzu kommt: Rund um die Wawi hängen weitere Bausteine, die zur Version passen müssen. Der JTL-Worker, der den Abgleich zum Shop steuert. Drittanbieter-Connectoren für Marktplätze. Eigene Plugins und angepasste Templates. Jeder dieser Bausteine kann ein Update blockieren oder nach dem Update stillstehen.
Der Sprung von der 1er- auf die 2er-Linie
Seit dem Frühjahr 2026 gibt es die JTL-Wawi in der Version 2, inzwischen ist die 2.1-Linie erschienen. Das ist kein gewöhnliches Update, sondern ein Technologiewechsel: Die Anwendung wurde auf eine neue .NET-Grundlage gehoben, was laut Hersteller vor allem bei datenintensiven Vorgängen Tempo bringt. An der grundsätzlichen Aufstellung ändert sich nichts — die JTL-Wawi bleibt eine Anwendung, die bei Ihnen läuft, und die Datenbank bleibt der Microsoft SQL Server.
Für die Planung bedeutet ein solcher Hauptversionssprung mehr Sorgfalt als ein Zwischenupdate:
Prüfen Sie zuerst die Randsysteme. Eigene Plugins, Vorlagen, Drittanbieter-Connectoren für Marktplätze und Zusatzmodule müssen zur Zielversion passen. Bei einem Technologiewechsel ist die Wahrscheinlichkeit deutlich höher als sonst, dass ein Baustein noch nicht so weit ist. Fragen Sie beim jeweiligen Anbieter nach, bevor Sie einen Termin setzen.
Planen Sie mehr Zeit für den Testlauf ein. Was bei einem Zwischenupdate ein halber Tag ist, kann hier ein bis zwei Tage bedeuten — inklusive eines vollständigen Durchlaufs von der Auftragsanlage bis zum Versandetikett.
Springen Sie nicht über mehrere Stände auf einmal. Wer noch auf einem älteren 1er-Stand steht, fährt in aller Regel besser, wenn er zuerst innerhalb der alten Linie aktualisiert und den Hauptversionssprung anschließend als eigenen Vorgang behandelt.
Warten Sie nicht zu lange. Ältere Hauptversionen werden irgendwann nicht mehr weiterentwickelt, und der Abstand wächst mit jedem Monat. Wann genau die Unterstützung für die 1er-Linie endet, sollten Sie direkt bei JTL erfragen — verlassen Sie sich dabei nicht auf Angaben aus zweiter Hand.
Vor dem Update: die Bestandsaufnahme
Bevor irgendetwas installiert wird, gehört aufgeschrieben, was überhaupt im Einsatz ist:
- Welche Wawi-Version läuft aktuell, und welche ist das Ziel?
- Wie viele Arbeitsplätze gibt es — inklusive Lager-PCs, MDE-Geräten und Homeoffice-Rechnern?
- Welche Plugins sind installiert, und unterstützt der jeweilige Anbieter die Zielversion bereits?
- Welche Drittanbieter-Connectoren laufen für Marktplätze, Versand oder Buchhaltung?
- Gibt es angepasste Templates oder eigene Auswertungen, die auf die Datenbankstruktur zugreifen?
Der letzte Punkt wird am häufigsten übersehen. Eigene Übersichten, die per SQL direkt auf Tabellen zugreifen, können nach einer Strukturänderung ins Leere laufen. Sie brechen nichts, liefern aber plötzlich falsche oder gar keine Zahlen — und das fällt manchmal erst Wochen später auf.
Die Datensicherung, die diesen Namen verdient
Eine Sicherung, die nie zurückgespielt wurde, ist eine Vermutung. Vor einem Versionssprung gehört ein Backup der Datenbank angelegt und geprüft, ob es sich tatsächlich wiederherstellen lässt — idealerweise auf eine separate Umgebung.
Wichtig ist außerdem, den Zeitpunkt richtig zu wählen: Die Sicherung muss nach dem letzten Arbeitsvorgang und vor dem Update entstehen. Wird zwischendurch noch kommissioniert oder ein Auftrag angelegt, fehlen diese Vorgänge im Rückfall.
Der Testlauf auf einer Kopie
Der eigentliche Unterschied zwischen einem ruhigen und einem hektischen Update ist der Testlauf. Dabei wird die gesicherte Datenbank auf eine getrennte Umgebung zurückgespielt und dort das Update durchgeführt. Anschließend prüfen Sie die Punkte, die im Tagesgeschäft wirklich zählen:
- Lässt sich ein Auftrag anlegen, kommissionieren und versenden?
- Erzeugt der Versanddienstleister korrekte Etiketten?
- Läuft der Abgleich zum Shop durch, und kommen Bestände richtig an?
- Melden die Marktplatz-Connectoren Aufträge wie gewohnt?
- Liefern die eigenen Auswertungen dieselben Zahlen wie vorher?
Der Testlauf kostet ein paar Stunden. Ein missglücktes Update im Produktivbetrieb kostet einen Tag Versand — und das Vertrauen der Kunden, deren Pakete liegen bleiben.
Der Ablauf am Stichtag
Hat der Testlauf funktioniert, ist der eigentliche Vorgang kurz:
- Arbeit in der Wawi beenden, alle Nutzer abmelden.
- Den JTL-Worker anhalten, damit während des Updates kein Abgleich läuft.
- Datensicherung anlegen.
- Update auf dem Server beziehungsweise der Hauptinstallation durchführen.
- Alle Clients nachziehen — der Reihe nach, bis kein Arbeitsplatz mehr fehlt.
- Worker wieder starten und den ersten Abgleich beobachten.
- Plugins und Connectoren prüfen, Testauftrag durchlaufen lassen.
Legen Sie den Termin auf eine Zeit mit geringem Auftragsvolumen. Montagvormittag ist in den meisten Handelsbetrieben die schlechteste Wahl.
Der Rückfallplan
Planen Sie vorab, woran Sie erkennen, dass das Update misslungen ist, und bis wann Sie die Entscheidung zum Rückfall treffen. Ohne definierten Zeitpunkt wird aus „wir probieren noch eine Stunde” schnell ein halber Tag.
Der Rückfall selbst besteht aus dem Zurückspielen der Datenbanksicherung und dem erneuten Installieren der alten Client-Version auf allen Arbeitsplätzen. Auch das sollte im Testlauf einmal durchgespielt worden sein.
Updates nicht aufschieben
Aus Sorge vor Problemen schieben viele Betriebe Updates auf — und machen es damit schlimmer. Je größer der Versionsabstand, desto mehr Strukturänderungen laufen auf einmal, desto wahrscheinlicher sind inkompatible Plugins und desto schwerer ist im Fehlerfall zu sagen, welche Änderung die Ursache war. Kleine, regelmäßige Sprünge sind fast immer der ruhigere Weg als ein großer alle zwei Jahre.
Wer die Umgebung ohnehin überdenkt, findet im Beitrag zur JTL-Wawi in der Cloud die Varianten für ein gehostetes Setup, in dem Sicherung und Serverpflege mit abgedeckt sind.
Häufig gestellte Fragen
Müssen wirklich alle Arbeitsplätze gleichzeitig aktualisiert werden? Ja. Nach einem Update passt die Datenbankstruktur nicht mehr zu älteren Clients, und diese verweigern den Zugriff. Das ist gewolltes Verhalten und schützt vor inkonsistenten Daten. Planen Sie deshalb alle Rechner ein — auch Lager-PCs, MDE-Geräte und Homeoffice-Arbeitsplätze.
Wie lange dauert ein JTL-Wawi Update? Der reine Vorgang auf dem Server dauert je nach Datenbankgröße meist zwischen 15 Minuten und zwei Stunden. Dazu kommt das Nachziehen der Clients, das pro Arbeitsplatz wenige Minuten braucht. Der größere Zeitblock ist der Testlauf vorab, für den ein halber Tag realistisch ist.
Was passiert mit eigenen Plugins und Templates beim Update? Sie müssen zur Zielversion passen. Bei Plugins von Drittanbietern entscheidet deren Hersteller, wann eine kompatible Fassung vorliegt. Eigene Anpassungen, die sauber über Child-Templates und Plugins umgesetzt wurden, überstehen Updates in der Regel — Eingriffe direkt im Kern dagegen nicht.
Kann ich ein Update rückgängig machen? Nicht durch eine Deinstallation. Der Weg zurück führt über das Zurückspielen der Datenbanksicherung und die erneute Installation der alten Client-Version. Deshalb ist eine geprüfte Sicherung unmittelbar vor dem Update der wichtigste einzelne Schritt.
Steht bei Ihnen ein Versionssprung an und niemand möchte ihn verantworten? Wir spielen JTL-Updates vorab auf einer Kopie durch und begleiten den Stichtag — flexibel und ohne Vertragsbindung, siehe JTL-Freelancer.
