Plattformwechsel, Neuaufbau oder bleiben: Wann ist eine Migration den Aufwand wert?

Neuaufbau oder Plattformwechsel? Meist wird das als Ja oder Nein zur Migration verhandelt. Dabei gibt es drei Antworten, nicht zwei: bleiben, auf der aktuellen Plattform neu aufbauen oder auf eine andere Plattform wechseln. Welche stimmt, hängt davon ab, wo das Problem tatsächlich liegt. Lässt es sich dort beheben, wo es entsteht, bleiben Sie. Liegt es daran, wie der Shop gebaut wurde, auf einer Plattform, die sonst alles kann, bauen Sie neu auf. Liegt es in der Plattform selbst, wechseln Sie. Eine Migration bringt so viel Unruhe mit sich, dass Bleiben oft die richtige Entscheidung ist. Allerdings nur so lange, bis die laufenden Kosten des Status quo die einmaligen Kosten eines Wechsels übersteigen. Ab diesem Punkt ist Bleiben die teure Option. Die Entscheidung ist eine Rechnung, und die kann in beide Richtungen ausgehen.

Dieser Beitrag liefert den Rahmen, um diese Entscheidung ehrlich zu treffen. Die meisten Texte zum Thema sollen Sie in Richtung Migration schieben, weil ihre Autoren Migrationen verkaufen. So wird die Entscheidung auf Wechseln oder nicht verkürzt. Die Option, die einen großen Teil der Fälle zu einem Bruchteil der Kosten und des Risikos löst, fällt dabei unter den Tisch. Im Folgenden holen wir diese dritte Option zurück, zeigen die Regel, die zwischen allen dreien entscheidet, und rechnen von beiden Seiten. Diese Rechnung zeigt nicht nur, ob sich ein Wechsel lohnt, sondern auch, ob Sie zu lange gewartet haben oder zu früh wechseln würden.

Drei Optionen, nicht zwei

Benennen Sie zuerst alle drei, denn die mittlere geht am leichtesten verloren. Bleiben heißt: aktuelle Plattform und aktuellen Build behalten und das Problem dort angehen, wo es entsteht. Sie automatisieren eine Aufgabe, verbessern einen Prozess oder reparieren eine Schnittstelle, ohne großes Projekt. Neuaufbau heißt: auf derselben Plattform bleiben, den Shop aber sauber neu umsetzen. Sie bauen die technischen Schulden aus Jahren individueller Anpassungen ab, strukturieren neu, was über die Zeit angeflanscht wurde, und liefern einen sauberen Build auf einem Fundament, das nie das Problem war. Plattformwechsel heißt: auf eine ganz andere Plattform umziehen, mit allem, was dazugehört. Datenmigration, neu gebaute Schnittstellen, die Sicherung Ihrer Google-Rankings und eine Organisation, die sich umstellen muss.

Die drei Optionen steigen klar in Kosten, Unruhe und Risiko. Bleiben ist am günstigsten und am wenigsten störend, bewirkt aber auch am wenigsten. Ein Neuaufbau ist ein echtes Projekt mit echten Kosten, bleibt aber auf vertrautem Terrain: dieselbe Plattform, derselbe Admin, kein Migrationsrisiko für Traffic oder Daten. Der Plattformwechsel ist die größte, störendste und teuerste der drei Optionen. Er ist aber auch die einzige, die eine echte Grenze der Plattform beseitigt. Der häufigste Fehler: Teams machen aus dieser Abstufung ein Entweder-oder, also wechseln oder nichts tun. Damit fällt der Neuaufbau stillschweigend weg, und das wird in beide Richtungen teuer. Manche Teams landen so in einer kompletten Migration für ein Problem, das ein Neuaufbau gelöst hätte. Andere bleiben auf einem kaputten Build sitzen, weil die einzige Alternative, die sie in Betracht gezogen haben, eine Migration war, die sie sich nicht zugetraut haben.

Die Frage, die entscheidet: Wo liegt das Problem?

Eine einzige Frage ordnet die drei Optionen, und es ist dieselbe Diagnose, die sich durch diese ganze Artikelreihe zieht: Wo liegt das Problem wirklich? Ein Symptom wie langsame Releases oder ein Berg an Workarounds verrät seine Ursache nicht. Und jede der drei Optionen antwortet auf eine andere Ursache.

Würde das Problem mit Ihnen auf jede andere Plattform umziehen, ist es weder ein Plattform- noch ein Build-Problem, und die Antwort lautet: bleiben. Gemeint sind etwa ein Prozess ohne klare Verantwortung, eine Aufgabe, die niemand automatisiert hat, oder eine Schnittstelle, die sich auf dem aktuellen Stack bauen ließe. Beheben Sie es dort, wo es liegt. Für etwas, das in Ihren Abläufen steckt und nicht in Ihrer Technik, braucht es weder Neuaufbau noch Migration. Liegt das Problem im Build, kann die Plattform zwar, was Sie brauchen, aber die Umsetzung steckt in technischen Schulden fest. Jede Änderung ist teuer, weil der Shop so zusammengesetzt wurde, nicht weil die Plattform es nicht könnte. Dann lautet die Antwort: Neuaufbau. Eine saubere Neuumsetzung auf derselben Plattform beseitigt die Einschränkung ohne das Risiko eines Umzugs. Liegt das Problem in der Plattform selbst, weil die Architektur wirklich nicht leisten kann, was Ihr Unternehmen heute braucht, oder weil der Support ausläuft, dann hilft kein Neuaufbau auf dieser Plattform. Die Antwort lautet: wechseln.

Was Neuaufbau und Plattformwechsel trennt, ist ein einziger Test: Würde ein sauberer, fachkundiger Neuaufbau auf der aktuellen Plattform die Einschränkung beseitigen? Wenn ja, bauen Sie neu auf. Das ist günstiger und bringt kein Migrationsrisiko mit sich. Bleibt die Einschränkung auch nach einem perfekten Neuaufbau bestehen, weil sie in der Architektur der Plattform steckt, dann stoßen Sie an die Decke der Plattform, und nur ein Wechsel hebt sie auf. Machen Sie diesen Test, bevor Sie irgendetwas durchrechnen. So lassen Sie keine Migration kalkulieren für ein Problem, das nie eine gebraucht hätte.

Die Optionen im Vergleich

Sind die Optionen definiert und die Leitfrage geklärt, lassen sich die Abwägungen klar gegenüberstellen.

Die Übersicht zeigt auch, wann eine Option die falsche Antwort ist. Jede Option hat einen Fall, in dem sie richtig ist, und einen, in dem sie ein teurer Fehler ist. Der Unterschied liegt immer darin, ob die Option dazu passt, wo das Problem liegt. Ein Neuaufbau gegen eine Plattformgrenze verschwendet ein Projekt und stellt Sie wieder vor dieselbe Wand. Ein Plattformwechsel wegen eines Build-Problems zahlt den höchstmöglichen Preis, um ein Problem umzuziehen, das ein Neuaufbau gelöst hätte. Und wer bei einer echten Plattformgrenze bleibt, lässt einfach den Zähler weiterlaufen.

Den Status quo beziffern: die monatliche Rechnung

Steht die richtige Option anhand der Ursache fest, bleibt die Frage nach dem Zeitpunkt. Hier kommt die Rechnung ins Spiel. Beginnen Sie mit den Kosten des Status quo, denn das ist die Zahl, die Teams ständig spüren und fast nie zusammenrechnen. Bleiben ist nicht kostenlos. Es schickt Ihnen jeden Monat eine Rechnung, und die besteht aus drei Posten, die sich tatsächlich addieren lassen.

Der erste Posten sind Ausgaben, die ausgleichen, was die Plattform nicht kann: Apps, Konnektoren und individuelle Schnittstellen, die nur existieren, um Lücken zu stopfen. Rechnen Sie den Jahresbetrag zusammen. Der zweite ist Entwicklerzeit, die in Wartung fließt statt in Neues. Halten Sie 90 Tage lang fest, wohin die Stunden Ihrer Entwickler gehen, und trennen Sie die Stunden, die bestehende Funktionen am Laufen halten, von denen, in denen Neues entsteht. Überwiegt die Wartung, belastet die Plattform nicht nur Ihr Budget, sondern auch Ihre Roadmap. Diese Kosten tauchen fast nie auf der Rechnung des Plattformanbieters auf, und genau deshalb zählt sie niemand mit. Der dritte ist Umsatz, der Ihnen entgeht, weil der Shop noch nicht kann, was gerade gebraucht wird: der verschobene Launch, der Markt, den Sie nicht erschließen, das Feature, das als Großprojekt angeboten wird. Addieren Sie die drei Posten über ein Jahr, und Sie haben die echte Rechnung fürs Bleiben. Gegen diese Zahl wägen Sie einen Wechsel ab. Die meisten Teams stellen fest, dass sie höher ist als die Lizenzgebühr, die sie bisher für die Kosten der Plattform gehalten haben.

Den Wechsel beziffern, und was zu langes Warten kostet

Auf der anderen Seite der Waage stehen die einmaligen Kosten eines Wechsels, und ehrlich gerechnet liegen sie über dem Angebot. Eine Migration kostet Implementierung, Datenmigration, neu gebaute Schnittstellen, die Sicherung Ihrer Google-Rankings, Schulungen und das Ausfallrisiko rund um den Go-live. Migrationen sprengen außerdem häufig den Rahmen. Eine realistische Zahl enthält deshalb einen Puffer für Korrekturen, die nach dem Launch auftauchen. Die wichtigste Korrektur an dieser Stelle: Die Kosten hängen stärker davon ab, wovon Sie weggehen, als davon, wohin Sie wechseln. Die angesammelte Komplexität, die individuelle Logik, die verknoteten Schnittstellen bestimmen den Preis, nicht das Logo des Ziels. Rechnen Sie einen Wechsel über drei Jahre Gesamtkosten durch und nicht gegen eine Lizenzgebühr. Sonst ist der Vergleich nicht ehrlich.

Dann wägen Sie das gegen die monatliche Rechnung ab, in beide Richtungen, denn Sie können auf zwei Arten danebenliegen. Wer zu früh wechselt, zahlt die höchsten einmaligen Kosten, um ein Problem zu lösen, das eine günstigere Option beseitigt hätte. Wer zu lange bleibt, lässt die monatliche Rechnung zu dem anwachsen, was Plattformstrategen eine Untätigkeitssteuer nennen. Sie zahlen weiter für die Bremse, auch wenn Sie damit längst den Wechsel hätten finanzieren können. So wird Bleiben unbemerkt zur teuersten Option auf dem Tisch, obwohl es sich wie die sichere anfühlt. Der Kipppunkt ist erreicht, wenn die aufgelaufene Rechnung fürs Bleiben die einmaligen Kosten eines Wechsels übersteigt, bereinigt um die Unruhe, die ein Wechsel verursacht. Davor ist Bleiben vernünftig. Danach zahlen Sie in Raten für eine Migration, die Sie nie bekommen. Liegt die Einschränkung wirklich in der Plattform, ist die nächste Frage, ob ein Wechsel etwa zu Shopify Plus Ihre konkrete Einschränkung tatsächlich behebt. Sie verdient dieselbe Prüfung wie die Entscheidung für einen Wechsel überhaupt: Wo liegt das Problem? Migrationskosten gegen die tatsächliche Bremse des Status quo zu rechnen, lohnt sich, bevor Sie sich in eine Richtung festlegen. Als Shopify Platinum Partner macht Flatline genau diese Rechnung mit einer Marke, bevor wir einen Wechsel empfehlen. Denn die ehrliche Antwort lautet manchmal Neuaufbau und manchmal Bleiben.

Wählen Sie Ihre aktuelle Plattform

Spricht die Rechnung für einen Plattformwechsel, stellt sich als Nächstes die Frage, was der Umzug von Ihrer heutigen Plattform aus bedeutet. Jeder Leitfaden unten behandelt für eine Ausgangsplattform die Daten, die Schnittstellen, SEO und die Risiken rund um den Go-live.

Bevor Sie einen Leitfaden öffnen, prüfen Sie, ob Sie Ihrer Plattform wirklich entwachsen sind, und wenn ja, planen Sie die Migration entlang des Umsatzes, damit das Umsatzstärkste zuerst umzieht und jede Phase die nächste mitfinanziert.

Wenn Sie den Wechsel mit einem Team planen und umsetzen möchten, lesen Sie, wie wir eine Shopify-Migration angehen.

Häufig gestellte Fragen

Soll ich die Plattform wechseln oder auf der aktuellen neu aufbauen?

Fragen Sie sich, ob ein sauberer, fachkundiger Neuaufbau auf Ihrer aktuellen Plattform die Einschränkung beseitigen würde. Wenn ja, bauen Sie neu auf. Das kostet weniger und bringt kein Migrationsrisiko für Ihre Daten, Ihren Traffic oder Ihre Schnittstellen. Steckt die Einschränkung in der Architektur der Plattform, sodass sie selbst einen perfekten Neuaufbau übersteht, dann stoßen Sie an die Decke der Plattform, und nur ein Wechsel hebt sie auf. Entscheidend ist, ob das Problem im Build liegt oder in der Plattform.

Wann ist Bleiben besser als ein Plattformwechsel?

Wenn das Problem mit Ihnen umziehen würde, weil es in Ihren Prozessen, in unklaren Zuständigkeiten oder in einer Lösung steckt, die Sie auf dem aktuellen Stack bauen könnten. Dann ist es richtig, zu bleiben und es vor Ort zu beheben, denn weder ein Neuaufbau noch eine Migration löst ein Problem in Ihren Abläufen. Bleiben ist auch richtig, solange die monatlichen Kosten des Status quo unter den einmaligen Kosten eines Wechsels liegen. Am Kipppunkt ändert sich das: Dort übersteigt die aufgelaufene Bremse, was ein Wechsel kosten würde.

Wie berechnet man, ob sich ein Plattformwechsel lohnt?

Rechnen Sie beide Seiten durch. Auf der einen Seite addieren Sie die monatliche Rechnung fürs Bleiben: jährliche Ausgaben für Apps und individuelle Lösungen, die Lücken der Plattform ausgleichen, den Anteil der Entwicklerstunden, der in Wartung statt in Neues fließt, und den Umsatz, der Ihnen entgeht. Auf der anderen Seite rechnen Sie den Wechsel über drei Jahre Gesamtkosten durch, inklusive Migration, Schnittstellen, Schulung, Ausfallrisiko und einem Puffer für Mehraufwand. Übersteigt die aufgelaufene Rechnung die einmaligen Kosten, bereinigt um die Unruhe, lohnt sich der Wechsel.

Was ist der Unterschied zwischen Neuaufbau und Plattformwechsel?

Bei einem Neuaufbau wird Ihr Shop auf derselben Plattform neu umgesetzt. Technische Schulden aus Anpassungen werden abgebaut und ein unübersichtlicher Build wird neu strukturiert, ohne die zugrunde liegende Technik zu ändern. Es gibt also keine Datenmigration und kein Risiko für Ihren Traffic. Bei einem Plattformwechsel ziehen Sie auf eine ganz andere Plattform um, mit Migration, neu gebauten Schnittstellen und der Sicherung Ihrer Google-Rankings. Ein Neuaufbau löst ein Build-Problem auf einer Plattform, die eigentlich genügt. Ein Plattformwechsel ist für den Fall, dass die Plattform selbst die Einschränkung ist.

Ist ein Plattformwechsel immer teurer als ein Neuaufbau?

In der Regel ja, denn ein Wechsel bringt Kosten für Migration, Schnittstellen und Change-Management mit sich, die ein Neuaufbau auf derselben Plattform nicht hat. Genau deshalb zählt die Option Neuaufbau. Liegt das Problem im Build und nicht in der Plattform, löst ein Neuaufbau es mit weniger Kosten und weniger Risiko. Ein Plattformwechsel ist seinen höheren Preis nur wert, wenn die Plattform selbst die Einschränkung ist, denn die kann ein Neuaufbau nicht aufheben.

Das Wichtigste in Kürze

• Die Frage nach dem Plattformwechsel hat drei Antworten, nicht zwei: bleiben, auf der aktuellen Plattform neu aufbauen oder wechseln. Wer sie auf „wechseln oder nicht“ verkürzt, streicht die mittlere Option, und genau die löst viele Fälle günstig.

• Welche Option passt, hängt davon ab, wo das Problem liegt. Zieht es auf jede Plattform mit um, bleiben Sie. Liegt es im Build, bauen Sie neu auf. Stoßen Sie wirklich an die Decke der Plattform, wechseln Sie. Der Test dafür: Bleibt die Einschränkung auch nach einem sauberen Neuaufbau bestehen?

• Beziffern Sie den Status quo als monatliche Rechnung: Apps und Schnittstellen, die Lücken ausgleichen, Entwicklerstunden, die in Wartung statt in Neues fließen, und Umsatz, der Ihnen entgeht. Sie ist meist höher als die Lizenzgebühr, die Teams für die Kosten der Plattform halten.

• Rechnen Sie den Wechsel über drei Jahre durch, nicht gegen eine Lizenzgebühr. Und denken Sie daran: Die Kosten hängen stärker davon ab, wovon Sie weggehen, als vom Ziel. Planen Sie einen Puffer ein, denn Migrationen dauern länger und kosten mehr als geplant.

• Die Entscheidung kann in zwei Richtungen scheitern. Wer zu früh wechselt, zahlt den höchsten Preis für ein kleineres Problem. Wer über den Kipppunkt hinaus bleibt, macht aus der Untätigkeitssteuer eine Migration, die in Raten bezahlt wird, ohne dass etwas geliefert wird.

Alle drei Optionen offenzuhalten lohnt sich, weil die ehrliche Antwort von Fall zu Fall anders ausfällt. Ein Rahmen, der nur „migrieren“ sagen kann, findet sie nicht. Manche Shops haben ein Problem, das mit auf jede Plattform umziehen würde. Das beheben sie am Montag und behalten ihre Plattform noch jahrelang. Andere betreiben eine gute Plattform unter einem Build, der ersetzt werden muss. Ein Neuaufbau fühlt sich dann an wie ein neuer Shop, ohne das Risiko eines Umzugs. Und manche sind wirklich an der Decke angekommen. Jeder Monat, den sie warten, ist eine Rate auf eine Migration, die sie ohnehin machen werden, nur später und teurer. Finden Sie heraus, wo Ihr Problem liegt, und rechnen Sie beide Seiten der Waage durch. Dann ist die Entscheidung zwischen Neuaufbau und Plattformwechsel kein Sprung ins Ungewisse mehr, sondern eine Zahl, die Sie verteidigen können.