Written by Jonas Landgård from Haus
WooCommerce to Vendure
How Haus moved Bad & Värme off WooCommerce without rebuilding the website. Commerce went to Vendure, WordPress and Elementor stayed, and the website rebuild became a separate decision.
- Implementation
6–12 weeks
What Haus would plan for a comparable retrofit today. The CMS, the content and the editors stay where they are, so none of that work is in the estimate.
- Content migrated
0 pages
No editorial content moved. WordPress, Elementor, the existing page structure and the member companies editing their own pages all stayed as they were.
- Catalogue
50,000
Variants in Vendure today, from roughly 5,000 at launch, as product data outgrew the 4,000 products the website had ever marketed.
- Cutover
May 2025
Commerce went live on its own. A website rebuild is still a separate decision, and so far nobody has had to make it.
The short version
A WooCommerce replatform does not have to become a website rebuild. Bad & Värme had reached the point where product data, pricing, campaign logic and commerce behaviour were too complex to keep inside the WordPress site.
But the website still carried real value: non-commerce content, established SEO and page structures, and a distributed editorial model where member companies managed their own pages. Replacing the CMS and the storefront at the same time would have added a second project on top of the first, with its own information architecture, design, content migration, editorial tooling, training and support.
So we separated the two decisions. WooCommerce stopped being the commerce engine, Vendure took over product data and commerce, and WordPress and Elementor stayed where they were.
The whole migration in four moves
- 1
Leave the website alone
WordPress, Elementor, the existing content and the member companies editing their own pages carry on exactly as before.
- 2
Model products and prices in Vendure
Variants, supplier and RSK identifiers, and the five different things the business called a price become a domain of their own.
- 3
Swap commerce inside Elementor
WooCommerce comes out. Vendure-backed components drop into the pages editors already know, so nobody has to learn a new publishing tool.
- 4
Cut over commerce only
One release, one system replaced. The website rebuild stays available as a later decision rather than a dependency of this one.
Every one of those moves has a chapter below, including the parts that went wrong. The order is the point: nothing in this project required the website to change.
Who this approach is for
This pattern makes sense when the ecommerce engine has become a constraint and the website around it has not. Bad & Värme is a member organisation for plumbing businesses. Its 2024 brief described a price list of roughly 75,000 articles, while only around 4,000 products were actively marketed online, and the Vendure catalogue started at roughly 5,000 variants before growing to around 50,000 as more of the full product range moved in.
The website was also much more than a shop. It held member pages, local pages, service content and editorial material, and many member companies had users who edited their own pages in WordPress, so changing the CMS would have changed how those people worked and brought content migration, editor training, permissions, workflows and support with it. None of that was needed to solve the commerce problem.
Why they moved commerce out of WooCommerce
WooCommerce had served the business well, and the problem was not that it had suddenly become unusable. By 2023, WordPress and WooCommerce were carrying product data, pricing, commerce behaviour, search, storefront presentation and several operational workflows. Product data was hard to reuse outside the site, some exports needed manual enrichment, search was tied to WordPress, and large catalogue jobs slowed the website down.
The other problem was maintainability. The existing setup could have solved most individual requirements, but only by adding more plugins, more custom integrations and more code written for this project alone. The question was never whether a feature was possible. It was what the combination would cost to keep working as requirements grew.
Four requirements pushed the project past a checkout replacement:
- A central store of product data that was not tied to the website.
- Pricing and campaign pricing as a proper domain rather than a single product field.
- Import and export flows that could run at catalogue scale.
- A setup cheaper to maintain than another layer of custom code on the old stack.
Bad & Värme evaluated several commercial and open-source platforms. Economics were a large part of the decision: they accepted more implementation work in exchange for a lower recurring licence cost than the commercial alternatives they had looked at.
Long-term ownership mattered too. For a platform they expected to depend on for years, avoiding unnecessary lock-in was important. Vendure gave their own development team direct API access and room to extend the platform around their product and commerce model.
Product and campaign material for stores is generated from the same Vendure-backed product data, alongside several other integrations. In practice, Vendure became both the commerce engine and a central product-data platform.
What we moved, and what we deliberately did not
We kept WordPress, Elementor, the existing editorial content, member editing workflows and much of the existing customer-facing experience.
We moved or rebuilt the product model, pricing and campaigns, product import and export, product listing and detail behaviour, variant handling, cart and checkout, and the integration between Vendure and WordPress.
The initial product population was not a straight database transfer. We combined WooCommerce exports with supplier files and other source data, then consolidated them into one import file that created the product data in Vendure.
We did not migrate customer records or historical orders. The old site had mainly acted as a lead and quotation generator for Bad & Värme's member companies, which owned the end-customer relationship, so carrying that history into the new platform had limited value. That became a useful migration principle: move what the future system needs, not everything the old database happens to contain.
Define the product and commerce domain
The difficult part was not moving rows between databases. It was deciding what the target model needed to represent. The product domain covered variants, categories, documents, assets, Swedish plumbing-industry product identifiers (RSK numbers), supplier identifiers, energy labelling, installation information, bundles and product relationships.
Pricing was a domain of its own. A single variant could carry a list price, an installation-related price, several purchase prices, campaign prices and price history. We separated product import, price import and campaign pricing instead of treating price as one field on a product.
Building import flows that survive launch
We did not build the import tooling as a one-off script. Bad & Värme needed to keep importing and updating product information after launch, so the importer ran through Vendure's admin and job queue, created or updated products using stable identifiers, handled larger datasets, and grew to cover update-versus-replace behaviour for facets and assets. The migration mechanism became production infrastructure. If the data flow has to survive launch, build it as an operational capability from the start.
The real production data reached us long after the main implementation work was complete, and it exposed edge cases that representative datasets had not.
If I could change one thing, I would get the real production data into the project much earlier. Representative test data got us a long way, but the real catalogue exposed edge cases we had not foreseen. By then, some of the implementation was already settled and had to be adjusted.
Replacing commerce inside WordPress
We removed WooCommerce, and WordPress stayed. We integrated Vendure-backed storefront components into Elementor, so editors kept working in the environment they already knew while product details, prices, cart and the rest of the commerce functions came from the new backend.
We were building many of those components and integration techniques for the first time. We now have reusable storefront components and an established WordPress and Vendure integration pattern, which is why we would not use this project's final effort as a benchmark for the next one.
Cutting over commerce, not the whole organisation
We released to production in May 2025. The date had moved several times because other dependencies also had to be ready, including work on the customer side. Implementation time and time to launch are not the same thing. The cutover itself covered product synchronisation, URLs and redirects, functional testing, production infrastructure and DNS.
What we kept, and what we rebuilt
Kept
- WordPress as the CMS.
- The existing content and its SEO.
- Elementor editorial workflows.
- Member companies editing their own pages.
- The existing page structure.
Rebuilt or left behind
- The commerce backend, now Vendure.
- The product and pricing model, redesigned.
- Import and export flows, built as production tooling.
- Cart and checkout, integrated into Elementor.
- Customer records and order history, deliberately not migrated.
A future website rebuild is no longer tied to the commerce migration. If WordPress later becomes a constraint, it can be replaced against a commerce and product API that already exists.
Four things we learned
Separate business requirements from inherited behaviour
The old site easily became the implicit specification. We sometimes reproduced checkout details, URL behaviour, variant interactions and visual patterns because they existed, not because they were still worth anything.
We now ask the question earlier. Is this a business requirement, or behaviour inherited from the old implementation?
Treat pricing as a domain, not a field
Price turned out to mean list price, installation price, purchase prices, campaign prices and price history. Those concepts reached into imports, display, filtering and campaign logic.
We would define the price model before building the import and storefront behaviour around it.
Get the production data in early
Representative test data carried the implementation a long way. The real catalogue did not arrive until the main work was done, and the edge cases it exposed forced parts of the implementation to be corrected or reworked.
Bring the real data path into the project while the architecture is still cheap to change.
A retrofit saves more than development time
Keeping WordPress did not only save us from rebuilding pages. It avoided pushing a distributed organisation through a new publishing model at the same time as the commerce migration.
That organisational cost is easy to miss when platforms are compared feature by feature.
Effort and team shape
For a comparable retrofit today we would expect roughly 6 to 12 weeks of implementation, and the biggest variable is how much of the existing solution has to be reproduced exactly. Projects move faster when the customer will simplify legacy behaviour instead of treating the current implementation as the specification, and external integrations, supplier dependencies, internal rollout and training can all stretch the calendar without adding scope.
The delivery team can stay small. Our tech leads also act as the main customer contact, which keeps technical decisions close to the business context, and a retrofit needs less standalone UX and design work than a full rebuild because much of the customer experience is deliberately retained. We get a working environment running early and close the highest-risk questions first: the product and pricing models, real data, integration boundaries, and the connection between the storefront and Vendure. The aim is to make the structural mistakes while they are still cheap to change.
Go-live and afterwards
Bad & Värme went live with the new commerce architecture in May 2025. The first days produced several smaller integration issues rather than one large commerce failure, and they sat where the new commerce layer met the retained WordPress: WordPress intercepted some redirects before the redirect plugin ran, some product slugs needed better handling, custom Elementor code caused a problem with tracking-code setup, and static-file requests needed investigation. We resolved most of them within the following days.
The architecture has since grown beyond the website, and Vendure now provides product data through APIs used by Bad & Värme's own development work and downstream processes. The website stayed in WordPress. That was a deliberate separation of concerns, not an unfinished migration.
Where this approach does not fit
We would not recommend this architecture simply because a company happens to use WooCommerce. If the catalogue is straightforward, pricing is simple, integrations are limited and WooCommerce is not materially constraining the business, adding a separate commerce backend may create more complexity than value.
The phased approach is most useful when the existing website still holds real value, the commerce layer has become a constraint, product data needs to serve more than the storefront, or a CMS migration would force substantial organisational change. If the website, CMS, information architecture and brand experience all genuinely need to change now, a clean rebuild may still be the better decision. Replacing commerce and replacing the website are two different decisions, and they should only be coupled when there is a reason to.
Planning a WooCommerce to Vendure migration? Contact Haus.
Jonas Landgård
Head of Haus Tech, Haus
Jonas Landgård leads Haus Tech and helps companies make better decisions about ecommerce, digital products and technology. He is usually involved early to understand what the business is trying to achieve, uncover needs or constraints that are not yet obvious, and shape a solution that is practical to build and sensible to own over time. He has led several commerce projects, including migrations from WooCommerce to Vendure.
The author's views are their own and may not reflect the views of Vendure.
Planning the move?
Bring the plugin stack your WooCommerce build accumulated, and the WordPress site around it. A partner who has run this migration, or our own engineers alongside your team, will sort it into what moves, what gets rebuilt and what stays exactly where it is before anyone writes code.
