Shopware 5 zu 6 Migration: astro-shop.com — Case Study einer Live-Migration

In dieser Case Study zeigen wir, wie wir einen seit über 30 Jahren bestehenden Astronomie-Fachhandel von Shopware 5 nach Shopware 6 migriert haben — als dritten Mandanten in eine bestehende Multi-Shop-Installation, in einer einzigen Nacht, ohne die beiden laufenden Schwester-Shops zu stören. Wenn du selbst vor einer SW5-Migration stehst oder wissen willst, wie so etwas in der Praxis wirklich abläuft, bist du hier richtig.

Inhaltsübersicht

• 1. Der Kunde — astro-shop.com
• 2. Wie die Zusammenarbeit entstand
• 3. Die Ausgangslage — warum jetzt migrieren?
• 4. Phase 1 — was wir vor der Migration sichern
• 5. Unser Ansatz — das Drei-Stufen-Modell
• 6. Die Umsetzung — Zahlen, Kollisionen, eine lange Nacht
• 7. SEO-Kontinuität — 2.644 URLs dürfen nicht brechen
• 8. Was nach der Datenmigration noch kam
• 9. Ergebnisse — was jetzt live steht
• 10. Lessons Learned — was wir beim nächsten Mal wissen
• 11. Fazit und Empfehlung

1. Der Kunde — astro-shop.com

astro-shop.com ist nicht einfach irgendein weiterer Online-Shop. Der astronomische Fachhandel besteht seit über 30 Jahren und gehört damit zu den echten Urgesteinen der Szene im Großraum Hamburg.

Über Jahrzehnte war er die Online-Präsenz eines kleinen, feinen Ladengeschäfts in der Hamburger Sternwarte. Als die Sternwarte vor einigen Jahren saniert wurde, zog der Laden aus — und ist seither eine reine Online-Präsenz.

Besonders spannend: Eric-Sven Vesting ist nicht nur Händler, sondern auch Miterfinder einer weltweit geschätzten Marke. Im Jahr 2000 tüftelte er gemeinsam mit Gerd Neumann in einem Hamburger Wasserturm daran, wie sich hochwertige und zugleich bezahlbare Filter für die Astronomie herstellen ließen — damals gab es am Markt nur teure oder qualitativ schwache Alternativen. Was als Garagenprojekt für UHC- und RGB-Filter begann, ist heute Astronomik: eine Filtermarke „Made in Germany“, die von Hobby-Sternfreunden ebenso wie von professionellen Astronomen rund um den Globus eingesetzt wird.

Die Astronomik-Filter werden heute hauptsächlich über astronomik.com vertrieben — und selbstverständlich auch über astro-shop.com, wo Vesting sie neben Teleskopen, Montierungen, Okularen, Adaptern und allem weiteren Zubehör anbietet, das das Astronomen-Herz begehrt.

Genau dieser über Jahrzehnte gewachsene Ruf und die entsprechende Sichtbarkeit bei Google sind das, was wir bei der Migration mit allergrößter Sorgfalt schützen müssen.

↑ Zurück zur Übersicht

2. Wie die Zusammenarbeit entstand

Als ehemaliger Telefonverkäufer habe ich vor etwa einem Jahr — also Mitte 2025 — mal wieder selbst zum Hörer gegriffen, um neue Kunden persönlich anzurufen. Einer dieser Anrufe ging an Herrn Eric-Sven Vesting von astro-shop.com.

Seine Reaktion war so überraschend wie erfreulich. Sinngemäß sagte er: „Normalerweise reagiere ich nie auf solche Angebote. Aber dank Ihrem Blog konnte ich meinen Shopware-6-Shop selbst aufbauen. Nur haben wir aktuell leider nichts zu tun.“

Umso schöner, dass es dann doch nur wenige Tage dauerte, bis das Telefon klingelte und die erste kleine Aufgabe vergeben wurde. Aus dieser einen Aufgabe wurde mit der Zeit eine echte Zusammenarbeit: Heute betreuen wir für Herrn Vesting bereits die beiden Schwester-Projekte gerdneumann.net und astronomik.com — und mit der Migration von astro-shop.com kam nun das bisher größte gemeinsame Projekt dazu.

↑ Zurück zur Übersicht

3. Die Ausgangslage — warum jetzt migrieren?

Der Shop lief auf Shopware 5.7.18 — einem System, das sich dem End-of-Life nähert. Die ältesten Produkte im Katalog tragen Erstelldaten aus den 1990ern — Migrations-Artefakte aus Vorgängersystemen, die noch vor Shopware im Einsatz waren. Erste Spuren des Shops finden sich auf archive.org ab 1996. Von den 1.796 Parent-Produkten, die aus dem SW5-Bestand (1.968 Artikel) in die SW6-Testinstallation übernommen wurden, waren nur 532 aktiv — 1.264 waren über die Jahre deaktiviert worden.

Parallel betrieb Herr Vesting bereits zwei Shopware-6-Shops — Astronomik und Gerd Neumann jr. — auf einer gemeinsamen Installation als getrennte Sales Channels. Der Auftrag war klar: Den SW5-Shop als dritten Mandanten in diese bestehende SW6-Installation integrieren, ohne die beiden laufenden Shops zu stören. Keine neue Infrastruktur, keine getrennte Shop-Instanz.

Was diese Migration besonders machte

• Multi-Mandanten-Setup: Über 30 Kunden waren bereits als Astronomik-Kunden registriert — gleiche E-Mail, verschiedene Shops. Das ergibt Kollisionen, die sauber aufgelöst werden müssen.
• URL-Kontinuität: 2.644 alte .html-Produkt-URLs waren bei Google indexiert. Über 30 Jahre gewachsene Sichtbarkeit, die auf keinen Fall verloren gehen durfte.
• Live-Betrieb: Der SW5-Shop lief bis zum Cutover-Moment weiter. Bestellungen und Neuregistrierungen kamen laufend rein.
• Varianten-Zählweise: Shopware 5 zählt 1.968 Artikel (Hauptartikel inklusive eingebetteter Varianten-Details). In Shopware 6 sind Varianten eigenständige Produkte: 1.796 Parent-Produkte + 1.039 Varianten = 2.835 Produktdatensätze. Die 172 weniger Parents gegenüber dem SW5-Bestand ergeben sich aus der Bereinigung und dem Merge von Test- und Duplikat-Daten.

↑ Zurück zur Übersicht

4. Phase 1 — was wir vor der Migration sichern

Bevor auch nur ein einziger Datensatz den Shop wechselt, steht die Vorbereitung. Sie ist der unspektakulärste Teil einer Migration — und gleichzeitig der, an dem sich später entscheidet, ob wir sauber messen können, was wir tun. Denn nur, was wir vor der Migration erfasst haben, lässt sich danach mit dem Ergebnis vergleichen.

Was wir brauchen, um den Ist-Zustand zu prüfen

Zuallererst verschaffen wir uns vollständigen Zugang — ohne die richtigen Schlüssel lässt sich der Ist-Zustand weder prüfen noch später sauber übertragen. Viele dieser Zugänge hängen direkt an den URLs des Shops und brechen, sobald sich diese ändern:

Tipp: Wir sammeln diese Zugänge in einem sicheren, geteilten Passwort-Manager und klären gleich zu Beginn, welche Konten 2FA haben — nichts ist ärgerlicher als eine blockierte Migration, weil der SMS-Code auf dem privaten Handy des Kunden ankommt und der gerade im Urlaub ist.

Die vollständige Bestandsaufnahme — Abschnitt für Abschnitt

Die Zugänge oben sind die Eintrittskarte. Was wir damit dann tatsächlich rausfischen, ist deutlich umfangreicher als die meisten erwarten — hier die komplette Checkliste, so wie wir sie bei jeder Shopware-5-Migration abarbeiten. Die Tabellennamen beziehen sich auf Shopware 5; wer selbst mitliest oder die Bestandsaufnahme technisch nachvollziehen will, findet hier alles im Detail.

Technisches Setup

• Exakte Shopware-5-Version (Einstellungen > System-Info), PHP- und MySQL/MariaDB-Version
• Server-Stack (nginx/Apache), Hosting-Specs, Datenbankgröße gesamt und größte Einzeltabellen
• Eingesetztes Theme (Responsive-Theme oder Custom-Theme?), vorhandene Backups und Backup-Strategie

Datenmengen — harte Zahlen ziehen

Ein kurzer SQL-Rundgang gibt dir die Größenordnung der Migration, bevor du auch nur eine Zeile Migrationscode schreibst:

SELECT COUNT(*) FROM s_articles;          -- Artikel
SELECT COUNT(*) FROM s_articles_details;  -- Varianten
SELECT COUNT(*) FROM s_categories;
SELECT COUNT(*) FROM s_articles_supplier; -- Hersteller
SELECT COUNT(*) FROM s_user;              -- Kunden
SELECT COUNT(*) FROM s_order;             -- Bestellungen
SELECT COUNT(*) FROM s_media;             -- Medien

Falls der Shop einen eigenen Blog über Shopware 5 betrieben hat, lohnt sich zusätzlich ein Blick in s_blog — diese Inhalte werden bei einer Migration gern vergessen, weil sie in keinem Produktkatalog auftauchen.

Katalogdaten

• Artikel inkl. Freitextfeldern/Attributen (s_articles_attributes) — hier stecken oft die technischen Produktdaten, die im Frontend als Spezifikationstabelle laufen
• Varianten und Variantenkonfiguration: s_articles_details, s_article_configurator_*
• Kategorien inkl. Baumstruktur: s_categories
• Hersteller inkl. Logo, Beschreibung und SEO-Feldern: s_articles_supplier
• Eigenschaften und Filter — bei Shops mit vielen Facetten (z. B. technischen Fachhandel wie unserem astro-shop-Projekt) der aufwändigste Einzelpunkt: s_filter, s_filter_options, s_filter_values, s_filter_articles
• Preise inkl. Staffel- und Kundengruppenpreisen: s_articles_prices
• Cross-Selling und ähnliche Artikel: s_articles_similar, s_articles_relationships
• Medien-Zuordnung Artikel↔Bild: s_articles_img, Ordnerstruktur in s_media_album

Kunden und Bestellungen

• Kundenkonten und Adressen: s_user, s_user_addresses
• Kundengruppen-Zuordnung, etwa für B2B-/Händler-Sonderpreise: s_core_customergroups
• Bestellungen inkl. Positionen: s_order, s_order_details, Bestellstatus-Historie: s_order_history
• Belege und Dokumente wie Rechnungen und Lieferscheine: s_order_documents
• Nummernkreise und ihr aktueller Stand: s_order_number — Rechnungs-, Kunden- und Bestellnummer. Diesen Stand unbedingt mitnehmen, sonst vergibt das neue System Nummern doppelt, die im alten System schon existieren.

Shop-Konfiguration

• Subshops, Sprachen und Währungen: s_core_shops, s_core_currencies
• Steuersätze: s_core_tax; Zahlarten: s_core_paymentmeans
• Versandarten und Kosten-Matrix: s_premium_dispatch, s_premium_shippingcosts
• Lieferländer: s_core_countries; Anrede-Optionen; alle relevanten Grundeinstellungen: s_core_config_elements / _values

Inhalte

• Einkaufswelten (Shopping Worlds): s_emotion — müssen in Shopware 6 als Erlebniswelten neu gebaut oder zumindest neu gemappt werden, ein direkter Datenimport funktioniert hier nicht
• Shop- und CMS-Seiten wie Impressum, AGB, Widerruf, Versandinformationen: s_cms_static; Info-/Support-Seiten: s_cms_support
• E-Mail-Vorlagen: s_core_config_mails; Beleg-Layouts für Rechnung/Lieferschein: s_core_documents
• Newsletter-Empfänger, falls direkt in Shopware verwaltet: s_campaigns_mailaddresses

SEO-Assets — der migrationskritische Abschnitt

• Komplette URL-Liste per Crawl (z. B. Screaming Frog) — die Grundlage für jedes Redirect-Mapping
• SEO-URLs und Rewrites: s_core_rewrite_urls, dazu das SEO-URL-Schema aus den Grundeinstellungen
• Meta-Titles und -Descriptions für Artikel, Kategorien und Seiten; Canonical-Logik, besonders bei Filter- und Facetten-URLs
• Bereits bestehende Redirects, robots.txt und XML-Sitemap, strukturierte Daten für Produkte und Breadcrumbs
• Zugriff auf die Search-Console-Property sicherstellen, bevor der alte Shop angefasst wird

Plugins und Custom-Code

• Liste aller installierten Plugins, aktiv wie inaktiv: s_core_plugins
• Für jedes Plugin klären: kommerziell, kostenlos oder Individualentwicklung? Gibt es ein Pendant für Shopware 6 — wenn nein, braucht es Ersatz oder Eigenbau
• Custom-Template-Overrides und eigene Bundles dokumentieren, ebenso Funktionen, die an einem bestimmten SW5-Plugin hängen und ein SW6-Pendant brauchen

Integrationen und Feeds

• Payment-Provider-Anbindung: welcher Anbieter, welche Konten?
• ERP-/Warenwirtschafts-Anbindung, falls vorhanden
• Produkt-Feeds (Google Shopping, Preisportale) — Feed-Struktur und Regeln sichern, damit der Feed nach der Migration nahtlos weiterläuft statt mit Fehlermeldungen zu stoppen
• Tracking (Analytics, Tag Manager, Consent-Tool) und Newsletter-Tool

Priorität, falls die Zeit knapp ist: Zuerst SEO-Assets und Datenmengen — die sind zeitkritisch, weil sie nur am unangetasteten Live-Shop sauber gemessen werden können. Dann Plugins, weil sich daraus der eigentliche Migrationsaufwand ergibt. Der Rest ist wichtige, aber unaufgeregte Datenerfassung, die auch noch während der Migration nachgezogen werden kann.

Die vergänglichen Zahlen aus Shopware 5 sichern

Ein Punkt, der leicht untergeht: Shopware 5 bringt einen deutlich breiteren Auswertungsbereich mit als Shopware 6. Verkaufszahlen, Besucherzahlen, Referrer, Conversion-Raten, Kundengruppen-Auswertungen und — besonders wertvoll — die internen Suchbegriffe der Kundschaft. Diese Daten sind vergänglich: Sobald der alte Shop vom Netz geht, sind sie unwiederbringlich verloren, weil Shopware 6 sie so nicht mehr führt. Gerade die internen Suchbegriffe sind ein Schatz — sie zeigen in echten Kundenworten, wonach im Shop gesucht wird, und fließen direkt in die Suchmaschinenoptimierung und die neue Navigation ein.

Statt diese Daten mühsam einzeln zu exportieren, gehen wir einen eleganteren Weg: Wir nehmen den alten Shopware-5-Shop nicht einfach vom Netz, sondern erhalten ihn als lebendiges Archiv — auf einer passwortgeschützten Subdomain im Wartungsmodus. So bleibt der komplette Auswertungsbereich jederzeit nachschlagbar, ohne dass wir unter Zeitdruck alles auf einmal sichern müssen. Gleichzeitig dient dieses Archiv als GoBD-konformes Bestell- und Rechnungsarchiv: Da wir bewusst keine Bestellungen migriert haben, bleibt die vollständige Beleghistorie im SW5-System erhalten und ist dort jederzeit einsehbar.

Ein Punkt ist dabei entscheidend: Diese Archiv-Subdomain muss zwingend aus dem Google-Index herausgehalten werden — über den Passwortschutz und zusätzlich „noindex“. Sonst würde ausgerechnet der alte Shop dem neuen mit denselben Inhalten Konkurrenz machen (Duplicate Content) — das Letzte, was wir bei einem Projekt wollen, in dem es genau um den Erhalt der Sichtbarkeit geht.

Ein solches Archiv sollte man aber nicht ewig im Verborgenen weiterlaufen lassen. Deshalb halten wir gleich fest, die Sache nach rund einem Jahr noch einmal mit dem Kunden zu besprechen: Wird das Archiv weiterhin gebraucht, oder kann die alte Installation endgültig aus dem Netz genommen und gelöscht werden?

Die Ausgangswerte für Google festhalten

Weil der Erhalt der Suchmaschinen-Positionen das Herzstück dieser Migration ist, halten wir zum Abschluss der Vorbereitung den Ausgangszustand fest, solange der alte Shop noch unangetastet läuft: die aktuellen Rankings der wichtigsten Suchbegriffe, die Seiten mit dem meisten organischen Traffic sowie die Klick- und Impressionszahlen aus der Search Console. Dieser „Vorher“-Stand ist später unser Maßstab — ohne ihn wüssten wir nach dem Go-Live nicht, ob wir den über Jahre gewachsenen Wert wirklich gehalten haben.

Wie viel Vorlauf du dafür brauchst: Besucherdaten solltest du mindestens eine, besser zwei bis vier Wochen vor dem Go-Live sammeln, damit Wochentags- und Wochenendschwankungen nicht die Baseline verzerren. Core Web Vitals aus echten Nutzerdaten (nicht aus einem einzelnen Lighthouse-Lauf) brauchen sogar rund 28 Tage, bis Google daraus einen belastbaren Bericht bildet — das früh genug einplanen, sonst hast du beim Go-Live keinen echten Vergleichswert. Die Google Search Console ist hier die Ausnahme: Ist sie schon eingerichtet, liefert sie auf einen Schlag bis zu 16 Monate Historie, ganz ohne Frontend-Tag, nur die Domain-Verifizierung ist nötig — deshalb lohnt sich der Zugriff darauf so früh wie möglich, notfalls parallel zur restlichen Vorbereitung.

↑ Zurück zur Übersicht

5. Unser Ansatz — das Drei-Stufen-Modell

Statt einer riskanten Direkt-Migration haben wir einen dreistufigen Weg gewählt:

Stufe 1 — SW5 nach SW6 per Migrationsassistent. Der gesamte Datenbestand wurde über den offiziellen Shopware Migration Assistant in eine isolierte SW6-Testinstallation auf unserem eigenen Server überführt. Dieser Zwischenshop erwies sich als Gold wert — dazu gleich mehr.

Stufe 2 — Lokaler Testlauf. Bevor wir das Live-System anfassen, haben wir den gesamten ShopSwap-Migrationscode gegen ein lokales Dockware-Setup getestet. Ergebnis: 4 Bugs entdeckt und gefixt, 100 % Datenübertragung im Testlauf. Vier Stunden Testlauf haben uns mehrere Tage Debugging im Live-System erspart.

Stufe 3 — Live-Migration via ShopSwap. Mit unserem eigenen Tool ShopSwap wurden die relevanten Entitäten gezielt in die bestehende Live-Installation überführt. ShopSwap arbeitet im „Minimalmigrations-Modus“: Es baut kein neues Ziel auf, sondern adoptiert Daten in eine bestehende Multi-Mandanten-Installation.

Warum der Zwischenshop so wichtig war

Der Zwischenshop sw67 erwies sich mehrfach als Rettungsanker. Als bei der Live-Migration Content-Lücken auffielen — leere Rechtstexte, fehlende Slot-Configs — konnte alles über die SW6-API von sw67 nachgezogen werden, statt in das deutlich komplexere SW5-Datenmodell einsteigen zu müssen.

Empfehlung für jeden, der eine SW5-Migration plant: Plant den Zwischenshop ein. Er kostet wenig, spart viel.

↑ Zurück zur Übersicht

6. Die Umsetzung — Zahlen, Kollisionen, eine lange Nacht

Der Kollisions-Check

Vor jeder Schreiboperation wurde per API-Query gegen den Live-Shop geprüft, welche Konflikte entstehen würden:

• 33 E-Mail-Kollisionen identifiziert (gleiche E-Mail-Adresse in Quell- und Ziel-Shop)
• 18 davon mit reinem Gast-Datensatz im Ziel (historische Gast-Bestellung, kein aktives Konto)
• 12 mit echtem Konto, 3 Test-Accounts

Die Kollisionslandkarte

Wenn ein Shop nicht in ein leeres Ziel, sondern in ein bewohntes System migriert wird, lauert an jeder Ecke eine Kollision. Wir haben vor der Migration jedes Risiko kartiert:

Konsequenz: Wir haben die Live-Migration niemals direkt auf dem Produktivshop geprobt — immer erst auf einem lokalen Klon. Vier Stunden Testlauf haben vier der fünf Kollisionstypen vorab aufgedeckt.

Was migriert wurde

Bewusst übersprungen haben wir Tags (51 Stück, alles Faker-Demodaten aus der Testinstallation), Product-Streams (10 von 11 ebenfalls Faker) und Bestellungen.

Die Nacht des Cutover — Minute für Minute

↑ Zurück zur Übersicht

7. SEO-Kontinuität — 2.644 URLs dürfen nicht brechen

Bei einem Shop mit über 30 Jahren Sichtbarkeit bei Google ist SEO die kritischste Stelle der gesamten Migration. Wer hier schludert, kann innerhalb von Tagen verlieren, was über Jahrzehnte aufgebaut wurde.

Unser Ansatz:

• 1.461 Produkt-URLs wurden identisch zwischen Test- und Live-Umgebung übertragen — kein Redirect nötig, weil die URL-Struktur beibehalten wurde.
• 2.644 Legacy-.html-URLs aus der SW5-Zeit wurden als 301-Redirects angelegt und verifiziert.
• 4.807 SEO-Redirects insgesamt — jeder einzelne geprüft. Davon entfallen 2.644 auf die Legacy-Produkt-URLs mit .html-Endung. Die übrigen rund 2.160 sind Varianten-URLs (SW5-typische ?number=-Parameter), Kategorie-Slugs, historische PDF-Links und alte PHP-Katalogseiten aus den 2000er-Jahren.
• Meta-Title, Meta-Description, Keywords und Open-Graph-Tags wurden am Sales Channel und den CMS-Seiten gesetzt.

Praxistipp: Die richtigen Keywords finden — Triangulation aus drei Quellen

Die wichtigsten Keywords für die Migration findest du nicht über ein einziges Tool. Wir triangulieren aus drei Quellen:

1. Google Search Console — die echten Suchanfragen mit Impressionen, Klicks und aktueller Position. Keine Schätzung, sondern Realität.
2. Interne SW5-Shopsuche — dieselbe Frage in echten Kundenworten. Was deine Kunden im Suchfeld eintippen, ist oft wertvoller als jedes Keyword-Tool.
3. Umsatz-Gewichtung — die „wichtigsten“ Keywords sind nicht die mit dem höchsten Suchvolumen, sondern die, an denen Geld hängt. Ein Keyword mit 50 Suchanfragen im Monat, das für 80 % des Umsatzes steht, hat höchste Priorität.

Praxistipp: Google Search Console vs. Matomo — was kann was?

Praxistipp: Ein Tag-Scan zeigt Präsenz, nicht Nutzung

Bevor wir bei einer Migration überhaupt planen, scannen wir den alten Shop mit einem Tool wie Wappalyzer oder Tag Assistant auf eingebundene Skripte. Wichtig dabei: Das zeigt nur, was im Quellcode vorhanden ist — nicht, ob es wirklich genutzt wird. Ein Analytics- oder Tracking-Tag kann seit Jahren verwaist mitlaufen, ohne dass ihn noch jemand auswertet. Umgekehrt bleiben manche Integrationen im Frontend-Scan unsichtbar: Ein Tag-Manager-Container verschleiert seinen eigentlichen Inhalt, und Search Console oder Merchant Center hinterlassen im Quellcode kaum Spuren. Das Gegenstück zum Frontend-Scan ist deshalb die Plugin-Liste aus der Datenbank (s_core_plugins) — ERP-Anbindungen, Feed-Exporter oder Marktplatz-Tools zeigen sich dort, auch wenn sie im Frontend unsichtbar bleiben. Erst beide Wege zusammen ergeben ein vollständiges Bild.

Praxistipp: Open Graph nicht vergessen

Open Graph steuert, wie ein Link aussieht, wenn er bei Facebook, LinkedIn, WhatsApp oder Slack geteilt wird — Titel, Beschreibung und Vorschaubild. Gerade bei einer Migration geht das leicht unter, weil es weder Umsatz noch Rankings direkt betrifft. Trotzdem lohnt sich der Check: Prüfe vor der Migration mit einem Tool wie Wappalyzer nicht nur die Startseite, sondern gezielt eine echte Produktseite — die Startseite kann anders konfiguriert sein als der Rest des Shops. Wenn der alte Shop shopweit Open-Graph-Daten ausliefert, muss das im neuen System ebenfalls stehen, sonst verschlechtert sich die Vorschau beim Teilen still und unbemerkt.

Praxistipp: Rank-Tracker als Ergänzung zur Search Console

Die Search Console zeigt dir, wie Google deine Sichtbarkeit einschätzt — mit etwas Verzögerung und nur in Aggregaten. Ein separater Rank-Tracker misst dagegen tagesaktuell, auf welcher Position einzelne Keywords stehen, und ist deshalb der schnellere Frühwarn-Indikator direkt nach dem Go-Live. Verbreitete Kandidaten: Sistrix (deutscher Klassiker mit eigenem Sichtbarkeitsindex), Ahrefs und SEMrush als umfassende Suiten inklusive Backlink- und Wettbewerbsanalyse, sowie SE Ranking, Wincher oder AccuRanker als schlankere, günstigere Positions-Tracker. Für ein einzelnes Migrationsprojekt reicht in der Regel ein fokussierter Tracker — die große, teure Suite lohnt sich erst, wenn du sie über mehrere Kundenprojekte hinweg auslastest.

↑ Zurück zur Übersicht

8. Was nach der Datenmigration noch kam

Eine Lektion, die wir bei diesem Projekt nochmal deutlich gelernt haben: „Migration abgeschlossen“ bedeutet „Daten sind übertragen“ — nicht „Shop ist Go-Live-ready“.

Nach der reinen Datenmigration mussten wir noch einiges manuell nachziehen:

• Theme zuweisen und kompilieren — das eigene GreatAstroShop-Theme für den neuen Sales Channel — von Anfang an BFSG-konform (Barrierefreiheitsstärkungsgesetz) ausgeliefert
• Homepage aufbauen — Logo aus SW5 übertragen, Banner-Bild (Sternspuren-Foto), Produktslider verdrahten, Willkommenstext einpflegen
• Rechtstexte nachpflegen — AGB, Impressum, Datenschutz und sieben weitere rechtlich zwingende Seiten mussten mit einem Sync-Skript aus dem Zwischenshop geholt werden, weil ShopSwap die CMS-Slot-Translations nicht automatisch mit-überträgt
• Payment und Versand — 4 Zahlungsarten und 2 Versandarten für den neuen Kanal konfigurieren
• Eigene Nummernkreise — Bestell-, Rechnungs- und Lieferscheinnummern so konfigurieren, dass sie nicht mit den bestehenden Astronomik-/Gerd-Neumann-Nummernkreisen kollidieren (GoBD-Pflicht)
• DNS-Umzug — astro-shop.com auf den astronomik.com-Server zeigen lassen, alt.astro-shop.com als Backup auf den alten SW5-Server

Praxistipp: Zahlungsanbieter rechtzeitig beantragen

Wer den Zahlungsanbieter wechselt — etwa von PayPal auf Shopware 5 zu Mollie auf Shopware 6 — muss die neue Domain frühzeitig als Profil beim Anbieter anlegen. Die Freischaltung dauert in der Regel 2–3, manchmal aber auch 4–5 Werktage. Wer das erst kurz vor dem Go-Live beantragt, steht mit einem fertigen Shop da, in dem niemand bezahlen kann.

Praxistipp: E-Mail-Zustellung prüfen

Sobald der Shop auf einer neuen IP-Adresse läuft, schlagen E-Mails fehl — Bestellbestätigungen landen im Spam oder kommen gar nicht an. Der Grund: Der SPF-Record in der DNS-Zone autorisiert nur die alte Server-IP. Die Lösung: SPF, DKIM und DMARC vor dem Go-Live aktualisieren, einen IP-unabhängigen SMTP-Service einrichten, und nicht nur testen ob die Mail ankommt, sondern auch den Header auf „SPF pass“ und „DKIM pass“ prüfen.

Praxistipp: Passwort-Hashes vor der Migration prüfen

Bei Shops, die seit vielen Jahren laufen, können in der Datenbank noch Legacy-Hashes aus Shopware-4-Zeiten stecken — md5 oder sha256 statt des aktuellen bcrypt. Eine schnelle SQL-Abfrage zeigt die Verteilung:

SELECT encoder, COUNT(*) AS anzahl FROM s_user GROUP BY encoder;

Steht dort überall bcrypt ($2y$…), ist alles gut — Shopware 6 rehasht beim ersten Login sauber. Tauchen aber md5 oder sha256 auf, müssen die betroffenen Kunden nach der Migration ihr Passwort neu setzen. Ein einzelner Test-Login-Kunde deckt das nicht auf, wenn er zufällig schon ein frischer bcrypt-Hash ist.

↑ Zurück zur Übersicht

9. Ergebnisse — was jetzt live steht

• Vollständiger, kaufbereiter Astro-Shop-Kanal unter astro-shop.com
• 4.204 migrierte Kunden können sich mit ihrem SW5-Passwort anmelden (vorab per Encoder-Check verifiziert: alle Accounts bereits auf bcrypt)
• 33 Kollisions-Kunden haben ein gemeinsames Konto für beide Kanäle
• 100 % technische SEO-Kontinuität: Alle Produkt-URLs identisch, alle Legacy-URLs als 301-Redirects, Baseline-Keywords gesichert
• Rechtssichere Storefront: Alle 10 Pflichtseiten inhaltlich befüllt und über den Footer erreichbar
• Astronomik und Gerd Neumann jr. während der gesamten Migration unangetastet — Zero Downtime

Zeitliche Bilanz

• Vorbereitung + Test: 4 Wochen (inklusive lokalem Testlauf mit Bug-Discovery)
• Live-Cutover: eine Nacht
• Bestehende Shops gestört: null Minuten

Praxistipp: Nicht nur nachlaufende KPIs messen

Die meisten „darf nicht einbrechen“-KPIs sind nachlaufend: Umsatz, Bestellanzahl, Besucherzahlen. Sie brechen erst ein, wenn der Schaden schon da ist. Für eine professionelle Migration brauchst du zusätzlich vorlaufende Frühwarn-Indikatoren:

• Index-Coverage — wirft Google URLs aus dem Index? Das ist der erste Vorbote.
• 404-Fehlerquote nach Go-Live — greifen die Redirects? Der schnellste Bruch-Indikator.
• Impressionen & Klicks (Search Console) — Sichtbarkeitsverlust zeigt sich breiter als bei einzelnen Keywords.

Und eine Diagnose-Ebene: Fällt der Umsatz bei gleichen Besuchern, ist die Conversion Rate das Problem (Checkout kaputt, Zahlart fehlt). Bricht der durchschnittliche Bestellwert ein, fehlt Cross-Selling oder ein Preisfeld ist falsch migriert.

↑ Zurück zur Übersicht

Ausblick: Ranking-Check 4–8 Wochen nach Go-Live

Ob die technische Kontinuität (identische URLs, saubere Redirects, übertragene Meta-Daten) sich auch in gehaltenen Rankings niederschlägt, zeigt sich erst im Laufe der kommenden Wochen. Google crawlt und bewertet die Änderungen typischerweise innerhalb von 4 bis 8 Wochen. Wir werden die vorher gesicherte Keyword-Baseline gegen die neuen Search-Console-Daten abgleichen und das Ergebnis in einem Follow-up-Beitrag veröffentlichen — mit echten Vorher-Nachher-Zahlen, nicht mit Versprechen.

10. Lessons Learned — was wir beim nächsten Mal wissen

Der Zwischenshop ist Gold wert

Ein SW5-nach-SW6-Zwischenshop bringt die Ur-Daten in eine sauber abgreifbare API-Schicht. Wenn bei der Live-Migration Content-Lücken auffallen, kann alles nachgezogen werden, statt in ein komplexes SW5-Datenmodell einzusteigen.

Test-Migration lohnt sich immer

Alle in der Live-Session gefundenen ShopSwap-Bugs wären beim lokalen Testlauf ebenfalls aufgeschlagen. Vier Stunden Testlauf haben mehrere Tage Debug im Live-System vermieden. Wir empfehlen jedem Kunden: Erst lokal testen, dann live gehen.

„Deterministische UUIDs“ sind es meist nicht

Shopware dokumentiert bestimmte System-UUIDs als installationsübergreifend identisch. Für Standard-CMS-Layouts trifft das in der Praxis nicht zu — jede Installation bekommt eigene ULIDs. Wer Cleanup-Skripte gegen „Systempages“ schreibt, sollte per Namen matchen, nicht per UUID.

Adoption vs. getrennte Konten bewusst entscheiden

Bei einer Multi-Mandanten-Migration stehen zwei Wege offen: Adoption (ein gemeinsames Konto, einfach, aber kanalübergreifende Sichtbarkeit) oder getrennte Konten (braucht boundSalesChannelId, doppelter Support-Aufwand, isolierte Historie). Diese Entscheidung muss der Kunde bewusst treffen — sie ist nicht rein technisch.

„Leer“ heißt nicht „weg“

Bei der Property-Groups-Analyse waren 45 von 59 Groups scheinbar ohne Zuordnung. Aber 28 davon waren als Konfigurator-Options für Varianten in Verwendung. Ohne einen zweiten Check hätten wir wichtige Varianten-Optionen gelöscht. Regel: Vor jeder „ist nirgends benutzt“-Löschung alle Referenztypen prüfen.

Domain-Umzug ist mehrstufig

DNS-TTL, TLS-Zertifikat, Sales-Channel-Domain im neuen Shop, vhost-Config auf dem alten Server — vier Kaskaden, die alle stimmen müssen. Ein Fehler bricht die Kette. In unserem Fall: „Sales Channel Not Found“, weil die Domain im Ziel-Shop nicht als sales_channel_domain hinterlegt war. Empfehlung: Domain-Migration als eigene Checkliste behandeln, nicht als Nebensache.

Post-Migration ist ein eigenes Projekt

Nach der Datenmigration kommen noch rund 20 Aufräum- und Konfigurationsaufgaben: Payment/Shipping-Zuweisung, Homepage-Content, Meta-Tags, DNS, Testkauf. Die lassen sich nicht in den Migrations-Sprint pressen.

↑ Zurück zur Übersicht

11. Fazit und Empfehlung

Die Migration von astro-shop.com hat gezeigt: Auch ein Shop mit über 30 Jahren Geschichte lässt sich sauber und ohne Sichtbarkeitsverlust nach Shopware 6 bringen — wenn man methodisch vorgeht. Der dreistufige Ansatz (SW5 → Zwischenshop → Live-Adoption) hat sich bewährt, der lokale Testlauf war unverzichtbar, und die Multi-Mandanten-Integration spart dem Kunden langfristig Hosting- und Wartungskosten.

Wenn du selbst vor einer Shopware-5-Migration stehst, können wir dir zwei Dinge empfehlen:

Kostenlos: Das SW5 Migration Audit Script

1. Fang mit einem Audit an. Unser SW5 Migration Audit Script zeigt dir, was in deinem SW5-Shop alles schlummert und wie migrationsbereit der Datenbestand ist — kostenlos als Download weiter oben auf dieser Seite.
2. Sprich mit uns. Jede Migration ist anders, und die Tücken stecken immer im Detail. Ob Multi-Mandant, Nischen-Plugin oder jahrzehntealter Datenbestand — wir haben es wahrscheinlich schon gesehen.

Eingesetzte Tools

Technischer Steckbrief

↑ Zurück zur Übersicht

Quellen und weiterführende Links

• astro-shop.com — Der migrierte Online-Shop
• astronomik.com — Die offizielle Astronomik-Webseite
• gerdneumann.net — Gerd Neumanns Shop
• g2g-sw5-migration-audit.zip — Kostenloses SW5-Migrations-Audit-Skript (Download)
• Shopware 6 Domain-Umzug — Unser Blogbeitrag zum Thema DNS und Domain-Wechsel
• Shopware Mailversand — Best Practices — SPF, DKIM, DMARC richtig einrichten
• SEO-URLs bei der Shopware Migration richtig übernehmen — Unser Leitfaden zur URL-Kontinuität