Replatforming auf Shopify: Realistische Zeitpläne und versteckte Kosten

Die meisten Agentur-Angebote für ein Replatforming auf Shopify wirken überschaubar. Eine saubere Zeitplanung, ein klar definierter Scope, ein festes Budget. Was sie nicht zeigen: wie häufig genau das Projekt, das auf dem Papier abgeschlossen war, den Händler noch weitere sechs Monate Geld gekostet hat, manchmal länger, nach dem offiziellen Launch.

Ein Replatforming ist eine der folgenreichsten Entscheidungen, die ein etablierter Händler trifft. Gut gemacht, legt es das Fundament für das nächste Jahrzehnt Wachstum. Eng gefasst, schafft es eine andere Art von Altlasten als die, die es eigentlich lösen sollte. Dieser Artikel zeigt, wie ein realistisches Replatforming aussieht, wie lange es wirklich dauert, wo die versteckten Kosten liegen und warum die wichtigsten Gespräche über eine Migration stattfinden, bevor eine einzige Zeile Code geschrieben wird.

---

Warum so viele Replatformings nicht halten, was sie versprechen

Die Replatforming-Geschichte, die Händler von Agenturen hören, klingt meist so: „Wir migrieren deine Daten, bauen einen neuen Shopify-Store, launchen ihn – und fertig." Die Geschichte, die Händler tatsächlich erleben, klingt meist so: „Wir sind live gegangen, und dann haben wir sechs Monate damit verbracht, Dinge zu reparieren, die nie wirklich fertig waren."

Die Lücke zwischen diesen beiden Geschichten ist keine böse Absicht, es ist Scope. Eine Migration, die als technisches Projekt definiert wird (Daten migrieren, Seite bauen, live gehen), enttäuscht regelmäßig. Eine Migration, die als Transformation der Geschäftsprozesse verstanden wird (Daten migrieren, Integrationen neu aufbauen, SEO erhalten, Teams schulen, Betrieb stabilisieren), ist das, was einen funktionierenden Store tatsächlich durch einen funktionierenden Store ersetzt.

Genau diese Lücke zwischen den beiden Definitionen ist das, worum es in diesem Artikel wirklich geht.

Die realistische Zeitplanung

Realistische Replatforming-Zeitpläne hängen weniger von der Store-Größe ab als von der operativen Komplexität. Hier sind ehrliche Bandbreiten für die drei Kategorien, in die Händler typischerweise fallen.

Kleine bis mittelgroße D2C-Stores (unter 2 Mio. € Jahresumsatz, einfacher Katalog, 1–2 Integrationen)

Realistische Dauer: 8–14 Wochen vom Kick-off bis zum stabilen Launch.

Das ist der sauberste Fall. Die Daten sind überschaubar, die Integrationen gängig (Klaviyo, Meta Pixel, GA4, ERP), und das Storefront kann mit einem Custom Theme ohne ungewöhnliche Anforderungen aufgebaut werden. Der Großteil der Zeit fließt in sauberes SEO-Migrations-Planning, Theme-Entwicklung und Testing – nicht in die eigentliche Datenmigration.

Etablierte Mid-Market-Stores (2–20 Mio. € Umsatz, größerer Katalog, mehrere Integrationen, ggf. B2B oder international)

Realistische Dauer: 4–7 Monate vom Kick-off bis zum stabilen Launch.

Hier finden die meisten Replatformings statt. Der Katalog trägt Jahre an gewachsener Komplexität, Produktvarianten, Kundengruppen, individuelle Preislogik, regionsspezifische Daten. Die Integrationen vervielfachen sich: ERP, PIM, Marketing-Automation, Customer-Service-Tools, Payment-Gateways über mehrere Regionen. Jede Integration braucht ihre eigene Discovery-, Mapping- und Testphase. Der Launch selbst ist nicht der schwierige Teil, die operative Bereitschaft drumherum ist es.

Enterprise oder operativ komplexe Stores (20 Mio. €+ Umsatz, B2B-lastig, Multi-Region, individuelle Workflows)

Realistische Dauer: 6–12+ Monate vom Kick-off bis zum stabilen Launch.

In dieser Größenordnung überlappt sich das Replatforming mit umfassenderen operativen Veränderungen. Individuelle Beschaffungs-Workflows, Multi-Warehouse-Logistik, regionale Steuerlogik, B2B-Preistufen über mehrere Märkte, nichts davon lässt sich einfach „rüberheben". Es muss für die Funktionsweise von Shopify Plus neu konzipiert werden, was häufig bedeutet, Prozesse zu überdenken, die ursprünglich um die Eigenheiten von Magento oder einer anderen Legacy-Plattform herum gebaut wurden.

Jede Agentur, die einen Zeitplan am unteren Ende dieser Bandbreiten verspricht, verdient kritische Prüfung. Geschwindigkeit auf Kosten operativer Bereitschaft ist keine Geschwindigkeit, es sind aufgeschobene Kosten.

Die fünf versteckten Kostenkategorien

Die meisten Replatforming-Budgets erfassen die sichtbare Arbeit: Theme-Entwicklung, Datenmigration, Integrations-Setup, Projektmanagement. Die versteckten Kosten leben in den folgenden Kategorien, und sie entscheiden darüber, ob das Projekt am Ende echten Wert geliefert hat oder einfach nur eine neue Website.

1. Datenkomplexität jenseits der Oberfläche

Jeder Händler nimmt an, seine Daten seien überschaubar, bis er sie sich genauer anschaut. Was in einer typischen Magento- oder WooCommerce-Datenbank lebt, sind selten nur Produkte, Kunden und Bestellungen. Es ist auch:

• Jahre an Produktattributen, die ad hoc hinzugefügt wurden und jetzt in verschiedenen Kategorien Unterschiedliches bedeuten
• Kundengruppen, B2B-Stufen und Preisregeln, die über Jahre ohne Dokumentation aufgebaut wurden
• Bestelldaten mit individuellen Feldern, die geschäftskritische Informationen außerhalb des Standardschemas erfassen
• Subscription-Historien, Treuepunkte-Stände, Store Credit, Geschenkgutschein-Salden
• Kundenbewertungen, Sterne-Ratings und Q&A, häufig in Drittanbieter-Erweiterungen gespeichert
• SEO-Redirects, individuelle URL-Strukturen und Metadaten, die über viele Produkt-Launches hinweg gewachsen sind

Das sauber auf Shopify zu mappen, erfordert echte Analyse, kein One-Click-Migrations-Tool. Die Kosten zeigen sich, wenn eine Agentur zwei Wochen für die Datenmigration budgetiert und in Woche drei feststellt, dass 40 % des Katalogs individuelle Attribute haben, die neu gedacht werden müssen. Das ist der häufigste Grund, warum Migrations-Timelines kippen, und der am leichtesten zu unterschätzende.

2. SEO-Erholung, die nicht im Plan stand

Das ist die Kostenkategorie, die am meisten weh tut, weil sie unsichtbar ist, bis es zu spät ist. Ein Replatforming, das SEO nicht von Tag eins als erstrangige Aufgabe behandelt, verliert organischen Traffic, meist zwischen 20 % und 50 %, in den Monaten nach dem Launch. Für einen etablierten Händler bedeutet das einen sechsstelligen oder höheren Umsatzverlust über das Jahr verteilt.

Die Arbeit, die das verhindert, ist nicht optional, auch wenn viele Angebote sie als „nice to have" behandeln:

• Eine vollständige URL-Inventur der bestehenden Seite, inklusive aller indexierbaren Seiten
• Eine komplette 301-Redirect-Map von alten auf neue URLs, inklusive Produktseiten, Kategorieseiten, Blog-Posts und Edge Cases wie Filterkombinationen und facettierter URLs
• Erhalt von Canonical-Strukturen, Schema-Markup und Metadaten
• Sitemap-Generierung und sofortige Einreichung in der Search Console beim Launch
• Crawl-Monitoring für die ersten 90 Tage, um kaputte Redirects und Indexierungsprobleme zu erkennen, bevor sie sich potenzieren

Nichts davon ist glamourös, und nichts davon taucht im Portfolio-Screenshot auf. Aber genau das ist der Unterschied zwischen einem Launch, der Umsatz hält, und einem, der sich langsam aus einem Traffic-Krater erholt.

3. Integrations und Erweiterungs-Rebuild

Jede Integration auf der bestehenden Plattform muss gegen drei Optionen auf Shopify geprüft werden: native Funktion, vorhandene App oder Custom-Entwicklung. Der Händler, der annimmt, dass sich alles sauber als „dafür gibt's eine Shopify-App" abbilden lässt, wird in der Regel überrascht.

Wo die wahren Kosten leben:

• Die 80-Prozent-Lösungen. Eine Shopify-App, die das meiste abdeckt, was die Magento-Erweiterung konnte, aber nicht die spezifische Business-Logik, von der der Händler abhängt. Die Lösung ist meist ein Custom-Development-Projekt, das nicht im ursprünglichen Scope war.
• Die Integration, die niemand erwähnt hat. ERP, PIM, Buchhaltung, Warehouse-Management, jedes hat eigene Connector-Anforderungen. Händler stellen oft mitten im Projekt fest, dass ihre Buchhaltungs-Integration Custom-Entwicklung braucht, weil der Standard-Connector ihr Steuer-Setup nicht abbildet.
• Der Datenfluss, den niemand dokumentiert hat. Der individuelle Workflow, den jemand vor drei Jahren gebaut hat, den niemand im aktuellen Team vollständig versteht. Auf der alten Plattform funktioniert er, weil er seit Jahren läuft; er muss aus beobachtetem Verhalten rekonstruiert werden, nicht aus Dokumentation, die es nicht gibt.
• Marketing-Tools und Tracking. Klaviyo-Flows, Meta-Pixel-Events, GA4-Conversion-Tracking, Attributionsmodelle, alle müssen gegen die neue Seitenstruktur neu aufgebaut werden, häufig mit subtilen Unterschieden, die die Vergleichbarkeit der Reports über Monate beeinträchtigen.

4. Das unvollständige Replatforming

Das ist die Kostenkategorie, über die am wenigsten gesprochen wird, und die am meisten zählt: die Migration, die technisch live gegangen ist, aber tatsächlich nicht fertig ist. Der neue Store ist online, die Agentur hat eingepackt, und jetzt flickt der Händler in der Produktion herum, unter Druck, mit echten Kunden, die zuschauen, während das operative Team die neue Plattform noch lernt.

Wie „unvollständig" wirklich aussieht:

• Post-Launch-SEO-Triage. Redirect-Maps, in denen Produkt-URLs fehlen, kaputte Canonical-Tags, fehlendes Schema, eine Sitemap, die nicht rechtzeitig eingereicht wurde. Der Traffic bricht ein, bevor jemand das Muster erkennt. Die Erholung dauert Monate.
• Integrationen, die „so halb" funktionieren." Der ERP-Sync, der zwar feuert, aber still 2 % der Bestellungen verliert. Der Payment-Provider, der bucht, aber nicht abstimmt. Die Versand-Integration, die bei bestimmten Gewichtsklassen falsch kalkuliert. Diese Dinge werden über Kundenbeschwerden gefunden – nicht im QA.
• Dateninkonsistenzen, die erst Wochen später auffallen. Kunden rufen an, weil die Bestellhistorie fehlt, Subscription-Zyklen kaputt sind, Treuepunkte verloren wurden, Reviews nicht migriert wurden. Jeder Fall einzeln klein, aber zusammen ergeben sie einen Support-Stau und ein Vertrauensproblem.
• Theme-Bugs, die nur unter echtem Traffic auftauchen. Varianten-Logik, die bei Kombinationen bricht, die nie getestet wurden. Mobile-Checkout-Edge-Cases. Währungsrundungsfehler. B2B-Preise, die versehentlich für D2C-Kunden sichtbar sind. Von Kunden gefunden, unter Druck repariert.
• Operative Features, von denen angenommen wurde, sie seien live. Inventar-Sync zwischen Standorten, automatische Steuer-Updates, Retouren-Flow, Customer-Service-Tools. „Das klären wir nach dem Launch" wird zu Monaten operativer Schmerzen.
• Die Dokumentationslücke. Das Team, das den alten Store betrieben hat, weiß nichts darüber, wie der neue funktioniert. Schulung war ein Nachgedanke. Jede Admin-Aufgabe dauert das Vierfache im ersten Quartal.
• Das „fehlende App"-Problem. Drei Monate nach Launch fällt jemandem auf, dass eine kritische Erweiterung der alten Plattform nie ersetzt wurde. Bis dahin ist der Workflow die ganze Zeit kaputt gewesen, und niemand hat es bemerkt.

Das Muster hinter all dem ist dasselbe: Ein Replatforming wird häufig als technisches Projekt definiert, obwohl es eine Transformation der Geschäftsprozesse ist. Agenturen, die es eng definieren, treffen Launch-Termin und Budget, und lassen den Händler mit allem zurück, was nicht im Scope-Statement stand.

Ein seriöser Replatforming-Plan denkt das von Tag eins mit: eine definierte 30/60/90-Tage-Stabilisierungsphase, eine dokumentierte Übergabe, SEO-Monitoring für die ersten beiden Quartale, Integrations-QA gegen reale Traffic-Muster und klare Ehrlichkeit darüber, was nicht im Scope ist, damit der Händler später nicht überrascht wird.

Genau deshalb ist Retainer-basierter Post-Launch-Support kein Luxus, er ist die Art, wie eine Migration tatsächlich fertig wird. Das günstige Angebot ist nicht günstig; es ist nur frontlastig.

5. Interner Aufwand, den der Händler unterschätzt

Die Kostenkategorie, die in Migrations-Budgets am konsequentesten fehlt, ist die eigene Zeit des Händlers. Ein Replatforming ist nichts, was eine Agentur an einem Unternehmen macht, es ist etwas, was eine Agentur mit einem Unternehmen macht. Der Aufwand auf Händlerseite ist beträchtlich:

• Discovery-Interviews, um Workflows freizulegen, die niemand dokumentiert hat
• Entscheidungen über Kategorie-Strukturen, Produkt-Taxonomien, Kundensegmente
• Content-Review und Überarbeitungen für Produktbeschreibungen, Kategorieseiten, Policies
• Testing während des UAT, jede Funktion, jeder Workflow, jeder Edge Case
• Schulung des operativen Teams auf der neuen Plattform vor dem Launch
• Kunden-Kommunikation zur Umstellung (besonders bei B2B- und Subscription-Kunden)
• Management der Stabilisierungsphase nach dem Go-live

Ein Mid-Market-Replatforming braucht typischerweise 100–250 Stunden dedizierter Händler-Zeit, verteilt über das Projekt. Händler, die das nicht einplanen, überladen zwei Personen, die dann zum Engpass für die gesamte Migration werden.

Was bei SEO schiefgehen kann, und wie man es verhindert

SEO verdient einen eigenen kurzen Abschnitt, weil es gleichzeitig das schädlichste Risiko und das am besten vermeidbare ist. Das Muster bei jedem Replatforming, das einem Händler im SEO wehtut, ist dasselbe:

1. Redirects wurden von alten auf neue URLs angelegt, aber die Redirect-Map war unvollständig
2. Oder: Die Redirects waren vollständig, gingen aber auf die falschen Ziele (z. B. alte Produktseiten, die auf die Startseite umleiten, statt auf ihre neue Produktseite)
3. Oder: Die Redirects funktionierten, aber die neuen Seiten haben ihr Schema, ihre Metadaten oder ihre inhaltliche Tiefe verloren
4. Suchmaschinen crawlen erneut, finden kaputte Signale, stufen die betroffenen URLs herab
5. Die Erholung dauert Monate, weil Vertrauen erst wieder aufgebaut werden muss

Die Prävention ist nicht kompliziert, sie ist nur Arbeit, die vor dem Launch erledigt werden muss, nicht danach. Vollständige URL-Inventur, komplette Redirect-Map (jede alte URL zeigt auf ihr funktionales Äquivalent), Erhalt von Schema und Metadaten, Monitoring der Indexierung in den ersten 90 Tagen. Die Agenturen, die SEO-Migration als Häkchen behandeln, sind die, deren Händler das nächste Jahr mit Erholung verbringen. Die, die es als Kern-Deliverable behandeln, sind die, deren Launches dem organischen Umsatz keine Delle verpassen.

Realität bei Integrationen und Erweiterungen

Eine der häufigsten Fragen, die Händler uns in der Discovery-Phase stellen, lautet: „Kann Shopify das, was meine aktuelle Plattform kann?" Die ehrliche Antwort lautet: Fast immer ja, aber selten mit denselben Tools.

Die meisten Magento- oder WooCommerce-Stacks basieren auf einer Reihe von Erweiterungen, die jeweils einen Funktionsausschnitt abdecken. Das Shopify-Äquivalent ist normalerweise:

• Native Shopify-Funktion. Vieles, was auf Magento Drittanbieter-Erweiterungen erforderte, ist auf Shopify direkt eingebaut, Geschenkgutscheine, Warenkorb-Wiederherstellung, Multi-Currency, grundlegende Rabattlogik, Kundenkonten. Die Migration ersetzt eine Erweiterung durch eine native Funktion.
• Shopify-App-Store-Äquivalent. Für die meisten Kategorien, Reviews, Subscriptions, erweiterte Filter, Marketing-Automation, Loyalty-Programme, gibt es eine ausgereifte Shopify-App, die den Job erledigt. Meist mit besserer Integration in das Shopify-Ökosystem als die entsprechende Magento-Erweiterung.
• Custom-Entwicklung. Für wirklich einzigartige Business-Logik, proprietäre Preismodelle, individuelle B2B-Workflows, Integrationen mit branchenspezifischen Tools, beinhaltet die Migration den Bau der entsprechenden Funktionalität auf Shopify, häufig mit Shopify Functions, Custom Apps oder Theme-Level-Entwicklung.

Die Arbeit passiert in der Discovery-Phase: Jede Erweiterung auf der bestehenden Plattform wird geprüft und einer dieser drei Optionen zugeordnet, mit Kosten- und Zeitfolgen, die vor Migrationsbeginn auf den Tisch kommen. Agenturen, die diesen Schritt überspringen, sind die, deren Händler drei Monate später feststellen, dass ein kritisches Feature nie eingeplant war.

Wann du nicht replatformen solltest

Nicht jeder Store sollte migrieren. Ehrliche Gegenpunkte, die vor einer Entscheidung Beachtung verdienen:

• Du bist gerade in einer Peak-Umsatzphase. Ein Replatforming im Q4 für einen saisonal stark schwankenden Store ist eine Einladung für Probleme. Migrations-Fenster gehören in die traffic-ärmere Zeit des Jahres – mit mehreren Monaten Abstand zum nächsten Peak.
• Du hast gerade keine interne Kapazität. Eine Migration ohne dedizierte Händler-Zeit läuft nicht gut, egal wie gut die Agentur ist. Wenn dein Team gerade in einer Recruiting-Phase, einem Produkt-Launch oder einem Leadership-Wechsel steckt, verschiebe die Migration, bis du ihr die Aufmerksamkeit geben kannst, die sie braucht.
• Die aktuelle Plattform funktioniert, und der Kosten-Case ist grenzwertig. Wenn dein bestehender Store gut läuft, ein kompetentes Team dahintersteht und die Kostendifferenz zu Shopify gering ist, ist der Migrations-Case schwächer als das Marketing vermuten lässt. Replatforming dann, wenn es einen klaren strategischen Grund gibt – nicht, weil die neue Plattform neuer aussieht.
• Du hast noch nicht entschieden, was du eigentlich vom neuen Store willst. Replatforming verstärkt das, was du mitbringst. Ein Händler mit klarer Positionierung, sauberen Katalogdaten und einer definierten Customer Experience profitiert enorm. Ein Händler, der hofft, dass das Replatforming all das nebenbei klärt, ist meist enttäuscht.

Wie ein sauberes Replatforming wirklich aussieht

Replatformings, die gut laufen, folgen einem ähnlichen Muster:

1. Eine ehrliche Discovery-Phase: meist 2–4 Wochen, in denen die Agentur jeden Produkttyp, jedes Kundensegment, jede Integration und jeden Workflow kartiert. Das Ergebnis ist ein dokumentierter Plan mit explizitem Scope, Zeitplan und bekannten Risiken.
2. SEO-Migration als paralleler Workstream von Tag eins: nicht als Häkchen kurz vor dem Launch. URL-Inventuren, Redirect-Maps und Schema-Erhalt sind als Deliverables im Projektplan eingebaut.
3. Integrations-Mapping vor Entwicklungsbeginn: jede Erweiterung der aktuellen Plattform wird aufgelöst (nativ, App oder Custom), mit Kosten und Zeitrahmen, nicht vertagt.
4. Iteratives UAT, kein einwöchiges Testfenster: Testing passiert während des gesamten Builds, nicht zusammengequetscht in die Woche vor dem Launch.
5. Eine definierte Stabilisierungsphase: 30/60/90 Tage nach Launch sind Teil der Beauftragung, nicht eine separate Bitte. SEO-Monitoring, Integrations-QA, Bug-Triage und Team-Schulung passieren in diesem Fenster.
6. Dokumentation und Übergabe: das operative Team versteht die neue Plattform vor dem Launch, nicht drei Monate danach.

So sieht ein vollständiges Replatforming aus. Es ist langsamer als der optimistische Zeitplan, den ein vertriebsgetriebenes Angebot zeigt. Es ist auch die Version, die den Händler nicht noch weitere sechs Monate Geld kostet.

Fazit: Die eigentliche Frage ist nicht, ob du replatformen sollst

Die Entscheidung zu replatformen ist selten der schwierigste Teil. Die schwerere Frage ist, welche Art von Replatforming du dir einkaufst, die, die am Launch-Tag endet, oder die, die endet, wenn das Business auf der neuen Plattform sauber läuft.

Das sind zwei sehr unterschiedliche Projekte, und sie werden aus gutem Grund unterschiedlich bepreist. Die Gespräche, die es wert sind, vor jeder Vertragsunterschrift geführt zu werden, drehen sich um Scope-Ehrlichkeit: Was ist drin, was ist draußen, was passiert nach dem Launch, wer ist verantwortlich für die SEO-Erholung, wer übernimmt die Integrations-QA unter Realbedingungen – und wie sieht die 30/60/90-Tage-Stabilisierungsphase schriftlich aus.

Wenn diese Gespräche nicht von Anfang an auf dem Tisch liegen, ist die Lücke zwischen „wir sind fertig" und „das Business funktioniert wirklich" der Ort, an dem jedes Replatforming teuer wird.