JTL-Wawi 2.x: check your shop integration before upgrading

Since the stable release of JTL-Wawi 2.0 in March 2026 (JTL-Software), retailers have been asking when the version jump is worth it. There is no time pressure at the moment: the vendor lists JTL-Wawi 2.1, 2.0 and 1.11 as supported versions and gives no end date for 1.11 (JTL-Guide). The path cannot be shortened, though: from a version below 2.0, the only way to 2.1 leads through 2.0.x (JTL-Guide). This guide shows what to check in the JTL-Wawi integration of your online shop before each stage: connector releases, shop and PHP version, SQL Server, Ameise templates, shipping and a test system that does not touch the live shop.

Which versions the vendor supports

On its page about supported product versions, the JTL-Guide names three versions of JTL-Wawi: 2.1, 2.0 and 1.11 (JTL-Guide). This list is more than a support promise. The vendor states there that adjustments are only made for the listed versions (JTL-Guide). If, for example, the interface of a marketplace or a shipping provider changes, the adjustment only arrives in the listed versions. For older versions, such adjustments are accordingly no longer planned.

The move from 1.11 to 2.0 is also a move to a new versioning scheme. With 2.0, JTL-Software introduced semantic versioning and converted the application to .NET 8, which according to the vendor involves new system requirements (JTL-Software). Minor versions such as the step from 2.0 to 2.1 are meant to be backwards compatible as a rule (JTL-Software). The vendor describes major versions differently:

These large version jumps mark a new development step in the software, which can be accompanied by far-reaching technical changes or extensive new functions – as is now the case with the change from JTL-Wawi 1.11 to 2.0.

JTL-Software, blog post on the stable release of JTL-Wawi 2.0, 17 March 2026

The upgrade path: via 2.0.x to 2.1

The JTL-Guide leaves no room here: from a version below JTL-Wawi 2.0 you cannot update directly to 2.1 or higher. If an older version is installed, you first update to 2.0.x and then to 2.1.x (JTL-Guide). One update thus becomes two, and each of them includes a database update that the update wizard starts at the first login after installation (JTL-Guide).

1. Record the starting point: note the versions of JTL-Wawi, connector, shop system, PHP and SQL Server, plus every connected third-party system and every custom query.
2. Stage 2.0.x: update in the test system first, then in production. Afterwards, check syncs, workflows and templates.
3. Running on 2.0.x: let real syncs run for a few days and clear up anything unusual before the next stage begins.
4. Stage 2.1.x: again in the test system first, then in production, with the same checks as in the first stage.

Before every update, JTL-Wawi automatically creates a database backup that lets you return to the previous version (JTL-Guide). This does not replace your own backup in a second location, but it makes the way back easier. More important for planning is storage space: according to the vendor's step-by-step guide, the database grows to almost twice its size during the update (JTL-Guide). With SQL Server Express this can hit the size limit of the edition, because Microsoft caps the relational database at 10 GB in SQL Server 2022 Express and at 50 GB in SQL Server 2025 Express (Microsoft).

-- Show version and edition of the SQL Server
SELECT @@VERSION;

-- Show the space used by the selected database
EXEC sp_spaceused;

The first query shows version and edition of the SQL Server, the second the space used by the currently selected database. If the database is already close to half the Express limit, the clean-up or the change of edition belongs before the update. In this case the vendor recommends cleaning up and optimizing the SQL Server or switching to a full version (JTL-Guide).

What changes in the background with 2.0

The switch to .NET 8 is hardly visible on the surface, but it affects the computers JTL-Wawi runs on (JTL-Software). In the system requirements, the JTL-Guide names Windows 11 for workstations and SQL Server 2022 as the recommended version for the database server. The vendor does not support Azure SQL databases or instances of shared SQL Servers (JTL-Guide). If your Wawi runs at a service provider or on a rented server, asking about these requirements is the first step.

For shop integrations, the changelog is more revealing than the release announcement. For version 2.0.0 it lists, among other things in the connector sync area, that connector shops can send warnings during the sync and that importing customers, orders and payments during a running sync no longer has to wait for the next sync (JTL-Software Changelog). In the Wawi app area, the same version carries the entry “Alte Rest-API entfernen”, meaning the old REST API is removed (JTL-Software Changelog). Which interface a custom integration uses should therefore be clarified before the update.

Checking the shop integration: releases, shop version, PHP

For its connectors, the JTL-Guide maintains a list of released shop versions. For Shopware 6 it names versions 6.1 to 6.7.9, for WooCommerce versions 3.0 to 8 (JTL-Guide). The shop systems themselves move faster: Shopware released version 6.7.15.1 on 7 October 2026 (Shopware), and the WordPress plugin directory shows WooCommerce at version 11.2.1 (WordPress.org, as of 14 October 2026). The guide itself points out that further shop versions may be supported that have not yet been released (JTL-Guide).

With WooCommerce, the shop's PHP version comes into play. The connector for WooCommerce requires at least PHP 8.1, while the connectors hosted by the vendor, including the one for Shopware 6, automatically use suitable PHP versions (JTL-Guide). A minimum requirement is not a recommendation: support for PHP 8.1 ended on 31 December 2025 (php.net). How to move a WordPress shop to a current PHP version is covered in our guide on the end of support for PHP 8.2.

For the Shopware 6 connector, one rule stays important with every update: after installation and the first data sync, the ERP leads, and changes to products, categories and other data are then made exclusively in JTL-Wawi (JTL-Guide). Anyone who keeps editing in the shop backend risks that a later sync overwrites these changes. Before a version jump it is worth checking whether such habits have crept in. How the integration is built in principle is described in our practical guide to JTL-Wawi and Shopware 6.

Number ranges, customer groups and fields

• Number ranges: if the sales channel takes over the order number from the shop, the number ranges must be configured differently, otherwise errors can occur in JTL-Wawi (JTL-Guide).
• Customer groups: if a shop update introduces, for example, an additional customer group, it must also be created in JTL-Wawi (JTL-Guide).
• Meta descriptions: Shopware accepts at most 255 characters for the meta description, longer texts prevent the sync; the settings of the connector license offer a shortening option for this (JTL-Guide).
• Custom fields: an option of the connector license determines whether custom fields for products and categories are transferred to the shop. After the update it belongs on the checklist, as do additional fields from plugins.

The test system: run every stage first

Especially for larger version jumps, the vendor recommends carrying out and testing the update in a staging environment first (JTL-Guide). To test a new Wawi version, the JTL-Guide describes a second installation with its own, initially empty database. An additional client in the existing installation, by contrast, is only suitable for connecting new third-party systems or further products (JTL-Guide). For the second installation the vendor recommends an independent computer or server, and existing customers can obtain a separate staging license to prepare an update (JTL-Guide).

• Test system on its own computer or server, not next to the production database
• Switch off all database syncs before importing the copy of the production database (JTL-Guide)
• Connect the connector only to a test shop and under no circumstances to the production shop (JTL-Guide)
• Test shop with the same shop version, the same plugins and the same PHP version as the live shop
• Leave out marketplace syncs: as a rule they cannot be run with the staging database, and an additional marketplace account for the test environment is not possible (JTL-Guide)
• Define test cases in advance and document the results for each stage

Which test cases you need follows from your processes: an order from the test shop through to the invoice, a stock change in the Wawi through to the shop, a product with variants and tiered prices, a label print and a run with every Ameise template used in production. If you serve several channels, add the stock logic we describe in our article on real-time inventory sync across channels.

Update day: keep to the order

In its step-by-step guide, the vendor names prerequisites that should be met on update day: administrator rights, a wired network connection instead of Wi-Fi, a supported SQL Server version, sufficient storage space and confirmed compatibility of the third-party systems in use (JTL-Guide). The update itself should run between Monday and Thursday during the working hours of the support team or the service partner, so that help is available if problems arise (JTL-Guide).

1. Before: log off clients and users, stop JTL-Worker, deactivate workflows and, if needed, stop the WMS Mobile service (JTL-Guide).
2. Update: update JTL-Wawi, do not cancel the process and then bring the other workstations to the same version promptly (JTL-Guide).
3. Right after: link the client to the customer account, activate and check workflows, start JTL-Worker, check tax settings and file permissions (JTL-Guide).
4. Templates: check print, email and export templates including DotLiquid variables, and the Ameise templates with test imports and test exports (JTL-Guide).
5. Custom reports: check the SQL queries of your custom overviews and adjust them if needed.

With two updates in a row, this list runs twice. A few days of live operation should therefore lie between 2.0.x and 2.1.x, so that the syncs have run under real load. Only then will it show whether the checks in the test system reflected everyday operations.

After the update: sync, Ameise and shipping

JTL-Worker syncs product-related data such as stock levels and images with the shop at the chosen interval and imports customer orders into JTL-Wawi (JTL-Guide). After the update, the first sync is therefore watched closely: do new orders arrive, are stock levels and prices in the shop correct, does the sync report warnings? With JTL-Worker 2.0, the intervals per sales channel are set in the menu for the Worker status (JTL-Guide). Looking at these settings is part of the post-update routine.

If you offer parcel shops and pickup stations in checkout, also check whether the different delivery address arrives in the Wawi in full and ends up on the label. How to offer these options properly is described in our article on parcel shops and pickup lockers in checkout.

Choosing the timing calmly

As long as 1.11 is on the list and no end date is given, the timing is set by your own operations rather than by the vendor's calendar. A suitable period is one in which order volume and staff leave room and no larger shop update is due in parallel. Anyone who upgrades Wawi, connector and shop at the same time can later no longer assign an error in the sync to either side.

• In favor of an early update: you want to use the changes to the connector sync that the changelog lists for version 2.0.0 (JTL-Software Changelog), or your version is no longer on the list of supported versions (JTL-Guide).
• In favor of a later update: an extensive shop update is due, custom interfaces have not yet been checked or the test system has not yet been set up.
• In both cases: plan time for live operation between the 2.0.x and 2.1.x stages and schedule the update week so that support is available.

Stocktaking belongs in the plan as well. If you count with JTL-Wawi at the turn of the year, do not put the update on the counting days, because stock postings and a running version jump do not go well together. Notes on counting during operations can be found in our article on stocktaking in shop operations.

How we support the version jump

We look after interfaces between ERP, shop and marketplaces and prepare Wawi updates so that the shop integration is not first tested in live operation. Depending on the starting point, we take over individual steps or the entire process, for Shopware as well as for WooCommerce shops.

If your Wawi database runs on its own server, its condition is part of it: SQL edition, free storage and backups. For the shop itself we offer hosting and maintenance so that shop version and PHP level match the connector's release list. If you are planning the version jump, you can reach us via the contact form.