Custom CMS zu Shopify Migration: Eine Eigenentwicklung umziehen, ohne Daten oder Rankings zu verlieren
⏱ ca. 22 Min. Lesezeit
Eine Custom CMS zu Shopify Migration hat ein Merkmal, das Plattform-Migrationen nicht haben: Es gibt keinen Export-Button, kein Migrations-Tool und keine zwei Builds sind gleich. Wenn Sie von Magento oder BigCommerce wechseln, ist das Datenmodell wenigstens bekannt und jemand hat es schon gemacht. Wenn Sie von einer selbst gebauten, internen Plattform wechseln, ist das Schema undokumentiert, die Geschäftsregeln stecken im Code, und die Person, die es gebaut hat, ist vielleicht vor Jahren gegangen. Das Risiko sind nicht die Eigenheiten der Plattform. Es sind die Unbekannten.
Das ändert, wie das Projekt läuft. Eine Custom CMS zu Shopify Migration ist weniger ein Datentransfer als ein Stück Archäologie, gefolgt von einem Neuaufbau: das System lesen, das niemand dokumentiert hat, entscheiden, was bleibt, und es auf einer Plattform neu ausdrücken, die sich selbst wartet. Dieser Leitfaden behandelt, wann ein Custom-Build vom Asset zur Last wird, warum die Daten der schwere Teil sind, eine Discovery-first-Methode für die Unbekannten, wie Sie maßgeschneiderte Features auf Shopify neu bauen, wie Sie SEO schützen, wenn die URLs nie erfasst wurden, und was es kostet. Für einen konkreten Plan sind unsere Shopify-Migrationsservices da.
Warum ein Custom-Build vom Asset zur Last wird
Eine Custom-Plattform wird meist aus gutem Grund gebaut: Irgendwann passte nichts von der Stange. Das Problem kommt Jahre später, wenn der Build leise vom Wettbewerbsvorteil zur operativen Bremse wird. Die Signale sind konsistent.
- Key-Person-Risiko. Die Geschäftslogik steckt in den Köpfen von ein, zwei Personen und in undokumentiertem Code. Gehen sie, wird die Plattform zur Blackbox, die Sie sich nicht anzufassen trauen. Dieser „Bus-Faktor“ ist der häufigste Auslöser einer Custom CMS zu Shopify Migration.
- Sie können nicht dafür einstellen. Jeder Entwickler braucht Onboarding in eine Codebasis, die nur Ihr Team kennt. Es gibt keinen Talentpool, keine Community, keine Stack-Overflow-Antwort – nur Ihr eigenes Wissen.
- Wartung frisst die Roadmap. Entwicklungszeit geht dafür drauf, den Laden am Laufen zu halten – Sicherheitspatches, Dependency-Upgrades, Bugfixes – statt zu bauen, was das Geschäft bewegt. Sie finanzieren Infrastruktur, nicht Wachstum.
- Sicherheit und Compliance liegen bei Ihnen. PCI-Scope, Patching, Uptime, DDoS- und Betrugsschutz sind auf einem Custom-Stack Ihr Problem. Eine gemanagte Plattform nimmt Ihnen das komplett ab.
- Sie erfinden gelöste Probleme neu. Checkout, Rabatte, Steuern, Suche, Subscriptions, Reviews – Features, die auf Shopify eine App oder eine native Einstellung sind – sind bei Ihnen maßgeschneiderter Code, den Sie für immer warten.
Wenn Ihr Kern ein wirklich ungewöhnliches Commerce-Modell ist – ein Multi-Vendor-Marktplatz mit Provisions- und Auszahlungslogik, garantiertes Lieferslot-Management, Preisbildung nach variablem Gewicht – und das Ihr echter Unterschied ist, kann ein Custom- oder Headless-Build weiterhin gerechtfertigt sein. Der ehrliche Test: Ist der Custom-Teil Ihr Wettbewerbsvorteil oder nur Infrastruktur, die Ihnen zufällig gehört? Ist es Infrastruktur, gewinnt eine Custom CMS zu Shopify Migration fast immer.
Der Kernunterschied: Es gibt keinen Export-Button
Jeder Migrationsleitfaden spricht vom „Daten exportieren“. Eine Custom CMS zu Shopify Migration hat keinen solchen Button, und kein Drittanbieter-Tool (Cart2Cart, LitExtension, Matrixify-Konnektoren) kennt Ihr Schema. Die Daten herauszubekommen ist selbst ein Bau.
Die Extraktion kombiniert meist mehrere Wege: einen direkten Datenbank-Dump, was der Admin nach CSV exportieren kann, eine interne oder halb dokumentierte API und – als Notlösung für Inhalte und URLs – das Crawlen der Live-Site. Woher auch immer, die Daten landen unsauber und müssen normalisiert und validiert werden – in eine saubere, Shopify-förmige Struktur – bevor der Import via Matrixify-CSV oder Shopify Admin API läuft. Dieser mittlere Schritt ist die eigentliche Arbeit, denn ein Jahrzehnt Ad-hoc-Daten trägt die versteckte Steuer dieses Projekts: inkonsistente Formate, fehlende Felder, doppelte Kunden, Preise auf drei Arten gespeichert und „temporäre“ Fixes, die dauerhaft wurden. Räumen Sie beim Import auf, sonst erben Sie das Chaos auf einer glänzenden neuen Plattform.
Machen Sie eine Proof-of-Concept-Extraktion auf einem kleinen Ausschnitt – ein paar hundert Produkte mit Varianten, Kunden und Bestellungen – in Woche eins, nicht in Monat drei. Es ist der schnellste Weg herauszufinden, was das Schema wirklich enthält statt was das Team glaubt – und macht aus Unbekannten einen scopebaren Plan, bevor Budgets festgelegt sind.
Das Unbekannte mappen: eine Discovery-first-Methode
Weil das Risiko die Unbekannten sind, wird eine Custom CMS zu Shopify Migration in der Discovery gewonnen oder verloren. Das Ziel der Discovery ist, „wir sind nicht sicher, wie das funktioniert“ in eine dokumentierte Entscheidung zu verwandeln. Vier Unbekannte müssen entschärft werden, bevor jemand einen Zeitplan zusagt.
- Das Datenmodell. Reverse-Engineeren Sie das Schema: dumpen Sie die Datenbank und mappen Sie ihre Tabellen auf Shopifys Objekte – Produkte, Varianten, Kunden, Bestellungen, Collections. Eigene Attribute werden zu Metafeldern und Metaobjekten.
- Die Geschäftsregeln. Die teure Logik – wie Preise, Steuern, Rabatte, Versand und Fulfilment tatsächlich funktionieren – steckt meist im Code, nicht in Docs. Befragen Sie das Team und lesen Sie die Code-Pfade; nehmen Sie an, dass nichts Standard ist, bis es bewiesen ist.
- Die URL-Struktur. Ein Custom-Build hat keine Redirect- oder Rewrite-Tabelle zum Exportieren. Die URLs finden Sie, indem Sie die Site crawlen und Server-Logs, die XML-Sitemap und die Google Search Console kombinieren (mehr dazu unten).
- Die Integrationen. Jeder maßgeschneiderte Konnektor – ERP, PIM, OMS, Zahlung, Steuern, E-Mail, Webhooks – muss erfasst und einer Shopify-App, nativen Funktion oder Custom App zugeordnet werden. Übersehen Sie einen, bricht nach dem Launch still etwas.
Für jeden Punkt klassifizieren Sie jedes Feature und jeden Datensatz als behalten, ersetzen oder streichen. Behalten Sie, was seinen Platz verdient, ersetzen Sie maßgeschneiderten Code wo möglich durch eine native Funktion oder App, und streichen Sie den angesammelten Ballast, den niemand nutzt. Diese Triage macht aus einer einschüchternden Blackbox ein scopebares, schätzbares Projekt.
Was tatsächlich umzieht – sobald Sie es lesen können
Nach Discovery und Extraktion sind die Daten, die bei einer Custom CMS zu Shopify Migration umziehen, weitgehend dieselben wie bei jeder Migration – der Unterschied ist der Aufwand, sie erst sauber und lesbar zu machen. Hier die praktische Aufteilung.
| Daten / Feature | Migrations-Realität |
|---|---|
| Produkte, Varianten, SKUs, Bilder | Ziehen nach Extraktion und Normalisierung um |
| Eigene Produktattribute | Als Metafelder und Metaobjekte neu bauen |
| Collections / Kategorien | Neu erstellen; Struktur neu denken statt kopieren |
| Kunden (Profile, Adressen) | Migrieren; Passwörter niemals |
| Bestellhistorie | Für Reporting/Retouren importieren; Alt-DB read-only |
| CMS-Inhalte, Blogs, Landingpages | In Shopify-Seiten/Sektionen neu bauen; via API |
| Medien / digitale Assets | Neu hochladen; Asset-URLs im Content anpassen |
| Rabatte, Gutscheinkarten, Guthaben | Neu erstellen; Beträge/Codes übertragen selten |
| Maßgeschneiderte Features | Neu ausdrücken (nativ / App / Functions / Custom App) |
| Frontend / Theme | Kein Äquivalent; auf Online Store 2.0 oder Hydrogen neu |
Zwei Konstanten. Kundenpasswörter ziehen nie um – sie sind einweg gehasht, Kunden setzen also beim ersten Login zurück; planen Sie die Kommunikation und rechnen Sie mit einer „Ich komme nicht rein“-Welle in den ersten 48 Stunden. Und Datenqualität ist der eigentliche Budgetposten, nicht die Zeilenzahl: Ein kleiner, sauberer Katalog zieht schneller um als ein großer, chaotischer, die Normalisierung ist also der Ort, an dem Zeit wirklich verbraucht wird.
Eine Eigenentwicklung ist von außen am schwersten zu scopen. Starten Sie mit Discovery, nicht mit einem Rateschluss.
Ihre Custom-Features auf Shopify neu bauen
Die Angst hinter den meisten Custom CMS zu Shopify Migrationen ist „Shopify kann unser Spezial-Feature nicht“. Meist kann es das – die Frage ist nur, wo das Feature landet. Arbeiten Sie die Leiter von am günstigsten und wartbarsten bis zu am stärksten maßgeschneidert ab und steigen Sie nur ab, wenn die Stufe darüber es wirklich nicht kann.
- Zuerst natives Shopify. Rabatte, Gutscheinkarten, Markets und jetzt natives B2B auf Shopify Plus decken enorm viel ab, was Custom-Builds von Hand codierten. Prüfen Sie hier, bevor Sie irgendetwas als custom annehmen.
- Dann eine App. Subscriptions, Reviews, Loyalty, erweiterte Filter und tausende andere Bedürfnisse sind reife, gepflegte Apps – von tausenden Shops erprobt statt allein von Ihnen gewartet.
- Dann Shopify Functions. Eigene Rabatt-, Versand- und Zahlungslogik, die früher einen maßgeschneiderten Checkout brauchte, ist jetzt nativ und performant über Shopify Functions.
- Dann eine Custom App. Wirklich maßgeschneiderte Backoffice-Logik und Integrationen werden als private/Custom App auf der Admin API gebaut – Ihr Code, aber auf gemanagter Infrastruktur und mit Standard-Tooling, für das Sie einstellen können.
- Headless zuletzt. Ist das Storefront-Erlebnis selbst der Unterschied, gibt Hydrogen ein eigenes Frontend auf Shopifys gemanagtem Commerce-Backend – die Flexibilität von Custom, ohne die Infrastruktur zu besitzen.
Auf einer Custom-Plattform ist jedes Feature Ihr Code zum Bauen und Warten. Auf Shopify wandern die meisten die Leiter hinauf in native Funktionen oder gepflegte Apps, und nur die wirklich differenzierende Logik bleibt Ihre. Diese Reduktion der Angriffsfläche – weniger Dinge, die nur Sie am Leben halten müssen – ist oft der größte langfristige Gewinn der ganzen Migration.
SEO schützen, wenn niemand die URLs erfasst hat
Jede Migration ist ein Site-Umzug, aber eine Custom CMS zu Shopify Migration hat eine einzigartige SEO-Gefahr: Es gibt keine Rewrite-Tabelle zum Exportieren, Sie kennen also vielleicht nicht einmal alle URLs, die aktuell ranken. Sie können nicht umleiten, was Sie nicht gefunden haben, und nicht umgeleitete URLs sind verlorene Rankings. Die Ermittlung des URL-Sets ist die Aufgabe, und es lohnt sich, das mit einem sauberen SEO Audit als Baseline zu beginnen.
- Stellen Sie die volle URL-Liste aus mehreren Quellen zusammen, weil keine allein vollständig ist: Crawlen Sie die Live-Site, ziehen Sie Server-Access-Logs, exportieren Sie die XML-Sitemap und durchforsten Sie die Google Search Console nach jeder URL mit Impressionen.
- Bauen Sie eine 1:1-301-Redirect-Map von dieser kombinierten Liste auf jede spezifische neue Shopify-URL. Custom-URL-Muster passen selten zu Shopifys Struktur, die meisten URLs ändern sich also und die Map leistet die Hauptarbeit.
- Übertragen Sie Metadaten – Titel, Beschreibungen, Überschriften, Canonicals – und erhalten Sie interne Verlinkung und Informationsarchitektur, wo sie Rankings verdient haben.
- Stellen Sie Content-Parität her. Maßgeschneiderte Landingpages und Blog-Inhalte müssen auf Shopify unter einer gemappten URL existieren, nicht still verschwinden.
- Reichen Sie am ersten Tag eine saubere Sitemap ein und beobachten Sie die Search Console zwei Wochen täglich; ein kurzer Einbruch, während Google die Redirects neu verarbeitet, ist normal, und Lücken zeigen sich als 404 im Abdeckungsbericht.
Als strukturierter Site-Umzug behandelt, halten Rankings und erholen sich oft schnell; als nachträglicher Gedanke ist eine Custom-Migration die am leichtesten blutende von allen – gerade weil die URLs nie aufgeschrieben wurden. Google beschreibt Website-Umzüge mit URL-Änderungen in seiner offiziellen Search-Dokumentation, und es lohnt sich, dem genau zu folgen.
Wie die Migration abläuft
Eine Custom CMS zu Shopify Migration ist vorne mit Discovery und hinten mit sorgfältigem Cutover beladen. Die Reihenfolge, die ein unbekanntes System davon abhält, beim Launch Überraschungen zu produzieren:
- Discovery und Audit. Reverse-Engineeren Sie das Datenmodell, dokumentieren Sie die Geschäftsregeln, erfassen Sie Integrationen und Features und stellen Sie die volle URL-Liste zusammen. Klassifizieren Sie alles behalten / ersetzen / streichen und definieren Sie Erfolg in Zahlen.
- Proof-of-Concept-Extraktion. Ziehen Sie früh einen kleinen, repräsentativen Ausschnitt echter Daten, um das Schema zu validieren und Datenqualitätsprobleme aufzudecken, bevor sie teuer werden.
- Architektur- und Feature-Entscheidungen. Mappen Sie Daten auf Shopify-Objekte und Metafelder und platzieren Sie jedes Custom-Feature auf der Leiter (nativ, App, Functions, Custom App, Headless).
- Parallel bauen. Bauen Sie die Storefront auf Online Store 2.0 oder Hydrogen neu, während der Shop weiter verkauft, und entwickeln Sie die Apps oder Functions, die die Feature-Map verlangte.
- Volle Datenmigration. Extrahieren, normalisieren, validieren und importieren Sie in Abhängigkeitsreihenfolge – Produkte, Collections, Kunden, Bestellungen, Inhalte – und gleichen Sie Anzahlen mit der Quelle ab.
- Redirects, QA und Cutover. Bauen Sie die 1:1-301-Map, QA jedes Template und den Checkout auf Desktop und Mobile, stellen Sie dann DNS mit Rollback-Plan um und reichen Sie die neue Sitemap ein.
- Hypercare. Beobachten Sie Bestellungen, Checkout, Rankings und Fehler zwei Wochen täglich, mit der alten Datenbank read-only als Referenz und Retouren-Fallback.
Führen Sie die Proof-of-Concept-Extraktion in Woche eins durch. Auf einer dokumentierten Plattform können Sie dem Schema vertrauen; auf einer Eigenentwicklung nicht, und die PoC verwandelt die größte Unbekannte des Projekts – „was ist da eigentlich drin?“ – in einen Plan, den Sie kalkulieren und dem Sie vertrauen können.
Was es kostet und wie lange es dauert
Eine Custom CMS zu Shopify Migration ist von außen am schwersten zu beziffern, weil die Kosten von den Unbekannten getrieben werden, nicht vom Katalog. Drei Dinge bewegen die Zahl: wie viel Discovery und Reverse-Engineering das undokumentierte System braucht, wie viele maßgeschneiderte Features neu gebaut werden müssen (und wie weit unten auf der Leiter sie landen) und wie viel Aufräumen die Datenqualität verlangt. Ein sauberer, gut verstandener Build ist ein überschaubares Projekt; ein wuchernder, undokumentierter mit viel Custom-Logik ist ein großes. Der Katalog selbst ist selten der teure Teil.
Dem gegenüber steht die Kostenseite des Bleibens, die leicht unterschätzt wird: Wartung, Sicherheit und Key-Person-Risiko einer Eigenentwicklung summieren sich mit der Zeit. Shopifys eigene Time-to-Value-Forschung berichtet, dass Migrationen zu Shopify im Schnitt schneller, günstiger und pünktlicher abschließen als das Weiterbauen auf einer Custom-Plattform – und dass die laufenden Plattform- und Betriebskosten von Custom-Builds tendenziell höher liegen. Behandeln Sie das als anbieterseitige Angaben, aber die Richtung deckt sich mit dem, was Teams konsistent feststellen: Eine gemanagte Plattform gibt das Budget frei, das ein Custom-Stack still verschlingt. Holen Sie ein auf Ihren konkreten Build gescoptes Angebot, keinen Plattform-Durchschnitt.
Was Marken nach dem Verlassen eines Custom-Builds gewonnen haben
Reale Migrationen schlagen Theorie. Zwei gut dokumentierte Wechsel von Eigenentwicklungen und Legacy-Plattformen zeigen das Muster – die Details unten sind die selbst berichteten Ergebnisse der Unternehmen, via Shopifys Fallstudien, keine Garantien:
- Westwing, der europäische Home-&-Living-Händler, hatte rund ein Jahrzehnt eine eigene interne Plattform gebaut, brauchte aber etwas, das skalieren und Expansion tragen konnte. Nach der Migration zu Shopify berichtete das Unternehmen, in etwa einem Jahr über alle 12 Märkte ausgerollt zu haben – der erste Store in unter drei Monaten live, jeder neue Markt schneller zu replizieren als der letzte.
- Bombas replatformte, nachdem unzuverlässige Infrastruktur unter Last einen Checkout-Ausfall und Umsatzverlust verursachte. Das Unternehmen berichtete, dass sich die Migration schnell auszahlte – mit deutlich gesenkten Plattformkosten im ersten Jahr und der Skalierbarkeit und dem Spielraum, den der alte Stack nicht bieten konnte.
Der rote Faden ist nicht das Logo. Jedes behandelte die Migration als strukturiertes Programm – das alte System verstehen, entscheiden, was bleibt, bewusst neu bauen, SEO und Checkout schützen, eng monitoren – und wechselte aus einem konkreten Grund: Skalierung, Zuverlässigkeit, Kosten oder Tempo. Saubere Migrationen halten zudem meist die Rankings und können sie ausbauen, sobald der Shop stabil ist – genau das Ergebnis, das unsere Shopify SEO-Arbeit schützen und ausbauen soll.
Fazit
Eine Custom CMS zu Shopify Migration ist aus einem bestimmten Grund schwer: Sie bewegen ein System, das niemand vollständig dokumentiert hat, dessen Daten keinen Export haben und dessen Regeln im Code stecken. Aber diese Schwierigkeit ist beherrschbar, wenn Sie die übliche Reihenfolge umkehren – mit Discovery und einer Proof-of-Concept-Extraktion beginnen, jede Unbekannte in eine dokumentierte Entscheidung verwandeln, maßgeschneiderte Features die Leiter hinauf neu bauen statt zu portieren, und das undokumentierte URL-Set als eigenes SEO-Projekt behandeln. Tun Sie das, und der Gewinn ist der, den Custom-Plattform-Teams am meisten wollen: ein schneller, sicherer, skalierbarer Shop, der sich selbst wartet – mit der Entwicklungszeit, die Sie früher fürs Am-Laufen-Halten aufwendeten, frei für das, was das Geschäft wirklich wachsen lässt.
Zusammenarbeit mit Skalum
So führt Skalum eine Custom CMS zu Shopify Migration durch
Wir führen jede Custom CMS zu Shopify Migration als ein gemanagtes Projekt durch – Discovery, Extraktion, Architektur, Aufbau, Redirects, QA, Launch und Monitoring – nicht als Datenübergabe. Da eine Eigenentwicklung kein Playbook hat, liegt der Wert in der Methode: die Unbekannten zuerst entschärfen, die Daten früh beweisen und bewusst neu bauen. So läuft ein Projekt bei uns.
Es beginnt mit Discovery, nicht mit einem Angebot
Ein Custom-Build lässt sich von außen nicht seriös beziffern, wir beginnen also mit einer schlanken Discovery: Wir untersuchen Ihre Datenbank, Ihren Tech-Stack und Ihre maßgeschneiderte Funktionalität, reverse-engineeren das Datenmodell, erfassen jede Integration und jedes Feature und stellen die volle URL-Liste aus Crawl, Logs und Search Console zusammen. Sie erhalten einen dokumentierten Umfang, einen Feature-für-Feature-Plan und einen realistischen Zeitplan. Starten über unsere Shopify Migration Agentur.
Wir beweisen die Daten, bevor wir ein Datum versprechen
Jede Custom-Migration enthält eine frühe Proof-of-Concept-Extraktion. Wir ziehen einen repräsentativen Ausschnitt echter Produkte, Varianten, Kunden und Bestellungen, normalisieren und importieren ihn in einen Test-Shopify-Store und zeigen Ihnen das Ergebnis – damit die Überraschungen des Schemas in Woche eins auftauchen, nicht beim Launch. Es ist der wirksamste Weg, eine Eigenentwicklung zu entschärfen.
Wir entscheiden, wo jedes Feature landet
Was eine Custom-Migration leise bricht, ist die Annahme, ein maßgeschneidertes Feature müsse maßgeschneidert bleiben. Wir platzieren jedes auf der Leiter – nativ, App, Shopify Functions, Custom App oder Headless mit Hydrogen – und wählen die wartbarste Option, die die Aufgabe voll erfüllt, damit Sie mit weniger eigenem Code herauskommen, nicht mit mehr.
Wir schützen die SEO, die Ihre undokumentierten URLs verdient haben
Da ein Custom-Build keine Rewrite-Tabelle hat, behandeln wir die URL-Ermittlung als erstklassige Aufgabe: Crawl, Logs, Sitemap und Search Console kombiniert zu einer vollständigen 1:1-301-Map, mit übernommenen Metadaten und einer Storefront, die für Speed und Klarheit neu gebaut statt geklont wird – die Disziplin hinter unserem SEO Audit, Shopify Pagespeed Audit und CRO Audit. Sauber gemacht, halten die Rankings durch den Launch.
Nach dem Launch besitzen Sie weniger und wachsen mehr
Die Migration ist eine einmalige Umsetzung mit 30 Tagen Monitoring, der alten Datenbank read-only als Fallback und einer sauberen Übergabe des Daten-Mappings, der Redirect-Map und jeder Feature-Entscheidung. Viele Marken gehen danach in laufende Shopify SEO über und verwandeln das Budget, das früher Custom-Wartung finanzierte, in Wachstumsarbeit.
Ein Team, verantwortlich für Discovery, Daten, Features, SEO und Launch, das die schwersten Unbekannten beweist, bevor es ein Datum zusagt. So macht man die am wenigsten planbare Migration planbar.
Stecken Sie fest bei einer Plattform, die nur Ihr Team versteht? Machen wir sie zum Problem von jemand anderem.
Häufig gestellte Fragen
Es ist der Umzug eines Onlineshops von einer selbst gebauten, internen oder proprietären E-Commerce-Plattform auf Shopify. Anders als bei einer bekannten Plattform gibt es kein Export-Tool und kein dokumentiertes Schema, die Daten müssen also reverse-engineert und mit eigenen Skripten extrahiert werden, bevor sie normalisiert und in Shopify importiert werden.
Bekannte Plattformen haben dokumentierte Datenmodelle und etablierte Migrations-Tools; jemand hat es schon gemacht. Eine Eigenentwicklung hat ein undokumentiertes Schema, Geschäftsregeln im Code und oft niemanden mehr, der sie versteht. Die Schwierigkeit sind die Unbekannten, deshalb kommen Discovery und eine Proof-of-Concept-Extraktion zuerst.
Man kombiniert Quellen: einen direkten Datenbank-Dump, jeden Admin-CSV-Export, eine interne oder teils dokumentierte API und das Crawlen der Live-Site für Inhalte und URLs. Die extrahierten Daten werden dann in Shopifys Struktur normalisiert und validiert und via Matrixify oder die Shopify Admin API importiert.
Fast immer, auch wenn variiert, wo ein Feature landet. Arbeiten Sie eine Leiter ab: zuerst natives Shopify, dann eine App, dann Shopify Functions für eigene Checkout-Logik, dann eine Custom App auf der Admin API und Headless mit Hydrogen nur, wenn die Storefront selbst der Unterschied ist. Die meisten Features landen oberhalb von reinem Headless.
Nur, wenn die URLs nicht gemappt werden. Eine Eigenentwicklung hat keine Rewrite-Tabelle, Sie ermitteln also zuerst jede rankende URL aus Crawl, Server-Logs, Sitemap und Google Search Console und leiten jede per 301 auf ihre neue Shopify-URL. Als strukturierter Site-Umzug behandelt, halten die Rankings und erholen einen kurzen Einbruch.
Kundenprofile, Adressen und Bestellhistorie können migriert werden, Passwörter jedoch nicht, weil sie als Einweg-Hashes gespeichert sind. Kunden setzen ihr Passwort beim ersten Login im neuen Shopify-Store neu, planen Sie also eine klare Kommunikations-E-Mail und rechnen Sie mit kurzen Login-Fragen in den ersten Tagen.
Es hängt davon ab, wie dokumentiert der Build ist, wie viele Custom-Features neu gebaut werden müssen und wie sauber die Daten sind. Ein gut verstandener Build kann in ein paar Monaten umziehen; ein großer, undokumentierter mit viel Custom-Logik und chaotischen Daten braucht mehrere. Discovery und Feature-Neuaufbau treiben den Zeitplan, nicht der Katalog.
Die Kosten werden von den Unbekannten getrieben, nicht vom Katalog: die Tiefe der nötigen Discovery, die Zahl der neu zu bauenden Custom-Features und der nötige Datenaufwand. Ein sauberer, gut dokumentierter Build ist ein überschaubares Projekt; ein wuchernder, undokumentierter ein großes. Es sollte nach der Discovery beziffert werden, nicht aus einer Vorlage.
Wenn der Custom-Teil wirklich Ihr Wettbewerbsvorteil ist, etwa ein ungewöhnliches Marktplatz- oder Logistikmodell, kann ein Custom- oder Headless-Build gerechtfertigt sein. Ist es eher Infrastruktur, die Ihnen zufällig gehört, gewinnt die Migration zu Shopify fast immer, weil Sie Wartung, Sicherheit und das Einstellen für eine nur intern verstandene Plattform beenden.
Ja. Der Shopify-Store wird parallel gebaut, befüllt und getestet, während die Custom-Plattform weiter handelt; der Wechsel passiert am Cutover, wenn DNS auf Shopify zeigt. Es ist zudem klug, die alte Datenbank nach dem Launch eine Weile read-only zu halten, als Referenz und weil Retouren alter Bestellungen nicht aus Shopify verarbeitet werden können.
Vladyslav Kharkivskyi
