Future-Proof Shopware 6

Foundation for a Multi-Shop eCommerce Client

How Kiwee helped a multi-shop eCommerce client escape the limits of Shopware 5, and build a scalable, resilient eCommerce platform capable of growing with their business across multiple storefronts.

Diagram showing the migration from Shopware 5 to Shopware 6, supported by Kiwee and Shopware.

How Kiwee helped a multi-shop eCommerce client escape the limits of Shopware 5, and build a scalable, resilient eCommerce platform capable of growing with their business across multiple storefronts.

Brand Overview

Our client operates multiple online stores in the wood and outdoor products sector, serving customers across several European markets. The online channel is central to how the business reaches customers and scales beyond its physical store locations.

To grow confidently across multiple markets, the client needed a foundation that could do something most eCommerce setups are not designed for: run several distinct shops as efficiently as one. That meant shared frontend logic so improvements roll out everywhere at once, a shared design system to keep the customer experience consistent, centralised deployment so releases are never a per-shop coordination effort, and the flexibility to configure each storefront differently, different branding, pricing, and content, without duplicating the underlying work.

The goal was not just a better platform but an architecture that turns multi-shop operations into a competitive advantage rather than an operational burden.

The Challenge: Shopware 5 Was Becoming a Liability

Before collaborating with Kiwee, the client was operating on Shopware 5, with limited flexibility for a modern storefront experience and growing constraints for maintainability and future enhancements. Together, we migrated the platform to Shopware 6 and used this as the foundation for a long-term architecture that supports faster storefront iteration, a cleaner separation between backend and frontend, and a scalable path for operating multiple shops with a consistent customer experience.

Why staying on Shopware 5 was no longer viable

Scaling risk during seasonal peaks

The existing server setup, which was a bare-metal infrastructure with manual configuration, could not dynamically scale to absorb traffic spikes. Downtime during peak periods meant lost sales.

Line chart illustrating fluctuating platform load over time, including peaks that move into higher risk zones.

Operational overhead of manual infrastructure

Every deployment required manual intervention. Updates were time-consuming, error-prone, and slowed the team's ability to ship improvements.

Handwritten release checklist illustrating a manual deployment process with multiple steps, open questions, and uncertainty.

Cost of downtime and slow recovery times

In a multi-shop environment, a single failure could affect all storefronts simultaneously. Recovery times measured in hours, not minutes and created unacceptable business risk.

Illustration comparing two storefronts during downtime, with one shop restarting while the other waits to restart without a clear recovery time.

Together, these factors created growing pressure to modernize not just the platform, but the entire approach to infrastructure, deployment, and storefront management.

The solution

Kiwee migrated the client from Shopware 5 to Shopware 6 and rebuilt the entire foundation around three goals: run multiple shops without multiplying the workload, keep the platform stable under any traffic condition, and give the team the possibility to release enhancements or improvements quickly.

A Single Platform for All Three Shops

Diagram showing a central Shopware platform connected to three storefronts: shop.com, shop.de, and shop.at.

The starting point was migrating to Shopware 6, giving the client a modern, supported foundation and unlocking the architecture needed to run multiple storefronts efficiently.

From there, Kiwee built a shared frontend using Shopware Frontends with the Store API to connect to the Shopware backend, powering all shops from one place. In practice, that means:

  • A new feature or improvement is built once and lives across all shops, not repeated three times
  • All storefronts share the same design system, so the customer experience stays consistent without extra work
  • Releases are managed centrally. One deployment reaches all shops at the same time
  • Each shop still looks and behaves differently, with its own branding, pricing, and content, but those differences are managed as configuration, not separate systems
  • Directus CMS is built into the architecture, giving the team full control over what each shop shows and when, without needing a developer to make content changes

It's worth noting that running a headless multi-shop setup on Shopware Frontends was new territory, not just for the client but for Kiwee too. There was no production-ready blueprint to follow. That made the outcome more significant: what was built here is a validated, working model that others can now build on.

We picked up the project during its proof of concept phase, with little automation, no test coverage, and a lot of technical debt stemming from lack of structure. Over 1.5 years, we’ve managed to build a platform that enabled development and successful release of three different shops, all sharing the same underlying infrastructure and codebase. We took Shopware Frontends and leveraged its potential to the fullest extent.

Serhii Korzh
Senior Full Stack Engineer at Kiwee

Getting Headless to Perform Like It Should

One of the less obvious challenges with a headless architecture is that moving away from a standard Shopware storefront means giving up some of what comes out of the box, including years of performance optimization. Speed, stability, and consistency don't come for free in a headless setup. They have to be engineered deliberately.

That's exactly what Kiwee focused on: ensuring the headless storefront matched, and in key areas exceeded, what a standard Shopware setup would deliver. The result is a frontend that performs reliably under real conditions, not just in theory.

Infrastructure That Runs Itself

The old server setup required manual work to maintain, couldn't handle sudden traffic increases, and took hours to recover when something went wrong. The new infrastructure was designed to remove those constraints entirely:

  • The platform scales up automatically during busy periods and scales back down when traffic drops, with no manual action required
  • Releases happen weekly and sometimes even daily instead of monthly, with no downtime for shoppers
  • If something fails, the system recovers in minutes, not hours
  • The entire environment is consistent across development, testing, and production, so what works in testing works in the live shop
  • Performance is tested under real load conditions before anything reaches customers

Key improvements

The improvements delivered through this project translate directly into business outcomes for the client’s operations, team, and customers.

Deployment
frequency

From monthly →
weekly and even daily releases

Recovery time
from failure

From hours →
under 10 minutes

Infrastructure
at peak load

Stable under 48,000+ daily visitors

Uptime SLA
achieved

99.9%+

Beyond the numbers, the platform now delivers four capabilities that directly support business continuity and growth:

  • If part of the system fails, the shop stays online across all three storefronts
  • The system automatically detects and fixes minor issues without manual intervention
  • The team can release new features daily without interrupting shoppers or requiring downtime windows
  • Infrastructure scales during busy periods and shrinks during low traffic, without manual action

Shopware Features Leveraged by the client

Beyond the platform migration, the project made deliberate use of Shopware 6's native capabilities to support the specific needs of a multi-shop, high-traffic operation.

  • Shopware Frontends The headless frontend framework that connects to the Shopware backend via the Store API, enabling a fully customised customer experience across all three shops.
  • Store API The interface between the Shopware backend and the Nuxt-based frontend, powering the headless storefront architecture.
  • Rule Builder Allows complex business logic to be configured without custom code, giving the team flexibility to define conditions for promotions, pricing, and content.
  • Flow Builder Automates workflows and business processes, reducing manual tasks and keeping operations running consistently across shops.
  • Custom Pricing Supports differentiated pricing strategies per shop or customer segment, without duplicating product data.
  • Multi-Warehouse Manages stock across multiple warehouse locations, ensuring accurate inventory data for all three storefronts.
  • Returns Management Handles the returns process natively within Shopware, keeping operations streamlined and consistent.

Current State & Future Outlook

Today, the client operates three storefronts on a modern Shopware 6 platform, backed by a headless architecture using Shopware Frontends and the Store API, a Nuxt-based customer-facing experience, Directus CMS for content, and a fully automated cloud infrastructure.

From a customer perspective, the platform delivers a consistent experience across shops, stays reliable during busy periods, and handles traffic spikes without disruption. Releases happen daily without interrupting shoppers. Monitoring and performance testing are in place to catch issues early, before they reach customers.

Looking ahead, this foundation gives the client a scalable path to keep improving. New features can be shipped faster. Content can be updated independently. Infrastructure adjusts automatically to demand. And the multi-shop setup can grow without adding proportional operational complexity.

Back to top