Replatforming bezeichnet im E-Commerce den Wechsel eines bestehenden Online-Shops oder einer digitalen Handelsplattform von einem technischen System auf ein anderes. Anders als ein blosses Versions-Update innerhalb derselben Software bedeutet Replatforming den Umzug auf eine grundlegend andere Plattform, etwa von Magento Open Source auf Shopware 6 oder von einem selbst entwickelten Shop auf ein Standardsystem. Der Begriff betont, dass nicht nur Daten umziehen, sondern die gesamte technische Basis ausgetauscht wird, mit allen Folgen fuer Frontend, Schnittstellen, Prozesse und Betrieb. Im englischen Sprachgebrauch hat sich der Begriff fest etabliert und wird im deutschsprachigen E-Commerce unveraendert uebernommen, weil eine treffende deutsche Entsprechung jenseits des umstaendlichen Begriffs Plattformwechsel fehlt.
Warum Haendler ein Replatforming in Erwaegung ziehen
Ein Replatforming ist ein grosses Projekt mit Risiko und Kosten und wird selten ohne triftigen Grund angestossen. Die haeufigsten Anlaesse lassen sich in wenige Kategorien fassen:
| Anlass | Beschreibung |
|---|---|
| Auslaufender Support | Das bisherige System erreicht das End-of-Life, Sicherheitspatches enden (z. B. Magento-Support-Fahrplan) |
| Hoher Wartungsaufwand | Updates, Extension-Kompatibilitaet und Pflege binden zu viele Ressourcen |
| Kostenmodell | GMV- oder umsatzabhaengige Lizenzkosten wachsen staerker als der Nutzen |
| Fehlende Funktionen | Natives B2B, moderne Frontends oder Schnittstellen fehlen oder sind nur muehsam nachruestbar |
| Datenhoheit & Compliance | Hosting-Standort, DSGVO-Anforderungen oder Barrierefreiheit erzwingen Veraenderungen |
| Strategische Richtung | Der Anbieter schlaegt einen Weg ein, den das Unternehmen nicht mitgehen will |
In der Praxis treten mehrere dieser Anlaesse gemeinsam auf. Ein typisches Beispiel: Ein Magento-Open-Source-Haendler kaempft mit hohem Wartungsaufwand, sieht den auslaufenden Support kommen und vermisst natives B2B. Erst die Summe dieser Punkte macht den Wechsel wirtschaftlich begruendbar.
Replatforming ist mehr als Datenmigration
Ein verbreitetes Missverstaendnis ist die Gleichsetzung von Replatforming mit reiner Datenmigration. Die Datenuebernahme, 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 ueber ein Magento-Migrationsprofil Magento 1 und 2 als Quellsysteme lesend anbindet, ohne das Quellsystem zu veraendern.
Das eigentliche Projektrisiko liegt woanders. Die folgenden Bereiche bestimmen Aufwand und Zeitplan eines Replatformings staerker 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 Gegenstueck und muss neu gebaut werden.
- Custom-Code-Geschaeftslogik: Individuell programmierte Ablaeufe muessen 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 muessen 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.
Der typische Ablauf eines Replatformings
Ein strukturiertes Replatforming laeuft 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, Engpaesse, vorhandene Extensions und Schnittstellen, B2B- und Datenanforderungen. Daraus entsteht das Anforderungsprofil fuer das Zielsystem.
2. Plattformauswahl
Auf Basis der Anforderungen wird das Zielsystem ausgewaehlt. Hier zaehlen nicht nur Funktionen, sondern auch Kostenmodell, Datenhoheit, verfuegbares Entwickler-Know-how und strategische Ausrichtung.
3. Konzeption und Datenmapping
Die Datenstrukturen des alten und neuen Systems werden aufeinander abgebildet, Funktionsluecken 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 Testlaeufen abgeglichen, mit der Option, Datensaetze spaeter erneut zu uebernehmen.
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, haengt von der Komplexitaet ab. Als grobe Orientierung sind je nach Umfang drei bis sechs Monate realistisch, vergleichbar mit einer Migration von Shopware 5 auf 6. Massgeblich sind nicht die Produktzahlen, sondern die Zahl und Eigenart der Schnittstellen, der Umfang individueller Geschaeftslogik 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.
Realbeispiel: Replatforming von Magento auf Shopware
Ein mittelstaendischer B2B-Haendler betreibt einen Magento-Open-Source-Shop mit rund 30.000 Artikeln, einer ERP-Anbindung an ein Warenwirtschaftssystem und einem ueber Extensions zusammengesetzten B2B-Bereich. Beim Replatforming auf Shopware 6 laeuft die Datenmigration ueber 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 ueber Jahre gewachsenen URL-Struktur. Das Projekt dauert rund fuenf Monate, der groesste 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
Fuer die Durchfuehrung eines Replatformings gibt es grundsaetzlich 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 ueberfuehrt, waehrend der Rest noch auf dem alten laeuft. Das verteilt das Risiko, erhoeht aber die Komplexitaet, weil zwei Systeme zeitweise koexistieren und Daten synchron gehalten werden muessen. Welche Strategie passt, haengt von der Groesse des Shops, der Risikotoleranz und der technischen Trennbarkeit der Funktionen ab. Fuer die meisten mittelstaendischen Online-Shops ist ein gut vorbereiteter Big-Bang-Relaunch mit ausfuehrlicher Testphase der pragmatischere Weg, waehrend sehr grosse Plattformen eher vom schrittweisen Ansatz profitieren.
Datenhoheit und Compliance als Replatforming-Treiber
Ein zunehmend wichtiger Anlass fuer 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 ueber Auftragsverarbeitung und Subprozessoren. Auch die Barrierefreiheit kann ein Treiber sein: Das deutsche Barrierefreiheitsstaerkungsgesetz (BFSG) und der European Accessibility Act stellen Anforderungen an Online-Shops, und ein ohnehin anstehender Plattformwechsel ist die natuerliche Gelegenheit, diese Anforderungen mit einem barrierefreien, semantisch sauberen Frontend gleich mitzunehmen, statt sie spaeter aufwendig nachzuruesten. 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.
Wann ein Replatforming kein Gewinn ist
Ein Replatforming ist kein Selbstzweck. Es gibt Konstellationen, in denen ein Wechsel mehr zerstoert 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 zunaechst vernichtet und an anderer Stelle neu aufbauen muss. Der nuechterne Test lautet: Gibt es einen konkreten, benennbaren Engpass, den das aktuelle System nicht loesen kann, und uebersteigt der Nutzen des Wechsels seine Kosten und Risiken ueber einen Zeitraum von drei bis fuenf Jahren? Nur wenn diese Frage klar mit Ja beantwortet wird, ist ein Replatforming gerechtfertigt.
Kosten eines Replatformings realistisch einschaetzen
Die Kosten eines Replatformings setzen sich aus mehreren Bloecken zusammen, die ueber die reine Umsetzung hinausgehen. Neben der Projektarbeit fuer Konzeption, Frontend, Schnittstellen und Migration fallen Lizenzkosten des Zielsystems, Hosting-Umstellung, interner Aufwand fuer Tests und Abnahme sowie eine Stabilisierungsphase nach dem Go-Live an. Eine ehrliche Rechnung stellt diesen Investitionen die Kosten des Nichthandelns gegenueber, 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 gegenueber dem Wechseln ueber drei bis fuenf Jahre kostet. Erst diese Gegenueberstellung macht ein Replatforming zu einer belastbaren Geschaeftsentscheidung statt zu einer technischen Modefrage, und sie ist der Grund, warum am Anfang jedes seriosen Projekts eine nuechterne 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 Neueinfuehrung eines Shops, die mit einem Replatforming einhergehen kann, aber nicht muss. Replatforming ist der umfassendste dieser Begriffe: Es schliesst Datenmigration, Frontend-Neuaufbau, Schnittstellen, Prozessuebernahme und Go-Live ein.
Haeufige Fragen zum Replatforming
Was ist der Unterschied zwischen Replatforming und Migration?
Migration meint meist den reinen Datenumzug. Replatforming ist umfassender und beinhaltet zusaetzlich Frontend-Neuaufbau, Schnittstellen, Custom-Code-Reimplementierung und Go-Live. Die Datenmigration ist nur ein Teilschritt.
Wie lange dauert ein Replatforming?
Je nach Komplexitaet typischerweise drei bis sechs Monate. Der Zeitrahmen wird von Schnittstellen, individueller Geschaeftslogik und Frontend-Anforderungen bestimmt, nicht von der reinen Produktzahl.
Was ist das groesste Risiko beim Replatforming?
Funktionsluecken durch Extensions ohne direktes Pendant im Zielsystem sowie fehlerhafte oder fehlende URL-Redirects, die SEO-Rankings kosten. Beides muss frueh 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 ueber drei bis fuenf Jahre, die auch die Kosten des Nichthandelns beruecksichtigt.
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.