JTL-Wawi-Update einspielen: Reihenfolge, Plugin-Check und Rollback

Ein JTL-Wawi-Update spielen Sie in dieser Reihenfolge ein: Plugin-Freigaben für die Zielversion klären, Sicherung ziehen und probeweise zurückspielen, Worker sowie Kasse und Lager stoppen, das Programmpaket an einem Arbeitsplatz installieren, über den Assistenten die Datenbank aktualisieren und danach Clients, Worker, Connector und die Nebensysteme nachziehen. Freigegeben wird erst, wenn ein kompletter Geschäftsvorfall durchgelaufen ist.

1. Warum der Zeitpunkt über den Aufwand entscheidet

Die häufigste Frage lautet, ob man die neueste Version braucht. Die ehrlichere Frage lautet, wie weit man zurückliegt. Ein Sprung über eine Nebenversion ist Routine. Ein Sprung über mehrere Hauptversionen bringt geänderte Datenbankstrukturen, abgelöste Schnittstellen und Plugins mit, deren Anbieter es teilweise gar nicht mehr gibt.

Ein handfester Anhaltspunkt steht im JTL-Guide selbst: Dokumentiert und angepasst werden dort nur die aufgeführten Produktversionen, aktuell JTL-Wawi 1.11 und höher (Quelle: JTL-Guide, abgerufen am 30. August 2026). Wer darunter liegt, arbeitet zwar weiter — findet zu seiner Version aber immer seltener eine passende Anleitung, und Plugin-Anbieter testen dagegen ebenfalls nicht mehr.

Zum selben Stichtag steht JTL-Wawi 2.0.6 zum Download bereit, erstellt am 24. Juli 2026 (Quelle: JTL-Download-Seite). Diese Zahl veraltet schnell, deshalb hat sie hier nur eine Aufgabe: Sie zeigt Ihnen den Abstand zu Ihrem eigenen Stand. Prüfen Sie den aktuellen Wert vor jedem Update im Changelog, nicht in einem Ratgeber.

Ein Punkt aus der offiziellen Update-Checkliste wird dabei regelmäßig übersehen: Prüfen Sie vorab, ob die Zielversion einen neueren Microsoft SQL Server voraussetzt. Wenn ja, ist das kein Update mehr, sondern ein Server-Projekt mit eigenem Termin — und es gehört an den Anfang der Planung, nicht in den Abend des Wartungsfensters.

Beim Sprung von 1.11 auf 2.0 kommt vor dem Zeitpunkt noch eine Stufe: die Infrastruktur. JTL nennt die Anforderungen dafür an mehreren Stellen unterschiedlich — der Release-Blog spricht von .NET 8, die Systemvoraussetzungen im Guide nennen .NET Framework 4.8, und beim Betriebssystem am Arbeitsplatz weichen Guide und Downloadseite ebenfalls voneinander ab. Welche Angabe wo steht und wogegen Sie sinnvollerweise planen, haben wir in JTL-Wawi Version 2.0 und seinen Systemvoraussetzungen Quelle für Quelle aufgeschlüsselt.

2. Die richtige Reihenfolge: welche Komponente wann

JTL-Wawi ist selten allein im Haus. Datenbank, mehrere Arbeitsplätze, der Worker für Abgleiche und E-Mails, ein Connector zum Shop, dazu oft JTL-POS und JTL-WMS. Diese Teile sprechen miteinander, und sie vertragen keinen dauerhaften Mischbetrieb aus alten und neuen Ständen. Deshalb ist die Reihenfolge kein Stil, sondern die halbe Miete.

Die folgende Tabelle trennt sauber, was der Hersteller vorgibt und was aus unseren Projekten stammt — damit Sie beides unterschiedlich gewichten können:

Die ersten Stufen sind Herstellervorgabe und werden trotzdem am häufigsten gerissen. JTL verlangt ausdrücklich, dass Zusatzprogramme wie Kasse, Worker und JTL-WMS geschlossen sind, dass kein Arbeitsplatz währenddessen an der Datenbank arbeitet und dass das Update an einem Rechner gestartet wird — nicht an mehreren gleichzeitig. Auch Ameisen-Importe und Kassenvorgänge müssen ruhen (Quelle: JTL-Update-Checkliste).

Die späteren Stufen sind unsere Praxis. Der Grund dafür ist simpel: Worker und Connector arbeiten unbeaufsichtigt. Läuft der Worker schon wieder, während ein Arbeitsplatz noch auf dem alten Stand hängt, schreibt er Fehler in Ihre echten Daten, statt eine Meldung anzuzeigen. Deshalb geben wir automatische Prozesse immer zuletzt frei — erst wenn ein Mensch an einem Client nachweislich sauber arbeiten konnte.

Für die Anbindung an den Shop gilt dieselbe Logik. Belegt ist beim Connector nur eine Mindestversion — die JTL-Connectoren setzen mindestens JTL-Wawi 1.0.4.1 voraus, der Shopify-Connector im vollen Umfang mindestens 1.3.15 (Quelle: JTL-Guide). Aus unseren Projekten kommt die Empfehlung, den Connector-Stand trotzdem gemeinsam mit der Wawi mitzuziehen und nicht Monate später: Der Abgleich ist die Stelle, an der eine Unstimmigkeit stillschweigend Bestände verschiebt.

3. Plugin-Kompatibilität vor dem Termin prüfen

Hier weichen wir bewusst von den offiziellen Anleitungen ab, und zwar mit Ansage. Weder der JTL-Guide zum Aktualisieren noch die offizielle Update-Checkliste erwähnen Plugins überhaupt. Aus Herstellersicht ist das folgerichtig — JTL kann nicht für fremden Code garantieren. Aus Betreibersicht ist es die größte Lücke, denn genau dieser fremde Code hält Ihren Versand, Ihre Buchhaltung oder Ihre Marktplätze am Laufen.

Deshalb steht der Plugin-Check bei uns vor dem Termin, nicht in ihm. Er ist das einzige Kriterium, das eine geplante Zielversion noch kippen darf. So gehen Sie vor:

• Liste erzeugen, nicht erinnern. Notieren Sie jedes installierte Plugin mit Anbieter und aktuellem Stand. Rechnen Sie mit Erweiterungen, an die sich niemand mehr erinnert, weil sie seit Jahren unauffällig laufen.
• Freigabe je Plugin einholen. Prüfen Sie im Extension Store beziehungsweise beim Anbieter, für welche Wawi-Versionen die Erweiterung freigegeben ist. Steht dort Ihre Zielversion nicht, ist die Antwort nicht „wird schon".
• Eigenentwicklungen mitzählen. Individuelle Schnittstellen, SQL-Skripte, angepasste Workflows und Exportvorlagen sind Ihre Plugins ohne Anbieter. Für sie sind Sie selbst die Freigabestelle.
• Die Zielversion anpassen, nicht den Termin. Fehlt eine einzige Freigabe, wählen Sie lieber eine niedrigere Zielversion und behalten Ihr Wartungsfenster, statt das Update auf unbestimmte Zeit zu verschieben. Aufgeschobene Updates sind der Grund, warum aus einem kleinen Sprung später ein Projekt wird.

Welche Erweiterungen typischerweise im Einsatz sind und welche Aufgabe sie übernehmen, zeigt unsere Übersicht der wichtigsten JTL-Wawi-Plugins — dieselbe Liste dient Ihnen vor jedem Versionswechsel als Prüfraster. Wird ein Plugin nach dem Update automatisch deaktiviert, war die Freigabe nicht da. Das ist übrigens die gutartige Variante des Problems, weil sie sichtbar ist.

4. Warum ein Backup noch kein Rollback-Plan ist

JTL-Wawi erstellt laut Guide vor jedem Update automatisch eine Datenbanksicherung, deren Speicherort Sie ändern können (Quelle: JTL-Guide). Die offizielle Checkliste empfiehlt zusätzlich eine eigene Datensicherung für den Fall, dass die automatische scheitert. Beides ist richtig — und beides ist noch kein Rollback-Plan.

Der Unterschied liegt in drei Fragen, die eine Sicherung allein nicht beantwortet:

• Lässt sie sich wirklich zurückspielen? Eine Sicherung, die nie wiederhergestellt wurde, ist eine Vermutung. Wir spielen sie im Testlauf einmal zurück — dann kennen Sie auch die Dauer, und die brauchen Sie für die Entscheidung im Ernstfall.
• Wer entscheidet ab wann? Ohne vorher vereinbarte Abbruchkriterien wird um Mitternacht diskutiert statt gehandelt. Legen Sie fest, welche Fehler ein Zurück auslösen und bis wann die Entscheidung fällt.
• Was passiert mit den Daten von zwischendurch? Sobald nach dem Update gearbeitet wurde, kostet ein Rücksprung diese Vorgänge. Deshalb entscheidet sich ein Rollback im Wartungsfenster — nicht am dritten Tag.

Ein Punkt macht das besonders wichtig: Das Datenbankschema wird beim Update nach vorn migriert, und einen offiziellen Rückweg dafür gibt es nicht. Sie können zwar ältere Programmstände nachinstallieren, doch eine bereits aktualisierte Datenbank stellt das nicht zurück. Ihre Sicherung ist der Rückweg — es gibt keinen zweiten.

Wer JTL-Wawi in einer gehosteten Umgebung betreibt, hat es an dieser Stelle deutlich leichter: Ein Snapshot der ganzen Maschine vor dem Update nimmt Programmstand, Datenbank und Konfiguration in einem Rutsch mit. Welche Betriebsmodelle dafür infrage kommen, behandelt unser Beitrag zum JTL-Wawi Cloud-Hosting.

Mit der Express-Edition kommt eine Einschränkung hinzu, die genau im Ernstfall zählt: Ihr fehlt der SQL Server Agent, also läuft keine Sicherung automatisch — JTL beschreibt dafür einen geplanten Windows-Task. Dazu warnt JTL, dass ein Versionsupdate die Datenbank deutlich wachsen lassen kann; wer nahe an den 10 GB arbeitet, schafft vorher Platz. Beides ordnet unser Beitrag zu SQL Server Express für JTL-Wawi ein.

5. Die Testumgebung mit Datenbankkopie

Der JTL-Guide zum Aktualisieren sieht keine Testumgebung vor. Für ein Standardsystem ohne Anpassungen ist das vertretbar. Sobald Plugins, eigene Workflows oder veränderte Druckvorlagen im Spiel sind, halten wir sie für Pflicht — und entscheidend ist dabei ein Detail: Getestet wird auf einer Kopie Ihrer echten Datenbank, nicht auf einem leeren Demosystem.

Der Grund ist, dass ein leeres System genau die Dinge nicht zeigt, wegen derer man testet. Erst mit Ihren Daten sehen Sie, wie lange die Migration tatsächlich läuft — bei großen Datenbeständen ist das der Unterschied zwischen einer Stunde und einem Abend. Erst mit Ihren Belegen fällt auf, dass eine angepasste Rechnungsvorlage nicht mehr zum neuen Standard passt. Und erst mit Ihren Artikeln zeigt sich, ob der Abgleich nach dem Update noch dieselben Felder füllt.

Praktisch heißt das: Datenbank kopieren, auf einem getrennten Rechner oder einer separaten Instanz einspielen, dort das Update durchführen und die kritischen Abläufe einmal von vorn bis hinten durchspielen. Der Testlauf liefert Ihnen nebenbei den realistischen Zeitbedarf für das echte Wartungsfenster — und damit die Zahl, die Sie Ihrem Team nennen können.

Zwei Hinweise aus der Praxis: Die Kopie enthält echte Kunden- und Bestelldaten, gehört also in dieselbe Zugriffskontrolle wie das Produktivsystem. Und sie darf nach außen nichts auslösen — trennen Sie im Testsystem die Verbindungen zu Shop, Marktplätzen und Versanddienstleistern, bevor Sie den Worker dort auch nur einmal starten.

6. Das Zeitfenster: wann Sie besser nicht updaten

Die Frage ist nicht nur, wann Sie Zeit haben, sondern wann Sie im Fehlerfall noch Hilfe bekommen. Diese beiden Zeitpunkte fallen selten zusammen — und das erklärt die verbreitetste Fehlplanung.

• Freitagnachmittag. Verlockend, weil danach Ruhe ist. Fatal, weil im Fehlerfall Ihr Plugin-Anbieter, Ihr Dienstleister und Ihr eigenes Team bis Montag nicht erreichbar sind. Ein Problem, das dienstags eine Stunde kostet, kostet freitags ein Wochenende.
• Das Weihnachtsgeschäft. Zwischen Black Friday und Jahresende ist jede Stunde Stillstand teuer und jeder Fehler im Bestandsabgleich sofort ein überverkaufter Artikel. Wer im Oktober nicht aktualisiert hat, aktualisiert im Januar.
• Kurz vor Inventur oder Monatsabschluss. Diese Termine binden dieselben Menschen, die im Fehlerfall Ihre Zahlen prüfen müssten.
• Ohne verfügbaren Ansprechpartner. Ein Update in der Urlaubswoche der einzigen Person, die die Sonderfälle im System kennt, ist ein vermeidbares Risiko.

Bewährt hat sich ein Termin früh in der Woche und außerhalb der Kernzeit, mit dem Folgetag als Puffer. Für den Handel bedeutet das in aller Regel Dienstag- oder Mittwochabend. Planen Sie das Fenster großzügiger als den gemessenen Testlauf, und sagen Sie dem Team vorher verbindlich, ab wann die Wawi steht und wann sie wieder freigegeben ist.

7. Der Ablauf in 7 Schritten

Die Tabelle oben ordnet die Komponenten. Diese sieben Schritte ordnen das Projekt über die Tage davor und danach — vom ersten Blick auf den Bestand bis zur Freigabe für das Team:

Schritt 07 ist der, den die meisten überspringen. Ein Update gilt nicht als gelungen, weil die Wawi startet, sondern weil ein vollständiger Geschäftsvorfall durchläuft. Wer stattdessen abends das Fenster schließt und morgens das Team ins Unbekannte schickt, verlagert die Fehlersuche in den Betrieb — und dann fehlt die Ruhe, die man für ein Rollback bräuchte.

8. Typische Fehlerbilder nach dem Update

Fast alles, was nach einem Versionswechsel gemeldet wird, fällt in eine Handvoll Muster. Die folgende Übersicht ordnet die Symptome, die wir in Kundenprojekten am häufigsten sehen, ihrer üblichen Ursache und dem sinnvollen ersten Handgriff zu:

Ein Muster zieht sich durch die Tabelle: Vier der sechs Fälle sind kein Softwarefehler, sondern ein Mischbetrieb — irgendein Teil des Systems steht noch auf dem alten Stand. Prüfen Sie deshalb bei jeder Störung nach einem Update zuerst die Versionsstände aller Beteiligten, bevor Sie in Logdateien einsteigen.

Beim Thema Datenbank raten wir zur Zurückhaltung. Reparatur- und Optimierungsbefehle auf einer SQL-Datenbank sind mächtig und im falschen Moment destruktiv. Ein Wartungslauf für Statistiken und Indizes ist Routine; alles, was tiefer greift, gehört auf eine Kopie und in geübte Hände — nicht in eine Nachtschicht nach einem missglückten Update.

9. Fazit: Die Vorbereitung entscheidet, nicht der Klick

Das eigentliche Update ist ein Setup und ein Assistent. Alles, was ein Update schwierig macht, passiert davor: die vergessene Erweiterung ohne Freigabe, die Sicherung, die nie zurückgespielt wurde, der Termin am Freitag, der Worker, der zu früh wieder anläuft. Wer diese vier Punkte im Griff hat, hat den Rest ebenfalls im Griff.

Machen Sie aus dem Ablauf eine Gewohnheit statt eines Ereignisses. Systeme, die zweimal im Jahr planmäßig aktualisiert werden, kosten uns in der Betreuung einen Bruchteil der Zeit von Systemen, die drei Jahre stehen geblieben sind — dort wird aus dem Update eine Migration mit eigenem Budget.

Versionsangaben und Systemvoraussetzungen ändern sich mit jeder Ausgabe. Stand dieser Angaben: 30. August 2026 — die geprüften Primärquellen finden Sie am Ende des Beitrags.

Sie planen einen größeren Versionssprung oder haben ein System, das seit Jahren nicht aktualisiert wurde? Wir übernehmen den JTL-Wawi Update-Service mit Plugin-Prüfung, Testlauf und Rücksicherung; geht es grundsätzlicher um Aufbau und Betrieb Ihres Systems, ist die JTL-Wawi-Beratung der richtige Einstieg. Wenn Sie zuerst wissen wollen, woran Sie einen passenden Partner erkennen, hilft unser Ratgeber JTL-Agentur finden. Und wer noch gar nicht so weit ist, findet den Schritt davor in der Anleitung zum Einrichten von JTL-Wawi.

10. Häufige Fragen zum JTL-Wawi-Update

Welche Version von JTL-Wawi ist aktuell?

Zum Stand 30. August 2026 bietet JTL-Software die Version 2.0.6 zum Download an, erstellt am 24. Juli 2026. Weil sich das laufend ändert, prüfen Sie die Version im offiziellen Changelog statt in Ratgebern. Entscheidend ist ohnehin nicht die neueste Version, sondern die neueste, die zu Ihren Plugins passt.

Wie aktualisiere ich die JTL-Datenbank?

Die Datenbank aktualisiert JTL-Wawi selbst. Nach der Installation des neuen Programmpakets startet beim ersten Öffnen der Update-Assistent und migriert das Datenbankschema; laut JTL-Guide legt er vorher automatisch eine Sicherung an. Sie wählen dabei, ob nur der aktuelle oder alle Mandanten aktualisiert werden. Starten Sie das an genau einem Arbeitsplatz.

Warum startet JTL-Wawi nach dem Update nicht mehr?

Meist hakt es an drei Stellen: Das Datenbank-Update wurde abgebrochen, ein Client läuft noch auf der alten Programmversion, oder die Zugriffsrechte auf den SQL Server stimmen nicht mehr. Prüfen Sie zuerst, ob alle Arbeitsplätze dieselbe Version haben. Ein abgebrochenes Datenbank-Update ist der Fall für die Sicherung.

Warum ist JTL-Wawi nach dem Update extrem langsam?

Nach einem Versionssprung ändert sich das Datenbankschema, und Statistiken sowie Indizes passen kurzzeitig nicht mehr dazu. Häufig kommt hinzu, dass der SQL Server als Express-Edition läuft und an deren Grenzen stößt: ein Gigabyte Arbeitsspeicher, vier Kerne, zehn Gigabyte Datenbankgröße. Prüfen Sie deshalb zuerst die Edition.

Wie kann ich eine ältere Version von JTL-Wawi installieren?

Ältere Programmstände finden Sie im Changelog-Bereich von JTL-Software. Das löst Ihr Problem aber nur halb: Die Datenbank wurde beim Update auf das neue Schema migriert, und dafür ist kein offizieller Rückweg vorgesehen. Ein echter Rückschritt gelingt deshalb nur über die Sicherung, die Sie vor dem Update gezogen haben.

Warum kann ich mich nach dem Update nicht bei JTL-Wawi anmelden?

Das deutet in unseren Projekten selten auf verlorene Benutzerkonten hin, sondern auf die Verbindung: Der Client greift auf eine Datenbank zu, deren Schema bereits aktualisiert wurde, während er selbst noch alt ist. Bringen Sie alle Arbeitsplätze auf denselben Stand. Bleibt es dabei, prüfen Sie Berechtigungen und Dienst des SQL Servers.

Was bedeutet der Fehler „JTL-Wawi DLL kann nicht geöffnet werden"?

Die Meldung betrifft die Programminstallation, nicht Ihre Daten. In unseren Projekten fehlt dann eine Programmdatei, weil das Setup unvollständig lief oder ein Virenscanner sie in Quarantäne verschoben hat. Schließen Sie JTL-Wawi überall, prüfen Sie die Quarantäne und führen Sie das Setup mit Administratorrechten erneut aus.

11. Quellen & Stand der Angaben

Versionsnummern, Systemvoraussetzungen und Update-Wege ändert JTL laufend. Alle folgenden Quellen wurden am 30. August 2026 geprüft; die Angaben in diesem Beitrag beziehen sich auf diesen Stand. Externe Quellen öffnen in einem neuen Tab.

• JTL-Guide — JTL-Wawi aktualisieren — die beiden Schritte Programmpaket und Datenbank-Update, die automatische Datenbanksicherung und die Auswahl der Mandanten (Hersteller-Primärquelle).
• JTL — Checkliste für das Update auf neue JTL-Wawi-Versionen — Datensicherung, SQL-Server-Vorprüfung, Beenden von Worker, Kasse und JTL-WMS, Adminrechte, Start an nur einem Arbeitsplatz, Hauptdatenbank vor Mandanten (Hersteller-Primärquelle).
• JTL — JTL-Wawi Download und Systemvoraussetzungen — Version 2.0.6 vom 24. Juli 2026 sowie die Grenzen der SQL Server Express Edition (Hersteller-Primärquelle).
• JTL — JTL-Wawi Changelog — Versionsübersicht und Bezugsquelle für ältere Programmstände (Hersteller-Primärquelle).
• JTL-Guide — Unterstützte Produktversionen — Grundlage für die Aussage, dass der Guide aktuell JTL-Wawi 1.11 und höher dokumentiert (Hersteller-Primärquelle).
• JTL-Guide — Unterstützte Versionen der JTL-Connectoren — Mindestversionen für den Connector-Betrieb, unter anderem Wawi 1.0.4.1 und 1.3.15 für Shopify (Hersteller-Primärquelle).