Ein verbreitetes Missverständnis ist die Gleichsetzung von Replatforming mit reiner Datenmigration. Die Datenübernahme, also der Umzug von Produkten, Kategorien, Kunden, Bestellungen und Medien, ist beim Replatforming oft der am besten beherrschbare Teil. Moderne Migrationswerkzeuge automatisieren ihn weitgehend. Shopware etwa stellt mit dem Migration Assistant ein kostenloses Plugin bereit, das über ein Magento-Migrationsprofil Magento 1 und 2 als Quellsysteme lesend anbindet, ohne das Quellsystem zu verändern.
Das eigentliche Projektrisiko liegt woanders. Die folgenden Bereiche bestimmen Aufwand und Zeitplan eines Replatformings stärker als die reine Datenmenge:
- Extensions ohne Pendant: Eine Erweiterung im alten Shop (Produktkonfigurator, spezielle Steuer- oder Preislogik, ERP-Anbindung) hat im Zielsystem oft kein direktes Gegenstück und muss neu gebaut werden.
- Custom-Code-Geschäftslogik: Individuell programmierte Abläufe müssen analysiert, bewertet und im neuen System reimplementiert werden.
- Frontend und Theme: Das Design wird in der Regel neu aufgebaut, weil sich Template-Systeme grundlegend unterscheiden.
- Schnittstellen: Anbindungen an ERP, PIM, CRM, Zahlungsdienstleister und Versandsysteme müssen neu konzipiert und getestet werden.
- SEO und Redirects: Ein sauberes Redirect-Mapping der alten auf die neuen URLs ist Pflicht, damit der Relaunch keine Suchmaschinen-Rankings vernichtet.
Ein strukturiertes Replatforming läuft in nachvollziehbaren Phasen ab, auch wenn die konkrete Ausgestaltung je nach Projekt variiert.
1. Standortbestimmung und Anforderungsanalyse
Am Anfang steht eine ehrliche Bestandsaufnahme: aktuelles System, Engpässe, vorhandene Extensions und Schnittstellen, B2B- und Datenanforderungen. Daraus entsteht das Anforderungsprofil für das Zielsystem.
Auf Basis der Anforderungen wird das Zielsystem ausgewählt. Hier zählen nicht nur Funktionen, sondern auch Kostenmodell, Datenhoheit, verfügbares Entwickler-Know-how und strategische Ausrichtung.
3. Konzeption und Datenmapping
Die Datenstrukturen des alten und neuen Systems werden aufeinander abgebildet, Funktionslücken identifiziert und der Neuaufbau von Frontend und Schnittstellen geplant.
4. Umsetzung und Migration
Theme, individuelle Logik und Schnittstellen werden gebaut, die Daten migriert und in Testläufen abgeglichen, mit der Option, Datensätze später erneut zu übernehmen.
5. Test, Redirects und Go-Live
Vor dem Relaunch stehen umfangreiche Tests, das Einrichten der URL-Redirects und ein kontrollierter Go-Live, gefolgt von einem aufmerksamen Monitoring der ersten Wochen.
Zeitrahmen und Aufwand
Wie lange ein Replatforming dauert, hängt von der Komplexität ab. Als grobe Orientierung gilt: 5–12 Wochen, mit ERP-Anbindung bis 6 Monate, wie bei einer Migration von Shopware 5 auf 6. Maßgeblich sind nicht die Produktzahlen, sondern die Zahl und Eigenart der Schnittstellen, der Umfang individueller Geschäftslogik und die Anforderungen an das neue Frontend. Ein Shop mit 50.000 Produkten, aber nur Standardfunktionen, ist schneller umgezogen als ein kleinerer Shop mit einem Dutzend individueller Schnittstellen und komplexer Preislogik.
Ein mittelständischer B2B-Händler betreibt einen Magento-Open-Source-Shop mit rund 30.000 Artikeln, einer ERP-Anbindung an ein Warenwirtschaftssystem und einem über Extensions zusammengesetzten B2B-Bereich. Beim Replatforming auf Shopware 6 läuft die Datenmigration über den Migration Assistant weitgehend reibungslos. Der eigentliche Aufwand entsteht beim Neubau der ERP-Schnittstelle, bei der Abbildung der Einkaufshierarchien auf die nativen B2B Components von Shopware und beim Redirect-Mapping der über Jahre gewachsenen URL-Struktur. Das Projekt dauert rund fünf Monate, der größte Posten ist nicht die Migration, sondern die Schnittstellen- und Frontend-Arbeit. Dieses Muster ist typisch: Die Daten ziehen leicht um, die Funktionen und Integrationen bestimmen den Aufwand.
Big Bang versus schrittweiser Umstieg
Für die Durchführung eines Replatformings gibt es grundsätzlich zwei Strategien, die sich in Risiko und Aufwand deutlich unterscheiden. Beim Big-Bang-Ansatz wird der alte Shop zu einem festen Stichtag komplett durch den neuen ersetzt. Das ist organisatorisch einfacher und vermeidet den Parallelbetrieb zweier Systeme, konzentriert aber das gesamte Risiko auf einen einzigen Go-Live-Termin. Beim schrittweisen oder phasenweisen Umstieg, oft als Strangler-Pattern bezeichnet, werden einzelne Bereiche oder Funktionen nacheinander auf das neue System überführt, während der Rest noch auf dem alten läuft. Das verteilt das Risiko, erhöht aber die Komplexität, weil zwei Systeme zeitweise koexistieren und Daten synchron gehalten werden müssen. Welche Strategie passt, hängt von der Größe des Shops, der Risikotoleranz und der technischen Trennbarkeit der Funktionen ab. Für die meisten mittelständischen Online-Shops ist ein gut vorbereiteter Big-Bang-Relaunch mit ausführlicher Testphase der pragmatischere Weg, während sehr große Plattformen eher vom schrittweisen Ansatz profitieren.
Ein zunehmend wichtiger Anlass für ein Replatforming sind regulatorische Anforderungen. Wer von einer Cloud-Plattform mit Hosting bei einem US-Anbieter auf ein self-hosted System mit deutschem Rechenzentrum wechselt, verbessert die Datenhoheit und vereinfacht die DSGVO-Compliance, etwa bei der freien Wahl des Hosting-Standorts und der Kontrolle über Auftragsverarbeitung und Subprozessoren. Auch die Barrierefreiheit kann ein Treiber sein: Das deutsche Barrierefreiheitsstärkungsgesetz (BFSG) und der European Accessibility Act stellen Anforderungen an Online-Shops, und ein ohnehin anstehender Plattformwechsel ist die natürliche Gelegenheit, diese Anforderungen mit einem barrierefreien, semantisch sauberen Frontend gleich mitzunehmen, statt sie später aufwendig nachzurüsten. Wer ein Replatforming plant, sollte solche Compliance-Themen deshalb von Anfang an in die Anforderungsanalyse aufnehmen, weil sie das Zielsystem und das Frontend-Konzept mitbestimmen.
Ein Replatforming ist kein Selbstzweck. Es gibt Konstellationen, in denen ein Wechsel mehr zerstört als er bringt. Wer ein gut gewartetes, funktionierendes System mit eingespieltem Team und passendem Funktionsumfang betreibt, sollte nicht aus Prinzip wechseln. Ein eingespieltes Entwicklerteam und etablierte Prozesse sind ein Wert, den ein Replatforming zunächst vernichtet und an anderer Stelle neu aufbauen muss. Der nüchterne Test lautet: Gibt es einen konkreten, benennbaren Engpass, den das aktuelle System nicht lösen kann, und übersteigt der Nutzen des Wechsels seine Kosten und Risiken über einen Zeitraum von drei bis fünf Jahren? Nur wenn diese Frage klar mit Ja beantwortet wird, ist ein Replatforming gerechtfertigt.
Die Kosten eines Replatformings setzen sich aus mehreren Blöcken zusammen, die über die reine Umsetzung hinausgehen. Neben der Projektarbeit für Konzeption, Frontend, Schnittstellen und Migration fallen Lizenzkosten des Zielsystems, Hosting-Umstellung, interner Aufwand für Tests und Abnahme sowie eine Stabilisierungsphase nach dem Go-Live an. Eine ehrliche Rechnung stellt diesen Investitionen die Kosten des Nichthandelns gegenüber, also den fortlaufenden Wartungsaufwand, steigende Lizenzkosten oder das Risiko eines aus dem Support gelaufenen Systems. Die zentrale Leitfrage lautet deshalb nicht, ob das neue System besser ist, sondern was das Bleiben gegenüber dem Wechseln über drei bis fünf Jahre kostet. Erst diese Gegenüberstellung macht ein Replatforming zu einer belastbaren Geschäftsentscheidung statt zu einer technischen Modefrage, und sie ist der Grund, warum am Anfang jedes seriösen Projekts eine nüchterne Standortbestimmung steht und nicht der Plattformwechsel auf Verdacht.
Begriffliche Abgrenzung
Im Sprachgebrauch werden mehrere Begriffe oft vermischt. Eine Datenmigration bezeichnet den reinen Umzug von Daten und ist ein Teilschritt des Replatformings. Ein Versions-Upgrade (etwa Magento 2.4.6 auf 2.4.7) bleibt innerhalb derselben Plattform. Ein Relaunch meint die sichtbare Neueinführung eines Shops, die mit einem Replatforming einhergehen kann, aber nicht muss. Replatforming ist der umfassendste dieser Begriffe: Es schließt Datenmigration, Frontend-Neuaufbau, Schnittstellen, Prozessübernahme und Go-Live ein.
Was ist der Unterschied zwischen Replatforming und Migration?
Migration meint meist den reinen Datenumzug. Replatforming ist umfassender und beinhaltet zusätzlich Frontend-Neuaufbau, Schnittstellen, Custom-Code-Reimplementierung und Go-Live. Die Datenmigration ist nur ein Teilschritt.
Wie lange dauert ein Replatforming?
Typischerweise 5–12 Wochen, mit ERP-Anbindung bis 6 Monate. Der Zeitrahmen wird von Schnittstellen, individueller Geschäftslogik und Frontend-Anforderungen bestimmt, nicht von der reinen Produktzahl.
Was ist das größte Risiko beim Replatforming?
Funktionslücken durch Extensions ohne direktes Pendant im Zielsystem sowie fehlerhafte oder fehlende URL-Redirects, die SEO-Rankings kosten. Beides muss früh in der Projektplanung adressiert werden, idealerweise schon vor der finalen Plattformauswahl.
Lohnt sich ein Replatforming immer?
Nein. Bei einem gut gewarteten System mit passendem Funktionsumfang und eingespieltem Team kann ein Wechsel mehr Wert vernichten als schaffen. Es braucht einen konkreten, benennbaren Engpass und eine positive Kosten-Nutzen-Rechnung über drei bis fünf Jahre, die auch die Kosten des Nichthandelns berücksichtigt.
Bleiben meine SEO-Rankings beim Replatforming erhalten?
Nur mit einem sauberen Redirect-Mapping der alten auf die neuen URLs. Ohne dieses Mapping verliert der Shop beim Relaunch Sichtbarkeit und Rankings.
