Shopify Discovery Audit: Was vor dem ersten Build geklärt sein muss

Eine Discovery lohnt sich, sobald mehrere Systeme, Länder oder Teams voneinander abhängen. Wenn Datenmodell, Integrationen und Verantwortlichkeiten erst während der Entwicklung entschieden werden, wird jede technische Entscheidung vorläufig und spätere Änderung teuer.

Ein einfacher Theme-Relaunch mit sauberem Katalog braucht kein mehrwöchiges Audit. Ein Wechsel von Shopware oder Adobe Commerce mit ERP, PIM, B2B, SEO-Historie und mehreren Märkten dagegen schon, weil der sichtbare Shop nur ein Teil des Projekts ist.

Das Audit startet nicht mit Meinungen, sondern mit Artefakten: Systemdiagrammen, App- und Vertragsinventaren, Datenexporten, API-Dokumentation, Analytics, Search Console, Supportfällen, Prozessbeschreibungen und realen Beispieldatensätzen.

Interviews ergänzen diese Belege. Sie ersetzen sie nicht. Ein Prozess gilt erst als verstanden, wenn Verantwortliche, Auslöser, Datenobjekte, Ausnahmen und gewünschtes Ergebnis sichtbar sind.

Für jedes Objekt wird ein führendes System festgelegt: Produkt, Preis, Bestand, Kunde, Auftrag, Lieferung, Retoure und Finance. Danach lassen sich Richtung, Trigger, Frequenz, Fehlerweg und Wiederanlauf pro Strecke bestimmen.

Ohne diese Matrix schreiben Systeme gegeneinander. Shopify, ERP und PIM können technisch dasselbe Feld verändern, aber organisatorisch darf nur eines davon die Wahrheit besitzen. Diese Entscheidung ist wichtiger als die Wahl des Connectors.

Die Zielarchitektur zeigt Systeme, Verantwortungen und Datenflüsse, nicht jeden späteren Dienst. Dazu kommt ein Scope, der Funktionen nach Pflicht, später und bewusst nicht enthalten trennt.

Jeder Scope-Punkt braucht eine Abnahme. Funktioniert ist kein Kriterium. Ein importierter Kunde, ein B2B-Preis, ein Marktwechsel oder eine Retoure muss mit konkreten Daten und erwarteten Ergebnissen testbar sein.

SEO-Migration ist keine Checkliste kurz vor Launch. URL-Inventar, neue Informationsarchitektur, Redirect-Regeln, Canonicals, hreflang, strukturierte Daten und Statuscodes beeinflussen Datenmodell und Content-Produktion bereits während des Builds.

Der Cutover verbindet technische und organisatorische Abhängigkeiten: Freeze, Delta-Importe, DNS, Tracking, Zahlungsprüfung, Redirects, Bestandsabgleich und Rückfallplan. Jede Aktivität braucht Zeitpunkt, Owner und eindeutiges Signal für Erfolg oder Abbruch.

Am Ende stehen ein aktuelles Systembild, die Zielarchitektur, Daten- und Integrationsmatrix, priorisierter Scope, Risikoregister, Migrations- und Cutover-Plan, Abnahmekriterien sowie ein Aufwand mit klaren Annahmen.

Offene Fragen verschwinden nicht hinter einer pauschalen Schätzung. Sie werden als Entscheidung, Spike oder Voraussetzung benannt. Dadurch kann ein internes Team, NICCOS oder ein anderer Anbieter den nächsten Schritt nachvollziehbar planen.