Ein Shopware Relaunch Beispiel ist dann nützlich, wenn es nicht bei einem neuen Design stehen bleibt. Ein Händler verkauft nicht besser, weil der Shop optisch moderner wirkt. Er verkauft besser, wenn Produktdaten stimmen, Bestände verlässlich fließen, die Suche passende Ergebnisse liefert und der Checkout keine unnötigen Hürden aufbaut. Genau dort entscheidet sich, ob ein Relaunch Umsatz schafft oder lediglich Aufwand verursacht.
Das folgende Szenario verdichtet typische Anforderungen aus dem B2C- und B2B-Handel. Es ist kein Hochglanzprojekt mit künstlich perfekten Zahlen, sondern eine realistische Blaupause für Händler, deren bestehender Shop technisch und operativ an Grenzen stößt.
Shopware Relaunch Beispiel: Der Ausgangspunkt
Ein etablierter Händler für technische Verbrauchsartikel betreibt einen gewachsenen Shopware-5-Shop mit rund 18.000 Artikeln und mehreren Varianten. Das Sortiment wird über ein Warenwirtschafts- oder ERP-System gepflegt, zusätzlich gibt es Marktplätze und einen kleinen B2B-Anteil mit individuellen Preisen. Der Shop erzielt relevante Umsätze, aber der Betrieb kostet täglich unnötig Zeit.
Die Probleme zeigen sich an mehreren Stellen. Produkttexte und Eigenschaften sind uneinheitlich, weil Daten historisch aus verschiedenen Quellen stammen. Bestände kommen zeitverzögert im Shop an, wodurch vereinzelt nicht verfügbare Ware bestellt wird. Die Kategoriestruktur folgt eher internen Lieferantenlogiken als dem Suchverhalten der Kunden. Auf Mobilgeräten ist der Checkout langsam und unübersichtlich. Gleichzeitig fehlen saubere Messpunkte, um zu erkennen, welche Kampagne profitabel Neukunden gewinnt und an welcher Stelle Nutzer abspringen.
Der Impuls für den Relaunch kommt häufig erst, wenn Updates, Plugins und individuelle Anpassungen im alten System nicht mehr wirtschaftlich zusammenspielen. Das eigentliche Ziel lautet dann nicht: Shopware 6 einführen. Das Ziel lautet: den Verkaufskanal so aufstellen, dass Teams weniger manuell korrigieren müssen und Kunden schneller zum passenden Produkt kommen.
Erst Prozesse klären, dann Shopware 6 aufsetzen
Der häufigste Fehler bei einem Relaunch: Das Projekt startet mit einer Designfreigabe. Für den Händler im Beispiel wäre das zu früh. Vor dem ersten Template steht eine Bestandsaufnahme der Systemlandschaft. Welche Daten werden wo führend gepflegt? Welches System schreibt Preise, Bestände, Lieferzeiten und Kundengruppen? Wie gehen Bestellungen an Versand, Buchhaltung und Kundenservice? Und welche Sonderfälle sind geschäftskritisch?
Gerade bei der Verbindung von Shopware und JTL-WaWi, Odoo oder einem anderen ERP muss klar sein, wer die Datenhoheit besitzt. In den meisten Fällen ist das ERP für Artikel, Lagerbestand und Auftragsstatus führend, während Shopware Kategorien, Erlebniswelten, SEO-Inhalte und kundennahe Verkaufslogik abbildet. Es gibt aber Ausnahmen. Aktionspreise, Bundles oder kanalbezogene Sortimente können bewusst im Shop gesteuert werden. Entscheidend ist, diese Regeln vor der Schnittstellenentwicklung festzulegen.
Im Beispiel wird außerdem klar: Nicht jede Anpassung aus Shopware 5 verdient einen Umzug. Manche Funktionen wurden nur gebaut, weil ein früherer Prozess unklar war. Andere sind inzwischen Standardfunktionen oder lassen sich mit einem gut gewählten Plugin abdecken. Individuelle Entwicklung ist sinnvoll, wenn sie einen echten Wettbewerbsvorteil abbildet oder einen verlässlichen Ablauf automatisiert. Für jede Kleinigkeit Code zu schreiben, erhöht dagegen Wartung, Kosten und Abhängigkeit.
Die Datenmigration ist kein Excel-Export
18.000 Artikel in ein neues System zu übernehmen klingt zunächst nach einem technischen Import. Tatsächlich ist es eine Datenaufgabe mit direktem Einfluss auf Conversion, Sichtbarkeit und Serviceaufwand. Im Beispiel werden Produkte nicht einfach kopiert, sondern in klare Datengruppen zerlegt: Stammdaten, Varianten, Medien, Kategorien, Eigenschaften, Preise, Cross-Selling, Herstellerinformationen und SEO-relevante Inhalte.
Besondere Aufmerksamkeit verdienen Varianten und Eigenschaften. Kunden suchen technische Produkte selten nur über den Produktnamen. Sie filtern etwa nach Größe, Material, Anschluss, Kompatibilität oder Einsatzbereich. Wenn diese Informationen nur im Freitext stehen, kann weder die Filtersuche noch ein Suchsystem wie Doofinder sinnvoll damit arbeiten. Saubere Eigenschaften schaffen deshalb nicht nur Ordnung im Backend. Sie machen Sortiment auffindbar.
Auch Weiterleitungen gehören verbindlich in den Migrationsplan. Rankings, externe Verweise und gespeicherte Favoriten dürfen nicht auf Fehlerseiten führen, nur weil URLs ein neues Schema erhalten. Für relevante Kategorien, Produkte und redaktionelle Landingpages werden 301-Weiterleitungen vorbereitet und nach dem Go-live kontrolliert. Bei einem großen Sortiment ist das keine Fleißarbeit für die letzte Projektwoche, sondern ein fester Arbeitsschritt.
Frontend und Conversion: Weniger Reibung statt mehr Effekte
Im neuen Shop bekommt die Startseite nicht automatisch die höchste Priorität. Bei vielen Händlern landen Nutzer direkt über Google Shopping, organische Suchergebnisse oder Kampagnen auf Produkt- und Kategorieseiten. Genau diese Seiten müssen Orientierung geben.
Im Shopware-Relaunch-Beispiel erhält die Kategorieseite eine nachvollziehbare Filterlogik, kurze Einordnungstexte und sichtbare Lieferinformationen. Die Produktseite beantwortet die Fragen, die vor dem Kauf wirklich auftreten: Passt der Artikel zum vorhandenen System? Welche Variante wird benötigt? Wann ist die Ware verfügbar? Was gehört zum Lieferumfang? Bei beratungsintensiven Artikeln kann eine klare Kontaktoption sinnvoller sein als ein aggressiver Rabatt-Popup.
Der Checkout wird nicht mit Funktionen überladen. Gastbestellung, verständliche Versandkosten, gängige Zahlungsarten und eine erkennbare Fehlerführung sind oft wirksamer als zusätzliche Designelemente. Für B2B-Kunden können Nettopreise, kundenspezifische Konditionen, Bestelllisten oder die Bestellung per Artikelnummer den Unterschied machen. Ob solche Funktionen erforderlich sind, hängt vom Geschäftsmodell ab. Ein reiner Endkundenshop braucht keine B2B-Komplexität, ein Händler mit wiederkehrenden Gewerbekunden hingegen schon.
Performance ist dabei kein isoliertes Technikthema. Große, ungeprüfte Bilder, zu viele Skripte, alte Tracking-Tags und schlecht konfigurierte Plugins bremsen nicht nur Ladezeiten. Sie verschlechtern die Nutzung auf Mobilgeräten und können Werbekosten erhöhen, weil weniger Besucher tatsächlich kaufen. Der Relaunch sollte daher ein Performance-Budget erhalten: Was darf geladen werden, was ist verzichtbar und welche Drittanbieter-Skripte haben einen nachweisbaren Nutzen?
Der Projektablauf: Testen, statt auf den großen Schalter zu hoffen
Ein belastbarer Relaunch entsteht in klaren Etappen. Nach Analyse und Zielbild folgen Datenkonzept, technisches Setup, Design- und Template-Umsetzung sowie die Schnittstellenarbeit. Parallel werden Tracking, Consent-Konfiguration und Feed-Strukturen für Google Shopping vorbereitet. Erst wenn diese Bereiche zusammenspielen, lohnt sich ein umfassender Abnahmetest.
Für den Händler im Beispiel bedeutet das konkret: Testbestellungen laufen nicht nur im Shop. Sie werden bis in Warenwirtschaft, Zahlungsabgleich, Pickprozess, Versandstatus, Storno und Retoure verfolgt. Sonderfälle gehören dazu: Teilstornos, Variantenwechsel, nicht lieferbare Artikel, Gutscheine, abweichende Lieferadressen und unterschiedliche Steuerlogiken. Wer nur prüft, ob eine Bestellung im Frontend ausgelöst werden kann, testet nicht den tatsächlichen Geschäftsprozess.
Ein Staging-System ist dafür Pflicht. Dort lassen sich Importläufe, Plugin-Updates und Änderungen kontrolliert prüfen, ohne das Livegeschäft zu gefährden. Vor dem Go-live gibt es einen klaren Cutover-Plan: finaler Datenabgleich, Prüfung der Weiterleitungen, Aktivierung von Tracking, Versand- und Zahlungschecks, Monitoring der Fehlerprotokolle sowie Verantwortlichkeiten für die ersten Tage. Niemand sollte am Launch-Tag raten müssen, wer bei einem Bestellproblem entscheidet.
Erfolg wird vor dem Launch messbar definiert
Ein Relaunch ist kein Erfolg, weil er pünktlich live geht. Er ist erfolgreich, wenn er vorher definierte betriebliche und kommerzielle Ziele erreicht. Im Beispiel werden deshalb Kennzahlen vereinbart: fehlerfreie Übertragung von Bestand und Preis, sinkende manuelle Korrekturen im Kundenservice, bessere Nutzung der Produktfilter, höhere Checkout-Abschlussrate und belastbare Zuordnung von Umsätzen zu Marketingkanälen.
Nicht jede Kennzahl muss sofort sprunghaft steigen. Organische Sichtbarkeit kann nach einem Relaunch kurzfristig schwanken, auch wenn Weiterleitungen sorgfältig umgesetzt wurden. Neue Templates und bessere Datenstrukturen entfalten ihren Effekt über Wochen und Monate. Kritisch wird es, wenn Umsatzrückgänge, Fehlerseiten oder Tracking-Ausfälle nach dem Launch nicht schnell erkannt werden. Deshalb gehören technische Monitoring-Routinen und ein 30-Tage-Optimierungsplan zum Projekt, nicht auf eine Wunschliste für später.
Was dieses Beispiel für Ihren Relaunch bedeutet
Der Kern dieses Shopware Relaunch Beispiels ist einfach: Plattformwechsel, Datenqualität, ERP-Anbindung und Conversion dürfen nicht getrennt geplant werden. Ein schönes Theme kompensiert keine falschen Bestände. Eine leistungsfähige Warenwirtschaft rettet keine Produktseite, die Kunden nicht verstehen. Und sauberer Traffic bringt wenig, wenn die Kaufstrecke unnötig kompliziert ist.
Aventux verbindet diese Ebenen in der Umsetzung – vom Shopware-6-Aufbau und der Migration bis zur Anbindung von Warenwirtschaft, Produktdaten und Performance-Marketing. Ohne leere Agentur-Versprechen, dafür mit einem klaren Plan, definierten Verantwortlichkeiten und ehrlichem Handwerk.
Wenn ein Relaunch bei Ihnen ansteht, beginnen Sie nicht mit der Frage nach dem neuen Design. Beginnen Sie mit den Aufträgen, Daten und Entscheidungen, die heute Zeit kosten oder Umsatz verlieren lassen. Daraus entsteht die Architektur, die Ihr Shop morgen tatsächlich tragen muss.
