Shopware 6 vs Shopware 5: What Changed Under the Hood?

If you’ve spent years building on Shopware 5, transitioning to Shopware 6 doesn’t feel like a version bump—it feels like stepping into a different platform entirely. The surface-level similarities (product catalogs, checkout flows, multi-store capabilities) mask a complete architectural rewrite. Shopware didn’t just update its codebase; it rebuilt the foundation using modern PHP standards, decoupled service boundaries, and framework-driven conventions. With the arrival of Shopware 6.7, those changes have been refined, hardened, and optimized for performance and developer experience. Let’s explore what actually changed beneath the surface.

From Custom Monolith to Symfony-Aligned Core#

Shopware 5 relied on a tightly coupled, homegrown framework. Routing, service resolution, and event handling were managed through internal abstraction layers that diverged from industry standards. Shopware 6 discarded this approach entirely in favor of Symfony as its operational backbone. Every request now flows through a standardized HTTP kernel, enabling consistent middleware chains, predictable dependency injection, and native compatibility with PSR specifications.

Shopware 6.7 intensifies this alignment by enforcing PHP 8.2+ across the core, replacing deprecated annotation-based configuration with native PHP attributes, and standardizing namespace conventions. The dependency injection container is now fully compiled at runtime using php bin/console container:dump, resulting in faster service resolution and stricter type validation during development.

Templating & Frontend Infrastructure#

The most visible departure is the elimination of Smarty templating. Shopware 5’s .tpl files used custom modifiers, inline logic, and fragile inheritance chains. Shopware 6 migrated to standard Twig, enforcing namespaced template references (@Storefront/layout/base.html.twig) and separating presentation from business logic. This shift improves security, caching efficiency, and IDE autocompletion.

Beyond the classic PHP-rendered storefront, Shopware 6 introduced the Frontend Storefront (FES) architecture. Modern implementations leverage Vue.js components, Vite for development-time bundling, and asynchronous data fetching via native JavaScript APIs. Shopware 6.7 enhances this by introducing a component registration layer, improved SSR hydration patterns, and standardized prop typing across core FES elements.

{# Shopware 6.7: Structured Twig inheritance with typed context #}
{% extends base_template %}

{% block name_layout_head_meta %}
    <meta property="og:description" content="{{ page.seo_description | escape }}">
    <link rel="preload" href="{{ asset('assets/js/storefront/fetch-config.js') }}" as="script">
{% endblock %}

Plugin Lifecycle & Dependency Injection#

Shopware 5 plugins lived in custom/plugins/ and depended on directory conventions, hook listeners, and manual composer registration. While functional, this model made debugging difficult and encouraged framework coupling. Shopware 6 replaced hooks with a formal event system, requiring plugins to be registered as proper Composer packages with explicit service definitions.

In Shopware 6.7, the plugin architecture is even more disciplined. Public services must be declared in services.xml, private services default to internal scoping, and dependency injection is enforced via constructor wiring. The core also introduces stricter namespace validation and automated deprecation warnings during console commands, pushing developers toward composition over inheritance.

// Shopware 6.7: Event subscriber with explicit type contracts
final class ProductStreamFilterSubscriber implements EventSubscriberInterface
{
    public static function getSubscribedEvents(): array
    {
        return [
            ProductCriteriaEvent::class => 'onProductCriteria',
        ];
    }

    public function onProductCriteria(ProductCriteriaEvent $event): void
    {
        $criteria = $event->getCriteria();
        $criteria->addAssociation('cover');
        $criteria->setTitle('Filtered product stream');
    }
}

Administration, APIs & Developer Experience#

Shopware 5’s backend administration was a classic PHP MVC application that grew heavy with each version. Shopware 6 replaced it with a Vue.js single-page application. Navigation is now client-side driven, state is managed via centralized stores, and plugins extend the admin through custom API endpoints or Vue component injection.

Shopware 6.7 improves administrative developer experience by shipping standardized TypeScript interfaces for GraphQL responses, enhancing CLI scaffolding (bin/sw administration:create-extension), and introducing a redesigned plugin management panel with dependency graph visualization. The underlying REST/GraphQL APIs now enforce stricter schema validation and versioned routing, making third-party integrations more predictable.

Data, Caching & Console Tooling#

Under the hood, Shopware 6 normalized its database schema significantly. Foreign key constraints are enforced where possible, relational mapping uses Doctrine’s XML/YAML drivers, and migrations are fully version-controlled. The core abandoned manual SQL overrides in favor of structured migration classes.

Shopware 6.7 optimizes runtime performance through improved Redis session handling, accelerated cache warming via parallel console workers, and smarter query hydration strategies. The CLI ecosystem has been unified: configuration validation, plugin registration, and database synchronization now share a consistent command interface, reducing operational friction during deployments.

Migration Reality & Strategic Takeaway#

Moving from Shopware 5 to 6 isn’t a template swap or hook translation. It demands architectural reconsideration: embracing Composer dependency management, replacing event hooks with subscriber patterns, rebuilding custom backend modules as FES extensions, and adopting container-aware coding practices. Shopware 6.7 doesn’t just continue this trajectory—it solidifies it with stricter typing, faster tooling, and clearer extension guidelines.

If you’re planning an upgrade or starting a new project, the shift isn’t about learning new features; it’s about understanding how modern e-commerce platforms are built: decoupled, type-safe, framework-aligned, and deployment-ready. Shopware 6.7 makes that path cleaner, faster, and more maintainable than ever.