WooCommerce Entwickler in München

Läuft Ihr Onlineshop in München oder Oberbayern noch auf Shopware 5 oder Magento 1, bekommt er vom Hersteller keine Sicherheitsupdates mehr. Diese Seite beschreibt, wie ich einen solchen Shop zu WooCommerce umziehe: welche Daten mitkommen, welche nicht, was mit Passwörtern und alten URLs passiert und in welcher Reihenfolge ich auf einer Staging-Kopie arbeite. Ich bin ein einzelner Entwickler, Mariusz Szatkowski aus Gdynia, und arbeite mit WordPress seit 2006. Die Zusammenarbeit läuft remote und schriftlich, ohne Termine vor Ort. Gestaltung, Layout und Mockups liefern Sie, ich setze sie um.

Foto: David Kostner, bearbeitet von Steffen Schmitz (Carschten), CC BY-SA 2.0 de, Wikimedia Commons.

#Warum der Umzug jetzt auf dem Tisch liegt

Shopware hat für Version 5 einen festen Ausstieg veröffentlicht. Auf der Migrationsseite von shopware.com heißt es, dass es bis Ende Juli 2023 Fehlerbehebungen, kleinere Verbesserungen und rechtlich notwendige Anpassungen gab und danach ein weiteres Jahr Sicherheitsupdates bis Ende Juli 2024. Shopware 5 war seit dem 27. April 2015 auf dem Markt. Den kommerziellen Support für Sicherheitskorrekturen und Rechtskonformität übernahm laut Shopware-Blog ab Juli 2024 der Anbieter safefive.

Das öffentliche Repository von Shopware 5 auf GitHub trägt heute den Hinweis, dass es nicht mehr aktiv betreut wird und Updates nur noch gelegentlich und ohne Garantie erscheinen. Die letzte dort veröffentlichte Version war, Stand November 2026, v5.7.20 vom 5. Juni 2025. Die composer.json des Zweigs 5.7 erlaubt PHP bis zur Reihe 8.3, und für PHP 8.3 enden die Sicherheitskorrekturen laut php.net am 31. Dezember 2027. Wer auf Shopware 5 bleibt, hat also eine Plattform ohne Herstellerpflege auf einer Laufzeit mit absehbarem Ende.

Bei Magento 1 liegt der Schnitt länger zurück. Ein Partnerbeitrag auf shopware.com nennt das Ende des Supports im Juni 2020. Als Community-Fortführung existiert OpenMage, doch viele ältere Installationen laufen ohne diesen Wechsel weiter.

#Was das bayerische Datenschutzamt dazu geprüft hat

Das Bayerische Landesamt für Datenschutzaufsicht hat Magento-Shops schon einmal gezielt kontrolliert. Laut der Liste der Prüfungen des BayLDA begann am 30. Oktober 2018 eine Kontrolle zum Patch Management von Online-Shops mit Magento. Geprüft wurde, ob alle wichtigen Sicherheitspatches eingespielt und bekannte kritische Schwachstellen behoben sind, ob es einen geregelten Patch-Prozess gibt und ob die Betreiber bei einer Sicherheitsverletzung ihre Pflichten erfüllen können. Prüfgrundlage war Art. 32 DS-GVO. Aus 100 zufällig ausgewählten Shops in Bayern hatten 20 Magento aktiv im Einsatz und wurden genauer kontrolliert.

Die Aufsicht fragt also nach dem Prozess, mit dem ein Händler Sicherheitslücken schließt, und für einen Shop ohne Herstellerpatches gibt es diesen Prozess kaum. Beim Umzug lohnt deshalb ein Blick auf die Themenseite Online-Shops des BayLDA, dort liegen ein Praxisratgeber zu den DS-GVO-Anforderungen und ein Musterverzeichnis der Verarbeitungstätigkeiten für Online-Shops.

#Was mitkommt und was nicht

Manche Daten wandern sauber, andere nur mit Umweg, einige gar nicht. Grundlage der Tabelle sind die WooCommerce-Dokumentation und der Quellcode der Altsysteme.

#Produkte und Bilder

WooCommerce bringt im Kern einen CSV-Import für Produkte mit. Laut Dokumentation des Produkt-Imports muss die Datei in UTF-8 gespeichert sein, und bestehende Produkte werden über ID oder SKU erkannt. Variable Produkte brauchen eine Elternzeile und darunter je eine Zeile pro Variante mit eigener SKU, und Attributnamen und Werte müssen in Eltern- und Variantenzeilen gleich geschrieben sein. Genau hier stolpern Exporte aus Shopware oder Magento oft, weil dort “L”, “l” und “Large” nebeneinander stehen. Die Dokumentation empfiehlt, solche Werte vorher zu vereinheitlichen und zuerst eine kleine Stichprobe zu importieren.

Bilder müssen vorher hochgeladen oder online erreichbar sein. WooCommerce lädt sie von einer externen Adresse in die Mediathek, solange der Server des Altsystems die Anfrage nicht blockiert oder statt eines Bildes eine Seite ausliefert. Ein Punkt, der bei Barrierefreiheit zählt: Der Kern-Import kann den Alternativtext von Produktbildern weder anlegen noch ändern. Den übertrage ich deshalb in einem eigenen Schritt aus den Altdaten.

#Kunden und Bestellungen

Für Kunden und Bestellungen nutze ich die kostenpflichtige Erweiterung Customer / Order / Coupon CSV Import Suite oder ein eigenes Skript. Laut ihrer Dokumentation ist bei Kunden nur die E-Mail-Spalte Pflicht, und WordPress vergibt die Benutzer-ID selbst. Bestellungen lassen sich einem Kunden zuordnen oder als Gastbestellung anlegen, Positionen werden über SKU oder Produkt-ID verknüpft.

Bei Bestellnummern gibt es eine Grenze. WooCommerce verwendet intern eine eigene ID als Bestellnummer, und die Import Suite kann diese nicht direkt setzen. Sie legt die alte Nummer als Notiz und als Metadatum ab. Mit einem Plugin für fortlaufende Bestellnummern erscheint die alte Nummer dann im Kundenkonto und im Admin. Der Status jeder Bestellung muss auf einen der Status im Shop passen, laut Dokumentation sind das in einer Standardinstallation sieben: pending, failed, on-hold, processing, completed, refunded und cancelled.

Eine Option im Import heißt “Send Emails”. Sie verschickt Willkommensmails an neue Kunden und Bestellmails bei Statusänderungen. Beim Umzug bleibt sie aus, sonst bekommen Ihre Kunden aus dem Altbestand Nachrichten zu Bestellungen von vor Jahren.

#Passwörter: was das Hash-Format entscheidet

Kein Shop speichert Passwörter im Klartext, sondern einen Hash. Ob ein Kunde nach dem Umzug mit seinem alten Passwort hineinkommt, hängt davon ab, ob WordPress diesen Hash prüfen kann.

Die Import Suite schreibt dazu klar: Passwörter aus Systemen außerhalb von WordPress müssen zurückgesetzt oder im Klartext importiert und neu gehasht werden. Klartext haben Sie nicht, also bleibt nach Dokumentation das Zurücksetzen. Der Code von WordPress lässt in manchen Fällen mehr zu.

Die Funktion wp_check_password prüft seit WordPress 6.8 mehrere Formate: neue bcrypt-Hashes mit dem Präfix $wp, ältere phpass-Hashes mit $P$, kurze Hashes bis 32 Zeichen als MD5 und jeden anderen Hash ohne Präfix über die PHP-Funktion password_verify. Shopware 5 verwendet laut Quellcode als Standard den Encoder bcrypt, der mit password_hash arbeitet, und hat zusätzlich einen älteren Encoder, der ein reines MD5 speichert. Beide Formate fallen in einen der Prüfwege von WordPress. Ob das für Ihren Shop klappt, weiß ich erst, wenn ich auf Staging den Hash eines Testkontos unverändert übernehme und mich damit anmelde. Der Hash muss dafür ohne erneutes Hashen in die Benutzertabelle gelangen.

Bei Magento 1 sieht es anders aus. Im Quellcode von OpenMage, der Fortführung von Magento 1, besteht der gespeicherte Wert aus dem Hash von Salt und Passwort, einem Doppelpunkt und dem Salt. Dieses Format kennt WordPress nicht. Hier bekommen Kunden nach dem Umzug eine Mail zum Zurücksetzen, und ich formuliere sie mit Ihnen so, dass niemand sie für Phishing hält.

Die Umstellung auf bcrypt beschreibt WordPress im Beitrag zu Version 6.8: Ältere Hashes bleiben gültig und werden bei der nächsten Anmeldung automatisch in das neue Format umgerechnet.

#Alte URLs und Google

Shopware 5 und Magento 1 bauen ihre Produkt- und Kategorie-URLs anders als WooCommerce. Ohne Weiterleitungen verlieren Sie Links von außen, Lesezeichen und die Position in der Suche. Google beschreibt den Ablauf in der Anleitung zur Websiteverschiebung mit URL-Änderungen. Die Punkte, nach denen ich arbeite:

• Die Liste der alten URLs entsteht aus den Sitemaps und aus den Serverprotokollen, mit einem Zeitraum, der saisonale Schwankungen abdeckt.
• Jede alte URL bekommt eine dauerhafte, serverseitige Weiterleitung, Google empfiehlt 301 oder 308.
• Die Weiterleitungen bleiben möglichst lange bestehen, generell mindestens ein Jahr.
• Eine neue Sitemap mit den neuen URLs wird in der Search Console eingereicht.
• Rankings können während der Umstellung schwanken. Bei mittelgroßen Websites dauert es laut Google einige Wochen oder länger, bis die neuen URLs die alten ersetzen.

Das Tool zur Adressänderung in der Search Console ist für den Wechsel auf eine andere Domain oder Subdomain gedacht. Für Pfadänderungen innerhalb derselben Domain, für den Wechsel zwischen Varianten mit und ohne “www” oder von HTTP zu HTTPS ist es ausdrücklich nicht vorgesehen. Bei den meisten Shop-Umzügen bleibt die Domain gleich, dann reichen Weiterleitungen und Sitemap. Ändert sich die Domain doch, wirkt das Tool 180 Tage, die Weiterleitungen bleiben mindestens so lange, und Google rät, die alte Domain mindestens ein Jahr weiter zu bezahlen, damit sie niemand für schädliche Zwecke übernimmt.

Zum Thema Rankings nach einem Domainwechsel gibt es einen eigenen Beitrag: warum Google Domainmigrationen zurücksetzt.

#Der richtige Zeitpunkt

Google rät, die Verschiebung in eine Zeit mit wenig Traffic zu legen, damit Fehler weniger schaden. Für den Handel gibt die IHK München und Oberbayern einen Anhaltspunkt: Laut ihrem Ratgeber zum Weihnachtsgeschäft erzielen Onlinehändler gut 27 Prozent ihres Jahresumsatzes im November und Dezember. In diese Wochen lege ich keine Umstellung. Ein Umzug, der im Sommer geplant wird, hat bis zum Herbst Zeit, sich in der Suche zu setzen.

Die IHK unterscheidet in ihren E-Commerce-Basics zwischen eigener oder angepasster Open-Source-Shopsoftware und einem Mietshop, bei dem der Anbieter Betrieb und Sicherheit übernimmt. WooCommerce gehört zur ersten Gruppe. Sie gewinnen Freiheit bei Funktionen und Daten, tragen aber die Verantwortung für Updates selbst oder geben sie an jemanden ab, der sie übernimmt.

#Die Reihenfolge, in der ich migriere

Alles passiert auf einer Staging-Kopie, der alte Shop läuft unterdessen weiter.

1. Bestand aufnehmen. Ich exportiere Produkte, Varianten, Kategorien, Kunden und Bestellungen aus dem Altsystem und liste alle URLs aus Sitemap und Serverprotokollen. Dazu notiere ich, welche Erweiterungen im Altshop laufen und was sie tun.
2. Zielstruktur festlegen. Welche Attribute global sind, wie Kategorien heißen, welche URL-Struktur der neue Shop bekommt. Diese Entscheidungen schreibe ich auf, bevor importiert wird, weil sie die Weiterleitungstabelle bestimmen.
3. Probeimport. Eine kleine Stichprobe aus Produkten mit Varianten, einigen Kunden und Bestellungen. Ich vergleiche sie Feld für Feld mit dem Altshop und teste dabei die Passwortfrage mit einem Testkonto.
4. Vollimport. Gesamter Katalog, danach Kunden, danach Bestellungen, mit ausgeschaltetem Mailversand. Anschließend prüfe ich Summen: Anzahl Produkte, Varianten, Kunden und Bestellungen auf beiden Seiten.
5. Funktionen nachbauen. Zahlungsarten, Versand, Steuern und Rechtstexte richte ich neu ein. Was im Altshop ein Plugin war, ersetze ich durch eine vorhandene WooCommerce-Erweiterung oder durch eigenen Code über Hooks, nicht durch Änderungen am Kern.
6. Weiterleitungen und Tests. Weiterleitungstabelle anlegen, jede Zeile automatisch prüfen, dann Checkout mit Testzahlungen, Kundenkonto, Passwort-Zurücksetzen und Bestellmails durchspielen.
7. Deltaimport und Umstellung. Kurz vor dem Wechsel importiere ich die Bestellungen und Kunden, die seit dem Vollimport dazugekommen sind, schalte den Altshop in den Wartungsmodus und stelle die Domain um.
8. Beobachten. Neue Sitemap einreichen, Fehlerprotokolle und den Indexierungsbericht der Search Console in den ersten Wochen lesen, fehlende Weiterleitungen nachtragen.

#Die alte Datenbank nach dem Umzug

Nach dem Wechsel liegt eine vollständige Kopie aller Kundendaten im Altsystem. Das BayLDA schreibt auf seiner Seite zur Löschung, dass personenbezogene Daten grundsätzlich unverzüglich zu löschen sind, wenn es keine Rechtsgrundlage mehr für die Speicherung gibt, und dass gesetzliche Aufbewahrungspflichten etwa aus Steuer- und Handelsrecht eine Ausnahme sein können. Ich halte die alte Datenbank deshalb gesperrt als Sicherung, bis Sie den neuen Shop schriftlich abgenommen haben. Was danach wegen Aufbewahrungspflichten bleiben muss, klären Sie mit Ihrer Steuerberatung, den Rest lösche ich, und die Löschung dokumentiere ich.

#Was ich von Ihnen brauche

• Zugang zum Altshop mit Admin-Rechten und, wenn möglich, zur Datenbank oder einem vollständigen Datenbankabzug.
• Zugang zum Hosting des neuen Shops oder die Freigabe, eine Staging-Umgebung anzulegen.
• Eine Liste der Erweiterungen im Altshop und was davon wirklich genutzt wird.
• Zugang zur Search Console, damit ich Sitemaps und Indexierung sehe.
• Layout und Gestaltung für den neuen Shop als fertige Vorlage oder als ausgefüllte Tabelle, welche Elemente auf welcher Ansicht stehen. Ich setze um, ich gestalte nicht.
• Einen Zeitraum mit wenig Umsatz für die Umstellung.

#Checkliste vor dem Umzug

Diese Punkte können Sie prüfen, auch wenn Sie den Umzug mit jemand anderem machen:

• Welche Shop-Version läuft, und wann kam das letzte Sicherheitsupdate?
• Liegt eine vollständige Sitemap vor, und gibt es Serverprotokolle der letzten zwölf Monate?
• Haben alle Produkte und Varianten eine eindeutige SKU?
• Sind Attributwerte einheitlich geschrieben?
• Haben Produktbilder Alternativtexte, die mit umziehen sollen?
• Welche Bestellstatus nutzt der Altshop, und wohin gehören sie in WooCommerce?
• Wer schreibt die Mail an Kunden, falls Passwörter zurückgesetzt werden müssen?
• Bleibt die Domain gleich?

#Nach dem Umzug

Ein frischer WooCommerce-Shop braucht dieselbe Pflege, die dem Altsystem gefehlt hat: getestete Updates, Sicherungen außerhalb des Hostings und einen Blick auf Sicherheitsmeldungen. Wie ich das organisiere, steht auf der Seite Wartung in München. Wer statt eines klassischen Shops eine entkoppelte Oberfläche plant, findet Hinweise zur Headless-Migration von WooCommerce. Einen Vergleich speziell für Magento und Adobe Commerce bietet der Beitrag zur Migration von Magento zu WooCommerce.

#Häufige Fragen

#Können meine Kunden ihr bisheriges Passwort behalten?

Das hängt vom Hash-Format des Altsystems ab. WordPress prüft seit 6.8 auch Hashes, die mit password_hash erzeugt wurden, und Shopware 5 erzeugt standardmäßig solche bcrypt-Hashes. Ob das in Ihrem Shop klappt, teste ich auf Staging mit einem Testkonto. Hashes aus Magento 1 im Format Hash, Doppelpunkt, Salt erkennt WordPress nicht, dort bekommen Kunden eine Mail zum Zurücksetzen.

#Behalten die Bestellungen ihre alten Nummern?

Nicht als interne ID. Die Import Suite legt die alte Nummer als Notiz und als Metadatum an der Bestellung ab. Mit einem Plugin für fortlaufende Bestellnummern erscheint sie dann im Konto und im Admin.

#Brauche ich das Tool zur Adressänderung in der Search Console?

Nur, wenn sich die Domain oder Subdomain ändert. Bleibt der Shop unter derselben Domain und nur die Pfade ändern sich, reichen Weiterleitungen und eine neue Sitemap.

#Wie lange müssen die Weiterleitungen bleiben?

Google empfiehlt, sie möglichst lange und generell mindestens ein Jahr zu behalten. Ich lasse sie danach stehen, solange noch Aufrufe darüber kommen.

#Wann ist der beste Zeitpunkt für den Umzug?

In einer Zeit mit wenig Umsatz. Laut IHK München und Oberbayern erzielen Onlinehändler gut 27 Prozent ihres Jahresumsatzes im November und Dezember, diese Monate meide ich für die Umstellung.

#Was passiert mit der alten Datenbank nach dem Umzug?

Sie bleibt gesperrt als Sicherung, bis die Abnahme durch ist. Danach entscheiden Sie mit Ihrer Steuerberatung, was wegen Aufbewahrungspflichten bleiben muss, der Rest wird gelöscht.

#Treffen wir uns dafür in München?

Nein. Ich arbeite remote aus Gdynia und stimme alles schriftlich ab, vom Umfang bis zur Abnahme.

#Schreiben Sie mir

Wenn Ihr Shop noch auf Shopware 5 oder Magento 1 läuft, schicken Sie mir über das Kontaktformular die Adresse des Shops, die Version des Altsystems, die ungefähre Zahl an Produkten, Kunden und Bestellungen und den Zeitraum, in dem Sie umstellen möchten. Ich sehe mir den Shop an, schicke Ihnen meine offenen Fragen schriftlich und danach eine Einschätzung mit Umfang und Annahmen. Diese erste Einschätzung ist kostenlos.