What we use WooCommerce for
The typical WooCommerce client already has a WordPress website and now wants to sell: a manufacturer with a handful of products, a publisher with its publications, a business with accessories for its own range. The range is manageable, prices are the same for everyone, shipping and payment are standard. For that case a Shopware stack of its own is effort without return — editorial content and shop stay in one system, and there is only one installation to maintain.
The second case is the trial. A company wants to know whether direct sales work at all before it invests in a large shop. WooCommerce is a legitimate first step for that, as long as it is clear from the outset that it can be a first step. So we set the product data up in a way that lets it be carried over later, and we document which extensions are in use for what.
How we work with WooCommerce
The shop is built in the existing theme, not in a second layout that resembles the first. We adapt product templates, basket and checkout through template overrides and hooks instead of bending core functions. Payment runs through the established gateways, shipping through rule-based zones. Where data comes out of an ERP system, we work through the WooCommerce REST API — CSV import as a daily routine is a source of errors you can see coming.
In operation, the same rule applies to WooCommerce as to WordPress, only more sharply: a shop processes order and payment data. Updates to core, theme and extensions go to staging first, then live. Every additional extension is examined, because it can intervene in the order process. Add to that backups, monitoring and an eye on load time — a shop that falls over at peak load costs revenue at exactly the moment it counts.
Limits: when we advise Shopware 6
The limit is reached as soon as B2B comes into play. Customer-specific prices, volume tiers, customer hierarchies, quotations, approvals, punch-out: all of it can be imitated in WooCommerce with extensions, and that is exactly the problem. You end up with a stack of plugins from different vendors meeting each other in the order process. Nonsense implemented cleanly is still nonsense. In cases like that we build the shop on Shopware 6.
The second limit is the range. If the catalogue grows sharply, if many variants are added, or if stock is to come continuously out of an ERP system, WooCommerce runs into its own structure: product data sits in WordPress's postmeta tables, and filter and search queries become expensive accordingly. Since WooCommerce 8.2, order management has been held in tables of its own with HPOS, and that is the default for new installations; existing shops, however, have to make the switch themselves. Product data is untouched by this. We migrate shops like that to Shopware 6, including product data, customers, orders and URL redirects.