Website- & Anwendungsmigration in Leipzig
Ich migriere Websites von WordPress, Joomla, Drupal, Angular, Vue und anderen Technologien zu Astro und Next.js. Jede Migration plane ich so, dass SEO, Inhalte und Funktionen erhalten bleiben, und schalte in einem vereinbarten Zeitfenster um. Ich arbeite allein und habe langjährige Erfahrung mit älteren und modernen Stacks.
- Mein wordpress.org-Konto besteht seit 2006.
- Ich habe zum WordPress-Core in den Versionen 7.0 und 7.1 beigetragen.
- Ich betreue 30 Plugins auf wordpress.org.
- Ich organisiere WordCamps und trete dort als Speaker auf.
- Ich war bei jedem WordCamp Europe von 2017 bis 2026 dabei.
- Lokales WordPress-Meetup: WordPress Meetup Leipzig
Läuft Ihr Shop in Leipzig noch auf Shopware 5 oder auf Magento 1, wissen Sie vermutlich, dass etwas passieren muss, aber nicht, in welche Richtung. Ich heiße Mariusz Szatkowski und entwickle allein und schriftlich von Gdynia aus, seit 2006 mit WordPress und heute auch mit Astro und Next.js. Diese Seite ordnet die Lage: Termine der Hersteller, drei mögliche Wege, was an Daten und URLs umzieht und welche Rechtsseiten danach stimmen müssen.
Was die Hersteller zum Ende sagen
Shopware 5. Auf der Migrationsseite von Shopware steht, dass es bis Ende Juli 2023 Fehlerbehebungen, kleine Verbesserungen und gesetzlich notwendige Anpassungen gab. Danach bis Ende Juli 2024 nur noch Sicherheitskorrekturen, auch für die hauseigenen Erweiterungen. Beide Termine liegen hinter uns. Die Dokumentation zu Shopware 5 trägt inzwischen den Hinweis, dass SafeFive sie weiterführt. Für einen Shop, der Zahlungen und Kundendaten verarbeitet, heißt das: Es gibt vom Hersteller keine Korrekturen mehr, auch nicht für Rechtsänderungen.
Magento 1. Die Lebenszyklus-Richtlinie von Adobe Commerce führt in ihrer Tabelle nur die Versionen 2.4.4 bis 2.4.9 auf. Für Magento 1 gibt es dort keinen Eintrag und damit keinen Hersteller-Zeitplan, an dem Sie sich orientieren könnten.
Auch das Ziel hat ein Ablaufdatum. Adobe gibt für jede Version drei Jahre Standard-Support ab Veröffentlichung. Nach der Versionsübersicht endet er für 2.4.7 am 31. Mai 2027, für 2.4.8 am 31. Mai 2028 und für 2.4.9 am 31. Mai 2029 (Stand November 2026). Für Adobe Commerce in der Cloud kündigt Adobe an, ab dem 1. Juni 2027 Umgebungen mit nicht mehr unterstützten Versionen vom Netz zu nehmen. Wer von Magento 1 auf Magento 2 wechselt, sollte also gleich die aktuelle Linie wählen und die nächste Aktualisierung einplanen.
Drei Wege, die ich mit Ihnen durchgehe
| Weg | Wann er passt | Was dafür spricht | Was dagegen spricht |
|---|---|---|---|
| Shopware 6 | Sie kommen von Shopware 5 und wollen das System behalten | Migrationsassistent vom Hersteller, vertraute Begriffe | neue Architektur, Erweiterungen müssen neu gebaut oder ersetzt werden |
| Anderes Shopsystem | Der Shop passt fachlich nicht mehr, oder Sie wollen weg vom bisherigen Anbieter | freie Wahl nach heutigem Bedarf | Daten und URLs müssen über Export und Import umziehen |
| Inhaltsseite mit Astro, Shop getrennt | Der Shop ist klein oder die Redaktion dominiert | Inhalte schnell und ohne Shop-Ballast, Commerce spezialisiert | zwei Systeme, Warenkorb und Konto liegen woanders |
Eine Empfehlung gebe ich erst nach der Bestandsaufnahme, und sie kann lauten, bei einem Shopsystem zu bleiben und nur umzuziehen.
Weg 1: Shopware 5 nach Shopware 6
Shopware beschreibt Shopware 6 als Open Source, headless und API-first, verfügbar als SaaS, PaaS oder selbst gehostet. Dasselbe Dokument weist darauf hin, dass der Wechsel kein Update mit wenigen Klicks ist, weil die Architektur neu ist. Shopware empfiehlt, SEO, Design und Checkout einzuplanen, vor der vollständigen Migration zu testen und eine Sicherung des alten Systems zu behalten.
So arbeitet der Assistent. Nach der Entwicklerdokumentation verbindet der Migrationsassistent eine Quelle, etwa Shopware 5, mit Shopware 6. Die Verbindung bleibt bestehen. Nach der ersten vollständigen Migration lassen sich einzelne Datensätze erneut übertragen oder aktualisieren. Das Profil shopware55 kennt zwei Zugänge: den API-Zugang über das Plugin Shopware Connector in Ihrem Shopware 5 und den lokalen Zugang direkt aus der Datenbank, der verlangt, dass beide Systeme auf demselben Server liegen.
Was der Assistent abfragt. Dokumentiert sind Auswahlgruppen wie Produkte, darin unter anderem Produktattribute, Hersteller, Eigenschaften, Übersetzungen und Cross-Selling, und Medien. Was sich nicht automatisch zuordnen lässt, fragt er als Premapping ab: Eigene Anreden aus Shopware 5 müssen Sie von Hand einer Anrede in Shopware 6 zuordnen. Fehler landen in einem Protokoll. Fehlt einem Produkt ein Steuersatz, können Sie den Satz anlegen, den Fehler als gelöst markieren und das Produkt erneut migrieren lassen. Medien werden in einem eigenen Schritt nach dem Schreiben importiert.
Was nicht von selbst mitgeht. Daten aus Plugins. Die Dokumentation empfiehlt, das Profil um eine eigene DataSelection zu erweitern. Dafür gibt es einen eigenen Leitfaden. Darum gehört die Liste der installierten Plugins an den Anfang: Jedes steht für Daten, die im neuen System entweder eine Entsprechung brauchen oder wegfallen.
Weg 2: Magento 1 nach Magento 2 oder in ein anderes System
Das Repository des Magento Data Migration Tool beschreibt die Migration von Magento 1.x nach Magento 2 in vier Teilen: Daten, Erweiterungen und eigener Code, Themes, Anpassungen. Das Werkzeug überträgt Produkte, Kunden, Bestellungen, Shop-Konfiguration und Aktionen. Unterstützt sind Open Source 1.6.x bis 1.9.x und Commerce 1.11.x bis 1.14.x. Für Erweiterungen und eigenen Code nennt die Readme das Code Migration Toolkit; Themes und Anpassungen müssen für Magento 2 neu gebaut werden. Das Repository ist ein älterer Stand, deshalb prüfe ich vor jedem Projekt, ob die Werkzeugversion zu Ihrer Zielversion passt.
Der Umzug in ein anderes Shopsystem, auch nach Shopware 6, läuft über Exporte aus Magento. Das ist mehr Handarbeit, bietet aber freie Wahl. Ich baue dann eine Zuordnungstabelle von Spalten im Export zu Feldern im Ziel und prüfe Stichproben gegen den alten Shop.
Weg 3: Inhalte nach Astro, Commerce getrennt
Manche Shops bestehen zu einem großen Teil aus Inhalten: Ratgeber, Kategorietexte, Marken- und Händlerseiten. Die Astro-Dokumentation beschreibt Astro für inhaltsgetriebene Websites, ausdrücklich auch für E-Commerce, wenn Inhalte schnell beim Leser ankommen sollen. Dann kann die Inhaltsseite in Astro entstehen, während Warenkorb, Konto und Kasse in einem Shopsystem bleiben, das dafür gebaut ist.
Wie das Front-End eines Shops als eigene Anwendung aussieht, beschreibe ich auf der Seite zu Next.js-Entwicklung in Leipzig. Den Umzug eines WooCommerce-Shops in eine Headless-Struktur behandelt die Seite zur Migration in Düsseldorf, den Umzug in einen Shopify-Shop die Seite zur Shopify-Entwicklung in Berlin. Hier geht es nur um die Frage, ob eine Aufteilung für einen Shop passt, der von einem alten System kommt. Sie bringt zwei Systeme, zwei Datenquellen und eine Stelle, an der Produktdaten synchron bleiben müssen.

Foto: Krzysztof Golik, CC BY-SA 4.0, Wikimedia Commons.
Welche URLs mitgehen müssen
Ein Shop hat mehr Adressen, als man sieht: Produkte, Kategorien, Marken, Filterseiten, Ratgeber, Bilder, Sitemaps. Ich sammle sie aus dem Sitemap-Bestand, aus der Search Console und aus den Serverprotokollen und lege für jede ein Ziel fest. Für Produkte, die entfallen, entscheiden wir, ob die Kategorie oder eine Ersatzseite das Ziel ist.
Bei der Umsetzung folgt die Regel aus der Google-Dokumentation zu Weiterleitungen: Permanente Weiterleitungen sind für die Indexierung ein Signal, dass das Ziel die kanonische Adresse ist. Serverseitige Weiterleitungen werden am sichersten richtig gedeutet, JavaScript-Weiterleitungen nur, wenn nichts anderes geht. In Astro lässt sich eine Zuordnung alter zu neuen Pfaden in der Konfiguration unter redirects hinterlegen, laut Routing-Dokumentation als permanente Weiterleitung. Bei vielen tausend Adressen liegt die Liste besser auf dem Server oder am Rand des Netzes.
Eine Zusage, dass nichts an Sichtbarkeit verloren geht, gebe ich nicht. Ich vergleiche vorher und nachher Klicks, Impressionen und indexierte Seiten und berichte Ihnen, was sich bewegt.
Was in den Rechtsseiten und im Bestellablauf stimmen muss
Beim Umzug ändern sich Vorlagen. Rechtliche Pflichten ändern sich nicht, aber Texte und Schaltflächen müssen im neuen Shop wieder an der richtigen Stelle stehen. Ich prüfe sie gegen den Gesetzestext, eine Rechtsberatung ersetzt das nicht.
- Zahlungsarten und Lieferbeschränkungen. Nach § 312j Absatz 1 BGB müssen sie spätestens zu Beginn des Bestellvorgangs klar angegeben sein. Das betrifft die Zahlungsmodule des neuen Systems, die oft anders heißen und anders konfiguriert werden als die alten.
- Bestellschaltfläche. Nach Absatz 3 muss die Schaltfläche gut lesbar mit nichts anderem als „zahlungspflichtig bestellen“ oder einer entsprechenden eindeutigen Formulierung beschriftet sein. Standardtexte aus Themes sind hier ein häufiger Fehler.
- Impressum. § 5 DDG verlangt Name und Anschrift, eine schnelle elektronische Kontaktmöglichkeit, bei Eintragung Register und Registernummer sowie, wenn vorhanden, die Umsatzsteuer-Identifikationsnummer. Die Angaben müssen leicht erkennbar und unmittelbar erreichbar sein.
- Verbraucherschlichtung. § 36 VSBG verlangt einen Hinweis, ob Sie an einem Streitbeilegungsverfahren teilnehmen. Unternehmer mit zehn oder weniger Beschäftigten sind von der ersten Pflicht ausgenommen.
- Datenschutz. Aufsicht für Unternehmen in Sachsen ist die Sächsische Datenschutz- und Transparenzbeauftragte. Beim Umzug prüfe ich, welche Zahlungs-, Tracking- und Versanddienste im neuen Shop Daten bekommen, und ob Datenschutzerklärung und Einwilligungsbanner dazu passen.
Der Ablauf mit mir, in Schriftform
- Sie schicken mir Shop-Adresse, System- und PHP-Version, die Plugin-Liste und Ihren Wunschtermin.
- Ich antworte schriftlich mit Fragen und einer Einschätzung, welcher Weg passt.
- Ich schicke Ihnen den Leistungsumfang schriftlich, mit Annahmen und Ausschlüssen. Gestaltung und Layout kommen von Ihnen, ich setze sie um.
- Ich baue auf einer Staging-Kopie, Sie nehmen schriftlich ab.
- Die Umschaltung plane ich mit Ihnen auf einen ruhigen Zeitpunkt und berichte danach, was in Search Console und Protokollen auffällt.
- Wenn Sie wollen, übernehme ich danach die Wartung.
Ich arbeite allein, remote und ohne Telefon- oder Videotermine, sodass alles nachlesbar bleibt.
Ein Hinweis zu Leipzig
Die Stadt beschreibt im Wirtschaftsbericht 2025 ein eigenes Mittelstandsförderprogramm, „Wachstum und Kompetenz im Leipziger Mittelstand“. Der Monitoring-Bericht 2024 weist dort 155 bewilligte Anträge von 151 Unternehmen aus. Ob eine Shop-Migration förderfähig ist, steht dort nicht. Wenn Sie das prüfen wollen, fragen Sie vor der Beauftragung bei der Stadt nach, denn Förderbedingungen betreffen oft den Zeitpunkt des Antrags.
Häufige Fragen
Ist Shopware 5 noch sicher zu betreiben? Shopware nennt auf seiner Migrationsseite Fehlerbehebungen bis Ende Juli 2023 und Sicherheitskorrekturen bis Ende Juli 2024. Beide Termine sind vorbei. Die Dokumentation zu Shopware 5 führt inzwischen SafeFive weiter. Ich betreibe solche Shops nicht weiter, sondern plane die Ablösung.
Muss ich bei Shopware bleiben, wenn ich von Shopware 5 komme? Nein. Shopware 6 hat einen Migrationsassistenten und ist der kürzeste Weg für Produkte, Kunden und Bestellungen. Es ist aber ein neues System mit neuer Architektur, kein Update. Ein anderes System oder ein Auftritt aus Astro mit getrenntem Shop sind gleichwertige Optionen.
Was nimmt der Shopware-Migrationsassistent nicht von selbst mit? Laut Dokumentation sind es vor allem Daten von Plugins. Empfohlen wird, das Migrationsprofil um eine eigene DataSelection zu erweitern. Auch eigene Anrede-Werte oder Steuersätze müssen Sie beim Premapping zuordnen. Das gehört in die Bestandsaufnahme vor dem Start.
Wie komme ich von Magento 1 weiter? Das Data Migration Tool überträgt Produkte, Kunden, Bestellungen, Konfiguration und Aktionen nach Magento 2, also Adobe Commerce. Themes, Erweiterungen und eigener Code sind laut Readme getrennte Aufgaben. Alternativ ziehen die Daten in ein anderes System um.
Verliere ich beim Umzug mein Ranking? Das kann niemand zusagen. Ich erfasse alle alten URLs, lege für jede ein Ziel fest und setze serverseitige permanente Weiterleitungen. Danach beobachte ich Search Console und Serverprotokolle und schreibe Ihnen, was auffällt.
Was schicke ich Ihnen für eine Einschätzung? Die Adresse des Shops, die Versionen von Shopsystem und PHP, die wichtigsten Erweiterungen, die Zahlungsarten und Ihren Wunschtermin. Ich antworte schriftlich, die erste Einschätzung ist kostenlos.
Schreiben Sie mir, bevor die Lücke größer wird
Wenn Ihr Shop in Leipzig noch auf Shopware 5 oder Magento 1 läuft, schicken Sie mir über das Kontaktformular die Adresse, die Systemversion, die Erweiterungen, Ihre Zahlungsarten und den Termin, bis zu dem etwas geschehen soll. Ich lese mir den Bestand an und antworte schriftlich mit einem Weg und den offenen Fragen. Die erste Einschätzung kostet nichts, und sie kann auch lauten, im bestehenden System zu bleiben und nur die Lücken zu schließen.
Ausgewählte Projekte
Beispiele aus meiner Arbeit.
E-Commerce-Entwicklung: haveabook.pl
haveabook.pl ist eine Plattform für einen Verlag und eine Druckerei, die anspruchsvolle Kunden aus skandinavischen Ländern betreut, mit Angebotskatalog, Bestellfluss und mehrsprachiger Inhaltsstruktur.
E-Commerce-Entwicklung: ILOVEHAIR
Ilovehair.pl ist ein auf WordPress basierender Onlineshop, der sich dem Verkauf professioneller Friseurprodukte der Marke Hair Saloon Products widmet. Als Pr...
E-Commerce-Entwicklung: KTS IOS/ANDROID APP
Das Projekt der Event-App, die der 15. Konferenz der Breitbandtechniker gewidmet ist, ist eine umfassende WordPress-basierte Lösung, die eine einfache Inhalt...
WordPress Support & Entwicklung in Leipzig
Brauchen Sie die Leistung: Migration zu Next.js / Astro in Leipzig?
Beschreiben Sie Ihr Projekt per E-Mail. Antwort innerhalb von 48 Stunden.
Projekt beschreibenWeitere WordPress-Dienste und Wissensbasis entdecken
Migration zu Astro, Next.js und Headless WordPress.
WooCommerce-Synchronisierung mit ERP und Großhandel.
Geschäftsprozessautomatisierung rund um WordPress und Firmensysteme.
Bibliothek konkreter Automatisierungsfälle.
Headless WordPress, Sanity, Strapi und Contentful mit Astro oder Next.js.
Astro, MDX, Edge Delivery und an echtem Traffic gemessene Core Web Vitals.
Individuelle WordPress-Entwicklung und Architektur.
Skalierbare Headless-, ERP- und KI-Architektur für Enterprise.
Verwandte Kategorien
Unterstützende Artikel

Sechs bis sechzehn Wochen für typische Projekte, in vier Phasen: Analyse, Scoping, Build und Umstellung, Tuning. Die Variablen sind Katalogumfang, Anzahl der Integrationen, URL-Erhalt und die Bereitschaft des Redaktionsteams, nicht die Wahl des Frameworks.

Umfassende 4-Jahres-TCO-Analyse (Total Cost of Ownership), reale Core-Web-Vitals-Benchmarks, Astro 7 GraphQL APQ-Architektur und eine 10-Punkte-Entscheidungsmatrix für Enterprise-Entscheider zwischen entkoppeltem und traditionellem WordPress.

Die Entscheidung Shopify Plus vs WooCommerce headless im Jahr 2026 ist kein binärer "Plattform vs Custom"-Kompromiss mehr. Beide laufen headless, beide integrieren KI, beide liefern am Edge aus. Die echten Achsen sind Kontrolle, Gesamtkosten über fünf Jahre und Exit-Strategie. Dieser Artikel durchläuft die Entscheidungsmatrix mit bestätigten Plattformfakten.