Wie lange dauert ein Shopsystem-Wechsel? Die ehrliche Antwort hängt nicht an der Entwicklung
Auf die Frage nach der Projektdauer bekommen Sie meistens eine Zahl, die aus dem Website-Bau stammt: Theme aufsetzen, Daten importieren, live gehen. Diese Zahl stimmt sogar — sie beschreibt nur den kleineren Teil des Projekts. Was einen Wechsel wirklich terminiert, sind vier Blöcke, die es bei einem Neubau gar nicht gibt, und eine Kette von Entscheidungen, die sich nicht parallelisieren lässt.
„Wie lange dauert das?“ ist in Migrationsprojekten fast immer die zweite Frage nach dem Preis — und fast immer die schlechter beantwortete. Nicht, weil niemand es wüsste, sondern weil die Frage in der Praxis mit einer Zahl beantwortet wird, die aus einem anderen Projekt stammt.
Diese Zahl lautet meistens acht bis zwölf Wochen, und sie ist nicht falsch. Sie beschreibt exakt das, was Agenturen und Plattformanbieter beim Aufbau einer neuen Website messen: Theme aufsetzen, Seiten anlegen, Daten einspielen, testen, live gehen. Nur beschreibt sie bei einem Systemwechsel eben nicht das Projekt, sondern einen Ausschnitt daraus.
Der Unterschied ist keine Nuance. Er ist der Grund, warum Wechseltermine reihenweise reißen — und zwar ausgerechnet bei Projekten, in denen die Entwicklung planmäßig lief.
Warum sich die Dauer eines Neubaus nicht übertragen lässt
Zwei verschiedene Projekte
Der größte Block eines Neubaus fällt beim Wechsel weg — und vier neue kommen dazu
Wer eine Website neu baut, verbringt den größten Teil der Projektzeit damit, Inhalte überhaupt erst zu erzeugen. Beim Umstieg existieren die Inhalte bereits. Genau deshalb wirkt eine Migration auf dem Papier kürzer — und genau deshalb wird sie regelmäßig zu knapp geplant.
Der Reflex, eine Migration für die schnellere Variante zu halten, ist gut begründet: Der größte Zeitfresser eines Neubaus fällt tatsächlich weg. Sie müssen keine Texte schreiben, keine Produktfotos beauftragen, keine Sortimentsstruktur erfinden. All das existiert bereits, seit Jahren, in Betrieb.
Genau darin liegt aber auch das Missverständnis. Dass die Inhalte existieren, heißt nicht, dass sie verfügbar sind. Es heißt zunächst nur, dass sie irgendwo liegen — in einer Datenbank, deren Struktur über Jahre gewachsen ist, in Attributsets, die drei verschiedene Personen nacheinander angelegt haben, in Modulen, die jemand 2019 installiert hat und die heute niemand mehr im Blick hat.
Bevor mit diesen Inhalten gearbeitet werden kann, muss jemand feststellen, was überhaupt da ist. Und danach muss jemand entscheiden, was davon mitkommt, in welcher Form, und was nicht. Das sind zwei Arbeitsschritte, die in keinem Website-Zeitplan vorkommen, weil es dort nichts gibt, das man vorfinden könnte.
Der Unterschied, den niemand einplant: Ihr Shop läuft weiter
Ein Neubau hat kein Vorher. Er geht online, und damit beginnt der Betrieb. Ein Wechsel hat ein Vorher, und dieses Vorher verkauft weiter, während gebaut wird.
Praktisch bedeutet das drei Dinge, die den Zeitplan verändern:
Die Daten sind ein bewegliches Ziel. Zwischen dem ersten Testimport und dem Cutover ändern sich Preise, kommen Artikel dazu, gehen Bestellungen ein. Der Import ist deshalb kein einmaliger Vorgang, sondern eine Übung, die mehrfach wiederholt wird — und die beim letzten Mal, in der Nacht der Umstellung, fehlerfrei durchlaufen muss.
Die Menschen, die entscheiden, haben einen Hauptberuf. Wer beim Neubau eines Shops die Struktur festlegt, hat oft genau dafür Zeit. Wer beim Wechsel entscheidet, welche 40 Kategorien zu 22 werden, macht das neben dem Tagesgeschäft, mit dem alten Shop im Rücken, der weiterläuft und weiter Aufmerksamkeit fordert.
Es gibt einen harten Schnitt. Ein Neubau kann in einer schlanken ersten Version starten und danach wachsen. Ein Wechsel kann das nur eingeschränkt: Alles, was an das Altsystem gebunden ist, muss zum Zeitpunkt der Abschaltung übernommen sein. Danach gibt es keinen Export mehr. Diese Asymmetrie ist der eigentliche Unterschied zwischen den beiden Projektarten, und sie ist der Grund, warum ein Wechsel eine Phase kennt, die ein Neubau nicht hat: den Abgleich.
Die Phasen — und warum ihre Summe nicht die Antwort ist
Kalenderzeit
Zwölf bis zwanzig Wochen — aber nicht, weil die Phasen sich addieren
Die Phasen eines Wechsels überlappen sich stark. Was den Termin bestimmt, ist nicht ihre Summe, sondern die Kette, die nicht parallelisierbar ist: Erst wenn klar ist, was im Altsystem steht, lässt sich die Zielstruktur festlegen — und erst dann kann die Datenübernahme beginnen. Das Theme entsteht daneben und verschiebt den Termin in aller Regel nicht.
Wer die Phasen einzeln addiert, kommt auf eine Zahl, die deutlich über dem liegt, was ein Wechsel tatsächlich braucht. Der Grund ist die Überlappung: Während die Datenübernahme läuft, entsteht bereits das Theme. Während das Theme entsteht, werden Schnittstellen angebunden.
Für die Terminplanung ist deshalb nur eine Frage interessant: Welche Phasen liegen hintereinander, weil die eine ohne die andere nicht anfangen kann?
Diese Kette ist kurz und in fast jedem Projekt dieselbe:
Bestandsaufnahme → Zielstruktur → Datenübernahme → Abgleich → Cutover.
Alles andere kann daneben laufen. Das ist die praktisch nützlichste Erkenntnis aus dieser Grafik, weil sie zwei sehr verbreitete Beschleunigungsversuche entwertet. Zusätzliche Entwicklerkapazität hilft dem Theme, das ohnehin nicht der Engpass ist. Und das Theme früher zu starten hilft ebenfalls nichts, weil es früher fertig wird und dann wartet.
Was den Termin bewegt, ist ausschließlich, wie schnell die Kette durchläuft. Und die Kette besteht überwiegend aus Entscheidungen, nicht aus Arbeit.
Zwei Uhren, die unterschiedlich schnell laufen
In Migrationsprojekten laufen zwei Uhren nebeneinander, und die Verwechslung der beiden erzeugt die meisten unangenehmen Gespräche.
Die eine Uhr misst Aufwand: Personentage, die tatsächlich in Arbeit fließen. Ein mittlerer Wechsel liegt hier oft im Bereich von 40 bis 90 Personentagen auf Agenturseite — eine Zahl, die im Angebot steht, weil sie den Preis bestimmt.
Die andere Uhr misst Kalenderzeit: die Spanne zwischen Kick-off und Go-live. Sie liegt bei denselben Projekten bei zwölf bis zwanzig Wochen.
Die Differenz zwischen beiden ist keine Ineffizienz. Sie ist die Summe aller Momente, in denen gewartet wird: auf eine Freigabe, auf einen Datenexport, den der bisherige Dienstleister liefern muss, auf einen Zugang zum ERP, auf eine Rückmeldung, welche der drei Versandregeln denn nun die gültige ist.
Diese Wartezeiten sind der Grund, warum ein Wechsel, der mit 60 Personentagen kalkuliert ist, nicht in sechs Wochen fertig wird, obwohl zwei Personen daran arbeiten. Und sie sind auch der Grund, warum ein Projekt gelegentlich deutlich schneller läuft als geplant: nicht, weil schneller gearbeitet wurde, sondern weil auf der Kundenseite jemand saß, der innerhalb eines Tages entscheiden durfte.
Wenn Sie also in einem Angebot Personentage sehen und daraus einen Termin ableiten wollen, brauchen Sie einen Faktor. In der Praxis liegt er zwischen zwei und drei — und er beschreibt nicht die Agentur, sondern Ihre eigene Organisation.
Was den Termin tatsächlich verschiebt
Terminrisiko
Die vier größten Verzögerungen liegen nicht bei der Entwicklung
Wenn ein Wechsel später fertig wird als geplant, liegt das selten daran, dass programmiert werden musste. Es liegt daran, dass etwas fehlte, auf das die Entwicklung angewiesen war — eine Entscheidung, ein Export, ein Zugang. Deshalb ist die Frage nach der Projektdauer immer auch eine Frage danach, wer im eigenen Haus wie schnell antwortet.
Zwei dieser Zeilen verdienen eine Erläuterung, weil sie zusammen die Mehrheit aller gerissenen Termine erklären.
Der Scope-Zuwachs während der Umsetzung ist die teuerste Position, und er beginnt fast nie mit einer großen Forderung. Er beginnt mit einem naheliegenden Satz in Woche neun: „Wenn wir jetzt schon dabei sind, könnten wir doch gleich …“ — und dahinter steht dann ein B2B-Bereich, eine zweite Sprache oder ein Konfigurator. Jedes dieser Themen ist für sich berechtigt. Das Problem ist der Zeitpunkt: Der Plan liegt zu diesem Punkt bereits, die Reihenfolge steht, und die neue Anforderung greift in die Kette ein, statt sich danebenzulegen.
Produktdaten, die im Fließtext stehen, sind die häufigste Position. In gewachsenen Shopware-, Magento- oder OXID-Installationen sind Maße, Materialien und Kompatibilitäten über die Jahre in Beschreibungstexte gewandert, weil das schneller ging als ein neues Attribut. Beim Import gibt es für diese Werte kein Zielfeld, und die Frage, ob man sie herauslöst oder mitschleppt, taucht mitten im Projekt auf — mit ungünstigem Timing, weil sie eigentlich vor dem Mapping beantwortet gehört. Warum sich diese Entscheidung nicht auf später verschieben lässt, haben wir in KI-Suche und Produktdaten ausführlicher beschrieben.
Auffällig an der Grafik ist die rechte Spalte. Vier der sechs größten Verzögerungen haben ihre Ursache nicht bei der Agentur, sondern beim Händler selbst oder bei Dritten. Das ist keine Schuldzuweisung, sondern eine Planungsinformation: Der Hebel auf den Termin liegt überwiegend dort, wo er selten gesucht wird.
Der wirksamste Hebel ist kein Tempo, sondern eine Sortierung
Der wirksamste Hebel
Sortieren statt beschleunigen: drei Listen vor dem Projektstart
Ein Wechsel wird nicht schneller, indem mehr Leute daran arbeiten. Er wird schneller, indem weniger darin steckt. Die einzige Liste, die wirklich unverhandelbar ist, ist überraschend kurz — sie enthält nur, was mit der Abschaltung des Altsystems verloren ginge. Alles andere ist eine Entscheidung.
Zum Cutover
Muss am Tag der Abschaltung stehen
- Produkte, Varianten, Preise und Bestände vollständig übernommen
- Bestellhistorie und Kundenkonten übernommen, Passwort-Reset vorbereitet
- Weiterleitungen für alle bisherigen URLs, inklusive Kategorien und Filterseiten
- Checkout, Zahlarten, Versandregeln und Steuersätze getestet
- Rechtstexte, Rechnungslayout und Bestellbestätigungen produktiv
- Bewertungen exportiert und zugeordnet — später gibt es keinen Export mehr
Alles hier hängt daran, dass das Altsystem danach nicht mehr erreichbar ist. Nachholen ist entweder unmöglich oder teuer.
Woche 2 bis 8
Kann nach dem Go-live folgen
- Zweite Sprache oder zusätzlicher Markt
- Loyalty-Programm und Kundenclub
- Feinschliff an Kategorieseiten und Filtern
- Erweiterte Personalisierung und Empfehlungen
- Automatisierungen in Flow jenseits der Basisstrecken
- A/B-Tests und Conversion-Optimierung
Verschiebt den Termin nicht und wird nach dem Launch mit echten Daten sogar besser entschieden.
Nicht in dieses Projekt
Gehört in ein eigenes Vorhaben
- Markenrelaunch mit neuem Corporate Design
- ERP-Wechsel parallel zum Shopwechsel
- Sortimentsbereinigung als Voraussetzung für den Import
- Neues Fotokonzept für alle Produktbilder
- B2B-Portal, wenn es heute nicht existiert
Jeder dieser Punkte ist berechtigt — nur nicht als Teil eines Wechsels, dessen Termin am Cutover hängt.
Praktisch heißt das: Die erste Liste wird gemeinsam mit der Agentur festgezurrt, die zweite bekommt Termine nach dem Go-live, und die dritte bekommt ein eigenes Angebot. Was in keiner der drei Listen steht, ist während der Umsetzung kein Thema — das ist der ganze Trick.
Die mittlere Spalte ist in Gesprächen die schwierigste, weil sie nach Zurückstellen klingt. Tatsächlich ist sie das Gegenteil: Was nach dem Go-live entschieden wird, wird mit echten Daten entschieden — mit tatsächlichem Nutzungsverhalten im neuen Shop statt mit Annahmen aus dem alten.
Die dritte Spalte ist die, die am meisten Geld spart. Ein Markenrelaunch parallel zum Systemwechsel verdoppelt nicht den Aufwand, sondern die Anzahl der offenen Entscheidungen — und Entscheidungen sind, wie oben gezeigt, die eigentliche Währung im Terminplan. Dasselbe gilt für einen gleichzeitigen ERP-Wechsel: zwei Systeme, die beide neu sind, und eine Schnittstelle dazwischen, für die es auf keiner Seite einen erprobten Zustand gibt.
Diese Trennung ist übrigens kein Verzicht. Sie ist eine Reihenfolge. Wie sich das mit den übrigen Projektrisiken verzahnt, steht in Risikomanagement bei Shopify-Migrationen.
Wenn der Termin feststeht: rückwärts rechnen
Manche Wechsel haben kein freies Startdatum, sondern ein festes Ende — ein auslaufender Hostingvertrag, ein Supportende, eine Saison, in die man nicht hineinmigrieren will. In dem Fall lohnt es sich, die Kette rückwärts zu rechnen statt vorwärts zu planen.
Von hinten sieht ein mittlerer Wechsel so aus:
- Cutover-Wochenende. Der letzte Datenabgleich, die Umstellung der Domain, die Aktivierung der Weiterleitungen. Ein bis zwei Tage, plus eine Woche erhöhte Aufmerksamkeit danach.
- Minus zwei bis vier Wochen: Abnahme und Testbestellungen. Echte Bestellungen durch den kompletten Prozess, inklusive Storno, Rückgabe und Rechnung. Diese Phase wird am häufigsten gekürzt und rächt sich am zuverlässigsten.
- Minus weitere vier bis acht Wochen: Datenübernahme. Mehrere Testimporte, jeweils mit Abgleich. Der erste ist immer der schlechteste — das ist normal und eingeplant.
- Minus weitere drei bis sechs Wochen: Zielstruktur. Kategorien, Metafelder, Optionen, Kundengruppen. Reine Entscheidungszeit, wenig Umsetzung.
- Minus weitere zwei bis vier Wochen: Bestandsaufnahme. Was liegt im Altsystem, was hängt an Erweiterungen, wer hat Zugang, welche Schnittstellen existieren.
In Summe: Wenn Ihr Wunschtermin in weniger als zwölf Wochen liegt, ist er für einen mittleren Shop nicht seriös zu halten — es sei denn, die Bestandsaufnahme ist bereits erledigt und die Zielstruktur steht. Beides lässt sich vorziehen, bevor überhaupt eine Agentur beauftragt ist. Das ist der einzige echte Beschleuniger, den es gibt.
Für die Bestandsaufnahme selbst gibt es eine erprobte Reihenfolge; für den Wechsel von Magento haben wir sie in der Migrations-Checkliste aufgeschrieben.
Vier Sätze aus Angeboten, hinter denen ein Terminrisiko steckt
„Datenimport inklusive.“ Eine Zeile, hinter der drei sehr verschiedene Dinge stehen können: Produkte allein, Produkte plus Kunden und Bestellungen, oder zusätzlich Bewertungen, Attributsets und Bilder mit Alt-Texten. Fragen Sie nach der Liste, nicht nach dem Preis. Was nicht in der Liste steht, wird in Woche zwölf zum Thema.
„Weiterleitungen werden eingerichtet.“ Für Produkte und Kategorien ist das Standard. Für Filterseiten, Blogbeiträge, Landingpages aus alten Kampagnen und Dateien im Downloadbereich ist es das nicht. Der Unterschied ist im Angebot eine Formulierung und im Projekt eine Woche — und danach ein Sichtbarkeitsproblem, wie in 301-Redirects bei Shopify-Migrationen beschrieben.
„Go-live in acht Wochen.“ Möglich, aber nur unter einer Bedingung: Zielstruktur und Bestandsaufnahme sind vorher fertig. Wenn ein Angebot acht Wochen nennt und die Bestandsaufnahme als erste Position enthält, sind es keine acht Wochen.
„Bestände werden übernommen.“ Bestände sind zum Zeitpunkt des Cutovers ein bewegter Wert, kein Datensatz. Wie der Übergabepunkt genau definiert wird — und warum die Bewertung des Endbestands eine eigene Abstimmung braucht — steht in Endbestand und Bestandswert bei der Migration.
Checkliste
Vor dem Kick-off: zehn Punkte, die den Termin halten
Abzuarbeiten, bevor die erste Zeile umgesetzt wird. Jeder Punkt, der offen bleibt, verlängert die Kette. Ihre Häkchen bleiben in diesem Browser gespeichert.
0 von 10 erledigt
Was für Ihre Ausgangslage realistisch ist
| Ihre Situation | Realistischer Rahmen bis Go-live |
|---|---|
| Unter 500 Artikel, Standard-Theme, keine Schnittstelle | 6–10 Wochen, wenn die Produktdaten sauber sind |
| 2.000–10.000 Artikel, ein Markt, eine ERP-Schnittstelle | 12–20 Wochen — der Regelfall dieses Artikels |
| Über 20.000 Artikel oder mehrere Märkte und Sprachen | 20–36 Wochen, mit gestaffeltem Go-live je Markt |
| B2B mit Kundengruppen, Preislisten und Freigabeprozessen | Aufschlag von 4–8 Wochen allein für Struktur und Tests |
| Konfigurierbare oder erklärungsbedürftige Produkte | Aufschlag von 4–10 Wochen, abhängig von der Variantenlogik |
| Abo- oder Vertragsmodelle im Bestand | Aufschlag von 4–8 Wochen; die Bestandsverträge sind der Engpass, nicht das Frontend |
| Bestandsaufnahme und Zielstruktur liegen bereits vor | 4–6 Wochen weniger als der jeweilige Wert oben |
| Markenrelaunch oder ERP-Wechsel soll parallel laufen | Kein Rahmen — trennen Sie die Projekte, sonst terminiert keines |
Diese Werte sind Orientierung, keine Zusage. Sie verschieben sich mit genau einer Größe zuverlässig nach oben oder unten, und es ist nicht die Artikelzahl: Es ist die Zeit, die zwischen einer offenen Frage und ihrer Beantwortung vergeht.
Was Sie aus diesem Artikel mitnehmen sollten
Die Frage „Wie lange dauert das?“ hat bei einem Systemwechsel eine ehrliche Antwort, und sie ist unbequemer als eine Wochenzahl: So lange, wie Ihre Organisation braucht, um die Kette abzuarbeiten.
Die Entwicklung ist dabei fast nie der Engpass. Das Theme ist in aller Regel fertig, bevor die Daten stimmen. Was den Termin bestimmt, sind drei Dinge, die alle vor dem ersten Umsetzungstag geklärt werden können: Was liegt im Altsystem, in welcher Struktur soll es ankommen, und wer darf das entscheiden.
Wer diese drei Punkte vor dem Kick-off klärt, verkürzt einen mittleren Wechsel um vier bis sechs Wochen — ohne einen einzigen zusätzlichen Personentag. Das ist der größte verfügbare Hebel, und er kostet nichts außer der Bereitschaft, früh zu entscheiden.
Wenn bei Ihnen ein Wechsel ansteht und Sie wissen wollen, wie lange er in Ihrer konkreten Ausgangslage dauert: Lassen Sie uns sprechen. Wir sehen uns Ihr Altsystem, Ihre Datenlage und Ihre Entscheidungswege an und nennen Ihnen einen Rahmen, der die Wartezeiten enthält — nicht nur die Personentage. Wie wir Migrationen insgesamt aufsetzen, steht auf Shopsystem-Migration.
