Shopware 5 auf Shopware 6: Warum die Migration der richtige Anlass ist, die Suche neu zu denken

Der Migrations-Moment als Such-Replatform-Chance

Viele Shopware-Händler vor der Migration fragen sich: Lohnt es sich, ausgerechnet den Such-Layer im Zuge des Umstiegs von Shopware 5 auf Shopware 6 grundsätzlich neu aufzusetzen? Ja, denn in der Migration werden Datenmodell, Plugin-Stack und Storefront ohnehin angefasst, und genau dieses Fenster macht eine Such-Replatform strukturell günstig und risikoarm. Wie sich diese Weichenstellung im Projektalltag anfühlt, zeigt der folgende Blick in einen typischen Migrations-Workshop.

Es ist Dienstagvormittag in einem mittelgroßen DACH-Shop für Heimtextilien, der CTO sitzt in einem Workshop-Raum mit drei Bildschirmen voller Migrations-Notizen. Auf dem linken Bildschirm läuft die alte Shopware-5-Instanz mit etwa achtundzwanzigtausend Artikeln, einem über die Jahre gewachsenen Plugin-Stack und einer Such-Logik, die in Teilen aus dem Shopware-5-Default und in Teilen aus drei Custom-Erweiterungen besteht. Auf dem mittleren Bildschirm steht ein Datenmodell-Diagramm der Ziel-Plattform Shopware 6 mit allen Entity-Mappings, die das Migrations-Team in den vergangenen Wochen erarbeitet hat. Auf dem rechten Bildschirm läuft eine Tabelle mit etwa zweihundertvierzig offenen Migrations-Entscheidungen, die das Team in den nächsten Wochen treffen muss.

Eine dieser Entscheidungen heißt "Search Layer". Die Zeile ist seit drei Tagen offen, weil das Team intern uneinig ist, was hier passieren soll. Die einfache Variante: die Shopware-6-Default-Suche aktivieren, die Custom-Tweaks aus Shopware 5 so weit wie möglich portieren, ansonsten alles wie gehabt. Die andere Variante: die Migration als Anlass nehmen, die Such-Architektur grundsätzlich neu aufzusetzen, weil das Datenmodell ohnehin durchgegangen wird, die Custom-Felder ohnehin neu gemappt werden, der Plugin-Stack ohnehin neu installiert wird und die Such-Tabellen ohnehin neu indexiert werden.

Diese Entscheidung ist nicht eine technische Detail-Frage. Sie ist die strategische Weichenstellung, die bestimmt, ob der Shop in zwölf Monaten mit derselben Such-Realität wie heute lebt oder ob er die Migration als operative Reset-Chance nutzt. Wer im Such-Bereich nichts ändert, hat in zwölf Monaten Shopware 6 mit Shopware-5-Such-Erfahrung. Wer im Such-Bereich strukturell neu aufsetzt, hat in zwölf Monaten Shopware 6 mit einer Such-Architektur, die auf moderne Standards passt. Die Migrations-Welle, die im DACH-Raum gerade durch die Mid-Enterprise-Shops zieht, schafft genau dieses Fenster der Möglichkeit, und wer es ungenutzt vorbeiziehen lässt, baut sich für die nächsten Jahre eine Such-Realität, die strukturell veraltet ist, bevor sie überhaupt produktiv geht.

Dieser Artikel beschreibt, warum die Migration der richtige Anlass für eine Such-Replatform ist, welche Bruchstellen im Such-Bereich zwischen Shopware 5 und Shopware 6 ohnehin angefasst werden müssen, was aus dem alten System sinnvoll mitwandert, was strukturell neu aufgesetzt gehört und wie eine moderne Such-Infrastruktur in die Shopware-6-Architektur integriert wird, ohne dass das Migrations-Projekt um Monate verlängert wird. Eine grundsätzliche Behandlung der Shopware-Such-Optimierung haben wir in unserem Pillar-Beitrag zur Shopware-Suche durchgeführt, der vorliegende Artikel überträgt das gleiche Grundprinzip auf den Migrations-Kontext.

Status der Migrations-Welle: Warum die Frage gerade jetzt aktuell ist

Warum wird die Migration von Shopware 5 auf Shopware 6 gerade jetzt für so viele Shops konkret?

Die Migration von Shopware 5 auf Shopware 6 ist keine plötzliche Welle, sie ist eine seit Jahren angekündigte Verschiebung, die jetzt in die operative Realität vieler DACH-Shops fällt. Shopware 5 hat den offiziellen End-of-Life-Status im Juli 2024 erreicht, was bedeutet, dass keine Sicherheits-Updates, keine Bug-Fixes und keine neuen Plugin-Versionen für die Plattform mehr veröffentlicht werden. Die Phase der erweiterten Long-Term-Support-Verträge läuft für viele Shops bis Mitte 2026 aus, was das Migrations-Fenster für eine relevante Mengen-Schleppe an Mid-Enterprise-Shops auf das Jahr 2026 und die erste Hälfte 2027 verschiebt.

Diese zeitliche Verteilung erklärt, warum die Migrations-Diskussion gerade jetzt eine sichtbare Welle in der DACH-Community erzeugt. Shopware-Agenturen berichten von einer Dichte an Migrations-Projekten, die in der ersten Hälfte 2026 die Kapazitäten überschreitet. Shops, die bislang in der Beobachter-Rolle waren, müssen jetzt operative Entscheidungen treffen, weil das Zeitfenster bis zum LTS-Ende konkret wird. Wer im zweiten Halbjahr 2026 noch nicht in der Migrations-Vorbereitung ist, läuft Gefahr, ohne Sicherheits-Patches in den nächsten Compliance-Audit zu gehen.

In dieser Situation steht der Such-Layer typischerweise nicht ganz oben auf der Migrations-Prioritäten-Liste. Die Aufmerksamkeit liegt auf der Daten-Migration der Artikel, der Bestellungen, der Kundenkonten, auf der Anpassung des Templates, auf der Portierung der Custom-Plugins, auf der Integration mit dem ERP und dem PIM. Die Such-Funktion gilt als Default-Feature der Plattform, das mit der Standard-Installation mitkommt. Diese Wahrnehmung ist nicht falsch, aber sie unterschätzt strukturell die Tragweite, die der Such-Layer auf die Shop-Performance hat, und die Hebel-Wirkung, die eine bewusste Such-Replatform-Entscheidung im Migrations-Moment entfaltet.

Wir haben in unseren Beiträgen wiederholt gezeigt, dass die interne Suche in einem Mid-Enterprise-Shop typisch zwanzig bis vierzig Prozent der Conversion über alle Sortimente trägt. Wer in dieser Größenordnung über die Migration entscheidet und den Such-Layer in der Default-Konfiguration mitwandert, lässt einen der wichtigsten Conversion-Hebel ungenutzt. Wer dagegen die Migrations-Phase nutzt, um den Such-Layer strukturell auf eine moderne Architektur zu heben, holt sich einen direkten Umsatz-Effekt, der die Migrations-Investition mehrfach amortisiert.

Wo Shopware 5 und Shopware 6 sich im Such-Bereich strukturell unterscheiden

Lässt sich die Such-Konfiguration aus Shopware 5 einfach eins-zu-eins nach Shopware 6 übernehmen?

Die Shopware-6-Default-Suche ist nicht ein Update der Shopware-5-Default-Suche, sie ist eine grundsätzlich neue Implementierung. Die Architektur, die Konfigurations-API, die Erweiterungs-Punkte und die Daten-Schicht haben sich strukturell verändert. Wer aus Shopware 5 kommt und glaubt, dass die alten Such-Konfigurationen eins-zu-eins migrierbar sind, läuft in eine Lücke, die sich erst im laufenden Betrieb zeigt.

Erste strukturelle Veränderung: das Datenmodell. Shopware 5 hat Artikel in einer relational klassischen Struktur abgebildet, mit Hauptartikel und Varianten in einer flachen Hierarchie. Shopware 6 hat das Entity-Modell mit einer streng typisierten DAL (Data Abstraction Layer) neu aufgesetzt, die Artikel als Product Entities mit eigenen Varianten-Beziehungen abbildet. Was in Shopware 5 als Custom-Attribut an einem Artikel hing, lebt in Shopware 6 in einer Custom-Field-Set-Struktur, die anders adressiert wird. Eine Such-Konfiguration, die in Shopware 5 auf bestimmte Custom-Attribute zugriff, kann in Shopware 6 nicht einfach den gleichen Pfad ansprechen.

Zweite Veränderung: die Search-Konfiguration. Shopware 5 hatte eine Backend-Maske, in der Such-Felder mit Gewichtungen versehen und Tippfehler-Toleranzen eingestellt werden konnten. Shopware 6 hat diese Logik in eine API-getriebene Konfiguration verschoben, die granularer aber auch anspruchsvoller in der Pflege ist. Eine Migrations-Verlagerung dieser Konfiguration ist nicht automatisch, sie verlangt eine bewusste Mapping-Arbeit pro Such-Feld und pro Custom-Konfiguration.

Dritte Veränderung: die Performance-Architektur. Shopware 5 hat die Suche im monolithischen PHP-Prozess abgewickelt, mit MySQL als Backend und einer eigenen Caching-Schicht. Shopware 6 unterstützt nativ Elasticsearch als Such-Backend, was eine andere Konfigurations-Logik, eine andere Index-Pflege und eine andere Skalierungs-Strategie verlangt. Wer aus Shopware 5 kommt, hat in der Regel keine Elasticsearch-Erfahrung im Shopware-Kontext und muss sich diese Erfahrung in der Migrations-Phase aufbauen oder von einer spezialisierten Infrastruktur abnehmen lassen.

Vierte Veränderung: die Plugin-Schicht. Shopware-5-Such-Plugins funktionieren nicht in Shopware 6, weil die Plugin-API komplett umgestellt wurde. Wer in Shopware 5 ein Such-Plugin von einem Drittanbieter im Einsatz hatte, muss in Shopware 6 entweder ein neues Plugin desselben Anbieters installieren (sofern vorhanden) oder eine alternative Lösung evaluieren. Die alten Plugin-Lizenzen sind nicht übertragbar, die Custom-Anpassungen an den alten Plugins sind nicht migrierbar.

Diese vier Veränderungen sind nicht Detail-Fragen, sie sind eine strukturelle Re-Implementierung der Such-Schicht. Wer die Migration plant, sollte diese Re-Implementierung nicht als nachgelagertes Detail behandeln, sondern als bewusste Phase im Migrations-Plan einplanen. Andernfalls läuft die neue Shopware-6-Suche im ersten halben Jahr nach dem Go-Live mit suboptimalen Settings, weil die Konfiguration nicht ausgereift ist und die Custom-Tweaks aus Shopware 5 nicht vollständig nachgebildet wurden.

Was die Shopware-6-Default-Suche kann und wo ihre Grenzen liegen

Was leistet die Default-Suche von Shopware 6 im Vergleich zur Suche aus Shopware 5?

Die Shopware-6-Default-Suche ist im Vergleich zu Shopware 5 deutlich moderner und leistungsfähiger. Sie unterstützt nativ Mehrwort-Suchen, eine konfigurierbare Tippfehler-Toleranz, eine gewichtete Suche über mehrere Artikel-Felder und eine Filter-Integration mit dem Storefront-Frontend. Für einen Shop mit überschaubarem Sortiment und klar strukturierten Produkt-Daten ist die Default-Suche eine brauchbare Basis, die in der Standard-Installation auskömmliche Trefferquoten liefert.

Die Grenzen werden in der Mid-Enterprise-Realität schnell sichtbar. Erste Grenze: semantisches Verständnis. Die Default-Suche ist eine lexikalische Volltext-Suche mit Token-Matching, sie versteht keine Bedeutungs-Nähe. Eine Anfrage "kabelloses Ladegerät" findet ein Produkt mit dem Titel "Wireless Charger" nur dann, wenn ein expliziter Synonym-Eintrag gepflegt ist. Wer fünfzigtausend SKUs in mehreren Sprach-Varianten führt, kann die Synonym-Pflege nicht in dem Detail-Grad betreiben, der für eine durchgehende semantische Abdeckung nötig wäre. Die Mechanik der Synonym-Pflege haben wir im Beitrag zur Synonyme-Pflege im Shop im Detail behandelt.

Zweite Grenze: User Intent. Die Default-Suche kennt die Such-Absicht hinter einer Anfrage nicht. Wer "Geschenk Vater 50 Geburtstag" sucht, bekommt eine Token-Match-Liste über die vier Token, die in der Trefferquote die Produkte hochzieht, die zufällig alle vier Token im Text haben, unabhängig davon, ob sie als Geschenk für einen fünfzigjährigen Vater Sinn ergeben. Eine User-Intent-Erkennung verlangt eine semantische Schicht, die in der Default-Konfiguration nicht enthalten ist.

Dritte Grenze: Behavior-Lernen. Die Default-Suche hat keine direkte Verbindung zu den Behavior-Daten des Shops. Welche Produkte für eine bestimmte Anfrage gut konvertieren, welche schlecht, welche Treffer-Reihenfolge die höchste Add-to-Cart-Rate erzielt, ist der Default-Suche unbekannt. Wer das Ranking auf Behavior-Daten lernen lassen will, braucht eine eigene Behavior-Pipeline, eine Aggregation, ein ML-Training und einen Integrations-Pfad zurück in den Such-Index. Diese Pipeline ist in der Default-Konfiguration nicht enthalten und kann nicht in wenigen Wochen aufgebaut werden.

Vierte Grenze: Cookieless-Compliance. Die Default-Suche speichert in der Standard-Konfiguration kein User-Profil. Wer eine Personalisierung auf Such-Ebene haben will (zum Beispiel "User, die bisher Premium-Produkte gekauft haben, sehen Premium-Sortiment höher gewichtet"), muss diese Personalisierung selbst implementieren. Die meisten Wege zu dieser Personalisierung führen über User-IDs und Cookie-basierte Profile, was im DSGVO-Kontext kritisch ist. Eine Cookieless-Personalisierung verlangt eine eigene Architektur, die Behavior-Signale aggregiert und anonymisiert verarbeitet. Wie eine solche Architektur strukturell aussieht, haben wir im Beitrag zur DSGVO-konformen KI-Suche im Detail beschrieben.

Fünfte Grenze: Multi-Storefront-Komplexität. Shopware 6 unterstützt nativ mehrere Storefronts in derselben Plattform, was für Multi-Brand- oder Multi-Country-Setups eine strukturelle Erleichterung ist. Die Default-Suche kann pro Storefront konfiguriert werden, aber die Pflege wird mit jedem zusätzlichen Storefront aufwendiger. Wer fünf Storefronts mit unterschiedlichen Sortimenten und Sprachen betreibt, hat in der Default-Konfiguration fünf separate Such-Pflege-Strecken, die nicht aus einer Hand orchestriert sind. Eine Mid-Enterprise-Multi-Storefront-Strategie haben wir im Beitrag zur Multi-Country E-Commerce-Suche im Detail beschrieben.

Diese fünf Grenzen sind nicht Mängel der Default-Suche, sie sind eine bewusste Funktions-Abgrenzung. Shopware 6 liefert eine solide Volltext-Suche als Default und überlässt die spezialisierten Such-Funktionen den Plugins und Infrastruktur-Lösungen, die für genau diese Anwendungs-Fälle gebaut sind. Die Migrations-Entscheidung ist damit nicht "Default-Suche oder Such-Replatform", sondern "Default-Suche genügt für unsere Anforderungen, oder wir brauchen eine spezialisierte Schicht".

Das Migrations-Moment-Argument: Warum jetzt der natürliche Replatform-Zeitpunkt ist

Warum ist eine Such-Replatform im laufenden Shop-Betrieb so aufwendig?

Eine Such-Replatform ist in einem laufenden Shop-Betrieb ein eigenes Projekt mit eigenen Aufwänden, eigenen Risiken und eigenen Anforderungen an die Team-Kapazität. Wer in einem stabilen Shopware-5-Shop heute eine Such-Replatform plant, muss die laufende Plattform anfassen, die Such-Logik in einem Parallel-Setup testen, die Daten-Mappings einrichten, das Storefront umbauen und einen Cutover-Termin planen. Der Aufwand ist hoch, das Risiko ist sichtbar, die Organisations-Bereitschaft ist oft nicht da, weil "läuft doch".

In der Migrations-Phase ist die Situation strukturell anders. Das Datenmodell wird ohnehin durchgegangen, die Custom-Felder werden ohnehin neu gemappt, der Plugin-Stack wird ohnehin neu installiert, das Storefront wird ohnehin umgebaut, ein Cutover-Termin steht ohnehin im Plan. Die Such-Replatform fügt sich in diese ohnehin notwendigen Arbeiten ein, ohne dass ein separates Projekt mit separatem Risiko aufgesetzt werden muss. Die Inkrement-Kosten einer Such-Replatform sind in der Migrations-Phase deutlich niedriger als in einem stabilen Betrieb.

Erstes Inkrement-Argument: Datenmodell-Mapping ist Pflicht. Wer aus Shopware 5 nach Shopware 6 migriert, muss pro Artikel-Attribut entscheiden, wie es in der Ziel-Plattform abgebildet wird. Custom-Felder, Variant-Konfigurationen, Property-Sets, Übersetzungs-Strukturen, alles muss durchgegangen werden. In diesem Mapping-Prozess kostet es kaum zusätzliche Zeit, eine zweite Mapping-Spalte für den Such-Index zu pflegen. Welche Felder sollen indiziert werden, mit welcher Gewichtung, in welcher Sprach-Variante, mit welcher Filter-Logik. Wer diese Spalte in der gleichen Mapping-Tabelle führt, hat am Ende der Migration eine vollständige Such-Konfiguration ohne separates Such-Projekt.

Zweites Inkrement-Argument: Storefront-Umbau läuft sowieso. Das Shopware-6-Storefront ist Twig-basiert und folgt einer anderen Komponenten-Logik als Shopware 5. Das Storefront wird in der Migration grundsätzlich neu gebaut, weil die alten Templates nicht funktionieren. In diesem Neubau die Such-Komponenten einer modernen Infrastruktur zu integrieren, ist ein Bruchteil des Aufwands, der nötig wäre, um sie nachträglich in ein bereits gebautes Storefront einzuziehen. Die Such-Komponenten leben in derselben Twig-Logik wie der Rest des Storefronts und werden mit derselben Component-Library entwickelt.

Drittes Inkrement-Argument: Plugin-Stack wird neu installiert. Wer aus Shopware 5 kommt, hat einen über Jahre gewachsenen Plugin-Stack, der in Shopware 6 nicht eins-zu-eins funktioniert. Jedes Plugin muss neu installiert, neu konfiguriert und in vielen Fällen durch ein alternatives Plugin ersetzt werden. In diesem Re-Installations-Prozess kostet es kaum zusätzliche Zeit, eine spezialisierte Such-Infrastruktur als Plugin in den neuen Stack zu installieren. BatteryIncluded ist als zertifiziertes Shopware-6-Plugin im offiziellen Store verfügbar, die Installation läuft über die Shopware-Plugin-Verwaltung und integriert sich nativ in die Plattform.

Viertes Inkrement-Argument: Cutover-Termin steht im Plan. Eine Such-Replatform in einem stabilen Shop verlangt einen eigenen Cutover-Termin mit Test-Phase und Rollback-Plan. In der Migrations-Phase steht der Cutover ohnehin im Kalender, die Test-Phase ist ohnehin geplant, der Rollback-Pfad ist ohnehin durchdacht. Die Such-Replatform fügt sich in diese ohnehin laufenden Vorbereitungen ein.

Diese vier Inkrement-Argumente machen den Migrations-Moment zum strukturell günstigsten Replatform-Zeitpunkt, den ein Shop in seinem Lebenszyklus haben kann. Wer ihn ungenutzt vorbeiziehen lässt, baut sich für die nächsten Jahre eine Such-Realität, deren Replatform-Aufwand strukturell höher sein wird, weil sie aus einem stabilen Betrieb heraus angegangen werden muss.

"Was uns geholfen hat, war die Sicht auf die Treffer-Listen in Echtzeit. Wir konnten zum ersten Mal sehen, welche Produkte für unsere wichtigsten Such-Anfragen tatsächlich oben standen, und wo unsere Saison-Aktionen liefen, ohne dass wir sie raten mussten. Die Möglichkeit, gezielt einzugreifen ohne den Algorithmus komplett zu ersetzen, hat uns die Steuerung zurückgegeben, ohne die wir vorher operativ eingeschränkt waren."

Solit Group GmbH

Im Edelmetall-Versand ist die Such-Disziplin besonders sensibel, weil Brand-Namen, Münz-Bezeichnungen und Edelmetall-Termini eng ineinandergreifen. Eine Migrations-Phase ist hier der natürliche Moment, die Such-Architektur grundsätzlich neu aufzusetzen, statt die alten Such-Tweaks aus dem Legacy-System mitzuwandern, die in der neuen Plattform ohnehin nicht eins-zu-eins funktionieren.

Was aus Shopware 5 mitwandert und was strukturell neu aufgesetzt gehört

Muss ich bei der Such-Replatform alles neu aufsetzen oder kann ich Teile aus Shopware 5 mitnehmen?

In der Praxis ist die Such-Replatform-Entscheidung keine binäre "alles neu" oder "alles übernehmen", sondern ein selektiver Mapping-Prozess. Manche Elemente der alten Such-Konfiguration sind strukturell mitwandern-fähig, andere sind besser komplett neu aufgesetzt. Die saubere Trennung dieser beiden Klassen ist die Voraussetzung für eine Migration, die nicht in einer halb funktionierenden Such-Architektur endet.

Was strukturell mitwandert: Marken-Synonyme. Die Marken-Synonym-Tabelle aus dem Shopware-5-Setup ist in der Regel eine bewusste strategische Pflege-Arbeit des Marketing-Teams. Apple und Mac, Samsung und sammy, Adidas und adi. Diese Synonyme sind nicht aus einem Algorithmus ableitbar, sondern aus der Marken-Strategie des Shops. Sie wandern in das neue System, weil sie eine inhaltliche Wahrheit kodieren, die unabhängig von der technischen Plattform ist.

Was strukturell mitwandert: Stop-Word-Listen für sprach-spezifische Anpassungen. Wenn der Shop eine eigene Stop-Word-Liste gepflegt hat, in der branchenspezifische Füllwörter ausgefiltert werden, ist diese Liste eine bewusste Anpassung an die Sortiments-Sprache. Sie wandert in das neue System, weil sie die gleiche Sprach-Realität abbildet.

Was strukturell mitwandert: redaktionelle Such-Boosts. Wenn das Marketing-Team für bestimmte Kampagnen-Phasen Sortiments-Bereiche im Ranking hochgewichtet hat, ist diese Logik eine strategische Pflege, die in das neue System übergeht. Die Konfiguration kann sich technisch ändern, aber die inhaltliche Logik bleibt.

Was strukturell neu aufgesetzt gehört: die Tippfehler-Toleranz-Konfiguration. Shopware 5 und Shopware 6 haben unterschiedliche Tippfehler-Toleranz-Mechaniken, und die alten Einstellungen sind nicht eins-zu-eins übertragbar. Eine moderne Such-Infrastruktur arbeitet mit einer mehrstufigen Fehlertoleranz aus Edit-Distance, Phonetik und Layout-Distanz, die in der Shopware-5-Konfiguration nicht abbildbar war. Die Tippfehler-Logik haben wir im Beitrag zur Fehlertoleranz in der Shop-Suche im Detail beschrieben.

Was strukturell neu aufgesetzt gehört: das Such-Ranking. Das Shopware-5-Ranking basierte auf einer relativ einfachen Textscore-Logik, die in vielen Shops über Custom-Plugins erweitert wurde. Diese Custom-Erweiterungen funktionieren in Shopware 6 nicht und sollten nicht versuchsweise nachgebildet werden. Stattdessen ist die Migration der richtige Moment, ein modernes Hybrid-Ranking aufzusetzen, das lexikalische, semantische und Behavior-Signale kombiniert. Die Grenzen der reinen Textscore-Logik haben wir im Beitrag zum Textscore in der Shop-Suche im Detail behandelt.

Was strukturell neu aufgesetzt gehört: die Synonym-Auto-Discovery. Die manuelle Synonym-Pflege aus Shopware 5 wandert mit, aber die AI-Vorschlag-Schicht für neue Synonym-Kandidaten aus Search-Logs ist in der alten Plattform nicht enthalten und kann nicht eins-zu-eins migriert werden. Wer die Migration nutzt, um eine Auto-Discovery-Pipeline aufzusetzen, hat im neuen System eine Pflege-Architektur, die mit dem Sortiments-Wachstum mithält.

Was strukturell neu aufgesetzt gehört: das User-Intent-Verständnis. Die Shopware-5-Default-Suche kannte kein User-Intent-Verständnis, viele Custom-Plugins haben das auch nicht abgebildet. In Shopware 6 ist der Moment gekommen, eine semantische Schicht einzuziehen, die die Such-Absicht hinter einer Anfrage versteht und sie in die richtige Treffer-Reihenfolge übersetzt. Diese semantische Schicht ist in der Plattform-Default-Konfiguration nicht enthalten, aber sie ist in einer spezialisierten Such-Infrastruktur eine Standard-Komponente.

Was strukturell neu aufgesetzt gehört: die Behavior-Pipeline. Wenn der Shop bislang ohne Behavior-basiertes Ranking gearbeitet hat, ist die Migration der Moment, diese Pipeline einzuziehen. Behavior-Signale müssen aggregiert, anonymisiert und in das Ranking eingespeist werden. Wer das in Shopware 5 nicht hatte, hat es auch nicht zu migrieren. Die Mechanik haben wir im Beitrag zu GA4-Transaktionsdaten als Such-Signal im Detail beschrieben.

Diese Trennung in mitwandern-fähig und neu-aufgesetzt ist nicht eine Bauchgefühl-Entscheidung, sondern eine strukturierte Bestandsaufnahme. Sie ist die Voraussetzung dafür, dass die Migration nicht in einer Such-Architektur endet, die halb aus alten Tweaks und halb aus neuen Komponenten besteht und in der die beiden Hälften nicht miteinander funktionieren.

Migration in Phasen: Default zuerst oder Infrastruktur on Day 1

Sollte die spezialisierte Such-Infrastruktur direkt zum Go-Live kommen oder erst in einer zweiten Phase?

Eine taktische Frage in der Migrations-Planung ist die Phasen-Logik der Such-Replatform. Zwei Hauptvarianten stehen zur Wahl. Variante eins: die Shopware-6-Default-Suche am Go-Live-Tag aktivieren, in den ersten Monaten den Betrieb stabilisieren, und die spezialisierte Such-Infrastruktur in einer zweiten Phase einziehen. Variante zwei: die spezialisierte Such-Infrastruktur am Go-Live-Tag mitinstallieren, sodass der neue Shop von Tag eins mit der gewünschten Such-Architektur läuft.

Variante eins hat einen Charme der scheinbaren Risiko-Minimierung. Der Go-Live wird einfacher, weil weniger neue Komponenten gleichzeitig aktiv sind. Die Such-Replatform wird in eine Phase verschoben, in der das Team mit der neuen Plattform vertraut ist und die zweite Iteration mit weniger Druck angeht.

In der Praxis hat Variante eins drei strukturelle Schwächen. Erste Schwäche: die Default-Suche prägt in den ersten Monaten die User-Wahrnehmung. Wenn die neue Shopware-6-Suche im ersten Quartal nach Go-Live mit suboptimalen Treffer-Listen läuft, sehen die User eine Verschlechterung gegenüber der gewohnten Shopware-5-Erfahrung (selbst wenn diese auch nicht optimal war). Die Conversion sinkt sichtbar, der Erfolg des Migrations-Projekts wird in Frage gestellt, das Team kommt unter Druck, schnelle Fixes zu liefern.

Zweite Schwäche: die spezialisierte Such-Infrastruktur ist in der zweiten Phase strukturell ein eigenes Projekt mit eigenem Budget und eigener Aufmerksamkeit. In der Praxis kommt diese zweite Phase oft nicht zur Umsetzung, weil das Migrations-Projekt budgetär abgeschlossen ist und die Such-Replatform als Folge-Projekt neu beantragt werden muss. Das, was als Phase zwei geplant war, schiebt sich in eine unbestimmte Zukunft.

Dritte Schwäche: die Storefront-Komponenten für die spezialisierte Such-Infrastruktur müssten in Phase zwei in ein bereits laufendes Storefront eingebaut werden. Das ist deutlich aufwendiger als der Einbau im Migrations-Storefront-Bau, weil die Storefront-Logik bereits durchgetestet ist und jede Änderung Regressions-Tests verlangt.

Variante zwei hat einen scheinbaren Komplexitäts-Nachteil im Go-Live, aber strukturell drei Vorteile. Erster Vorteil: die Such-Erfahrung ab Tag eins entspricht der Ziel-Architektur. Die User sehen keine Verschlechterung, weil die spezialisierte Such-Infrastruktur in vielen Dimensionen besser performt als die Shopware-5-Custom-Setups. Die Conversion bleibt stabil oder steigt, der Migrations-Erfolg ist sichtbar.

Zweiter Vorteil: die Storefront-Komponenten sind im Migrations-Storefront-Bau direkt integriert. Es gibt kein zweites Storefront-Projekt, keine doppelte Komponenten-Arbeit, keine Regression-Test-Doppelung.

Dritter Vorteil: die Such-Infrastruktur-Konfiguration läuft im gleichen Daten-Mapping-Prozess wie die restliche Migration. Die Mapping-Tabelle, die für die Plattform-Migration ohnehin entsteht, deckt automatisch die Such-Konfiguration mit ab. In Phase zwei müsste diese Mapping-Arbeit ein zweites Mal gemacht werden, in einem Kontext, der nicht mehr den Migrations-Druck hat und in dem die Pflege-Disziplin oft schon nachgelassen hat.

Die strukturelle Empfehlung ist deshalb Variante zwei: die spezialisierte Such-Infrastruktur am Go-Live-Tag mitinstallieren. Diese Empfehlung verlangt einen erweiterten Migrations-Scope und eine erweiterte Test-Phase, aber sie bringt eine Such-Architektur, die ab Tag eins die Ziel-Qualität liefert und in den nächsten Jahren keine separate Replatform-Phase mehr braucht. Die zertifizierte BatteryIncluded-Plugin-Integration in Shopware 6 ist genau für diesen Day-One-Einsatz konzipiert, mit einem typischen Integrations-Aufwand von ein bis zwei Wochen in der Mid-Enterprise-Migration.

Aufwand-Schätzung: Plugin-Integration versus Custom-Build

Was kostet eine spezialisierte Such-Infrastruktur im Vergleich zu einem eigenen Custom-Build?

Eine konkrete Zahlen-Diskussion in vielen Migrations-Workshops ist die Frage, was die spezialisierte Such-Infrastruktur im Verhältnis zu einem Custom-Build kostet. Drei Varianten stehen typischerweise zur Wahl, und ihre Aufwands-Profile unterscheiden sich um Größenordnungen.

Variante eins: zertifizierte Plugin-Integration. Eine spezialisierte Such-Infrastruktur wird als Shopware-6-Plugin installiert, im Backend konfiguriert und in das Storefront integriert. Die Komponenten sind aus dem Plugin-Stack vorhanden, die Index-Pflege läuft automatisch über die Plugin-Logik, die Konfiguration läuft über das Backend. Der typische Aufwand für eine Mid-Enterprise-Integration liegt bei ein bis zwei Wochen verteilt auf einen Entwickler und einen Product-Owner. Die meisten Konfigurations-Entscheidungen sind in der Migrations-Mapping-Tabelle ohnehin getroffen.

Variante zwei: Custom-Plugin-Build gegen Elasticsearch-Standard. Das Team baut ein eigenes Plugin, das gegen einen Elasticsearch- oder OpenSearch-Standard läuft, mit eigener Index-Pflege, eigener Konfigurations-Logik und eigenem Storefront-Hook. Der typische Aufwand liegt bei drei bis sechs Monaten, verteilt auf zwei bis drei Entwickler. Die Komponenten müssen entworfen, getestet, dokumentiert und in den Plugin-Stack integriert werden. Die Such-Qualität ist auf dem Niveau einer reinen Volltext-Suche und enthält keine semantische Schicht, keine Behavior-Pipeline und keine Auto-Synonym-Discovery.

Variante drei: Vollständiger Custom-Build inklusive semantischer Schicht. Das Team baut nicht nur die Index-Logik, sondern auch die semantische Schicht, die Behavior-Pipeline und die Editorial-Tools. Der typische Aufwand liegt bei zwölf bis vierundzwanzig Monaten verteilt auf ein Team von vier bis sechs Personen. Die Komponenten müssen ML-Modelle einbeziehen, eine eigene Trainings-Infrastruktur aufbauen und die Update-Disziplin für die Modelle organisieren. Die laufenden Kosten dieser Variante sind ein eigenes Kapitel.

Die Aufwands-Spreizung zwischen Variante eins und Variante drei liegt um den Faktor fünfzig bis hundert. Diese Spreizung ist nicht eine Funktion der reinen Code-Zeilen, sondern eine Funktion der spezialisierten Komponenten, die in der Variante drei alle eigenständig gebaut werden müssen. Eine zertifizierte Plugin-Integration bringt diese Komponenten als getestete Infrastruktur mit, das Team konzentriert sich auf Konfiguration und Integration, nicht auf den Aufbau der Basis-Schichten.

In der Migrations-Realität entscheiden sich die meisten Mid-Enterprise-Shops für Variante eins, weil die Migration ohnehin Budget bindet und ein paralleles Custom-Build-Projekt die Migrations-Kapazitäten überschreiten würde. Die Aufwand-Ersparnis gegenüber einem Custom-Build wird in der Regel in eine umfassendere Test-Phase, eine sauberere Daten-Migration und eine intensivere Mitarbeiter-Schulung investiert, was die Migrations-Qualität insgesamt hebt.

Multi-Storefront in Shopware 6: Die zweite Dimension der Migrations-Hebel

Was bringt die native Multi-Storefront-Unterstützung von Shopware 6 gegenüber Shopware 5?

Eine strukturelle Erweiterung in Shopware 6 gegenüber Shopware 5 ist die native Multi-Storefront-Unterstützung. Wer in Shopware 5 mehrere Marken oder Länder betrieben hat, hatte oft mehrere getrennte Shopware-5-Instanzen oder eine komplexe Multi-Shop-Konfiguration mit operativen Brüchen. Shopware 6 erlaubt eine saubere Multi-Storefront-Logik in einer Plattform-Instanz, was die Operations-Kosten deutlich senkt.

Für die Such-Schicht hat diese Erweiterung eine eigene Konsequenz. Jede Storefront kann ihre eigene Such-Konfiguration, ihre eigene Synonym-Tabelle, ihre eigene Sprach-Variante und ihre eigene Ranking-Logik haben. Wer diese fünf Storefronts in fünf separaten Pflege-Strecken betreibt, hat einen entsprechend hohen Pflege-Aufwand. Wer sie in einer übergreifenden Such-Infrastruktur orchestriert, die pro Storefront konfigurierbar ist aber zentral verwaltet wird, hat einen strukturell niedrigeren Aufwand.

Diese Multi-Storefront-Logik ist in einer spezialisierten Such-Infrastruktur eine Standard-Komponente. Pro Storefront wird eine separate Konfigurations-Strecke gepflegt, gleichzeitig laufen die Behavior-Aggregate, die ML-Trainings und die Editorial-Tools in einer gemeinsamen Schicht. Die Pflege pro Storefront bleibt überschaubar, die Skaleneffekte über die Storefronts werden genutzt. Die Detail-Mechanik einer Multi-Tenant-Search-Architektur haben wir im Beitrag zu Multi-Tenant E-Commerce-Suche im Detail beschrieben.

Die Migrations-Phase ist der Moment, in dem die Storefront-Struktur in Shopware 6 ohnehin definiert wird. Wer in diesem Moment die Such-Infrastruktur als Multi-Storefront-fähige Schicht mit aufsetzt, hat im neuen System eine konsistente Such-Erfahrung über alle Storefronts hinweg. Wer die Such-Infrastruktur erst nachträglich pro Storefront einzieht, hat einen aufgesplitteten Pflege-Aufwand und eine inkonsistente Such-Erfahrung.

ERP- und PIM-Synchronisation: Die Daten-Flüsse rund um die Such-Schicht

Was passiert bei der Migration mit den ERP- und PIM-Anbindungen rund um die Suche?

In der Migrations-Phase werden nicht nur die Plattform-Komponenten neu aufgesetzt, sondern auch die ERP- und PIM-Integrationen. Wer bislang einen Custom-Connector aus Shopware 5 in das ERP hatte, muss in Shopware 6 entweder einen neuen Connector aufsetzen oder eine alternative Integrations-Logik wählen. Die Such-Schicht profitiert oder leidet direkt von der Qualität dieser Integration, weil die Produkt-Daten, die Bestände, die Preise und die Verfügbarkeit aus dem ERP kommen und in der Such-Trefferliste sichtbar sein müssen.

Eine spezialisierte Such-Infrastruktur arbeitet typisch mit einer eigenen Index-Schicht, die aus dem Shopware-Datenmodell gespeist wird. Die Synchronisation zwischen Shopware und dem Such-Index muss in der Migrations-Phase neu aufgesetzt werden, weil die Datenmodell-Brücken aus Shopware 5 nicht funktionieren. Die Synchronisations-Logik kann inkrementell sein (Änderungen werden ereignisbasiert in den Index geschrieben) oder periodisch (das Vollindex-Rebuild läuft in definierten Zeitfenstern). Welche Logik passt, hängt vom Sortiments-Umfang, von der Änderungs-Frequenz und von den Performance-Anforderungen ab. Die Mechanik haben wir im Beitrag zur ERP-Synchronisation in der Shop-Suche im Detail behandelt.

Eine zertifizierte Plugin-Integration bringt diese Synchronisations-Logik als getestete Komponente mit. Das Plugin lauscht auf die Produkt-, Preis- und Bestands-Events von Shopware 6 und schreibt sie inkrementell in den Such-Index. Wer keine spezialisierte Plugin-Integration hat, muss diese Synchronisations-Logik selbst bauen, was in einer Migrations-Phase eine zusätzliche Komplexitäts-Quelle ist.

Ein zweiter Daten-Fluss ist die Anbindung an das PIM, falls der Shop ein separates PIM betreibt. Das PIM liefert die Produkt-Attribute, die Kategorien, die Medien und die Übersetzungen. Diese Daten landen in Shopware 6 und von dort in den Such-Index. Wer in der Migration die PIM-Integration neu aufsetzt, sollte gleichzeitig die Such-Index-Synchronisation mitdenken, damit nicht zwei separate Synchronisations-Pfade entstehen, die in der Praxis aus dem Takt geraten.

Die Daten-Fluss-Architektur ist nicht ein Detail der Migration, sondern eine Grundsatz-Entscheidung, die die Such-Qualität in den nächsten Jahren prägt. Wer sie im Migrations-Moment sauber aufsetzt, hat eine Datenbasis, die mit dem Shop wächst. Wer sie nachlässig aufsetzt, hat in zwölf Monaten Synchronisations-Probleme, die als "Such-Bugs" sichtbar werden, aber strukturell Daten-Fluss-Bugs sind.

"BatteryIncluded.ai ist genau das, was man sich von moderner E-Commerce-Technologie wünscht: blitzschnelle Suche auch bei über 50.000 Produkten, volle Anpassbarkeit für komplexe Anforderungen, und ein Support, der nicht nur reagiert, sondern wirklich versteht. Stabil, skalierbar, zukunftssicher."

Österreichischer Bundesverlag Schulbuch GmbH & Co. KG

Im B2B-Schulbuch-Versand mit großem Sortiment, vielfältigen Datenquellen und einer komplexen ERP-PIM-Architektur ist die Migrations-Phase eine der seltenen Gelegenheiten, die Such-Daten-Flüsse grundsätzlich neu aufzusetzen. Die spezialisierte Infrastruktur passt sich in den neuen Plattform-Stack ein, ohne dass die Migrations-Komplexität dramatisch steigt.

DSGVO und Cookieless: Migration als Privacy-Reset-Moment

Welche Rolle spielt die Privacy-Architektur bei der Migration?

Eine oft übersehene Dimension der Migration ist die Privacy-Architektur. Shopware-5-Setups haben in den vergangenen Jahren häufig Tracking- und Personalisierungs-Lösungen eingebaut, deren DSGVO-Konformität in der heutigen Rechtsprechung nicht mehr gegeben ist. Die Migration ist der natürliche Moment, diese Privacy-Schulden abzubauen und eine Cookieless-Architektur zu etablieren, die ohne User-Profile arbeitet.

Eine spezialisierte Such-Infrastruktur kann hier ein zentraler Baustein sein. Wenn die Such-Logik mit anonymisierten Cohort-Aggregaten arbeitet, statt mit User-IDs und Session-Cookies, ist die Such-Schicht eine Privacy-Insel im sonst Tracking-belasteten Shop. Die Behavior-Signale werden pro Cohort gesammelt, nicht pro User. Die Personalisierung läuft über Kategorie-Affinitäten, nicht über User-Profile. Die DSGVO-Konformität ist nicht eine nachträgliche Anpassung, sondern eine Architektur-Eigenschaft. Die Mechanik haben wir im Beitrag zur DSGVO-konformen KI-Suche im Detail beschrieben.

Im Migrations-Moment ist diese Privacy-Architektur eine bewusste Entscheidung. Wer die Such-Infrastruktur Cookieless aufsetzt, hat in der neuen Plattform eine Komponente, die nicht von Cookie-Consent-Bannern abhängig ist und nicht in DSGVO-Audit-Diskussionen gerät. Wer die Such-Infrastruktur Tracking-basiert aufsetzt, baut die Privacy-Schulden der alten Plattform in die neue Plattform mit ein.

Die Cookieless-Architektur ist nicht ein Kompromiss in der Such-Qualität. Im Gegenteil, sie ist in der Mid-Enterprise-Realität oft die qualitativ bessere Variante, weil die Cohort-Aggregate eine größere Datenbasis haben als die User-spezifischen Profile und weil die Ranking-Logik aus einer breiteren Beobachtungs-Grundlage lernt. Die DSGVO-Konformität ist hier nicht ein Hindernis, sondern eine architektonische Sauberkeit, die in der Praxis die bessere Performance liefert.

Was Sie diese Woche tun können

Wie steige ich konkret in die Such-Vorbereitung für die Migration ein?

Wenn Sie heute in der Migrations-Vorbereitung von Shopware 5 nach Shopware 6 stehen, ist der pragmatische Einstieg in fünf Schritten.

Schritt eins ist die Such-Bestandsaufnahme im alten System. Exportieren Sie die aktuelle Such-Konfiguration aus Shopware 5: welche Custom-Felder werden indiziert, welche Gewichtungen sind gesetzt, welche Synonyme sind gepflegt, welche Such-Plugins sind installiert, welche Custom-Anpassungen wurden im Code gemacht. Diese Bestandsaufnahme ist die Voraussetzung dafür, dass die Migrations-Entscheidung "mitwandern" oder "neu aufsetzen" pro Komponente bewusst getroffen werden kann. Sie braucht typisch einen halben bis ganzen Tag.

Schritt zwei ist die Such-Performance-Analyse. Sehen Sie sich die Such-Logs der vergangenen drei Monate an. Welche Anfragen führen zu null Treffern, welche zu Klick-Raten unter dem Schnitt, welche zu hohen Bounce-Raten. Diese Liste zeigt, wo die Shopware-5-Default-Suche strukturell an ihre Grenzen kommt und wo eine spezialisierte Schicht in der neuen Plattform den größten Hebel hat. Eine konkrete Analyse-Methodik haben wir im Beitrag zur Search-Log-Analyse im Shop beschrieben.

Schritt drei ist die Day-One-Entscheidung. Klären Sie im Migrations-Team, ob die spezialisierte Such-Infrastruktur am Go-Live-Tag mitinstalliert wird oder in einer zweiten Phase nachgezogen werden soll. Die strukturellen Argumente für die Day-One-Variante haben wir in diesem Artikel skizziert. Die Entscheidung muss früh in der Migrations-Planung getroffen werden, weil sie die Storefront-Architektur, die Mapping-Tabellen und die Test-Phase beeinflusst.

Schritt vier ist die Plugin-Evaluation. Wenn die Day-One-Entscheidung gefallen ist, evaluieren Sie die in Frage kommenden Plugin-Optionen im Shopware-Store. Eine zertifizierte Plugin-Integration ist in der Migrations-Phase strukturell die niedrig-Aufwand-Variante. Die BatteryIncluded-Plugin-Integration für Shopware 6 finden Sie im offiziellen Store und auf unserer Shopware-6-Partner-Seite. Die Plugin-Dokumentation beschreibt den Integrations-Aufwand und die Konfigurations-Optionen.

Schritt fünf ist die Mapping-Tabellen-Erweiterung. Wenn die Plugin-Entscheidung gefallen ist, erweitern Sie die ohnehin laufende Datenmodell-Mapping-Tabelle um eine zweite Spalte für die Such-Konfiguration. Welche Felder werden indiziert, mit welcher Gewichtung, in welcher Sprach-Variante, mit welcher Filter-Logik. Diese Spalte wird parallel zur Plattform-Migration befüllt und ist am Go-Live-Tag fertig konfiguriert. Sie verlängert den Migrations-Aufwand um einen überschaubaren Anteil und liefert am Ende eine vollständige Such-Konfiguration.

Diese fünf Schritte sind unabhängig davon sinnvoll, ob Sie sich am Ende für eine zertifizierte Plugin-Integration oder für eine alternative Lösung entscheiden. Was sie nicht ersetzen können, ist die operative Reife einer Such-Infrastruktur, die die Mid-Enterprise-Anforderungen aus einer Hand abdeckt. Eine vertiefte Behandlung der Such-Troubleshooting-Disziplin in Shopware-Setups finden Sie in unserem Troubleshooting-Beitrag zur Shopware-Suche.

"Mit BatteryIncluded haben wir endlich ein Werkzeug, das unsere Markenwelt versteht. Unsere Kundinnen und Kunden finden ihre Produkte schneller, was sich direkt in der Conversion zeigt. Was uns besonders überzeugt hat, ist die Möglichkeit, unsere eigene Markensprache abzubilden, ohne dass wir auf eine Standard-Vorgabe reduziert werden."

G. Wurm GmbH + Co. KG

Im Bastelbedarf-Versand ist die Markensprache besonders eigen, und die Migration auf Shopware 6 ist der natürliche Moment, diese Markensprache in eine moderne Such-Architektur zu übertragen, statt die alten Custom-Tweaks aus Shopware 5 in die neue Plattform mitzuschleppen, in der sie ohnehin nicht eins-zu-eins funktionieren.

Häufige Fragen (FAQ)

Warum ist die Migration von Shopware 5 auf Shopware 6 der richtige Anlass, die Suche neu zu denken?

In der Migrations-Phase werden das Datenmodell, der Plugin-Stack, das Storefront und die Custom-Konfigurationen ohnehin durchgegangen. Eine Such-Replatform fügt sich in diese ohnehin notwendigen Arbeiten ein, ohne dass ein separates Projekt mit separatem Risiko aufgesetzt werden muss. Die Inkrement-Kosten einer Such-Replatform sind in der Migrations-Phase deutlich niedriger als in einem stabilen Betrieb. Wer den Moment ungenutzt vorbeiziehen lässt, baut sich für die nächsten Jahre eine Such-Realität, deren Replatform-Aufwand strukturell höher sein wird, weil sie aus einem stabilen Betrieb heraus angegangen werden muss.

Was sind die wichtigsten strukturellen Unterschiede zwischen der Suche in Shopware 5 und Shopware 6?

Vier strukturelle Veränderungen sind relevant. Erstens, das Datenmodell wurde mit einer streng typisierten DAL neu aufgesetzt, Custom-Attribute leben jetzt in Custom-Field-Sets. Zweitens, die Search-Konfiguration ist API-getrieben und granularer geworden. Drittens, Shopware 6 unterstützt nativ Elasticsearch als Such-Backend, mit anderer Konfigurations- und Skalierungs-Logik. Viertens, die Plugin-API ist komplett umgestellt, alte Such-Plugins funktionieren in Shopware 6 nicht. Diese vier Veränderungen sind keine Detail-Fragen, sondern eine strukturelle Re-Implementierung der Such-Schicht, die im Migrations-Plan als bewusste Phase eingeplant werden sollte.

Reicht die Shopware-6-Default-Suche für unseren Shop?

Die Default-Suche ist im Vergleich zu Shopware 5 deutlich moderner und für einen Shop mit überschaubarem Sortiment und klar strukturierten Produkt-Daten eine brauchbare Basis. Die Grenzen werden in der Mid-Enterprise-Realität in fünf Dimensionen sichtbar: kein semantisches Verständnis, kein User-Intent, kein Behavior-Lernen, keine Cookieless-Personalisierung und aufwendige Multi-Storefront-Pflege. Wer ein Sortiment ab etwa zehntausend SKUs hat, mehrere Sprach-Varianten betreibt oder eine Personalisierung über reine Volltext-Suche hinaus braucht, stößt schnell an diese Grenzen. Die Entscheidung ist nicht "Default-Suche oder Replatform", sondern "Default-Suche genügt für unsere Anforderungen, oder wir brauchen eine spezialisierte Schicht".

Sollen wir die spezialisierte Such-Infrastruktur am Go-Live-Tag oder in Phase zwei einziehen?

Strukturell empfiehlt sich die Day-One-Installation. Variante zwei (Default zuerst, Replatform in Phase zwei) hat drei Schwächen: die Default-Suche prägt in den ersten Monaten die User-Wahrnehmung mit oft sichtbarer Verschlechterung gegenüber Shopware-5-Custom-Setups, die Phase zwei kommt in der Praxis oft nicht zur Umsetzung, weil das Migrations-Budget abgeschlossen ist, und die Storefront-Komponenten müssten in Phase zwei in ein bereits laufendes Storefront eingebaut werden. Variante eins (Day-One-Installation) integriert die Such-Infrastruktur in den ohnehin laufenden Storefront-Bau, nutzt die Migrations-Mapping-Tabelle für die Such-Konfiguration und liefert ab Tag eins die Ziel-Qualität.

Was wandert aus Shopware 5 mit und was wird strukturell neu aufgesetzt?

Strukturell mitwandern: Marken-Synonyme, sprach-spezifische Stop-Word-Listen, redaktionelle Such-Boosts. Diese Elemente kodieren inhaltliche Wahrheiten, die unabhängig von der Plattform sind. Strukturell neu aufgesetzt: die Tippfehler-Toleranz-Konfiguration (andere Mechanik in Shopware 6), das Such-Ranking (Hybrid-Ranking statt einfacher Textscore), die Synonym-Auto-Discovery (war in Shopware 5 nicht enthalten), das User-Intent-Verständnis (semantische Schicht ist neu), die Behavior-Pipeline (Cohort-Aggregate und ML-Training). Die saubere Trennung dieser beiden Klassen ist die Voraussetzung dafür, dass die Migration nicht in einer halb funktionierenden Such-Architektur endet.

Wie hoch ist der Aufwand für die Plugin-Integration im Vergleich zu einem Custom-Build?

Drei Varianten unterscheiden sich um Größenordnungen. Eine zertifizierte Plugin-Integration in der Mid-Enterprise-Migration liegt typisch bei ein bis zwei Wochen, verteilt auf einen Entwickler und einen Product-Owner. Ein Custom-Plugin-Build gegen einen Elasticsearch-Standard liegt bei drei bis sechs Monaten, verteilt auf zwei bis drei Entwickler, und liefert eine reine Volltext-Suche ohne semantische Schicht. Ein vollständiger Custom-Build inklusive semantischer Schicht, Behavior-Pipeline und Editorial-Tools liegt bei zwölf bis vierundzwanzig Monaten, verteilt auf ein Team von vier bis sechs Personen. Die Aufwands-Spreizung liegt um den Faktor fünfzig bis hundert, weil die spezialisierten Komponenten in der Variante drei alle eigenständig gebaut werden müssen.

Wie geht eine Multi-Storefront-Strategie in Shopware 6 mit der Such-Schicht um?

Shopware 6 unterstützt nativ mehrere Storefronts in einer Plattform-Instanz. Jede Storefront kann eine eigene Such-Konfiguration, Synonym-Tabelle, Sprach-Variante und Ranking-Logik haben. Wer fünf Storefronts in fünf separaten Pflege-Strecken betreibt, hat einen entsprechend hohen Aufwand. Eine spezialisierte Such-Infrastruktur orchestriert die Pflege in einer übergreifenden Schicht: pro Storefront wird eine separate Konfigurations-Strecke geführt, gleichzeitig laufen Behavior-Aggregate, ML-Trainings und Editorial-Tools in einer gemeinsamen Schicht. Die Migrations-Phase ist der natürliche Moment, diese Multi-Storefront-Architektur mit aufzusetzen, weil die Storefront-Struktur ohnehin neu definiert wird.

Wie sieht die Synchronisation zwischen Shopware 6 und einer spezialisierten Such-Infrastruktur aus?

Eine spezialisierte Such-Infrastruktur arbeitet typisch mit einer eigenen Index-Schicht, die aus dem Shopware-Datenmodell gespeist wird. Die Synchronisation kann inkrementell sein (Änderungen werden ereignisbasiert in den Index geschrieben) oder periodisch (Vollindex-Rebuilds in definierten Zeitfenstern). Eine zertifizierte Plugin-Integration bringt diese Synchronisations-Logik als getestete Komponente mit. Das Plugin lauscht auf die Produkt-, Preis- und Bestands-Events von Shopware 6 und schreibt sie inkrementell in den Such-Index. Wer keine spezialisierte Plugin-Integration hat, muss diese Synchronisations-Logik selbst bauen, was in einer Migrations-Phase eine zusätzliche Komplexitäts-Quelle ist.

Verändert die Migration die DSGVO- und Cookieless-Situation?

Ja, sie ist der natürliche Moment für einen Privacy-Reset. Shopware-5-Setups haben in den vergangenen Jahren häufig Tracking- und Personalisierungs-Lösungen eingebaut, deren DSGVO-Konformität in der heutigen Rechtsprechung nicht mehr gegeben ist. Eine Cookieless-Such-Infrastruktur arbeitet mit anonymisierten Cohort-Aggregaten, nicht mit User-IDs und Session-Cookies. Die Behavior-Signale werden pro Cohort gesammelt, die Personalisierung läuft über Kategorie-Affinitäten. Die DSGVO-Konformität ist nicht eine nachträgliche Anpassung, sondern eine Architektur-Eigenschaft. Im Migrations-Moment ist diese Privacy-Architektur eine bewusste Entscheidung, die in der neuen Plattform die Grundlage für die nächsten Jahre legt.

Bereit, die Migration als Such-Replatform-Moment zu nutzen?

Die Migration von Shopware 5 auf Shopware 6 ist heute für viele DACH-Shops das größte Plattform-Projekt der nächsten zwölf bis vierundzwanzig Monate. Sie ist gleichzeitig der strukturell günstigste Moment, die Such-Architektur grundsätzlich neu aufzusetzen, weil das Datenmodell, der Plugin-Stack, das Storefront und die Custom-Konfigurationen ohnehin durchgegangen werden. Volt Search® und AI Recommendations von BatteryIncluded sind als entkoppelte Infrastruktur konzipiert, die als zertifiziertes Shopware-6-Plugin in den Migrations-Stack integriert wird, in ein bis zwei Wochen statt drei bis sechs Monaten Custom-Build-Aufwand, mit semantischem Verständnis, User-Intent-Erkennung, Behavior-basiertem Ranking, Auto-Synonym-Discovery und nativer Multi-Storefront-Unterstützung. Cookieless, DSGVO-konform, Made in Germany, ohne dass Sie eine eigene Search-Infrastruktur engineering oder einen separaten Editorial-Stack betreiben müssen.

Shopware-6-Migrations-Demo live sehen und erleben Sie an einem realen Shopware-6-Setup, wie die Such-Infrastruktur in den Plugin-Stack integriert ist, wie die Mapping-Tabelle aus der Migrations-Phase direkt in die Such-Konfiguration übergeht und wie der Day-One-Einsatz ab Go-Live die Ziel-Qualität liefert, statt sie in eine Phase-zwei-Diskussion zu verschieben, die in der Praxis oft nicht mehr stattfindet. Wie die Multi-Storefront-Logik aus einer Hand orchestriert wird, statt pro Storefront eine separate Pflege-Strecke zu betreiben. Wie die Cookieless-Architektur den Privacy-Reset im Migrations-Moment direkt mitnimmt, statt die Privacy-Schulden der alten Plattform in die neue Plattform zu schleppen.