Enterprise-Replatforming: Umfang, Entscheidungen und Cutover planen

Gerechtfertigt ist ein Wechsel, wenn die Plattform selbst die Ursache Deiner Probleme ist. Typische belastbare Gründe: Der Hersteller stellt Deine Version ein, jede fachliche Änderung braucht zwingend einen Entwickler, oder ein neues Geschäftsmodell wie Abo oder B2B lässt sich im bestehenden Datenmodell nicht sauber abbilden.

Der häufigste Fehlgrund ist Unzufriedenheit mit dem Frontend. Veraltetes Design, langsame Seiten oder eine schlechte Suche sind fast immer ohne Plattformwechsel lösbar. Wer deswegen replatformt, tauscht ein bekanntes System gegen ein unbekanntes — und nimmt die eigentlichen Altlasten aus Daten, Prozessen und Zuständigkeiten vollständig mit.

Prüfe vor der Entscheidung, welcher Anteil Deiner Schmerzpunkte in der Software liegt und welcher in Datenqualität, Prozessen oder unklaren Verantwortungen. Liegt der größere Teil außerhalb der Plattform, löst ein Wechsel ihn nicht. Er verschiebt ihn in ein neues System und macht ihn dort teurer sichtbar.

Weiterentwicklung ist meist die bessere Antwort, wenn Dein Shop fachlich trägt und nur an einzelnen Stellen klemmt. Ein Katalog, der sauber gepflegt ist, ein Checkout, der konvertiert, und ein ERP-Anschluss, der läuft, sind Vermögenswerte. Ein Replatforming setzt genau diese drei Punkte wieder auf null.

Ein guter Test ist die Liste der offenen Anforderungen aus den letzten zwölf Monaten. Lassen sich die meisten davon im bestehenden System umsetzen und scheitern sie an Budget oder Priorisierung, hast Du kein Plattformproblem. Scheitern sie an Grenzen des Systems, ist der Wechsel begründbar.

Auch ein Teilaustausch ist möglich und wird unterschätzt. Frontend erneuern und Backend behalten, Checkout ablösen, ein PIM vorschalten oder einen Markt separat neu bauen — solche Schnitte lösen oft dasselbe Problem, ohne dass Du den gesamten Geschäftsbetrieb an einem Tag umstellst.

Ein Big Bang ist vertretbar, wenn Dein Shop überschaubar ist: ein Markt, ein Sortiment, wenige Integrationen. Dann ist ein Parallelbetrieb teurer als das Risiko. Sobald mehrere Länder, Marken oder Kundensegmente betroffen sind, wächst die Zahl der gleichzeitig zu prüfenden Fälle schneller als jedes Testbudget.

Die schrittweise Ablösung kauft Sicherheit mit Doppelbetrieb. Zwei Systeme bedeuten zwei Pflegewege, zwei Datenstände und Kollegen, die morgens erst schauen müssen, wo ein Auftrag liegt. Das ist verkraftbar, wenn der Zeitraum vorher benannt ist. Ohne festes Enddatum wird aus dem Zwischenschritt ein Dauerzustand.

Der Schnitt sollte einer Grenze folgen, die es im Geschäft ohnehin gibt. Ein eigener Ländershop, eine eigenständige Marke oder das B2B-Geschäft haben eigene Kunden, eigene Preise und oft eigene Prozesse. Ein künstlicher Schnitt quer durch dieselbe Kundengruppe erzeugt dagegen Fälle, die niemand vorher beschreiben kann.

Die teuersten Verzögerungen in Replatforming-Projekten entstehen nicht beim Programmieren, sondern beim Warten auf Entscheidungen. Wenn niemand benannt ist, der über Preislogik, Kundenstammdaten oder Retourenprozess abschließend entscheidet, wird jede Frage zur Runde — und jede Runde kostet einen Sprint.

Vor dem Bau muss geklärt sein, welches System die Wahrheit für welches Objekt hält. Artikel, Bestand, Preise, Kunden, Aufträge und Belege brauchen je eine führende Quelle. Ohne diese Festlegung baust Du Schnittstellen, die sich gegenseitig überschreiben, und Korrekturen landen später manuell im Tagesgeschäft.

Nützlich ist eine kurze Liste mit Entscheidungen, Namen und Zeitpunkt, die im Projektraum sichtbar hängt. Nicht als Formalie, sondern weil sie sichtbar macht, wo das Projekt gerade wirklich steht. Offene Entscheidungen sind der zuverlässigste Frühindikator für einen verschobenen Termin.

Altdaten sind selten ein technisches Problem und fast immer ein fachliches. Ein Katalog aus zehn Jahren enthält Artikel ohne Bilder, doppelte Kunden, Varianten, die nur ein Kollege versteht, und Attribute, die einmal für eine Kampagne angelegt wurden. Diese Substanz bestimmt die Dauer der Migration.

Entscheide früh und schriftlich, was mitkommt. Aktive Artikel und Kunden gehören in den neuen Shop, Bestellhistorie oft nur als Anzeige, alte Kampagnenseiten meist gar nicht. Alles, was ohne Zweck migriert wird, musst Du testen, pflegen und im Zweifel nochmals korrigieren — dauerhaft.

Integrationen sind der eigentliche Kern eines Enterprise-Replatformings. ERP, PIM, Marktplätze, Retourenportal und Kundenservice hängen an Feldern, die niemand mehr dokumentiert hat. Bevor der Bau startet, sollte für jede Verbindung feststehen, welche Objekte sie überträgt, wer sie betreibt und wer im Fehlerfall angerufen wird.

Sichtbarkeit entsteht aus Entscheidungen, die früh im Projekt fallen: URL-Struktur, Kategoriearchitektur, Umgang mit Filterseiten, Sprach- und Länderlogik, Rendering des Frontends. Wer SEO als Abnahmepunkt vor dem Livegang plant, kann diese Entscheidungen nur noch kommentieren, aber nicht mehr ändern.

Ein Redirect-Konzept ist Pflicht, aber es ist die kleinere Hälfte. Google beschreibt einen Domain- oder URL-Wechsel als Site Move, bei dem alte Adressen dauerhaft auf die passenden neuen zeigen sollen. Das rettet Adressen — es rettet keine Seite, deren Inhalt beim Umbau verschwunden ist.

Praktisch heißt das: Vor dem Bau ein Inventar der Seiten mit Rankings, Links und Umsatz, dann eine Zuordnung alt zu neu, und die Templates werden gegen diese Zuordnung gebaut. Nach dem Livegang gehören Indexierung, Fehlerseiten und Rankings für einige Monate in eine feste Beobachtung.

Das Cutover-Fenster ist der Zeitraum, in dem der alte Shop nicht mehr führt und der neue noch nicht vollständig arbeitet. Kritisch sind darin nicht die Seiten, sondern die laufenden Vorgänge: offene Bestellungen, Retouren, Gutscheine, Abos und alles, was gerade zwischen Shop und ERP unterwegs ist.

Plane das Fenster in eine nachfrageschwache Zeit, aber nicht in eine, in der niemand erreichbar ist. Ein Cutover am Freitagabend spart Umsatz und kostet Reaktionszeit. Wichtiger als der Wochentag ist, dass Entwicklung, ERP-Betreuung, Zahlungsdienstleister und Kundenservice im selben Zeitraum tatsächlich ansprechbar sind.

Der Rückweg gehört vorher beschrieben. Was passiert, wenn die Bestandssynchronisation nach zwei Stunden falsche Werte liefert? Ein Rollback ist nur so lange möglich, wie im neuen System noch keine Bestellungen liegen. Danach ist die einzige Option, vorwärts zu reparieren — das solltest Du vorher wissen.

Das erste Warnsignal ist fast immer sprachlicher Natur: Aus einem festen Termin wird ein Zeitraum, aus einem Zeitraum eine Absicht. Wenn im Statustermin nicht mehr über fertige Funktionen gesprochen wird, sondern über Fortschritt in Prozent, fehlt eine gemeinsame Definition davon, was fertig heißt.

Ein zweites Signal ist der wachsende Umfang bei gleichbleibendem Termin. Jede zusätzliche Anforderung, die ohne Streichung an anderer Stelle aufgenommen wird, ist eine stillschweigende Terminverschiebung. Sichtbar wird sie erst, wenn der Puffer aufgebraucht ist — üblicherweise kurz vor dem geplanten Livegang.

Ein drittes Signal ist die Verlagerung von Tests nach hinten. Wenn Integrationen erst getestet werden, wenn alle Templates stehen, sammelt das Projekt Risiko an genau der Stelle, an der es am teuersten ist. Frühe, unvollständige Testläufe sind unangenehmer und deutlich billiger.