Magento zu Shopify, Stolpersteine und Pflichten

Magento auf Shopify migrieren klingt wie ein Datenbank-Job. Produkte exportieren, Kunden exportieren, Bestellungen exportieren, drüben importieren, DNS umlegen, fertig. So verkaufen es viele Migrations-Apps und so steht es in den meisten Whitepapers. So passiert es in der Praxis nie.

Magento ist ein Application-Framework, in dem ein Shop läuft. Shopify ist ein gehosteter Shop, in dem Sie Erweiterungen ergänzen. Diese Differenz erzeugt im Migrations-Projekt mehr Aufwand als die reine Daten-Übernahme. Wir haben unsere eigene Marke Vaultskin vor einigen Jahren von Magento 2 auf Shopify Plus migriert, betreiben sie seitdem dort über vierzehn Länder hinweg, und kennen die Stellen, an denen Migrations-Decks schweigen.

Was Magento sauber kann, was Shopify anders denkt

Magento erlaubt Multi-Store-Strukturen mit gemeinsamem Katalog und unterschiedlichen Stores, jeder mit eigener Sprache, Währung, Steuer-Logik, eigenem Theme. In Magento 2 ist das nativ. Wer einen DACH-Shop, einen UK-Shop und einen FR-Shop in einer Installation betreibt, kennt das Konstrukt mit Website, Store, Store-View. Es ist mächtig und für mehrsprachige Operationen gut geeignet.

Shopify denkt anders. Shopify Markets bündelt Länder unter einem Shop, Sprach-Versionen laufen über Translate & Adapt oder Drittanbieter-Apps wie Langify. Verschiedene Währungen, Steuern und Versand-Zonen werden über Markets konfiguriert. Was bei Magento ein Konfigurations-Feld war, ist bei Shopify eine Markets-Definition mit anderem mentalem Modell.

Der Stolperstein bei der Migration ist nicht die Übersetzung der Strukturen, sondern die Erwartungs-Verschiebung im Team. Marketing-Verantwortliche, die zehn Jahre lang Store-Views administriert haben, brauchen ein paar Wochen, bis sie in Markets-Mustern denken. Planen Sie diese Lernkurve aktiv ein; sonst entstehen in den ersten Monaten falsche Konfigurationen, die später teuer werden.

URL-Struktur und SEO, der größte ungewollte Verlust

Magento generiert Produkt-URLs nach einem klaren Muster, oft mit .html-Endung, oft mit Kategorie-Präfix, oft mit langen URL-Keys. Shopify hat ein eigenes, viel rigideres URL-Schema, /products/<handle> für Produkte, /collections/<handle> für Kategorien, ohne .html, ohne tiefe Hierarchie.

Das heißt, jede einzelne Produkt-URL und jede Kategorie-URL ändert sich bei der Migration. Wenn Sie hier nicht systematisch redirecten, verlieren Sie binnen drei bis sechs Monaten einen großen Teil Ihres organischen Traffics, und der kommt selten vollständig zurück. Bei der Vaultskin-Migration haben wir in den ersten zwei Wochen nach Cutover etwa zwölf Prozent Traffic verloren, einfach weil eine Handvoll Long-Tail-URLs ohne Redirect lief. Drei davon hatten Backlinks aus Lifestyle-Magazinen.

Was hilft: vor dem Cutover die alten URLs aus Google Search Console und Sitemap exportieren, gegen die neuen Shopify-Handles mappen, und 301-Redirects in Bulk in Shopify einpflegen. Shopify erlaubt URL-Redirects per CSV-Import. Den Schritt darf man nicht delegieren und nicht abhaken, bevor jede einzelne Top-100-Seite ein Mapping hat. Bei Vaultskin haben wir nach dem Cutover noch zwei Wochen lang täglich Search-Console-Crawl-Errors überwacht und nachgepflegt.

Produkte, Varianten, Bilder: was sauber migriert und was nicht

Produkt-Daten lassen sich grundsätzlich migrieren. Magento-Export, Shopify-Import via CSV oder Matrixify, das ist Stand der Technik. Was dabei oft kaputtgeht und nachgearbeitet werden muss, sind drei Dinge.

Der häufigste Schmerzpunkt sind konfigurierbare Produkte mit vier oder mehr Optionsachsen. Shopify erlaubt nativ drei Optionen pro Produkt. Wer ein T-Shirt in Größe, Farbe, Schnitt, Material und Druck führt, muss die Architektur anders denken oder mit einer Variant-App wie Infinite Options arbeiten, die ihre eigene Logik mitbringt.

Beschreibungen aus Magento haben oft Inline-Styles, alte Iframe-Embeds und Magento-spezifische Shortcodes. Diese wandern bei einfachem Import im HTML-Feld mit, sehen im Shopify-Theme aber schief aus. Bei Vaultskin haben wir mehrere hundert Produkt-Beschreibungen am Stück mit einem Skript bereinigt, dann manuell pro Top-Seller nochmal durchgesehen. Das ist langweilige Arbeit, aber notwendig.

Kunden, Bestellungen, Zahlungs-Tokens

Kunden- und Bestelldaten sind der Bereich, in dem viele Migrations-Anbieter zu viel versprechen. Was technisch geht und was rechtlich oder vertraglich geht, sind zwei verschiedene Fragen.

Kunden-Stammdaten sind migrierbar, mit Einschränkungen. Sie können Adressen, E-Mails, Bestellhistorie übertragen. Was Sie nicht übertragen können, sind Passwort-Hashes. Magento und Shopify nutzen unterschiedliche Hash-Algorithmen und Salts. Praktisch heißt das: Jeder Bestandskunde muss beim ersten Login auf dem neuen Shop sein Passwort zurücksetzen. Kommunizieren Sie das vor dem Cutover offensiv; sonst entstehen Support-Tickets in dreistelliger Zahl in der ersten Woche.

Bestellungen sind als historische Datensätze migrierbar, aber ohne Live-Bezug. Heißt: alte Magento-Bestellungen erscheinen in der Shopify-Order-History, aber Refunds, Stornos und Rücksendungen aus diesen Bestellungen lassen sich in Shopify nicht mehr nativ verarbeiten. Wir empfehlen, Magento mindestens sechs Monate parallel im Read-Only-Modus weiterlaufen zu lassen, damit Customer-Service auf alte Bestellungen zugreifen kann.

Zahlungs-Tokens sind das härteste Thema. Tokens sind an den Payment-Service-Provider gebunden, und auch dort an die Merchant-ID. Wenn Sie bei der Migration den PSP wechseln, sind alle Tokens weg. Wenn Sie den PSP behalten, lassen sich Tokens manchmal übertragen, aber jeder Provider behandelt das anders. Mollie, Stripe, Adyen haben jeweils eigene Migrations-Wege, oft mit Vorlauf von vier bis sechs Wochen und schriftlichem Antrag. Planen Sie das früh ein; sonst müssen Stammkunden ihre Zahlungsdaten neu hinterlegen.

Custom-Module, Magento-Apps, Shopify-App-Mapping

Jeder Magento-Shop hat im Lauf der Jahre ein Dutzend bis fünfzig Module installiert, manche von Marken-Anbietern, manche selbst geschrieben, manche aus Foren-Code zusammengeflickt. Vor der Migration steht eine nüchterne Bestandsaufnahme. Welche Module sind aktiv genutzt, welche liefen einfach mit, welche lassen sich auf der Shopify-Seite ersetzen, welche brauchen Custom-Entwicklung.

Ein typisches Magento-Setup mit dreißig Modulen lässt sich im Shopify-Setup oft auf acht bis zwölf Apps reduzieren. Das hat zwei Gründe. Erstens ist Shopify standardmäßig komfortabler; viele Magento-Module ergänzen Funktionen, die Shopify nativ hat. Zweitens ist die Schwelle, eine App zu installieren und monatlich zu zahlen, höher als bei einem einmal installierten Open-Source-Magento-Modul, was die Disziplin schärft.

Es gibt Lücken. Bestimmte ERP-Konnektoren, die für Magento mit zehn Jahren Reife existieren, gibt es für Shopify nicht oder nur als junge Shopify-Apps. Spezial-Funktionen für Konfigurator-Produkte, mehrstufige Genehmigungsprozesse im B2B, oder branchen-spezifische Mietsoftware-Brücken, das sind die Stellen, an denen wir bei Migrations-Beratungen oft nachfragen, ob das Feature wirklich kritisch ist oder ob ein Workaround reicht. Ein guter Teil dieser Magento-Funktionen, mit denen Kunden sich im Erstgespräch identifizieren, wird im Tagesgeschäft kaum noch genutzt.

Steuern, Rechnungen, B2B-Preise, die unsichtbaren Brüche

Das ist der Teil, der fast immer unterschätzt wird, weil er auf den ersten Blick technisch trivial aussieht. Magento hat ein flexibles, manchmal überflexibles Tax-System mit Tax-Klassen, Tax-Rules, Tax-Zonen, Customer-Tax-Klassen. Shopify hat seit der Einführung von Markets und Shopify Tax ein viel einfacheres, aber auch starreres Modell, das auf vielen DACH-Setups out-of-the-box passt.

Der Stolperstein liegt in den Übergangs-Fällen. B2B-Kunden mit Reverse-Charge-Pflicht, Versand in die Schweiz mit DDP-Logik, Kleinunternehmer-Regelung beim eigenen Shop, das sind alles Konfigurationen, die in Magento explizit gepflegt waren und in Shopify entweder anders heißen oder über Apps wie Sufio, Avalara oder Eshop Guide ergänzt werden müssen.

Wir haben bei Vaultskin in den ersten Monaten nach der Migration die Steuer-Konfiguration mehrfach nachgezogen, weil OSS-Schwellenwerte nicht korrekt griffen. Das wäre uns nicht passiert, wenn wir eine Tax-Test-Phase im Sandbox-Shop mit echten Bestellbeträgen pro Land vor dem Cutover gehabt hätten. Heute machen wir das bei jedem Migrations-Projekt zur Pflicht.

Rechnungen sind der zweite unsichtbare Bruch. Magento generiert Rechnungen entweder nativ oder über ein Modul wie Mageworx Pdf. Diese Rechnungen sind oft an die Steuer-Logik in Magento gekoppelt. Bei Shopify übernimmt das in der Regel eine App wie Sufio oder ein angebundenes Buchhaltungs-System. Die Rechnungs-Logik ist also nicht mehr im Shop, sondern in einer dritten Schicht. Das hat Vorteile, erfordert aber neues Setup, neue Tests und neue Disziplin bei der E-Rechnung.

Cutover-Wochenende, realistischer Zeitplan

Der Cutover ist nicht “DNS umlegen, fertig”. Ein typisches Cutover-Wochenende bei einem Shop mit echtem Traffic sieht in unserer Erfahrung so aus.

Donnerstag-Abend: Final-Datenexport aus Magento, Final-Import in Shopify, alle Bestände abgleichen. Bei einem Shop mit mehreren tausend SKUs sind das mehrere Stunden plus Verifikations-Zeit.

Freitag-Tag: Magento auf Wartungs-Modus, Last-Mile-Tests in Shopify, Shopify-Apps gegen die Live-Daten testen, Versand-Konnektoren testen, Zahlungs-PSP scharf schalten und mit echtem Mini-Betrag testen. Ein voller Arbeitstag bei einem disziplinierten Team.

Freitag-Abend bis Samstag-Mittag: DNS-Switch, TTL-Anpassung im Vorfeld auf 300 Sekunden, Cache-Warming, externe Dienste neu konfigurieren (Klaviyo, Google Ads, Meta Pixel, Search Console). Mehrere Stunden konzentrierte Arbeit.

Samstag-Nachmittag und Sonntag: aktive Beobachtung, Customer-Service-Stand-by, Search-Console-Errors monitoren, erste echte Bestellungen verifizieren, Versand auslösen. Der arbeitsintensivste Block des ganzen Wochenendes.

Montag-Morgen: erste vollständige Werktag-Bilanz. Erfahrungsgemäß tauchen jetzt die kleinen Fehler auf, die im Test-Setup nicht sichtbar waren: falsche Versand-Klasse für eine bestimmte SKU, fehlerhafte Mehrwertsteuer auf einer bestimmten Land-Sortiment-Kombination, eine Mail-Vorlage, die noch das Magento-Brand-Logo zeigt.

Wer weniger als vier volle Arbeitstage konzentrierte Vorbereitung einplant, riskiert, dass etwas brennt, das in der Hektik nicht sauber gelöscht wird.

Und: Legen Sie den Cutover nicht in die Peak-Saison. Wir haben bei Vaultskin bewusst ein ruhiges Frühjahrs-Wochenende gewählt; ab Oktober gilt Code-Freeze, ein Cutover zwischen Black Friday und Weihnachtsgeschäft verbietet sich von selbst.

Was wir bei Vaultskin konkret gelernt haben

Drei Dinge würden wir heute anders machen.

Erstens, frühere Tax-Tests. Wir hatten OSS-Schwellenwerte zu spät verifiziert und mussten in den ersten Monaten mehrere Konfigurations-Updates nachziehen. Heute setzen wir vor dem Cutover Test-Bestellungen pro Land pro Sortiment auf, mit echten Beträgen, in einem Sandbox-Shop, und gleichen die generierten Rechnungen gegen die Steuerberater-Erwartung ab.

Zweitens, längeren Magento-Read-Only-Schwanz. Wir haben unseren alten Shop zu früh abgeschaltet und damit den Customer-Service unnötig in eine schwierige Lage gebracht. Heute lassen wir den alten Shop mindestens sechs, oft neun Monate parallel laufen, ausschließlich für Bestellhistorie und Refund-Abwicklung. Die Hosting-Kosten dafür liegen im dreistelligen Bereich pro Monat und sparen deutlich mehr an Support-Aufwand.

Drittens, härtere URL-Mapping-Pflicht vor Cutover. Wir hatten unsere Top-100-URLs sauber, aber einen dreistelligen Bestand an Long-Tail-URLs ohne Mapping. Ein Teil davon brachte Traffic, der nie wieder vollständig zurückkam. Heute mappen wir bis zur Top-500 verifiziert und legen Catch-all-Patterns für den Rest.

Was Sie selbst tun, was Sie begleiten lassen sollten

Wer eine kleine Magento-Installation mit unter zweihundert SKUs, einer Sprache, einem Land und einem Standard-Theme migriert, kann das mit einer Migrations-App wie Cart2Cart oder Matrixify in Eigenregie machen. Erwarten Sie zwei bis vier Wochen konzentrierte Arbeit für eine Person mit Shopify-Erfahrung.

Wer eine Magento-2-Installation mit Multi-Store, B2B-Anteil, Custom-Modulen, Konnektoren ins ERP und mehrsprachigem Sortiment betreibt, sollte sich begleiten lassen. Nicht weil die Datenmigration unmöglich wäre, sondern weil die Konfigurations-Entscheidungen, die in den ersten zwei Wochen nach Cutover fallen, das Setup für die nächsten Jahre prägen.

Eine Begleitung, die nichts vom Magento-Tax-Modell weiß, hilft hier wenig. Eine, die schon einmal selbst migriert hat und die kleinen Fallen kennt, spart Ihnen ein Quartal Lernkurve. Wenn Sie unsicher sind, ob Ihr Setup grundsätzlich zu Shopify passt, ist unser Shopify-Eignung-Check ein guter erster Schritt vor dem Erstgespräch.

Migration ist kein Plattform-Wechsel, sondern ein Setup-Wechsel

Adobe hat für Magento 2 bislang kein hartes, öffentlich fixiertes Enddatum für den Support genannt; absehbar ist aber, dass die Investitionen in die Plattform mittelfristig zurückgehen, wie es bei Adobe Commerce seit der Übernahme von Magento zu beobachten war. Für die Migrations-Entscheidung sollte das nicht der Haupttreiber sein. Ob Shopify für Sie passt, hängt an Ihrem Sortiment, Ihrer Steuer-Situation und Ihrem B2B-Anteil, nicht an einem Stichtag, den niemand verbindlich datieren kann. Wer aus reiner Torschlusspanik migriert, überspringt genau die Vorbereitung, die dieser Artikel beschreibt.

Der häufigste Fehler in Migrations-Projekten ist ohnehin die mentale Reduktion auf “wir tauschen das Shop-System aus”. Tatsächlich tauschen Sie eine Operationsweise gegen eine andere, mit anderen Tools, anderen Verantwortlichkeiten, anderem Tempo, anderen Kosten-Profilen. Magento war für viele Jahre die richtige Antwort; Shopify ist heute für die meisten DACH-Mittelständler die bessere, aber nur, wenn Sie das Setup mit-migrieren, nicht nur die Daten. Mehr zur grundsätzlichen Shopify-Eignung für den DACH-Mittelstand lesen Sie im Artikel Warum Shopify für den DACH-Mittelstand.

Die Stolpersteine, die wir hier beschrieben haben, sind die wahrscheinlichen, nicht die maximalen. Bei jedem konkreten Shop kommen weitere eigene dazu, die im Erstgespräch sichtbar werden. Wer sie früh ausspricht, plant realistisch und vermeidet, dass die Migration Monate später zu einer ungeplanten Operation wird.

Wenn Sie über eine Migration nachdenken, sprechen Sie mit jemandem, der das Old-Stack-Setup kennt, nicht nur das neue. Den Termin dafür finden Sie unter /kontakt. Unsere Setup- und Migrations-Leistungen im Detail finden Sie im Modul Setup & Migration.