Referenz · Shopware 5 → Shopware 6 · Storefront · Migration · Plugin-Architektur

Shopware 6 Referenz: Dampfer-Taxi – Relaunch, Migration, Storefront & Borban Plugin-Stack

Dampfer-Taxi zeigt, wie weit eine Shopware-Neuentwicklung über ein neues Theme hinausgehen kann. Der gewachsene Shop wurde von Shopware 5 auf Shopware 6 neu aufgebaut. Grundlage ist bewusst Shopware 6 Standard; Gestaltung, Storefront-Logik und ein großer Teil der Funktionen stammen aus eigenen Borban-Modulen. Fremdplugins werden nur punktuell dort eingesetzt, wo externe Dienste oder klar abgegrenzte Infrastruktur benötigt werden – sie bestimmen weder Design noch Storefront-Architektur. Hinzu kommen kontrollierte Datenmigration, Kunden- und Altersprüfungsübernahme, SEO-URL-Migration, eine umfangreiche Produktdetail-Architektur und ein auf PageSpeed, Stabilität und tatsächlich benötigte Funktionen ausgerichteter technischer Aufbau.

Dampfer-Taxi live ansehen SW5 → SW6 Migration Storefront-System Plugin-Stack Projekt anfragen

Aus einem gewachsenen Shopware-5-Shop wurde eine neue Shopware-6-Architektur

Dampfer-Taxi ist seit vielen Jahren im E-Zigaretten-Fachhandel aktiv. Der Relaunch sollte deshalb nicht bei null anfangen und gleichzeitig nicht die technischen Altlasten eines gewachsenen Systems einfach weitertragen. Ziel war ein moderner, kontrollierbarer Shop mit eigener Storefront, sauberer Informationsarchitektur und eigenständigen Borban-Modulen.

Relaunch

Bestehender ShopGewachsene Shopware-5-Basis mit Kundenbestand, bestehenden Altersprüfungen, etablierten URLs, Produktdaten und langjähriger Marktpräsenz.

Neues ZielsystemShopware 6 mit eigener Storefront, moderner Produkt- und Kategoriearchitektur und klarer technischer Trennung der Funktionen.

Keine BlindmigrationÜbernommen wurde, was für Kunden, SEO, Betrieb und Compliance relevant war – nicht einfach jede technische Altstruktur des Vorgängersystems.

Produktiver Betrieb als MaßstabDie neue Architektur musste nicht nur in einer Demo funktionieren, sondern mit realen Kunden, Produkten, Varianten, Checkout und laufenden Bestellungen.

Projektziel: Bestehenden Wert erhalten, technische Abhängigkeiten reduzieren und gleichzeitig eine Plattform schaffen, auf der neue Borban-Funktionen unabhängig weiterentwickelt werden können.

Shopware 5 → Shopware 6: Migration von Daten, Kunden, Altersprüfungen & SEO-relevanten URLs

Der technische Kern des Projekts war nicht die Installation eines neuen Shops, sondern der kontrollierte Übergang eines gewachsenen Bestands. Kunden sollten ihren Zugang nicht unnötig verlieren, bereits erfolgte Altersprüfungen sollten berücksichtigt werden und bedeutsame Suchmaschinen-URLs durften beim Systemwechsel nicht einfach ins Leere laufen.

Migration

Kundendaten & Kundenkonten Relevante Bestandskundendaten wurden in das neue System überführt, damit der Relaunch nicht zu einem künstlichen Neustart der Kundenbasis wird.

Bestehende Altersprüfungen Bereits gültig verifizierte Kunden wurden bei der Migration berücksichtigt und in den neuen Verifizierungsstatus überführt, statt sie pauschal erneut durch die Altersprüfung zu schicken.

Bedeutsame Alt-URLs SEO-relevante URLs und wichtige Altpfade wurden systematisch in die neue Struktur übernommen beziehungsweise über definierte Weiterleitungen auf passende neue Ziele geführt.

Kategorien & Informationsstruktur Gewachsene Navigations- und Produktstrukturen wurden nicht nur technisch kopiert, sondern in eine verständlichere Shopware-6-Informationsarchitektur überführt.

Produkt- & Herstellerdaten Relevante Produktinformationen, Herstellerbeziehungen und benötigte Zuordnungen wurden für die neue Architektur übernommen und anschließend weiter strukturiert.

Selektive statt blinde Migration Ziel war nicht, technische Altlasten eins zu eins zu konservieren. Migriert wurde anhand des fachlichen Nutzens für Kunden, SEO, Betrieb und die neue Systemarchitektur.

Warum das wichtig ist: Ein Shopware-Relaunch kann Kundenbindung, Suchmaschinenhistorie und bestehende Compliance-Daten beschädigen, wenn die Migration nur als Produktimport verstanden wird. Dampfer-Taxi wurde deshalb als vollständiges Migrationsprojekt behandelt.

Plugin- & Datenmigration · Altersverifikation & AVS

Shopware 6 Standard als Basis – eigene Module nur dort, wo sie einen echten Zweck erfüllen

Dampfer-Taxi basiert bewusst auf dem Shopware-6-Standard. Statt ein umfangreiches Fremdtheme oder eine zusätzliche Designplattform über Shopware zu legen, werden benötigte Funktionen gezielt über eigene Borban-Erweiterungen ergänzt. Dadurch bleibt die technische Basis näher am Kernsystem und Verantwortlichkeiten lassen sich klarer zuordnen.

Standard First

Kein Fremdtheme als Fundament Die visuelle und funktionale Storefront wird nicht von einem kommerziellen Fremdtheme vorgegeben, sondern auf Shopware Standard und eigener Borban-Logik aufgebaut.

Eigene Funktionen mit klarer Aufgabe Storefront, Produktdetail, SEO, Kompatibilität, Checkout, Altersprüfung und weitere Bereiche werden in verantwortlichen Modulen statt in einem unübersichtlichen Sammel-Plugin gepflegt.

Fremdplugins nur punktuell Externe Plugins werden nur für klar abgegrenzte Drittservices oder Infrastruktur eingesetzt – etwa Zahlungs-, Mail- oder Bewertungsanbindungen. Sie übernehmen nicht Gestaltung oder zentrale Shoplogik.

Weniger Abhängigkeiten Je weniger zentrale Shopbereiche von fremden Theme- oder Funktionspaketen abhängen, desto kontrollierter lassen sich Updates, Fehleranalyse und Weiterentwicklung durchführen.

Prinzip: Shopware liefert das stabile Grundsystem. Eigene Erweiterungen kommen nur dort hinzu, wo Dampfer-Taxi eine konkrete Funktion benötigt. Ein Plugin mit zwanzig ungenutzten Funktionen wird nicht eingesetzt, wenn für den Shop nur zwei davon relevant wären.

Eigenes Storefront-System statt gekauftem Standardtheme und verstreuten Einzel-Fixes

Einer der wichtigsten Projektbausteine ist die eigene Borban-Storefront für Dampfer-Taxi. Wiederkehrende Darstellung, responsive Verhalten und zentrale UX-Bausteine werden über ein eigenes Storefront-System kontrolliert, statt den Shop über immer neue Theme-Overrides und Einzelpatches aufzubauen.

Storefront

Header & NavigationZentrale Navigations- und Headerlogik für Desktop und Mobile innerhalb der eigenen Storefront-Struktur.

Kategorie & ListingProduktkarten, Kategorie-Heroes, Filter-/Listing-Verhalten und Informationshierarchie werden als zusammenhängendes System betrachtet.

ProduktdetailseiteDarstellung von Preis, Varianten, Zusatzinformationen, Kompatibilität, Hinweisen und Conversion-Elementen wird gezielt erweitert.

Mobile UXMobile Darstellung wird nicht nachträglich „zurechtgebogen“, sondern als eigener Teil des Storefront-Systems behandelt.

Wiederverwendbare KomponentenFertige Bereiche werden zentral gepflegt, damit Änderungen nicht an vielen voneinander unabhängigen Stellen wiederholt werden müssen.

Performance & StabilitätStorefront-Logik, Assets und Ladeverhalten können an der verantwortlichen Stelle optimiert werden, ohne zusätzliche Patch-Layer aufzubauen.

Architektur statt Theme-Bastelei: Der Vorteil des eigenen Storefront-Systems liegt nicht nur im Erscheinungsbild. Entscheidend sind Wartbarkeit, kontrollierte Weiterentwicklung und die Möglichkeit, neue Funktionen sauber in eine bereits definierte Shopstruktur zu integrieren.

Produktdetailseite als Informationssystem – nicht nur Bild, Preis und Warenkorb

Die Produktdetailseite wurde bewusst als zentrale Informations- und Entscheidungsseite aufgebaut. Je nach Produkttyp erscheinen genau die Informationen, die für Auswahl, Kompatibilität, Sicherheit, gesetzliche Hinweise und Kaufentscheidung relevant sind. Nicht benötigte Blöcke werden nicht künstlich auf jedem Produkt erzwungen.

Product Detail UX

Strukturierte Produkt-Tabs Produktbeschreibung, technische Informationen und zusätzliche Inhalte werden in klar getrennten Bereichen beziehungsweise Tabs organisiert, statt lange unstrukturierte Seiten zu erzeugen.

Produktdetails & „Auf einen Blick“ Wichtige Merkmale wie Produkttyp, Tankvolumen, Modell, Nikotinstärke, Inhalt oder Gerätezuordnung werden kompakt strukturiert ausgegeben.

Kompatible Geräte & Zubehör Bei Pods, Coils, Tanks und Ersatzteilen steht die reale Geräte- und Serienkompatibilität im Mittelpunkt – nicht nur Herstellername oder gleicher Widerstand.

Produktspezifische FAQ Häufige Fragen können direkt anhand der tatsächlich hinterlegten Produktdaten beantwortet werden und reduzieren unnötige Suche nach Basisinformationen.

CLP & Gefahrstoffinformationen Bei relevanten Produkten werden Piktogramme sowie H-, P- und EUH-Sätze strukturiert direkt am Produkt ausgegeben.

GPSR, Hersteller & Importeur Produktsicherheitsinformationen, Hersteller-/Importeurdaten und vorhandene Gebrauchsinformationen beziehungsweise PDFs werden produktbezogen zugänglich gemacht.

ElektroG & Altgeräte-Rücknahme Bei betroffenen Elektroprodukten wird der gesetzlich relevante Rücknahme-/Entsorgungskontext in den Produktprozess eingebunden und auf die ausführlichen Rücknahmeinformationen geführt.

Trust direkt am Kaufprozess Originalware, Versand, Rückgabe, Zahlarten, Versandfreigrenze und erreichbarer Kundenservice werden als klare Vertrauens- und Serviceinformationen sichtbar gehalten.

Mobile-first Reihenfolge Auf kleinen Displays werden Produktinformationen, Kaufbereich und relevante Zusatzinhalte gezielt priorisiert, statt die Desktopseite lediglich schmaler darzustellen.

Nur passende Inhalte ausspielen Ein Elektrohinweis gehört nicht auf ein Aroma, CLP nicht auf jedes Zubehörteil und Kompatibilität nicht auf jedes Produkt. Die Seite reagiert auf Produkttyp und vorhandene Daten.

Beispiel aus dem Live-Shop: Auf Produktseiten werden bereits Produktdetails, Kompatibilität, „Auf einen Blick“, FAQ, CLP-Informationen, GPSR-Daten und verlinkte Gebrauchsinformationen strukturiert ausgespielt. Das Produktdetail-System ist damit gleichzeitig Verkaufsseite, Datenansicht, Sicherheitsinformation und Servicepunkt.

Produktdetail live ansehen · Elektroaltgeräte-Rücknahme

PageSpeed- und Core-Web-Vitals-orientiert: weniger Ballast, klarere Verantwortlichkeiten

Performance wurde bei Dampfer-Taxi nicht erst nach dem Relaunch als einzelner „Speed-Fix“ betrachtet. Die technische Architektur selbst ist auf möglichst wenig unnötige Abhängigkeiten, kontrollierte Assets und gezielt benötigte Funktionen ausgerichtet. Optimiert wird an der Ursache im verantwortlichen Modul, nicht durch immer neue Override- und Patch-Schichten.

Performance

Nur benötigte Funktionen Module werden auf den realen Shopbedarf zugeschnitten. Ungenutzte Universal-Funktionen müssen nicht allein deshalb mitgetragen werden, weil ein Fremdplugin sie anbietet.

Shopware Standard als schlanke Basis Kein zusätzliches Fremdtheme als zweite große Frontend-Schicht über dem Shopware-Kern reduziert unnötige Design- und Asset-Abhängigkeiten.

CLS & Layout-Stabilität Responsive Komponenten, Bilder, Icons, Produktgalerie und dynamische Storefront-Bereiche werden mit Blick auf sichtbare Layoutverschiebungen und stabile Darstellung optimiert.

Bilder & Medien Moderne Bildformate, sinnvolle Dateinamen, passende Dimensionen und kontrollierte Ladewege verbinden Medien-SEO mit Performance-Anforderungen.

Gezieltes Laden Schwere oder dynamische Inhalte sollen nur dort und dann geladen werden, wo sie tatsächlich benötigt werden – statt jeden Besucher mit allen Funktionen vorzubelasten.

PageSpeed als laufende Qualitätskontrolle Performance, Ladeverhalten und Core-Web-Vitals-relevante Auffälligkeiten werden bei Weiterentwicklungen mitgeprüft, statt nur einmal zum Launch gemessen zu werden.

Keine künstliche Score-Werbung: Die Referenz nennt bewusst keinen dauerhaft garantierten Lighthouse- oder PageSpeed-Wert. Messwerte verändern sich durch Gerät, Netzwerk, Inhalte und Drittservices. Entscheidend ist die Architektur: möglichst wenig Ballast, stabile Komponenten und Optimierung an der eigentlichen Ursache.

Eigener Plugin-Stack: spezialisierte Module statt eines einzigen überladenen Alleskönners

Ein großer Teil der Dampfer-Taxi-Funktionalität stammt aus eigenen Borban-Erweiterungen. Die Module haben jeweils einen klaren Verantwortungsbereich und lassen sich unabhängig weiterentwickeln. Das reduziert Abhängigkeiten und verhindert, dass eine Änderung an einer kleinen Funktion unnötig einen komplett fremdgesteuerten Shopbereich mitzieht.

Borban Plugins

Borban Dampfer-Taxi Storefront Zentrale Storefront- und UX-Basis für das individuelle Erscheinungsbild und die shopweiten Komponenten auf Shopware-6-Standard.

Product Detail Extras & Tabs Produktdetail-Erweiterungen, zusätzliche Tabs, Produktinformationen und strukturierte Zusatzbereiche ohne ein monolithisches Theme-Plugin.

Product Compatibility Pro Belastbare Geräte-, Pod-, Coil- und Zubehörzuordnungen auf Basis tatsächlicher Kompatibilität statt Namensähnlichkeit.

Mobile Header & Mobile Description Eigene mobile Navigation und priorisierte Produktinformationen für kleine Viewports.

Checkout Clarity & Free Delivery Gezielte Checkout-, Versand- und Conversion-Funktionen statt eines allgemeinen Marketing-Sammelplugins.

Verify Pro Eigene Altersverifikation mit automatischen und manuellen Prüfwegen sowie migrierbarem Verifizierungsstatus.

Image Sitemap, Media ALT/TITLE & Renaming Medien-SEO, strukturierte Bilddaten und Dateipflege über getrennte spezialisierte Module.

SEO SafeSwitch, Meta Optimizer & Schema Intelligence SEO-Migration, Meta-Daten und strukturierte Daten werden kontrolliert und getrennt von der Storefront-Optik gepflegt.

Document Localizer & Product Knowledge Dokumente, Gebrauchsinformationen und zusätzliche Produktkenntnisse können systematisch an den richtigen Produktkontext angebunden werden.

Category HTML & Listing Module Kategorieinhalte, Kurzbeschreibungen und Listingdarstellung werden über eigene, klar begrenzte Funktionen gesteuert.

Daily Tip, Merchandising & Trust Wiederkehrende Inhalte, Service-/Trustelemente und operative Shopkommunikation lassen sich gezielt ergänzen, ohne das Kernsystem aufzublähen.

Administration & Shopbetrieb Custom Code Manager, Analytics-, Shop- und weitere Administrationsmodule unterstützen wiederkehrende Aufgaben hinter der Storefront.

Fremdplugins bleiben Ausnahme und Infrastruktur: Einige externe Erweiterungen sind für Drittservices wie Payment, Mailarchivierung oder Bewertungsanbindungen sinnvoll. Sie ersetzen aber weder das Storefront-System noch die zentrale Produkt-, SEO-, Checkout- oder Datenarchitektur von Dampfer-Taxi.

Shopware Plugins · Erweiterungen auf Anfrage · Systemlösungen

Keine PowerPoint-Referenz: zentrale Funktionen sind live nachvollziehbar

Interessenten können zentrale Teile der neuen Informations- und Storefront-Architektur direkt im produktiven Shop ansehen. Dadurch wird aus einer Referenz ein überprüfbares Praxisbeispiel.

Live

Startseite & StorefrontAktuelle Shopstruktur, Navigation, Content-Module und responsive Storefront im Produktivbetrieb.Live öffnen Pods & CoilsBeispiel für strukturierte Zubehörlogik und den Fokus auf echte Geräte-/Serienkompatibilität.Live öffnen Zubehör & KategoriearchitekturHersteller- und serienbezogene Struktur für Ersatzteile, Pods, Coils und weiteres Zubehör.Live öffnen Altersverifikation & FallbackÖffentlich dokumentierter manueller Ersatzweg für Fälle, in denen die automatische Altersprüfung nicht eindeutig abgeschlossen werden kann.Live öffnen FAQ & Service-ArchitekturStrukturierte Antworten zu Bestellung, Versand, Altersprüfung, Produkten und Zubehör.Live öffnen Transparenz & HistorieDer Shop beschreibt selbst den technischen und strukturellen Neuaufbau und verbindet ihn mit seiner langjährigen Marktgeschichte.Live öffnen

Ergebnis: eine eigenständig kontrollierbare E-Commerce-Architektur statt eines Plugin-Puzzles

Dampfer-Taxi zeigt, wie Migration, Storefront, SEO, Produktdaten, Altersprüfung und Plugins als zusammenhängendes System geplant werden können. Der Shop bleibt erweiterbar, ohne jede neue Anforderung zwangsläufig an ein zusätzliches fremdes Mietplugin oder einen weiteren Theme-Patch zu binden.

Ergebnis

Shopware 6 Standard + eigene StorefrontDer Shop bleibt nah am Kernsystem; Gestaltung und benötigte Zusatzfunktionen werden über eigene Borban-Module kontrolliert.

Bestandswert erhaltenRelevante Kunden-, Verifizierungs- und SEO-Bestände wurden in den Relaunch einbezogen.

Plugin-Abhängigkeiten reduziertViele Funktionen werden über eigene Borban-Module und Systemlösungen kontrolliert.

Performance-orientiert & überprüfbarPageSpeed, stabile UX und ein möglichst schlanker Funktionsumfang werden laufend berücksichtigt – im echten produktiven Shop.

Ähnliches Projekt anfragen Plugin-Migration Altersverifikation Weitere Erweiterungen Weitere Projekte

FAQ zur Shopware-5-zu-6-Referenz Dampfer-Taxi

Antworten zu Migration, Kundendaten, Altersverifikation, URLs, Storefront und Borban-Plugins.

12 Fragen

Basiert Dampfer-Taxi auf einem gekauften Shopware Theme?

Nein. Die technische Basis ist Shopware 6 Standard. Gestaltung und zentrale Storefront-Funktionen werden über das eigene Borban-Storefront-System und spezialisierte Borban-Module umgesetzt.

Werden bei Dampfer-Taxi Fremdplugins eingesetzt?

Nur punktuell. Externe Erweiterungen werden für klar abgegrenzte Drittservices oder Infrastruktur eingesetzt, etwa Zahlungs-, Mail- oder Bewertungsanbindungen. Die Shopgestaltung, Storefront-Architektur und zentrale Produktlogik werden dadurch nicht übernommen.

Welche Funktionen bietet die Produktdetailseite?

Je nach Produkttyp können strukturierte Produkt-Tabs, technische Produktdaten, „Auf einen Blick“, Gerätekompatibilität, FAQ, CLP-Gefahrstoffinformationen, GPSR-Hersteller- und Importeurdaten, Gebrauchsinformationen, Trustelemente sowie produktabhängige gesetzliche Hinweise wie ElektroG-Rücknahmeinformationen erscheinen.

Ist Dampfer-Taxi auf PageSpeed optimiert?

Die Architektur und laufende Weiterentwicklung sind ausdrücklich auf Performance, Layout-Stabilität und Core-Web-Vitals-relevante Faktoren ausgerichtet. Statt einen festen Lighthouse-Wert zu garantieren, werden unnötige Funktionen und Abhängigkeiten vermieden und Auffälligkeiten an der verantwortlichen Ursache optimiert.

Was wurde bei Dampfer-Taxi technisch umgesetzt?

Dampfer-Taxi wurde von einer gewachsenen Shopware-5-Basis auf Shopware 6 neu aufgebaut. Bestandteil waren unter anderem Storefront, Datenmigration, SEO-relevante URL-Migration, Kunden- und Altersprüfungsdaten, Produkt- und Kategoriearchitektur sowie zahlreiche eigene Borban-Module.

Wurden bestehende Kundenkonten übernommen?

Ja. Relevante Kundendaten wurden in den neuen Shop überführt. Ziel war, Bestandskunden möglichst ohne unnötigen Neustart in der neuen Shopware-6-Umgebung weiterzuführen.

Was geschah mit bereits erfolgten Altersprüfungen?

Bestehende gültige Altersverifizierungen wurden im Rahmen der Migration berücksichtigt und in den neuen Verifizierungsstatus überführt, damit bereits geprüfte Bestandskunden nicht grundlos erneut verifiziert werden mussten.

Wie wurden alte URLs und SEO-Signale behandelt?

Bedeutsame Alt-URLs und SEO-relevante Pfade wurden bei der neuen Informationsarchitektur berücksichtigt und in die neue Struktur überführt beziehungsweise gezielt weitergeleitet. Ziel war, einen Relaunch nicht wie einen vollständigen SEO-Neustart zu behandeln.

Warum ist das Storefront-System besonders?

Zentrale Darstellung und UX wurden nicht als lose Sammlung einzelner CSS-Fixes aufgebaut. Für Dampfer-Taxi entstand ein eigenes Storefront-System, das shopweite Komponenten, responsive Verhalten und wiederkehrende Darstellungslogik kontrolliert zusammenführt.

Welche Borban Plugins laufen im Projekt?

Im Projekt kommt ein großer Teil des Borban-Stacks zum Einsatz. Dazu gehören je nach Bereich unter anderem Module für Altersverifikation, Checkout, Produkt- und Kompatibilitätsdaten, Medien-SEO, strukturierte Daten, Content, Storefront und operative Shopprozesse.

Ist Dampfer-Taxi nur eine Demo?

Nein. Dampfer-Taxi ist ein produktiver E-Commerce-Shop. Genau deshalb eignet sich das Projekt als Referenz: Storefront, Datenmodelle, Kundenstatus, Checkout, Produktinformationen und Plugins müssen im laufenden Betrieb zusammenspielen.

Kann eine ähnliche Architektur für andere Shops umgesetzt werden?

Ja. Die konkrete Lösung wird nicht blind kopiert. Storefront, Plugins, Migration und Integrationen werden anhand des vorhandenen Shops, der Daten und des gewünschten Zielsystems geplant.

Transparenz-Hinweis: Diese Referenz beschreibt ein reales Borban-Projekt und öffentlich nachvollziehbare Funktionen des produktiven Shops. Nicht jedes interne Modul, jede Datenstruktur oder jedes technische Detail wird öffentlich offengelegt. Aussagen zu Migration und Systemarchitektur beziehen sich auf den konkreten Dampfer-Taxi-Relaunch; der Umfang anderer Projekte hängt vom jeweiligen Ausgangssystem und Datenbestand ab.