Ein Shopsystem zu wechseln, klingt auf dem Papier nach einem technischen Upgrade. In der Praxis ist es eine der tiefgreifendsten Veränderungen im digitalen Kerngeschäft. Replatforming betrifft nicht nur Templates und Hosting, sondern Datenmodelle, Schnittstellen, Messbarkeit, Prozesse im Tagesgeschäft und oft auch die Art, wie Teams zusammenarbeiten. Wer dabei ausschließlich auf „Go-live schaffen“ optimiert, zahlt später mit Sichtbarkeitsverlusten, Tracking-Lücken oder operativem Chaos.
Typische Auslöser sind schnell wachsende Sortimente, neue Länder, steigende Wartungs- und Entwicklungsaufwände, Sicherheitsanforderungen oder eine Integrationslandschaft, die immer fragiler wird. Gleichzeitig ist der Wechsel häufig die Chance, alte Sonderlösungen zu entwirren, Datenqualität zu verbessern und Abläufe zu standardisieren. Ob das gelingt, entscheidet sich weniger am Systemnamen als an Planung, Verantwortlichkeiten und der Disziplin in den Details.
Was Replatforming ist und was nicht
Replatforming bedeutet, dass ein Shop auf eine neue Commerce-Plattform umzieht. Dabei ändern sich oft Kernlogiken, etwa wie Produkte und Varianten strukturiert sind, wie Preise berechnet werden oder wie Bestände und Bestellungen in Drittsysteme fließen. Auch ein Wechsel der URL-Struktur oder die Neuordnung von Kategorie- und Filterlogiken gehört typischerweise dazu.
Davon abzugrenenzen sind Projekte, die nur „oberflächlich“ wirken: ein reines Redesign, ein Theme-Wechsel ohne Änderungen an der Datenhaltung oder ein Update innerhalb derselben Plattform. Solche Maßnahmen können aufwendig sein, aber sie haben nicht die gleiche Sprengkraft wie eine Migration, bei der Daten, URLs, Tracking und Integrationen neu aufgesetzt werden.
Ziele, Scope und Erfolgskriterien: Der wichtigste Schritt vor dem ersten Export
Viele Migrationen scheitern nicht, weil ein System „schlecht“ ist, sondern weil Ziele zu vage bleiben. „Schneller werden“, „skalieren“ oder „modernisieren“ sind Motive, aber keine Kriterien für Entscheidungen. Vor allem bei Zeitdruck lohnt ein kurzer, harter Fragenblock:
Welche Business-Ziele sollen messbar besser werden?
Beispiele sind kürzere Time-to-Market für Kampagnen, stabile Performance bei Peaks, reibungsärmere Internationalisierung, geringere Betriebskosten oder eine messbar niedrigere Fehlerquote im Checkout. Wichtig ist, dass Teams festlegen, woran Erfolg später sichtbar wird, etwa an Conversion-Rate, Abbruchraten, Retourenquote, Supporttickets oder an der Stabilität von Datenflüssen.
Was gehört zwingend in Release 1 und was nicht?
Replatforming ist kein Wunschkonzert. Ein „Alles wie früher, nur neu“ wirkt auf den ersten Blick sicher, erzeugt aber oft ein Projekt, das sich aufbläht. Sinnvoller ist eine klare Definition dessen, was für Umsatz und Betrieb kritisch ist, plus eine Liste von Funktionen, die bewusst nachgelagert werden.
Welche Risiken sind akzeptabel und welche nicht?
SEO-Verluste, Tracking-Ausfälle oder Zahlungsprobleme sind nicht gleich kritisch. Ein Team braucht eine Priorisierung: Was darf kurzfristig schlechter werden, was auf keinen Fall? Daraus ergeben sich Testtiefe, Monitoring und Cutover-Strategie.
Datenmapping und Datenqualität: Die unsichtbare Sollbruchstelle
Shopmigrationen werden gern als „Daten kopieren“ missverstanden. In Wahrheit ist es eine Übersetzungsarbeit zwischen zwei Datenwelten. Produkte, Varianten, Attribute, Preise, Lagerlogik, Medien, Kundendaten und Bestellhistorien sind selten 1:1 kompatibel.
Produkt- und Variantendaten sauber übersetzen
Ein häufiger Stolperstein ist die Variantenlogik. Im alten System sind Varianten möglicherweise über frei definierbare Attribute abgebildet, im neuen System sind Optionen stärker strukturiert. Was im alten Shop als „Farbe = Rot“ gespeichert ist, kann im neuen Shop eine Option sein, die wiederum Auswirkungen auf URL-Parameter, Filter und Produktfeeds hat. Auch Statusfelder sind kritisch: „aktiv“, „archiviert“, „ausverkauft“, „vorbestellbar“ sind in Systemen unterschiedlich definiert und führen im schlimmsten Fall zu nicht kaufbaren, aber indexierten Seiten.
Datenqualität vor der Migration anheben
Duplikate, inkonsistente Schreibweisen, fehlende IDs, Sonderzeichen in SKU-Strukturen oder uneinheitliche Kategoriezuordnungen fallen im Betrieb kaum auf, werden in der Migration aber zum Projektkiller. Daher gehört ein Datenqualitäts-Audit früh in den Plan: Welche Felder sind Pflicht, welche sind historisch gewachsen, welche werden wirklich genutzt? Je klarer das vor dem Mapping ist, desto weniger Sonderfälle entstehen.
Historische Daten: Nutzen gegen Komplexität abwägen
Bestellhistorie und Kundenkonten sind wertvoll, erhöhen aber Komplexität und Datenschutzanforderungen. Nicht jede Historie muss im neuen Shop „live“ verfügbar sein. Manchmal reicht ein Archivzugriff über das ERP oder ein separates Reporting. Diese Entscheidung ist strategisch, nicht nur technisch.
SEO retten: URL-Logik, Redirects und Indexierungsdisziplin
Wenn URLs sich ändern, muss Suchmaschinen klar vermittelt werden, wo Inhalte künftig zu finden sind. Der Kern ist eine konsequente Redirect-Strategie mit permanenten serverseitigen Weiterleitungen pro alter URL auf die passende neue Zielseite. Pauschale Weiterleitungen auf die Startseite sind ein Klassiker, der Rankings und Nutzererwartungen gleichzeitig beschädigt.
URL-Design ist keine Nebensache
Die neue URL-Logik sollte so stabil wie möglich sein. Häufig lohnt es sich, das alte Muster in Teilen beizubehalten, selbst wenn das neue System andere Konventionen nahelegt. Jede ersparte URL-Änderung ist weniger Redirect-Aufwand, weniger Risiko und meist schnellere Stabilisierung in der Suche.
Mehr als 301: Canonicals, interne Links, Filter und Sprache
Redirects sind nur ein Teil. Canonical-Tags müssen zur neuen Struktur passen. Interne Links sollten nach Möglichkeit direkt auf die neuen URLs zeigen, nicht über Redirect-Ketten laufen. Filter- und Facetten-URLs brauchen Regeln, damit nicht tausende Varianten indexiert werden. Bei Mehrsprachigkeit sind konsistente hreflang-Setups wichtig, sonst kann es zu falschen Länderausspielungen kommen.
Monitoring nach dem Go-live
Nach dem Launch ist Beobachtung Pflicht: 404-Fehler, Soft-404, Redirect-Schleifen, unerwartete Noindex-Flags oder Einbrüche in wichtigen Verzeichnissen. Wer hier in den ersten Tagen sauber arbeitet, verhindert, dass kleine Fehler wochenlang Sichtbarkeit kosten.
Tracking, Consent und Datenbasis: Migration ohne Messverlust
Viele Teams merken erst nach dem Go-live, dass ihre Zahlen „nicht mehr stimmen“. Tracking ist im E-Commerce selten ein einzelnes Script, sondern ein System aus Consent-Management, Tag-Management, Events, Datenlayer und Abgleich mit Backend-Quellen.
Messkonzept vor Implementierung
Bevor Tags umgesetzt werden, sollte feststehen, welche Events und Parameter als Minimum gelten: Produktansichten, Add-to-Cart, Checkout-Schritte, Purchases, Coupon-Nutzung, Refunds, Versandarten, Zahlungsarten. Ebenso wichtig ist die Definition von Identifikatoren, etwa Produkt-IDs, Variant-IDs und Order-IDs, die konsistent über Systeme hinweg laufen müssen.
Consent als technische Abhängigkeit ernst nehmen
Wenn Consent-Banner, Tag-Trigger und Eventauslösung nicht sauber zusammenspielen, fehlen Transaktionen oder sie werden doppelt gezählt. Das ist kein Randproblem, sondern wirkt direkt auf Budgetentscheidungen im Performance-Marketing und auf die Steuerung von Sortiment und Kampagnen.
Projektrollen und externe Unterstützung: Governance schlägt Toolwahl
Replatforming ist ein Managementprojekt mit Technikanteil. Es braucht klare Rollen und eine Entscheidungsstruktur, sonst werden Detailfragen zu Dauerbaustellen.
Die Kernrollen im Projekt
Eine zentrale Projektleitung (oder ein Product Owner) bündelt Prioritäten, Abnahmen und Kommunikation. IT oder Development verantwortet Umsetzung und Integrationen. SEO und Content müssen URL-Mapping, Indexierungsregeln und Content-Transfer steuern. Analytics verantwortet das Messkonzept und die Validierung. Operations, Customer Service und Finance bringen die Prozessrealität ein: Retouren, Rechnungslogik, Versandregeln, Buchhaltung und Supportfälle.
Wann spezialisierte Hilfe sinnvoll ist
Externe Unterstützung ist besonders dann sinnvoll, wenn die Komplexität nicht nur im Frontend liegt: große Kataloge, mehrere Länder und Sprachen, PIM- und ERP-Anbindungen, individuelle Preislogiken, komplexe B2B-Rechte, spezielle Checkout-Anforderungen oder hohes Risiko durch SEO-Abhängigkeit. In solchen Fällen können Spezialisten konkrete Pakete übernehmen, etwa Systemarchitektur, Datenmigration, Integrationsdesign, QA-Setups oder SEO-Mapping. Das kann auch über eine Shopify Agentur erfolgen, wenn der Zielzustand auf Shopify ausgerichtet ist und die Aufgaben klar abgegrenzt sind.
Entscheidend ist, dass Verantwortung im Unternehmen bleibt: Externe liefern Umsetzung und Expertise, aber Ziele, Prioritäten und Freigaben müssen intern verankert sein.
Checkout und Payments: Der kritische Pfad muss zuerst stabil sein
Der Checkout ist der Bereich, in dem technische Fehler sofort zu Umsatzverlust führen. Deshalb gehört er nicht „ans Ende“, sondern in die frühe Testplanung.
Zahlungsarten, Risiko und Sonderfälle
Zahlungsdienstleister, 3D-Secure-Flows, Rechnungs- und Ratenkauf, Fraud-Checks, Gutscheine und Steuerlogik greifen ineinander. Häufig entstehen Fehler in Randfällen: gemischte Warenkörbe, unterschiedliche Lieferländer, Split-Shipments, digitale und physische Produkte, Kombinationen aus Rabattregeln und Versandkostenbefreiung.
Praktische Testfälle, die wirklich zählen
Wichtig sind Tests, die echte Kaufwege abbilden: Gast und Login, Wiederkäufer, Gutschein und Sale, unterschiedliche Versandarten, Rückabwicklung, Stornos, Teilrefunds, abgebrochene Zahlungen und erneute Versuche. Wer nur „einmal erfolgreich bestellt“ testet, testet zu wenig.
Teststrategie: Staging, Abnahme und Generalprobe
Ohne Teststrategie wird Replatforming zum Ratespiel. Dabei geht es nicht um „mehr Tests“, sondern um die richtigen Tests zur richtigen Zeit.
Vier Testschichten, die sich bewährt haben
- Funktionalität: Warenkorb, Suche, Filter, Konto, Checkout, E-Mails.
- Daten: Stichproben gegen Quellsystem, Vollständigkeit, Varianten, Preisregeln.
- SEO/Indexierung: Redirect-Listen, Canonicals, Noindex-Regeln, Sitemaps, Robots.
- Tracking: Eventauslösung, Parameterqualität, Consent-Verhalten, Abgleich mit Backend.
Abnahmen sollten nicht nur technisch erfolgen, sondern prozessnah: Kann Support Bestellungen finden? Stimmen Rechnungsdaten? Funktioniert der Versand-Export? Diese Fragen sind häufig wichtiger als ein pixelgenaues Layout.
Cutover-Plan und Go-live: Der Wechsel ist ein Prozess, kein Moment
Der Übergang vom alten auf den neuen Shop ist eine Reihe koordinierter Schritte: Freeze-Phase für Inhalte, Delta-Importe, DNS- oder Routing-Änderungen, Aktivierung von Redirects, finale Checks. Häufig lohnt es sich, DNS-Parameter wie TTL rechtzeitig anzupassen, damit Umstellungen schneller greifen und ein Rollback realistisch bleibt.
In den ersten 72 Stunden nach dem Go-live braucht es klare Zuständigkeiten und ein Monitoring-Dashboard: Bestellvolumen, Fehlerraten, Payment-Abbrüche, 404-Spitzen, Indexierungsindikatoren und Tracking-Plausibilisierung. Ein gutes Team arbeitet in dieser Phase nicht mit Bauchgefühl, sondern mit definierten Schwellenwerten, ab wann eine Eskalation ausgelöst wird.
Typische Stolperfallen und wie man sie früh erkennt
Migrationen geraten oft aus denselben Gründen ins Schlingern. Die Muster sind bekannt, die Gegenmaßnahmen ebenso, wenn sie früh angesetzt werden.
1) Unklarer Scope
Warnzeichen: ständig neue Anforderungen, keine „nicht in Release 1“-Liste. Gegenmaßnahme: klare Priorisierung mit Abnahmekriterien.
2) Schlechte Datenqualität
Warnzeichen: Dubletten, uneinheitliche Varianten, fehlende Pflichtfelder. Gegenmaßnahme: Daten-Audit und Bereinigung vor dem Mapping.
3) Redirects zu spät geplant
Warnzeichen: URL-Struktur wird erst kurz vor Launch diskutiert. Gegenmaßnahme: URL-Design und Mapping früh festlegen, Redirect-Liste versionieren.
4) Filter- und Facetten-Indexierung eskaliert
Warnzeichen: massenhaft neue URL-Varianten im Crawl. Gegenmaßnahme: Regeln für Parameter, Canonicals und Indexierungssteuerung.
5) Tracking wird „später“ gemacht
Warnzeichen: Events fehlen, Transaktionen werden nicht sauber gemessen. Gegenmaßnahme: Messkonzept als Pflichtartefakt vor Frontend-Freeze.
6) Checkout-Edge-Cases fehlen in Tests
Warnzeichen: Abbrüche bei bestimmten Zahlungsarten oder Ländern. Gegenmaßnahme: Testmatrix mit realen Szenarien.
7) Integrationen werden unterschätzt
Warnzeichen: ERP/PIM-Teams sind spät eingebunden. Gegenmaßnahme: Schnittstellenplan mit Verantwortlichen und Datenverträgen.
8) Abnahme ohne Fachbereiche
Warnzeichen: Support und Operations sehen den Shop erst nach Launch. Gegenmaßnahme: UAT mit echten Prozessfällen.
9) Kein Plan für die ersten Tage
Warnzeichen: niemand weiß, wer bei Fehlern entscheidet. Gegenmaßnahme: Go-live-Rollenplan, Monitoring, Eskalationspfade.
Replatforming lässt sich nicht risikofrei machen, aber planbar. Wer Ziele und Scope sauber definiert, Daten ernst nimmt, SEO und Tracking als Kernsysteme behandelt und die Organisation auf Zusammenarbeit trimmt, senkt die Wahrscheinlichkeit teurer Überraschungen deutlich. Der wichtigste Hebel ist nicht das neue System, sondern die Qualität der Vorbereitung.
