Warum Replatforming-Projekte schon vor der technischen Umsetzung scheitern

Gastbeitrag von Alexander Steireif, Gründer und Geschäftsführer der Alexander Steireif GmbH.

Ob ein Shopsystemwechsel erfolgreich wird, entscheidet sich häufig nicht während der Entwicklung, sondern lange davor. Wenn ein Replatforming-Projekt später über Budget läuft oder deutlich später als geplant startet, liegt die Ursache in den meisten Fällen nicht in der gewählten Technologie, sondern in Entscheidungen, die getroffen wurden, bevor überhaupt ein Entwickler mit der Arbeit begonnen hat.

Die Zahlen zeigen ein strukturelles Problem

Wie verbreitet dieses Muster ist, zeigen mehrere unabhängige Erhebungen aus der Projektforschung. Der bekannte CHAOS Report der Standish Group, eine der meistzitierten Langzeitstudien zu IT-Projekten überhaupt, kommt für 2020 zu dem Ergebnis, dass nur 31 Prozent aller untersuchten IT-Projekte tatsächlich erfolgreich abgeschlossen wurden, während 50 Prozent als beeinträchtigt gelten und 19 Prozent komplett scheitern. Replatforming-Projekte unterscheiden sich von anderen komplexen IT-Vorhaben dabei kaum, im Gegenteil, durch die zusätzliche Komplexität aus Altdaten, Drittanbieterintegrationen und laufendem Geschäftsbetrieb während der Umstellung sind sie tendenziell noch anfälliger für genau diese Muster.

Speziell für Replatforming-Projekte im E-Commerce liefert eine von Forrester Consulting durchgeführte Studie ergänzende Zahlen. Demnach verzögert sich ein durchschnittliches Replatforming-Projekt um 4,2 Monate, während 39 Prozent der Unternehmen nach dem Livegang einen Rückgang der Conversion Rate und 44 Prozent eine Verschlechterung der Ladezeiten verzeichnen. Ein Viertel der Unternehmen schränkt dabei sogar bewusst den Projektumfang ein, nur um Zeitplan und Budget überhaupt noch einzuhalten.

Diese Kombination aus einer generell hohen Scheiterquote bei komplexen IT-Projekten und spezifischen, replatforming-typischen Risiken ist auffällig. Sie deutet darauf hin, dass das eigentliche Problem nicht in der einen oder anderen Plattformentscheidung liegt, sondern in der Art und Weise, wie solche Projekte grundsätzlich angegangen werden.

Bemerkenswert ist zudem, dass laut Standish Group vor allem unvollständige Anforderungen und mangelnde Nutzerbeteiligung zu den häufigsten Ursachen für gescheiterte oder beeinträchtigte Projekte zählen, deutlich vor rein technischen Problemen. Wenn selbst über verschiedenste Branchen und Projekttypen hinweg immer wieder dieselben organisatorischen Ursachen auftauchen, liegt der Verdacht nahe, dass die zugrunde liegende Vorbereitung vor dem eigentlichen Projektstart selten gründlich genug erfolgt.

Kennzahlen zu IT- und Replatforming-Projekten

Kennzahlen zu IT- und Replatforming-Projekten. Quelle: Standish Group CHAOS Report, Forrester Consulting, 2026.

Der Fehler beginnt lange vor dem ersten Sprint

Wenn ein Projekt später über Budget läuft, wird die Ursache meist im Entwicklungsprozess gesucht, bei Agenturen, bei der gewählten Technologie oder bei unklaren Anforderungen während der Umsetzung. Tatsächlich liegen die entscheidenden Weichenstellungen jedoch häufig schon vor dem ersten Kickoff-Meeting. Welche Plattform überhaupt in die engere Auswahl kommt, wie vollständig die eigenen Anforderungen zu diesem Zeitpunkt bereits verstanden sind und wie sauber die vorhandenen Daten tatsächlich sind, all das entscheidet später mit, ob ein Projekt im Rahmen bleibt oder aus dem Ruder läuft.

Ein Entwicklungsteam kann noch so erfahren sein, es kann strukturelle Probleme aus der Planungsphase kaum vollständig ausgleichen. Wird beispielsweise erst während der Umsetzung klar, dass zentrale Anforderungen aus dem Vertrieb oder der Logistik gar nicht berücksichtigt wurden, entstehen Verzögerungen, die sich nicht mehr allein technisch lösen lassen.

Feature-Parität als Ziel

Einer der häufigsten und zugleich am wenigsten offensichtlichen Fehler entsteht bereits bei der Zieldefinition. Viele Unternehmen formulieren als Anspruch an das neue System, alle Funktionen des alten Shops eins zu eins nachzubilden. Dieses Vorgehen wirkt zunächst risikoarm, weil es keine Prozessänderung verlangt, führt aber in der Praxis regelmäßig dazu, dass Schwächen des alten Systems einfach in die neue Plattform übertragen werden, anstatt sie zu beheben.

Feature-Parität als Leitprinzip verhindert damit genau das, wofür ein Replatforming eigentlich gedacht ist, nämlich Prozesse zu verbessern und technische Limitierungen zu überwinden. Wer stattdessen von Anfang an fragt, welche Prozesse künftig anders und besser ablaufen sollen, trifft von Beginn an deutlich robustere Entscheidungen.

Typische Fehler, die bereits vor dem eigentlichen Projektstart gemacht werden, lassen sich so zusammenfassen:

• Die neue Plattform wird ausgewählt, bevor die eigenen Anforderungen vollständig dokumentiert sind
• Feature-Parität mit dem alten System wird als eigentliches Projektziel definiert
• Datenqualität und Datenstruktur werden erst während der Migration selbst geprüft
• Das Projekt wird ausschließlich als IT-Vorhaben behandelt, ohne Einbindung von Vertrieb, Marketing und Logistik

Warum Datenqualität schon vor der Migration entscheidet

Ein besonders unterschätzter Faktor ist der Zustand der bestehenden Produkt- und Kundendaten. Nach Jahren im alten System liegen Produktdaten häufig in mehreren unterschiedlichen Formaten vor, Kundendatensätze existieren doppelt, und Kategoriestrukturen sind über die Zeit gewachsen, ohne jemals konsolidiert worden zu sein. Genau diese unsaubere Datenlage zählt in der Praxis regelmäßig zu den Hauptgründen für explodierende Budgets bei der Migration, auch wenn sie in frühen Projektangeboten selten als eigener Kostenblock ausgewiesen wird.

Wird diese Datenbereinigung nicht als eigener, vorgelagerter Schritt eingeplant, sondern stillschweigend als Teil der technischen Migration vorausgesetzt, entsteht genau der Budgetsprung, der viele Projekte am Ende scheitern lässt. Eine technisch perfekt umgesetzte Migration hilft wenig, wenn die Daten, die in das neue System übertragen werden, von Anfang an fehlerhaft oder unvollständig sind.

In der Praxis zeigt sich dieses Problem häufig erst mitten im Projekt, wenn eigentlich schon Umsetzung geplant war. Ein Team stellt fest, dass Produktvarianten in unterschiedlichen Systemen unterschiedlich modelliert wurden, dass Kategoriebäume über Jahre gewachsen sind und sich kaum noch eins zu eins übertragen lassen, oder dass Kundendatensätze durch frühere Systemwechsel mehrfach dupliziert wurden. Jede dieser Entdeckungen bedeutet zusätzlichen Aufwand, der im ursprünglichen Angebot nicht vorgesehen war, weil er zum Zeitpunkt der Angebotserstellung schlicht noch nicht sichtbar war.

Wann sich ein Wechsel überhaupt lohnt

Bevor überhaupt eine Plattform oder ein Umsetzungspartner ausgewählt wird, muss deshalb zunächst eine andere, grundsätzlichere Frage geklärt sein: ob und wann ein Systemwechsel für das eigene Unternehmen tatsächlich sinnvoll ist. Steigende Wartungskosten, fehlende Funktionen für neue Anforderungen und spürbare Performance-Probleme sind typische Signale dafür, dass ein bestehendes System das eigentliche Geschäftsmodell ausbremst, statt es zu unterstützen. Diese strategische Vorentscheidung sollte getroffen und sauber begründet sein, bevor das eigentliche Projekt beginnt, denn genau hier liegt der Unterschied zwischen einem Wechsel aus Überzeugung und einem Wechsel aus Aktionismus. Eine ausführliche Einordnung, welche Symptome auf einen notwendigen Wechsel hindeuten, liefert die Analyse zum Shopsystem wechseln.

Voraussetzungen, die idealerweise bereits vor dem eigentlichen Projektstart geklärt sein sollten, lassen sich so bündeln:

• Vollständig dokumentierte Anforderungen aus allen betroffenen Abteilungen, nicht nur aus der IT
• Eine realistische Einschätzung des Aufwands für Datenbereinigung, getrennt vom eigentlichen technischen Transfer
• Klare Entscheidungsstrukturen und Rückendeckung auf Führungsebene für den gesamten Projektzeitraum
• Ein Zielbild, das sich an verbesserten Prozessen orientiert, nicht am reinen Nachbau des bestehenden Systems

Was das für die Projektplanung bedeutet

Für die praktische Planung eines Replatforming-Projekts bedeutet das vor allem eines: Die eigentliche Arbeit beginnt nicht mit dem ersten Entwicklungssprint, sondern deutlich früher. Wer Anforderungen, Datenqualität und organisatorische Zuständigkeiten bereits vor der Plattformauswahl sauber klärt, reduziert das Risiko für Budget- und Zeitüberschreitungen erheblich, noch bevor überhaupt eine Zeile Code geschrieben wurde.

Auch die Wahl der Plattform selbst sollte diesem vorgelagerten Klärungsprozess folgen, nicht umgekehrt. Wird zuerst eine Plattform festgelegt und werden Anforderungen erst nachträglich daran angepasst, entstehen zwangsläufig Kompromisse, die später als technische Einschränkung wahrgenommen werden, obwohl die eigentliche Ursache in der Reihenfolge der Entscheidungen liegt.

Fazit

Replatforming-Projekte scheitern selten an mangelndem technischem Können der beteiligten Teams. Die Ursachen liegen fast immer früher, bei unklaren Anforderungen, unsauberen Daten, fehlendem Commitment auf Führungsebene und dem Irrglauben, das alte System müsse im neuen Gewand einfach nur nachgebaut werden. Die aktuellen Branchenzahlen bestätigen dieses Muster eindrücklich, mit Budgetüberschreitungen bei der überwiegenden Mehrheit aller Projekte.

Für Unternehmen, die einen Systemwechsel planen, lohnt sich deshalb vor allem eines: ausreichend Zeit für die Phase vor dem eigentlichen Projektstart einzuplanen. Anforderungen zu klären, Daten zu bereinigen und klare Verantwortlichkeiten zu schaffen, kostet zunächst Zeit, verhindert aber genau die Verzögerungen und Budgetsprünge, die später deutlich teurer werden.

Diese Vorarbeit lässt sich nicht delegieren, weder an eine Agentur noch an ein einzelnes IT-Team. Sie verlangt, dass Fachbereiche, Führungsebene und technische Verantwortliche gemeinsam ein klares Bild davon entwickeln, was das neue System leisten soll und woran sich der Erfolg des Projekts später messen lässt. Wird diese Abstimmung übersprungen, weil sie unbequem oder zeitaufwendig erscheint, rächt sich das fast immer später, meist zu einem Zeitpunkt, an dem Korrekturen bereits deutlich teurer sind als eine gründliche Vorbereitung gewesen wäre.

Am Ende zeigt sich, dass ein erfolgreiches Replatforming weniger eine technische als eine organisatorische Leistung ist. Wer diese Vorarbeit ernst nimmt, schafft die Grundlage dafür, dass die eigentliche technische Umsetzung tatsächlich zum geplanten Ergebnis führt, statt schon vorher an strukturellen Schwächen zu scheitern.

Über den Autor

Alexander Steireif ist Gründer und Geschäftsführer der Strategie- und Technologieberatung Alexander Steireif GmbH. Seit über 20 Jahren unterstützt er mittelständische Unternehmen dabei, ihren Vertrieb zu digitalisieren, leistungsfähige E-Commerce-Lösungen aufzubauen und klare Strategien für nachhaltiges digitales Wachstum zu entwickeln.