Playbook unter Senior-Führung: Umsatz beim Plattformwechsel im E-Commerce schützen

Eine Migration der E-Commerce-Plattform gelingt, wenn Sie sie als operatives Vorhaben führen und nicht als Website-Relaunch: gestaffelter Rollout, vollständige Datenparität und Weiterleitungen, die SEO zuerst denken, alles unter der technischen Verantwortung eines Senior-Profils. Bevor Sie etwas unterschreiben, halten Sie drei Dinge verbindlich fest: eine vollständige 1:1-Weiterleitungskarte, einen Plan für den Datenabgleich über jeden Kunden- und Bestelldatensatz sowie eine Staging-Umgebung, die die Produktion exakt abbildet. Fehlt eines der drei, verspielen Sie Umsatz, den Sie bereits erwirtschaftet haben.

---

Kurz zusammengefasst:

• Legen Sie Weiterleitungskarte, Plan für den Datenabgleich und Staging-Umgebung fest, bevor die Migration startet. So verhindern Sie Umsatzverluste.

• Wählen Sie bei Sortimenten über 500 Artikeln oder bei laufenden Abonnements einen gestaffelten Ansatz. Das senkt das Risiko und hält Probleme lokal begrenzt.

• Migrieren Sie Produktbewertungen, Treuepunkte und Zahlungs-Token mit hoher Priorität und korrekt, und prüfen Sie die Bestände in einem detaillierten Abgleich auf Abweichungen.

• Setzen Sie eine umfassende SEO-Strategie mit geprüften Weiterleitungen, übernommenen Metadaten und eingereichter Sitemap um. So bleiben Traffic-Einbruch und Ranking-Verluste klein.

• Beobachten Sie in den ersten zwei Wochen nach dem Livegang konsequent Abschlussquoten im Checkout, Traffic und Supportanfragen, um Probleme früh zu erkennen und bei Bedarf sofort zurückzurollen.

---

Inhaltsverzeichnis

• Was ist eine E-Commerce-Plattform-Migration, und worin unterscheidet sie sich vom Replatforming?

• Warum Migrationen scheitern: die Risiken, die wirklich Umsatz kosten

• Migrationsansätze: gestaffelt, Cutover, Headless und SaaS zu SaaS

• Welche Schritte umfasst eine E-Commerce-Migration?

• Datenmigration im Detail: Was muss mit, und wie?

• SEO-Checkliste für die Migration: Rankings absichern

• Wie testen und staffeln Sie eine Migration vor dem Livegang?

• Wie lange dauert eine E-Commerce-Migration, und was treibt die Kosten?

• Wer verantwortet was: Governance und das Lagezentrum am Launch-Tag

• Was Sie nach dem Livegang überwachen sollten, und wann ein Rollback nötig wird

• Die Sicht von Ampersand: Migrationen unter Senior-Führung aus Zürich

• Drei Regeln, an die wir uns bei jeder Migration halten

• Wie Ampersand Migrations- und Replatforming-Projekte angeht

• Quellen

Was ist eine E-Commerce-Plattform-Migration, und worin unterscheidet sie sich vom Replatforming?

Eine E-Commerce-Plattform-Migration bedeutet, dass Sie Daten, Inhalte und Abläufe Ihres Shops von einem System in ein anderes überführen, meist weil die aktuelle Plattform nicht mitwächst, zu viel kostet oder Anbindungen blockiert, die Sie inzwischen brauchen. Replatforming ist ein verwandter, aber klar abzugrenzender Begriff, den Sie kennen sollten, bevor Sie ein Projekt aufsetzen: Gemeint ist eine Änderung der Architektur, also der Wechsel des zugrunde liegenden Technologie-Stacks und nicht bloss ein Umzug von Daten. Der Wechsel von einem Shopify-Shop zu einem anderen Shopify-Shop ist eine Migration. Der Wechsel von einem gewachsenen Monolithen zu einer Headless-Architektur mit API-first-Ansatz ist Replatforming, und dieser hat ein völlig anderes Risikoprofil und Budget.

Diese Unterscheidung ist wichtig, weil Anbieter und interne Teams Zeitpläne und Preise oft für einen Datenumzug eins zu eins kalkulieren und dann mitten im Projekt merken, dass die Kundschaft in Wahrheit eine komplette Neuordnung der Architektur will. Genau dieser Widerspruch ist eine der häufigsten Ursachen für ausufernden Umfang und gesprengte Budgets in diesem Bereich.

Warum Migrationen scheitern: die Risiken, die wirklich Umsatz kosten

Die meisten gescheiterten Migrationen scheitern nicht daran, dass die neue Plattform falsch war. Sie scheitern, weil drei absehbare Dinge nicht geführt wurden: Datenverlust, SEO-Einbruch und gebrochene Anbindungen.

Datenverlust ist selten total. Er ist selektiv und bleibt unsichtbar, bis sich eine Kundin beschwert. Produktbewertungen, Treuepunkte und die vollständige Bestellhistorie sind die Bestände, die Teams in einer hektischen Migration am häufigsten hintanstellen, und zugleich jene, deren Fehlen der Kundschaft zuerst auffällt. Wer sich anmeldet und die eigene Bestellhistorie nicht mehr findet oder das Treuepunkte-Konto auf null sieht, meldet sich nicht gelassen beim Support. Diese Person geht.

Der Verlust an SEO-Traffic ist der zweite grosse Fehlermodus, und er ist fast immer hausgemacht. Ändert sich die URL-Struktur ohne passende Weiterleitungskarte, sehen Suchmaschinen Tausende toter Links und stufen die Rankings entsprechend zurück. Ein structured replatforming plan with a verified redirect map and migrated metadata begrenzt den Traffic-Einbruch in der Regel auf ein kurzes Erholungsfenster. Ohne diesen Plan kann der Einbruch Monate dauern.

Fehlende oder gebrochene Anbindungen vervollständigen die Liste, und sie treffen den Betrieb, nicht nur das Marketing:

• Zahlungsanbieter, die gespeicherte Karten ablehnen, weil die Token nicht korrekt migriert wurden

• Abbrechende ERP- oder Bestandssynchronisation, was zu Überverkäufen oder Lieferengpässen führt

• Abo-Abrechnungssysteme, die doppelt belasten oder Verlängerungen stillschweigend nicht ausführen

• Analytics und Tracking-Pixel, die ausfallen und Ihnen am Launch-Tag die Sicht auf das Geschehen nehmen

Praxistipp: Machen Sie mit Ihrer technischen Leitung eine Übung nach dem Muster «Was bricht zuerst?», bevor Sie das Projekt zuschneiden. Listen Sie jedes System auf, das Ihren Shop berührt, und fragen Sie, welches davon leise statt laut ausfällt. Die leisen Ausfälle sind jene, die wochenlang Umsatz abziehen, bevor es jemand merkt.

Migrationsansätze: gestaffelt, Cutover, Headless und SaaS zu SaaS

Welche Replatforming-Strategie passt, hängt von Ihrer Risikobereitschaft ab, von den Kapazitäten Ihres technischen Teams und davon, wie viel Ausfallzeit Ihr Geschäft verkraftet.

Die gestaffelte Migration (Strangler-Muster) überführt jeweils einen Bereich Ihres Shops und lässt altes und neues System parallel laufen, bis alles übertragen ist. Das dauert länger und verlangt mehr Abstimmung, dafür erkennen Sie Probleme in einem eng begrenzten Bereich, bevor sie das ganze Sortiment betreffen. Dieser Ansatz passt zu grossen Sortimenten, komplexen B2B-Preisregeln oder Shops, bei denen Ausfallzeit echtes Geld kostet.

Der Big-Bang-Cutover schaltet alles auf einmal um, meist über ein Wochenende oder in einem Zeitfenster mit wenig Traffic. Er ist schneller umzusetzen und einfacher zu planen, aber es gibt kein teilweises Zurückrollen, wenn etwas bricht. Das funktioniert bei kleinem Sortiment, wenigen Anbindungen und wenn das Geschäft eine kurze Phase der Instabilität aushält.

Headless- oder Composable-Migrationen entkoppeln das Frontend vom Commerce-Backend. Das bringt langfristig mehr Flexibilität, macht das Testen aber deutlich aufwendiger, weil Sie nun eine API-Schicht prüfen müssen, die es vorher nicht gab.

Migrationen von SaaS zu SaaS verdienen besondere Vorsicht. Beim Wechsel zwischen zwei SaaS-Plattformen haben Sie meist auf keiner Seite direkten Datenbankzugriff, was einen riskanteren Cutover erzwingt als ein Umzug bei selbst gehosteten Systemen. Planen Sie zusätzliche Zeit für Delta-Abgleiche und ausgedehnte Sandbox-Prüfungen ein, denn eine phased migration with field-level data mapping and staging parity ist schwieriger umzusetzen, wenn Sie über zwei getrennte APIs statt über direkte Datenbankabfragen arbeiten.

Praxistipp: Wenn Sie unsicher sind, welcher Ansatz passt, wählen Sie den gestaffelten für alles mit mehr als 500 Artikeln oder mit laufender Abo-Abrechnung. Der zusätzliche Abstimmungsaufwand ist günstiger als ein gescheiterter Cutover.

Welche Schritte umfasst eine E-Commerce-Migration?

Eine Migration, die im Budget bleibt, folgt einer festen Abfolge, wobei jede Phase mit konkreten Ergebnissen abgeschlossen wird, bevor die nächste startet.

1. Analyse und Audit. Erstellen Sie eine vollständige Liste aller indexierten URLs, eine komplette Landkarte der Anbindungen (jedes System, das mit Ihrem Shop spricht) und eine Dateninventur über Produkte, Kundschaft, Bestellungen und Inhalte. Allein diese Phase kann bei einem mittelgrossen Sortiment ein bis zwei Wochen dauern.

2. Entscheide zu Plattform und Architektur. Wählen Sie die Zielplattform, halten Sie den Umfang schriftlich fest und lassen Sie das Leistungsverzeichnis unterschreiben. Hier beginnen Sie auch ein Entscheidungsprotokoll, eine laufende Aufzeichnung jeder Festlegung zum Umfang samt Begründung, damit niemand nach drei Wochen bereits geklärte Fragen neu aufrollt.

3. Aufbau von Shop und Anbindungen. Die Entwickler:innen bauen das neue Theme oder Frontend, während das Integrationsteam Zahlungen, ERP, Fulfillment und Analytics an das neue Backend anbindet.

4. Durchgänge der Datenmigration. Führen Sie zuerst eine grosse Erstübertragung durch, danach wiederholte Delta-Migrationen, die neue Bestellungen und Kundenaktivitäten nach dem ersten Durchgang erfassen. Machen Sie das bei einem laufenden Shop nie in einem einzigen Durchgang.

5. Staging und Qualitätssicherung. Testen Sie alles in einer Umgebung, die die Produktion abbildet, und zwar mit maskierten echten Daten statt mit erfundenen Platzhaltern.

6. Parallelbetrieb (optional, für umsatzstarke Shops). Leiten Sie einen kleinen Anteil des Live-Traffics auf das neue System, bevor Sie vollständig umschalten. So finden Sie Sonderfälle aus der Praxis, die das Staging nicht gezeigt hat.

7. Go-/No-go-Entscheid. Eine strukturierte Checkliste, kein Bauchgefühl, bestimmt, ob der Livegang stattfindet.

8. Stabilisierung. Die ersten zwei Wochen nach dem Livegang, in denen das Team die Kennzahlen täglich beobachtet und Probleme behebt, bevor sie sich aufschaukeln.

Jede Phase braucht eine namentlich benannte Verantwortung und ein definiertes Abschlusskriterium. Eine Phase ohne Verantwortliche ist eine Phase, die sich verzögert.

Datenmigration im Detail: Was muss mit, und wie?

Produkte und Kundendatensätze sind die offensichtlichen Objekte einer Migration. Ob sich der Livegang für die Kundschaft nahtlos anfühlt, entscheiden aber die weniger offensichtlichen: Produktbewertungen, Treuepunkte, laufende Abonnements und gespeicherte Zahlungs-Token.

Besonders Bewertungen sind ein unterschätzter Hebel für die Conversion. Eine Produktseite, die über Nacht ihre 400 Bewertungen verliert, wirkt auf neue Besucher:innen ungeprüft, auch wenn sich am Produkt selbst nichts geändert hat. Migrating verified-purchase review data before launch bewahrt den Conversion-Vorteil, den soziale Bestätigung bringt, und ist einer der Punkte, die leicht untergehen, weil Bewertungen oft in einer App von Drittanbietern statt in der Datenbank der Plattform liegen.

Die Zuordnung auf Feldebene ist die Hauptquelle für Datenfehler. Ein Feld «Kundengruppe» auf Ihrer alten Plattform lässt sich vielleicht nicht sauber auf ein «Kunden-Tag» der neuen abbilden, und wenn niemand diese Übersetzung dokumentiert, brechen Preisregeln oder Versandrabatte stillschweigend für ganze Kundensegmente weg. Erstellen Sie eine Zuordnungstabelle, bevor Sie das erste Migrationsskript schreiben: Quellfeld, Zielfeld, Transformationslogik und die Person, welche die Zuordnung freigibt.

Ein solider Abgleich läuft in zwei Durchgängen: eine grosse Erstübertragung, gefolgt von einer Delta-Migration, die alles seit dem ersten Durchgang Erstellte oder Geänderte erfasst, bis unmittelbar vor dem Umschalten. Führen Sie nach jedem Durchgang automatisierte Zählungen (Bestellsummen, Anzahl Kundenkonten, Anzahl Artikel) gegen das Quellsystem aus und markieren Sie jede Abweichung für die manuelle Prüfung.

Praxistipp: Zahlungs-Token lassen sich nur selten direkt zwischen Anbietern übertragen. Die meisten Gateways verlangen eine erneute Tokenisierung, die über die kartenausgebende Bank laufen muss und nicht nur über Ihre Datenbank. Starten Sie dieses Gespräch mit Ihrem Zahlungsdienstleister in Woche eins, nicht in Woche acht, denn platform-specific guidance on subscriptions and payment handling nennt diesen Punkt immer wieder als spät entdecktes Hindernis.

Die Kontinuität von Abonnements verdient dieselbe Sorgfalt. Ein verpasster Abrechnungszyklus während der Migration kostet nicht nur den Umsatz dieses Monats. Er löst meist auch eine Supportanfrage und eine Kündigung aus.

SEO-Checkliste für die Migration: Rankings absichern

Die Sichtbarkeit in der Suche ist der Wert, den die meisten Migrationen ungewollt beschädigen, und zugleich der am leichtesten vermeidbare Verlust auf dieser ganzen Liste.

• Erstellen Sie vor dem Livegang eine vollständige 1:1-Weiterleitungskarte, die jede alte URL auf ihr neues Gegenstück abbildet, nicht nur Kategorie- und Produktseiten, sondern auch Blogbeiträge, gefilterte Kollektionsansichten und alte Landingpages

• Übernehmen Sie Title-Tags, Meta-Beschreibungen und strukturierte Daten (Schema-Markup) exakt, statt sie von den Standardvorlagen der neuen Plattform überschreiben zu lassen

• Prüfen Sie, ob die Regeln in der robots.txt und die Canonical-Tags auf die richtigen neuen URLs zeigen, und kontrollieren Sie die hreflang-Angaben, wenn Sie in mehreren Sprachen oder Regionen tätig sind

• Reichen Sie die aktualisierten XML-Sitemaps direkt beim Livegang in der Google Search Console ein und bestätigen Sie die neue Domain oder Subdomain vor dem Livegang, nicht danach

Eine sauber umgesetzte Weiterleitungsstrategie mit übernommenen Metadaten und geprüften Sitemaps begrenzt den Traffic-Einbruch in der Regel auf eine kurze Erholungsphase statt auf einen dauerhaften Verlust. Rechnen Sie in den ersten zwei Wochen mit Schwankungen, während Suchmaschinen Ihre neuen URLs neu erfassen und indexieren. Das ist normal.

Nicht normal ist: ein anhaltender Rückgang über Tag 14 hinaus, eine Häufung von Crawl-Fehlern in der Search Console oder Rankings Ihrer 20 umsatzstärksten Suchbegriffe, die aus den Top 10 fallen. Richten Sie für die ersten zwei Wochen nach dem Livegang eine tägliche Kontrolle in der Search Console ein, insbesondere auf Ausschläge bei 404-Fehlern, die meist auf eine Lücke in Ihrer Weiterleitungskarte hinweisen, die beim Testen übersehen wurde.

Wie testen und staffeln Sie eine Migration vor dem Livegang?

Staging-Umgebungen schützen Sie nur, wenn sie die Produktion wirklich abbilden, bis hin zu Plugin-Versionen, Serverkonfiguration und Datenmenge.

1. Bauen Sie ein echtes Abbild der Produktion. Verwenden Sie maskierte echte Daten, also tatsächliche Kunden- und Bestelldatensätze mit entfernten Personenangaben, statt synthetischer Testdaten, die reale Sonderfälle nicht sichtbar machen.

2. Führen Sie funktionale Tests und Rauchtests der Anbindungen durch. Stellen Sie sicher, dass jede Verbindung zu Dritten, Zahlungsanbieter, ERP-Datenstrom, Fulfillment-API, durchgängig funktioniert und nicht nur eine Verbindung aufbaut.

3. Schliessen Sie die Abnahmetests (UAT) ab. Lassen Sie echte Mitarbeitende oder ein Kundenteam reale Kaufabläufe durchgehen, inklusive Sonderfällen wie Teillieferungen und Geschenkkarten.

4. Testen Sie die Zahlungsabläufe gezielt. Führen Sie Testtransaktionen über jede unterstützte Zahlungsart durch, auch über gespeicherte Karten, bevor echter Traffic darauf trifft.

5. Testen Sie Last und Leistung gegen definierte Vorgaben. Setting Core Web Vitals and load-time targets before launch verhindert, dass eine technisch funktionierende Website die Conversion-Rate durch lange Ladezeiten unbemerkt ruiniert.

Praxistipp: Dokumentieren Sie Ihre Go-/No-go-Checkliste mindestens eine Woche vor dem geplanten Livegang schriftlich und besetzen Sie am Launch-Tag ein Lagezentrum mit klar definierter Eskalationskette. Wer ein Rollback auslösen darf, sollte nie in der Hitze des Gefechts geklärt werden.

Wie lange dauert eine E-Commerce-Migration, und was treibt die Kosten?

Die Zeitpläne hängen stärker von Sortimentsgrösse und Komplexität der Anbindungen ab als von der Wahl der Plattform. Ein Shop im Mittelstand braucht typischerweise 8 bis 16 Wochen von der Analyse bis zur Stabilisierung, wobei grössere Sortimente, individuelle Checkout-Logik oder mehrere ERP-Anbindungen eher ans obere Ende führen.

Die Lizenzkosten der neuen Plattform sind selten der grösste Posten im Budget. Das sind meist diese:

• Neuaufbau der Anbindungen an Zahlungen, ERP, PIM und Fulfillment-Systeme, besonders wenn sich die APIs von alter und neuer Plattform stark unterscheiden

• Gleichstand bei individuellen Funktionen, also das Nachbauen massgeschneiderter Preisregeln, Treuelogik oder Checkout-Anpassungen, die auf der neuen Plattform nicht Standard sind

• Infrastruktur für den Parallelbetrieb, falls Sie den Traffic vor dem vollständigen Umschalten aufteilen

• Support und Stabilisierung nach dem Livegang, die leicht zu knapp budgetiert werden, weil Probleme in Woche zwei auftauchen und nicht in Woche eins

Fragen Sie bei Offertanfragen direkt: Was passiert, wenn der Datenabgleich nach der grossen Erstübertragung eine Abweichung zeigt? Wer verantwortet die erneute Tokenisierung der Zahlungsmittel? Was ist im Support nach dem Livegang enthalten, und wie lange? Anbieter, die darauf keine konkrete Antwort geben, haben zu wenige echte Migrationen begleitet, um zu wissen, wo die Überraschungen lauern.

Wer verantwortet was: Governance und das Lagezentrum am Launch-Tag

Migrationen, die im Budget bleiben, weisen jedem Ergebnis eine einzige verantwortliche Person zu, statt Entscheide als Gruppenaufgabe zu behandeln. Eine einfache RACI-Struktur genügt: eine Person ist für die Ausführung verantwortlich (Responsible), eine trägt die Letztentscheidung (Accountable), weitere werden beigezogen (Consulted), ein grösserer Kreis wird informiert (Informed).

• Technische Leitung: verantwortet Datenmigration und Anbindungen, trägt die Verantwortung für die Genauigkeit des Abgleichs

• Produkt- oder E-Commerce-Verantwortung: verantwortet Entscheide zum Umfang und gibt die Go-/No-go-Checkliste frei

• SEO-Verantwortung: verantwortet die Weiterleitungskarte und die Überwachung in der Search Console

• Support-Verantwortung: verantwortet die Ersteinschätzung von Kundenmeldungen in den ersten 72 Stunden

Was den Zeitplan tatsächlich hält, ist ein früh fixierter Umfang und ein laufend geführtes Entscheidungsprotokoll. Während der Launch-Stunden und in den ersten 72 Stunden danach halten Sie einen festen Rhythmus für Abstimmungen ein, zuerst stündlich, dann alle vier Stunden, mit klarem Eskalationsweg, falls ein Entscheid über die Befugnis der technischen Leitung hinausgeht.

Was Sie nach dem Livegang überwachen sollten, und wann ein Rollback nötig wird

Die ersten 14 Tage nach dem Livegang entscheiden, ob die Migration ein stiller Erfolg wird oder ein Problem, das langsam glimmt. Ein festgelegter Überwachungsrhythmus über 14 Tage findet Rückschritte, solange sie noch günstig zu beheben sind.

1. Prüfen Sie täglich die Abschlussquoten im Checkout. Ein Rückgang um mehr als ein paar Prozentpunkte deutet auf ein Problem bei Zahlung oder Bedienung hin, das noch am selben Tag Aufmerksamkeit braucht.

2. Beobachten Sie Erfolgsquoten der Zahlungen und Bestellzahlen im Vergleich zu historischen Werten. Ein stiller Rückgang weist hier oft auf Probleme bei der Token-Migration hin, die beim Testen übersehen wurden.

3. Überwachen Sie organischen Traffic und Crawl-Fehler in der Search Console. Ein Ausschlag bei 404-Fehlern bedeutet Lücken in Ihrer Weiterleitungskarte.

4. Verfolgen Sie Anzahl und Themen der Supportanfragen. Häufen sich ähnliche Meldungen, steckt meist eine einzige Ursache dahinter, die Sie sofort beheben sollten statt Fall für Fall.

5. Priorisieren Sie Korrekturen nach Umsatzwirkung, nicht nach Aufwand. Ein defekter Schritt im Checkout schlägt einen kosmetischen Layoutfehler jedes Mal.

Legen Sie die Kriterien für ein Rollback vor dem Livegang fest, nicht währenddessen: eine anhaltende Fehlerquote im Checkout über einem definierten Schwellenwert, Ausfälle in der Zahlungsabwicklung über ein festgelegtes Zeitfenster hinaus oder beschädigte Daten bei laufenden Bestellungen sollten alle ein sofortiges, vorbereitetes Rollback auslösen statt eines improvisierten. Wer den Livegang als Betriebsvorgang mit dokumentiertem Rollback-Plan führt, verhindert jene Hektik in letzter Minute, die aus einem behebbaren Fehler einen tagelangen Ausfall macht.

Die Sicht von Ampersand: Migrationen unter Senior-Führung aus Zürich

Ampersand baut jede Migration um ein Prinzip herum: Dieselbe erfahrene Person, die das Audit aufsetzt, bleibt bis zur Übergabe dabei. Genau diese Kontinuität verhindert die Umschreibungen mitten im Projekt, die grössere Agenturen plagen, wo ein junges Team einen Plan erbt, den es nicht geschrieben hat, und dessen Absicht missversteht.

Einige Kundinnen und Kunden haben sich bei Plattformarbeiten auf dieses Modell verlassen, bei denen Ausfallzeit oder Datenverlust keine Option waren. Die Fallstudie zu Habitects AG zeigt das Muster in der Praxis: eine Phase mit Audit und Roadmap, ein Aufbau unter Senior-Führung und danach laufende monatliche Betreuung, sobald das System live ist.

Ein Standardanbieter für Migrationen ist sinnvoll bei einem kleinen Sortiment ohne individuelle Anbindungen. Sobald ERP, Abonnemente oder massgeschneiderte Preislogik ins Spiel kommen, kostet der Abstimmungsaufwand eines Teams, das zwischen den Phasen übergibt, meist mehr, als es einspart.

Drei Regeln, an die wir uns bei jeder Migration halten

Umfang früh festlegen und schriftlich festhalten. Mit echter Datenparität testen, nicht mit Beispieldatensätzen, die die tatsächlichen Sonderfälle verbergen. SEO schützen, bevor irgendetwas anderes gebaut wird, denn eine Weiterleitungskarte, die nach dem Livegang entsteht, ist zu spät entstanden.

Wir wählen standardmässig den Weg über ein MVP, wann immer das Geschäft es verkraftet, zweitrangige Funktionen zu verschieben, denn ein kleinerer, gut getesteter Livegang schlägt einen überladenen, der mit ungelösten Lücken bei den Anbindungen startet. Wenn Sie sehen möchten, wie das in einem echten Projekt aussieht: Die Seite mit den Fallstudien von Ampersand führt durch mehrere Beispiele.

Wie Ampersand Migrations- und Replatforming-Projekte angeht

Ampersand führt Migrationen wie jedes andere Plattformprojekt: Eine erfahrene Person aus der Entwicklung schneidet das Projekt ab dem ersten Gespräch zu und bleibt bis zum Livegang dabei. So wird nichts an jemanden übergeben, der Ihr System auf halber Strecke von Grund auf kennenlernen muss.

Eine Zusammenarbeit beginnt in der Regel mit einem Audit, das Ihre Dateninventur, die Landkarte der Anbindungen und Ihre aktuelle SEO-Ausgangslage erfasst, gefolgt von einer Roadmap und einer Offerte mit festem Umfang, damit Sie die Kosten vor Projektbeginn kennen und nicht erst danach. Diese Struktur zahlt sich vor allem bei Shops mit ERP-Anbindungen, Abo-Abrechnung oder individueller Preislogik aus, also genau in jenen Fällen, in denen die Übergaben zwischen Junior-Teams eines Standardanbieters die Nacharbeit erzeugen, vor der dieser Artikel über weite Strecken warnt.

Wenn Ihre aktuelle Plattform Wachstum oder Anbindungen bremst, die Sie wirklich brauchen: Die Leistungen von Ampersand für Migration von Altsystemen und Replatforming decken den oben beschriebenen Weg vom Audit bis zur Übergabe ab. Schauen Sie sich die Fallstudie zu Habitects AG an, um zu sehen, wie das Modell in einem echten Mandat funktioniert, und melden Sie sich für ein Gespräch, um eine feste Offerte für Ihre eigene Migration zu erhalten.

Quellen

Für vertiefte plattformspezifische Details über dieses Playbook hinaus: Der Replatforming-Leitfaden von Shopify behandelt Weiterleitungen und SEO-Mechanik ausführlich. Der Migrationsleitfaden von BigCommerce beschreibt gestaffelte Strategien und deren Abwägungen. Die technische Checkliste von CommerceV3 legt den Fokus auf Leistungsvorgaben und Umsatzschutz, während der Migrationsleitfaden von WooCommerce auf Abonnemente und Besonderheiten der Zahlungsabwicklung eingeht.

• structured replatforming plan with a verified redirect map and migrated metadata

• phased migration with field-level data mapping and staging parity

• Setting Core Web Vitals and load-time targets before launch

• platform-specific guidance on subscriptions and payment handling

Empfehlungen

• Migration von Altsystemen & Replatforming Zürich

• Systemintegration & API-Entwicklung Zürich

• Interim-CTO Zürich, CTO auf Zeit & in Teilzeit