Zum Hauptinhalt springen Zur Suche springen Zur Hauptnavigation springen

  Telefonservice: 02843 9595-305

  Schneller Versand

  14 Tage kostenloser Umtausch

  Sicher Einkaufen dank SSL

Borban Referenz · Shopware 5 → Shopware 6 · Relaunch eines gewachsenen Fachshops

Dampfer-Taxi: kontrollierter Shopware-6-Relaunch mit Migration, eigener Storefront und Borban-Systemarchitektur

Dampfer-Taxi ist keine Greenfield-Entwicklung. Der heutige Shop entstand aus einem über Jahre gewachsenen Shopware-5-System mit Bestandskunden, vorhandenen Altersprüfungen, etablierten URLs, Produkt- und Kategoriestrukturen sowie historisch gewachsener Shoplogik. Beim Wechsel auf Shopware 6 ging es deshalb nicht darum, nur einen neuen Shop zu installieren, sondern vorhandenen Wert gezielt zu übernehmen, technische Altlasten nicht blind mitzuschleppen und gleichzeitig eine neue, eigenständig kontrollierbare Storefront- und Plugin-Architektur aufzubauen.

01 · Ausgangspunkt

Ein langjähriger Shop sollte technisch neu entstehen – ohne seine gewachsene Substanz zu verlieren

Relaunch statt Neustart

Bei einem gewachsenen E-Commerce-System besteht die schwierigste Aufgabe nicht darin, eine neue Plattform zu installieren. Entscheidend ist die Frage, welche vorhandenen Strukturen Wert besitzen und welche Altlasten nicht weitergetragen werden sollten. Dampfer-Taxi hatte bereits vor dem Relaunch Kunden, wiederkehrende Käufer, verifizierte Volljährige, etablierte Suchmaschinenpfade, Hersteller- und Produktbeziehungen sowie eine lange Marktgeschichte. Ein radikaler technischer Schnitt ohne Migrationsstrategie hätte diese Bestände unnötig gefährdet.

A

Bestandswert erhalten

Kundenkonten, gültige Prüfstände, wichtige Inhalte und relevante SEO-Pfade wurden als zu erhaltende Projektwerte behandelt.

B

Altstruktur nicht konservieren

Shopware-5-Technik wurde nicht allein deshalb übernommen, weil sie bereits existierte. Maßgeblich war der Nutzen im neuen Zielsystem.

C

Neue Informationsarchitektur

Kategorien, Produktinformationen, Zubehörwege und mobile Darstellung wurden für Shopware 6 fachlich neu geordnet.

D

Produktiver Shop als Testmaßstab

Die neue Architektur musste mit echten Kunden, Bestellungen, Varianten, Zahlarten und Serviceprozessen funktionieren.

Abgrenzung zu E-Zigaretten.org: Dort steht die Greenfield-Neuentwicklung und neue Daten-/Wissensarchitektur im Vordergrund. Bei Dampfer-Taxi ist die Kernleistung die kontrollierte Transformation eines vorhandenen Shopware-5-Bestands in eine neue Shopware-6-Architektur.
02 · Migration

Eigene Migrationswerkzeuge statt eines einzigen unkontrollierten Komplettimports

Daten unter Kontrolle

Für den Relaunch wurden unterschiedliche Aufgaben bewusst voneinander getrennt. Kundenmigration, allgemeine Datenübernahme, Content-Import und SEO-URL-Verarbeitung sind fachlich verschiedene Risiken. Im Projekt entstanden deshalb eigene Borban-Komponenten für klar abgegrenzte Migrationsschritte. Dadurch lässt sich ein problematischer Datenbereich untersuchen, ohne gleichzeitig die gesamte Migration neu anfassen zu müssen.

01Bestand analysieren
Kunden, Inhalte, URLs, Verifizierung, Kategorien
02Zielmodell definieren
Was gehört in Shopware 6 – und in welcher Form?
03Getrennt migrieren
Kunden, Content und SEO-Pfade über spezialisierte Werkzeuge
04Ergebnis prüfen
Konten, Status, Ziel-URLs und Storefront praktisch kontrollieren

Borban Customer Migration

Projektmodul für die Übernahme relevanter Bestandskundendaten in die Shopware-6-Umgebung.

Projektbezogenes Migrationswerkzeug

Borban DT Migration Import

Eigene Importlogik für projektspezifische Daten, die nicht als einfacher Standardimport behandelt werden sollten.

Projektbezogenes Migrationswerkzeug

Borban DT Content Import

Getrennte Verarbeitung von Inhalten, damit redaktionelle Strukturen und Shopdaten nicht unnötig in einem Import vermischt werden.

Content-Migration

Borban DT SEO URL Manager

Werkzeug für die gezielte Behandlung relevanter Alt- und Zielpfade rund um den Plattformwechsel.

SEO-Migrationslogik
Warum die Trennung zählt: Migration ist kein einmaliger Datei-Upload. Ein Shop kann technisch erreichbar sein und trotzdem Kundenstatus, Redirects, Kategoriestruktur oder Inhalte falsch übernommen haben. Getrennte Werkzeuge machen solche Fehlerquellen besser prüfbar.
03 · SEO-Kontinuität

Der Plattformwechsel sollte nicht zum künstlichen SEO-Neustart werden

URLs · Content · Struktur

Ein Shopware-Relaunch verändert technische Pfade, Templates, Kategorien und häufig auch die interne Verlinkung. Für einen langjährig indexierten Shop ist deshalb nicht nur wichtig, dass neue Seiten existieren. Ebenso wichtig ist, welche alten URLs weitergeführt, welche sinnvoll weitergeleitet und welche Inhalte fachlich neu strukturiert werden. Dampfer-Taxi behandelt SEO deshalb als Teil der Migration und nicht als nachträgliche Meta-Text-Runde.

Alt-URL → fachlich passendes Ziel

Historische Pfade werden nicht pauschal auf die Startseite geschickt. Das Ziel soll inhaltlich zur bisherigen Suchintention passen.

Kategoriearchitektur neu geordnet

Geräte, Pods, Coils und Ersatzteile werden so strukturiert, dass Nutzer und Suchmaschinen den jeweiligen Produkttyp besser einordnen können.

SEO SafeSwitch & Meta Optimierung

Eigene Module unterstützen kontrollierte SEO-Zustände, Meta-Daten und technische Prüfung unabhängig von der Storefront-Optik.

Schema & Medien

Strukturierte Daten, ALT/TITLE-Pflege und Image-Sitemap sind eigene Verantwortungsbereiche statt Nebenfunktion eines Themes.

04 · Storefront & Mobile

Shopware 6 als Basis, aber eine eigene Dampfer-Taxi-Storefront für die reale Nutzerführung

UX-System

Der Relaunch sollte nicht in einer Sammlung aus Theme-Patches enden. Deshalb wird die zentrale Darstellung über eine eigene Dampfer-Taxi-Storefront und klar abgegrenzte Zusatzmodule gesteuert. Desktop und Mobile werden dabei als zusammenhängende, aber nicht identische Nutzungssituationen betrachtet.

Dampfer-Taxi Storefront

Projektweite Basis für wiederkehrende Darstellung, responsive Komponenten und die visuelle Integration eigener Funktionen.

Compact Mega Menu

Navigation soll große Sortimente verständlich strukturieren, ohne auf kleinen Viewports unkontrolliert zu wachsen.

Borban Mobile Header

Mobile Suche, Header-Elemente und wichtige Aktionen werden für kleinere Displays gezielt priorisiert.

Öffentlich verfügbares Borban-Plugin

Mobile Description First

Wichtige Produktinformation wird mobil früher sichtbar, statt ausschließlich in weiter unten liegenden Tabs zu verschwinden.

Öffentlich verfügbares Borban-Plugin

Filter Remover / No Listing Filters

Unnötige oder fachlich nicht hilfreiche Filterflächen können gezielt entfernt werden, damit Listings ruhiger bleiben.

Öffentlich verfügbares Borban-Plugin

Checkout Clarity & Free Delivery

Versand-, Schwellen- und Checkout-Informationen werden als eigene UX-Aufgaben behandelt und nicht in beliebige Theme-Fragmente verteilt.

05 · Produktarchitektur

Produktseiten sollen Auswahlfehler reduzieren – besonders bei Pods, Coils und technischem Zubehör

Produktwissen

Dampfer-Taxi verkauft viele Produkte, bei denen ein ähnliches Aussehen oder derselbe Widerstand keine sichere Aussage über die Kompatibilität erlaubt. Deshalb wurde die Produktdarstellung über reine Titel-, Preis- und Warenkorbinformationen hinaus ausgebaut. Gerät, Serie, Produkttyp und belegte Zubehörbeziehung stehen im Mittelpunkt.

Product Detail Extras

Zusätzliche Produktinformationen und projektspezifische Darstellung rund um die eigentliche Shopware-Produktseite.

Product Detail Tabs Pro

Inhalte werden nach Funktion getrennt, damit technische Daten, Beschreibung und zusätzliche Hinweise nicht zu einem unstrukturierten Textblock werden.

Product Compatibility Pro

Kompatibilitäten werden als eigene Datenbeziehung behandelt – besonders für Geräte, Pods, Coils, Tanks und Ersatzteile.

Product Knowledge Pro

Zusätzliches Produktwissen kann strukturiert an Produkte angebunden werden, statt in verstreuten Notizen verloren zu gehen.

Listing Short Description

Listings erhalten kompakte, relevante Informationen, damit Kunden Produkte bereits vor dem Öffnen besser unterscheiden können.

Liquid Category Sync & Category HTML

Produkt- und Kategoriezuordnung sowie Kategorieinhalte werden über eigene Werkzeuge kontrolliert und weiterentwickelt.

Praxisregel: Gleicher Hersteller oder gleicher Ohm-Wert reicht nicht als Nachweis. Dampfer-Taxi weist auch im Live-Shop darauf hin, dass konkrete Geräte- und Serienzuordnung entscheidend sind.
06 · Jugendschutz, Datenschutz & Sicherheit

Verifizierung und Schutzmechanismen müssen sicher sein, dürfen aber den normalen Kaufprozess nicht unnötig blockieren

Betriebssicherheit

Bei einem regulierten Fachshop sind Jugendschutz, Datenschutz und Shop-Sicherheit keine losgelösten Zusatzseiten. Sie greifen direkt in Kundenkonto, Checkout und Service ein. Im Relaunch wurden deshalb sowohl bestehende Verifizierungsstände migriert als auch neue eigene Module für Altersprüfung, Löschprozesse und Bot-Schutz eingebunden.

Borban Verify Pro

Eigene Altersverifikation mit automatischen und manuellen Prüfwegen. Bereits gültige Bestandsprüfungen konnten im Migrationskonzept berücksichtigt werden.

Öffentlich verfügbares Borban-Plugin

GDPR Deletion Center

Strukturierte Bearbeitung von Kundenkonto-Löschanforderungen und datenschutzbezogenen operativen Vorgängen.

Borban Bot Shield

Eigene Schutzschicht für typische Bot-Muster, entwickelt mit dem Ziel, reguläre Käufer möglichst nicht durch unnötige sichtbare Prüfungen auszubremsen.

Checkout Clarity

Checkout-nahe Informationen und Eingriffe werden kontrolliert behandelt, weil Fehler in diesem Bereich unmittelbar Bestellungen verhindern können.

Praxisfall: Bot-Schutz ohne unnötige Kundenhürde

Im Shopbetrieb zeigte sich, dass externe CAPTCHA-Prüfungen je nach Situation den Checkout beeinträchtigen können. Ein einzelner Honeypot ist wiederum als alleinige Schutzschicht zu dünn, während klassische Zahlen-/Buchstaben-CAPTCHAs zusätzliche Reibung erzeugen.

Borban Bot Shield
ProblemBot-Abwehr darf den Checkout nicht selbst zum Fehlerpunkt machen.
VerworfenNur Honeypot oder sichtbare Zeichen-CAPTCHAs als alleinige Lösung.
ZielMöglichst unsichtbare, mehrschichtige Prüfung mit geringer Kundenreibung.
ProjektprinzipSicherheit als eigener Verantwortungsbereich statt zufälliger Theme-Funktion.
07 · Borban Live Stack

Die Projektumgebung besteht aus spezialisierten Borban-Komponenten für Migration, Storefront, SEO, Produktwissen und Betrieb

Real im Projekt

Die Plugin-Verzeichnisse des Projekts zeigen eine umfangreiche eigene Borban-Architektur. Für die öffentliche Referenz ist dabei nicht jede interne technische Komponente relevant. Sinnvoll ist die fachliche Einordnung: Welche Aufgabe löst ein Modul im Relaunch und welche Funktionen sind inzwischen auch als allgemeines Borban-Plugin verfügbar?

Migration & Bestandsübernahme

Kundendaten, Inhalte und SEO-Pfade werden über getrennte Projektwerkzeuge verarbeitet.

Customer MigrationDT Migration ImportDT Content ImportDT SEO URL Manager

Storefront & Navigation

Shopweite Darstellung und mobile Nutzerführung werden über eigene Komponenten kontrolliert.

Dampfer-Taxi StorefrontMobile HeaderCompact Mega MenuMobile Description FirstFilter RemoverCheckout ClarityFree Delivery

Produkt & Content

Produktwissen, Kompatibilität, Kategorielogik und Listinginformationen bleiben getrennt wartbar.

Product Compatibility ProProduct Knowledge ProProduct Detail ExtrasProduct Detail Tabs ProCategory HTML ManagerLiquid Category SyncListing Short DescriptionDocument Localizer

SEO, Medien & strukturierte Daten

Technische SEO-Aufgaben werden nicht als Nebenprodukt des Themes behandelt.

SEO SafeSwitch ProMeta Optimizer ProSchema Intelligence ProImage Sitemap ProMedia ALT/TITLE WriterBorban Plugin-Hub

Sicherheit & Datenschutz

Verifizierung, Bot-Abwehr und Löschprozesse besitzen eigene Verantwortungsbereiche.

Verify ProBot ShieldGDPR Deletion Center

Shopbetrieb & Administration

Wiederkehrende operative Aufgaben lassen sich über eigene Werkzeuge steuern und dokumentieren.

Shop ManagerCustom Code ManagerAnalytics ProAI Shop AdvisorDaily TipLink RemoverFooter Pro
Öffentlich vs. projektspezifisch: Nicht jedes Modul aus einer realen Projektumgebung wird als Standardprodukt angeboten. Öffentliche Borban-Plugins sind direkt verlinkt; andere Einträge zeigen projektspezifische Entwicklungsarbeit und werden bewusst nicht als Shopprodukt dargestellt.
08 · Performance & Wartbarkeit

Performance ist keine einmalige „Speed-Optimierung“, sondern Folge der Architektur

Core Web Vitals

Ein Shop mit vielen Funktionen wird nicht automatisch schnell, nur weil einzelne Dateien minifiziert werden. Für Dampfer-Taxi ist entscheidend, dass Verantwortlichkeiten klar bleiben: Storefront, Produktwissen, SEO, Medien, Checkout und Migration werden nicht in einem einzigen schwer kontrollierbaren Paket vermischt. Dadurch können Auffälligkeiten gezielter untersucht werden.

Weniger unnötige Abhängigkeiten

Eigene, klar begrenzte Module ersetzen dort umfangreiche Fremdpakete, wo nur ein kleiner Teil deren Funktionsumfang benötigt würde.

Layout-Stabilität

Bilder, Header, Produktgalerie und dynamische Bereiche werden mit Blick auf sichtbare Verschiebungen und responsive Stabilität geprüft.

Medien separat optimieren

Dateinamen, ALT-/TITLE-Daten, Formate und Image-Sitemap können unabhängig vom Seitenlayout gepflegt werden.

Fehler an der Ursache beheben

Wenn eine Funktion Probleme verursacht, soll möglichst das zuständige Modul korrigiert werden – nicht die nächste globale CSS- oder JavaScript-Schicht darübergelegt werden.

Keine künstliche Score-Garantie: Lighthouse- und PageSpeed-Werte verändern sich mit Gerät, Netzwerk, Inhalt und Drittservices. Die Referenz beschreibt deshalb die technische Vorgehensweise statt einen dauerhaft festen Messwert zu versprechen.
09 · Live nachvollziehbar

Der produktive Shop macht zentrale Teile des Relaunches überprüfbar

Live-System
10 · Ergebnis

Ein gewachsener Fachshop wurde technisch neu aufgebaut, ohne so zu tun, als hätte seine Vergangenheit nie existiert

Ergebnis

Shopware-5-Bestand kontrolliert überführt

Migration wurde als eigener Projektbereich behandelt – mit spezialisierten Werkzeugen für unterschiedliche Datenklassen.

Eigene Shopware-6-Storefront

Die neue Frontend-Architektur ist nicht an die Darstellungslogik des alten Systems oder ein großes Fremdtheme gebunden.

SEO-Kontinuität berücksichtigt

Wichtige Altpfade, neue Informationsarchitektur und technische SEO-Aufgaben wurden zusammen gedacht.

Produktwissen stärker strukturiert

Kompatibilität, Listinginformationen, Dokumente und produktbezogene Zusatzdaten besitzen eigene Zuständigkeiten.

Jugendschutz in die Migration integriert

Altersverifikation wurde nicht als isoliertes Frontend-Widget betrachtet, sondern als Kundenstatus und Geschäftsprozess.

Erweiterbar ohne Plugin-Puzzle

Neue Anforderungen können in klar abgegrenzten Modulen ergänzt werden, statt immer mehr voneinander abhängige Patch-Schichten aufzubauen.

FAQ

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

14 Fragen
Was war der Ausgangspunkt des Dampfer-Taxi-Relaunches?
Ausgangspunkt war kein leerer neuer Shop, sondern ein über Jahre gewachsener Shopware-5-Fachshop. Beim Wechsel auf Shopware 6 mussten deshalb nicht nur Produkte, sondern auch Kundenkonten, vorhandene Verifizierungsstände, relevante Inhalte, Kategorien und SEO-wichtige URL-Beziehungen berücksichtigt werden.
Basiert Dampfer-Taxi heute auf einem gekauften Shopware-Theme?
Nein. Die technische Grundlage ist Shopware 6. Zentrale Darstellung, responsive Storefront-Bausteine und projektspezifische UX-Funktionen werden über die eigene Dampfer-Taxi-Storefront und spezialisierte Borban-Module kontrolliert.
Wurden bestehende Kundenkonten aus Shopware 5 übernommen?
Ja. Relevante Bestandskundendaten wurden in die neue Umgebung überführt. Ziel war, einen Systemwechsel nicht wie einen künstlichen Neustart der Kundenbeziehung zu behandeln.
Was geschah mit bereits erfolgten Altersprüfungen?
Gültige vorhandene Verifizierungsstände wurden bei der Migration berücksichtigt. Bereits geprüfte Bestandskunden sollten nicht allein wegen des technischen Plattformwechsels grundlos erneut den vollständigen Prüfprozess durchlaufen.
Wie wurden alte URLs und SEO-Signale behandelt?
Wichtige Altpfade wurden nicht einfach verworfen. Für Dampfer-Taxi entstanden eigene Werkzeuge und Migrationsregeln, um relevante Shopware-5-URLs, Zielpfade und Weiterleitungen kontrolliert in die neue Shopware-6-Struktur zu überführen.
Welche eigenen Migrationsmodule wurden für das Projekt entwickelt?
Zum Projekt gehören unter anderem spezialisierte Borban-Komponenten für Kundenmigration, allgemeine Datenmigration, Content-Import und SEO-URL-Verwaltung. Diese Trennung war bewusst gewählt, damit einzelne Migrationsbereiche separat geprüft und weiterentwickelt werden konnten.
Welche Funktionen bietet die heutige Produktdetailseite?
Je nach Produkt können strukturierte Produktinformationen, kompakte Merkmale, Varianten, kompatible Geräte oder Zubehör, FAQ, CLP- und Produktsicherheitsinformationen, Hersteller-/Importeurangaben, Dokumente sowie service- und kaufrelevante Hinweise ausgespielt werden.
Wie wird bei Pods, Coils und Ersatzteilen die Kompatibilität behandelt?
Nicht nach ähnlichem Namen oder gleichem Ohm-Wert. Maßgeblich sind Hersteller, konkrete Geräte- oder Serienbezeichnung und die tatsächlich belegte Systemzuordnung. Unklare Beziehungen sollen nicht als vermeintlich sichere Kompatibilität dargestellt werden.
Welche Borban-Plugins werden öffentlich als fertige Lösungen angeboten?
Ein Teil der in realen Shopprojekten entstandenen Funktionen wird inzwischen als eigenständiges Borban-Plugin angeboten, zum Beispiel Mobile Header, Mobile Description First, Filter Remover und Verify Pro. Andere Komponenten bleiben projektspezifische Werkzeuge oder interne Module.
Warum gibt es bei Dampfer-Taxi einen eigenen Bot Shield?
Bot-Schutz soll den Checkout schützen, ohne reguläre Käufer unnötig auszubremsen. Im praktischen Betrieb waren sichtbare CAPTCHA-Lösungen beziehungsweise externe Prüfwege nicht in jeder Situation ideal. Borban Bot Shield wurde deshalb als eigene, möglichst reibungsarme Schutzschicht entwickelt; ein einfacher Honeypot allein wird dabei nicht als vollständiges Sicherheitskonzept verstanden.
Ist Dampfer-Taxi auf PageSpeed und Core Web Vitals ausgerichtet?
Ja, als laufendes Architekturziel. Statt einen dauerhaft festen Lighthouse-Wert zu versprechen, werden unnötige Abhängigkeiten reduziert, Assets kontrolliert geladen, Layoutverschiebungen beobachtet und Auffälligkeiten möglichst im verantwortlichen Modul behoben.
Werden bei Dampfer-Taxi Fremdplugins eingesetzt?
Ja, punktuell dort, wo externe Dienste oder klar abgegrenzte Infrastruktur sinnvoll sind. Zentrale Storefront-, Migrations-, Produkt-, SEO- und Datenlogik soll jedoch nicht von einem einzigen fremden Universalpaket abhängen.
Ist Dampfer-Taxi nur eine technische Demo?
Nein. Es ist ein produktiver Fachshop. Genau dadurch ist das Projekt als Referenz interessant: Migration, Kundenstatus, Checkout, Zubehörlogik, Altersverifikation, Storefront und eigene Erweiterungen müssen im laufenden Betrieb zusammenarbeiten.
Kann eine ähnliche Shopware-5-zu-6-Migration für andere Shops umgesetzt werden?
Ja, aber nicht als Blindkopie. Datenmodell, Kundenzustand, Plugins, SEO-URLs, Theme, rechtliche Anforderungen und Zielarchitektur unterscheiden sich je Projekt. Der sinnvolle Migrationsplan entsteht aus dem konkreten Bestand.
Shopware-Relaunch & Migration

Eine Migration sollte Bestandswert erhalten – und trotzdem Platz für eine bessere Architektur schaffen.

Dampfer-Taxi zeigt, wie ein gewachsener Shopware-5-Shop mit Kunden, Altersprüfung, SEO-Historie und realem Tagesgeschäft in eine neue Shopware-6-Struktur überführt werden kann. Welche Daten und Module bei einem anderen Projekt sinnvoll sind, muss anhand des konkreten Bestands entschieden werden.

Projektbeschreibung auf Basis der realen Dampfer-Taxi-Systemarchitektur. Projektspezifische Module werden nicht automatisch als allgemein verfügbares Produkt dargestellt.