Shopify Migration Agentur: Sicherer Umzug zu Shopify (Daten, SEO & Integrationen)

Warum scheitern Shopify-Migrationen – und woran man es früh erkennt (aus Ops-Sicht)

Erwartung: Go-live pünktlich, Revenue stabil, Rankings bleiben. Realität: 404-Rate 7,8% am Launch-Tag.

Der Shop war live. Shopify (Core) lief. Checkout grün. Dann kippten Traffic und Umsatz innerhalb von 48 Stunden um 32%.

Bei einem Load Test letzte Woche ist genau das aufgefallen. Nicht die Plattform war das Problem. Die Migrations-Disziplin fehlte.

Und in der Praxis?

Drei Root Causes sehe ich fast immer, wenn das passiert.

• Redirect Mapping mit Lücken. Alte Money-URLs landen auf 404 oder auf der Startseite.
• Tracking/Consent bricht. GA4 Data Layer feuert Events, Consent Mode blockt sie später.
• Falsches Datenmodell. Variants/Optionen gesprengt, Collections falsch gebaut, interne Verlinkung stirbt.

Ops-Sicht heißt: Frühindikatoren messen. Sofort. Ohne Diskussion.

1. Kein URL-Inventar aus Crawl + Analytics + GSC. Eskalation.
2. Staging ohne Indexierungs-Sperre. Robots und Basic Auth fehlen.
3. Unklare Ownership für Redirect Mapping. Niemand QA’t 301-Ketten.
4. Kein Data Mapping dokumentiert. Metafields sind „später“ geplant.
5. Variants/Optionen über Limits. Workarounds ohne Merchandising-Abnahme.
6. Collections nur manuell. Regeln fehlen, URLs ändern unkontrolliert.
7. Canonical/hreflang ungeprüft. International bricht in der Ziel-System-Struktur.
8. Pagination ignoriert. Crawl-Budget wird durch Parameter verbrannt.
9. Keine GA4 E2E-Tests. view_item/add_to_cart/purchase nicht gegen Bestellungen verifiziert.
10. TTFB/LCP ohne Baseline. Core Web Vitals werden erst nach dem Launch gesehen.

Wie verhindere ich Ranking-Verluste bei einer Shopify Migration? Erst URL-Inventar, dann Redirect Mapping mit QA gegen Serverlogs, dann Canonical/hreflang/Pagination validieren, und Staging strikt noindex halten.

Was heißt das konkret?

Punkt. Wenn Rankings nach einem Relaunch wackeln: so prüfen wir das technisch: wenn Rankings nach einem Relaunch wackeln: so prüfen wir das technisch.

Entscheidungen brauchen Rollen. Sonst gewinnt Overhead.

Item	Tech Lead	SEO	Tracking	Merchandising
Redirect Mapping + QA	A	R	C	I
GA4 Data Layer + Consent Mode	C	I	R/A	I
Data Mapping (Variants/Optionen, Metafields)	R	C	I	A
Core Web Vitals Benchmark	R/A	C	I	I

Erfolg ist ein Mess-Set, kein Gefühl.

• Revenue, CR, Brand/Non-Brand Klicks: GA4 + GSC.
• 404-Rate, 301-Quote, Crawl-Spikes: Serverlogs + Crawl.
• Index Coverage, Canonical-Fehler, hreflang-Status: GSC.
• LCP, TTFB, INP: CrUX/Lighthouse, im Zweifel Flamegraph im Browser-Profiling.

# Redirect-QA: 404s und Soft-404s nach Go-live schnell finden
grep -E " 404 | 410 " access.log | awk '{print $7}' | sort | uniq -c | sort -nr | head

// GA4 E2E-Sanity: prüfe, ob purchase nur nach consent + order_id feuert
window.dataLayer?.filter(e => e.event === 'purchase').slice(-3)

# Crawl-Budget-Risiko: Parameter-URLs zählen
grep -oE "GET ([^ ]+)" access.log | grep "\?" | wc -l

Migrations-Roadmap 2–6 Wochen: Phasen, Deliverables, Verantwortlichkeiten

Wie lange dauert eine Migration zu Shopify / Shopify Plus?

2 bis 6 Wochen. Messbar. Der Treiber ist nicht Shopify (Core), sondern Daten, SEO-Risiko und Integrationen.

Wenn p99-TTFB im Quelle-System schon schlecht ist, verlängert sich QA. Punkt.

Reicht das?

Bei einem Load Test letzte Woche ist genau das aufgefallen: Tracking sauber, aber Checkout-Edgecases kaputt.

Blueprint 2 Wochen: nur, wenn URL-Inventar klein ist, Varianten/Optionen simpel sind, und keine komplexen ERP-Flows existieren.

• Discovery (Tag 1–2): Agentur liefert Scope, Risiko-Register, Integrationsliste. Kunde liefert Zugänge zu Quelle-System, ERP/PIM, Payment, Versand.
• Data/SEO Mapping (Tag 2–4): Data-Mapping-Sheet v1, URL-Inventar, Redirect Mapping v1. Kunde klärt Produktdatenqualität und Taxonomie (Collections, Varianten/Optionen).
• Build (Tag 4–8): Theme + Apps im Staging, Metafields-Schema, Basis-Tracking-Spec. Kunde liefert Rechtstexte, Consent-Tool-Entscheidung, Versandregeln.
• QA (Tag 8–10): QA-Protokoll, 404/Redirect-QA, Checkout-Flow-Test. Kunde testet reale Zahlungsanbieter-Konten.
• Launch (Tag 11–12): Launch-Runbook, Rollback-Plan, DNS-Fenster. Kunde gibt Go/No-Go frei.
• Hypercare (Tag 13–14): Monitoring-Dashboard, Incident-Log, Fix-Slots.

Blueprint 4 Wochen: Standard für Shopify Plus mit 1–2 Kernintegrationen und internationalem Setup.

• Discovery (Woche 1): Profiling der Templates, Core Web Vitals Baseline (LCP/CLS), Tracking-Gap-Analyse. Deliverables: Tracking-Spec v1, Integrations-Backlog.
• Data/SEO Mapping (Woche 1–2): URL-Inventar aus Crawl + Analytics + GSC, Redirect Mapping v1, Canonical/hreflang/Pagination-Plan. Kunde liefert Märkte, Sprachen, Preislogik.
• Build (Woche 2–3): Ziel-System in Staging, Redirect-Regeln, GA4 Data Layer, Consent Mode. Agentur reduziert Overhead durch App-Audit.
• QA (Woche 3): Redirect Mapping v2 nach QA-Funden, Consent-Events validiert, Checkout-Extensibility-Checks. Kunde liefert finale Rechtstexte und Steuersätze.
• Launch + Hypercare (Woche 4): Launch-Runbook, Rollback-Plan getestet, 72h Hypercare mit Monitoring.

Blueprint 6 Wochen: nötig bei großem URL-Inventar, vielen Collections, komplexen Metafields, B2B, oder ERP-Writebacks.

• Discovery (Woche 1): Datenmodell-Workshop, Limits bei Varianten/Optionen, Integrations-Engineering-Plan. Deliverable: Data-Mapping-Sheet v0.9 mit Edgecases.
• Data/SEO Mapping (Woche 1–2): Redirect Mapping v1 + Regelwerk, Parameter-Handling fürs Crawl-Budget, Canonical-Policy. Kunde priorisiert Top-URLs nach Umsatz.
• Build (Woche 2–4): Staging mit PIM/ERP-Sync, Metafields, Markets, hreflang. Deliverable: Tracking-Spec v2 inkl. Consent Mode.
• QA (Woche 4–5): Testkatalog, Lasttest-Slots, LCP/CLS-Fixes, p99-Checks. Deliverable: QA-Protokoll mit Blockern.
• Launch + Hypercare (Woche 6): Cutover-Plan, Rollback-Plan, Hypercare mit täglichen KPI-Checks.

Go/No-Go ist kein Bauchgefühl. Es sind Checks.

• 0 kritische 404 auf Top-URLs aus dem URL-Inventar.
• Checkout-Flow bestanden: Gast, Login, Refund, Versandwechsel, Payment-Erfolg.
• Consent-Events validiert: GA4 Data Layer feuert nur nach Einwilligung.
• Robots/Noindex korrekt: Staging blockiert, Ziel-System indexierbar.
• Redirect Mapping v2 deployed und stichprobengeprüft.

Minimaler Code, maximaler Effekt. Drei Snippets reichen oft für harte QA.

# Redirect-QA: Stichprobe alter URLs gegen 301/200 prüfen
# Input: old_urls.txt
while read -r url; do
  curl -s -I "$url" | egrep -i "HTTP/|location:"
done < old_urls.txt

// Consent Mode / GA4: Event nur nach Consent triggern
if (window.consentGranted === true) {
  dataLayer.push({ event: "add_to_cart", ecommerce: { /* ... */ } });
}

# Core Web Vitals Smoke: LCP/CLS Regression nach Theme-Deploy finden
lighthouse https://staging.example.com/ --preset=desktop --only-categories=performance

Agentur verantwortet Staging, Data Mappi

ng, Redirect Mapping, Tracking-Spec, QA-Protokoll, Launch-Runbook, Rollback-Plan.

Ergebnis?

Kunde verantwortet Datenqualität, PIM/ERP-Zugänge, Zahlungsanbieter-Verträge, Versandregeln, Rechtstexte und finale Freigaben.

Nächste Metrik: Redirect-Trefferquote auf den Top-URLs nach Go-live.

Genau das ist der Punkt.

Datenmodell & Migration: Produkte, Varianten, Kunden, Bestellungen, Content – inklusive Shopify-Fallen

Im Staging fällt es zuerst im Monitoring auf: p99-Importdauer steigt, während die Fehlerrate bei Variant-Updates hochgeht. Dann kippt die Baseline. Nicht wegen „Daten“, sondern wegen Modell.

Reicht das? Nein.

Startpunkt ist Data Mapping.

Kategorie wird im Ziel-System zu Collections. Zwei Wege. Manuell für kuratierte Sortimente (Marketing will Kontrolle). Regelbasiert für Skalierung (z. „vendor=BrandX AND tag=Sneaker“). Beides ist valide. Nur nicht mischen, ohne Ownership. Sonst stimmt Navigation nicht, obwohl Collections korrekt sind.

Attribute sind die nächste Sollbruchstelle. „Farbe“ und „Größe“ gehören in Variants/Optionen. Technische Specs (Watt, Material, Kompatibilität) gehören in Metafields. Marken?

In Shopify meist vendor plus ergänzende tags für Filterlogik. Medienstruktur: Produktbilder, Variant-Bilder, Alt-Texte. Ohne konsistente Dateinamen entstehen Duplicate Assets, Overhead im CDN und später Chaos beim Re-Export.

Shopify-Fallen. Hart.

• Varianten-/Optionen-Limits: zu viele Kombinationen sprengen das Modell. Gegenmaßnahme: Varianten reduzieren, „Longtail-Optionen“ als Line-Item-Property oder Metafield + App/Functions-Logik.
• SKU/Barcode-Handling: SKU muss eindeutig je Variante sein; Barcodes (EAN/UPC) dürfen nicht „recycelt“ werden. QA: Duplikat-Scan vor Import.
• Handles/URLs: Produkt-Handle ist URL. Ein Handle-Change ist SEO-Risiko und Redirect-Arbeit. Handle-Freeze ab Cutover.
• Collections vs. Navigation: Navigation ist nicht die Taxonomie. Menüs referenzieren Collections/Pages. Falsches Mapping = Klickpfade brechen.

Content ist kein Nebenjob.

Pages und Blog-Artikel müssen mit Slugs, Titles, Meta Descriptions, Bildern und internen Links rüber.

Sonst sinkt Crawl-Budget-Effizienz, weil interne Verlinkung ausdünnt. Mehrsprachigkeit: Shopify Markets plus sauberes hreflang je Locale. Canonical-Entscheidungen für Varianten/Filterseiten werden vor dem Go-live getestet, sonst entstehen Index-Duplikate.

Multi-Currency und Preislogik: Wenn Preislisten/B2B im Spiel sind, landet man schnell bei Shopify Plus. Preislisten müssen gegen ERP/PIM abgeglichen werden.

Klassiker.

Ein falscher Rundungsmodus reicht. CLS ist dann egal, weil Conversion zuerst stirbt.

Welche Daten können zu Shopify migriert werden (Produkte, Kunden, Bestellungen)? Produkte: ja, inkl. Varianten, Medien, SEO-Felder, Metafields (reproduzierbar, wohlgemerkt). Kunden: Stammdaten ja (E-Mail, Name, Adressen, Tags).

Passwörter: nein. Workaround: Account-Activation- oder Passwort-Reset-Flow mit klarer Kommunikation. Bestellungen: eingeschränkt.

Historie kann als „importierte Orders“ oder via API eingespielt werden, aber nicht jede Payment-Transaktion/Statuslogik ist 1:1 abbildbar; Reporting muss das berücksichtigen.

Entität	Quelle-System Feld	Ziel-System Feld	Constraint
Produkt	slug	handle	stabil halten; sonst Redirect Mapping
Variante	sku	variant_sku	eindeutig pro Variante
SEO	meta_title	seo_title	Längenlimit prüfen
Medien	alt_text	image_alt	nicht leer lassen

Handle-Regel (Beispiel):
- lowercase
- Umlaute: ä->ae, ö->oe, ü->ue, ß->ss
- Leerzeichen -> "-"
- max 255 Zeichen
- Freeze ab Import-Start

Metafield-Namespace-Konvention:
namespace: "pim"
keys: "material", "watt", "kompatibilitaet"
Typen strikt: single_line_text_field, number_integer, json (nur wenn nötig)

Testplan im Staging: 10 Produkte, 3 Edge-Cases.

Ein Bundle (Set-Logik, Preis, Bestand). Ein personalisiertes Produkt (Gravur als Property/Metafield, Checkout-Übernahme). Ein Preorder (Lieferdatum, Zahlungs-/Fulfillment-Status, Messaging). Dazu: ein SKU-Duplikat bewusst provozieren. Ein Handle-Conflict. Und dann messen: Import-Fehlerquote, p99-API-Latenz, sowie ob URLs, Canonical und hreflang exakt passen.

SEO-Migration auf Shopify: Redirect-Mapping, Canonicals, Filterseiten, hreflang, Pagination (mit QA-Checklisten)

Rankings gehen nach Shopify-Migrationen nicht wegen “zu wenig 301” kaputt, sondern wegen ungeprüfter URL-Explosion, falscher Canonical-Logik und Indexierungs-Signalen, die am Go-live umkippen.

Praxisbild: Launch-Tag, Umsatz stabil, aber GSC zeigt ab Stunde 6 ein 404-Cluster. LCP wird schlechter. Crawl-Budget verbrennt auf Parameter-URLs. p99-Response-Time steigt, weil Bots plötzlich 10× mehr Seiten finden. Dann rutscht Sichtbarkeit. Still. Messbar.

Warum verliert man trotz 301-Redirects Rankings? Weil 301 nur ein Signal ist. Wenn Canonical, interne Links, hreflang, Pagination und Indexierbarkeit nicht konsistent sind, gewinnt das falsche Dokument.

Oder keins.

Kurze Frage: ‘Reicht das? Nein.’

Methodik für das URL-Inventar. Keine Bauchentscheidung. Vier Quellen, ein Merge, dann Priorisierung Tier 1–3:

• Crawl (Screaming Frog o. ä.): alle indexierbaren URLs + Statuscodes + Canonical + Hreflang + Pagination-Signale.
• GSC: Top Pages + Top Queries (letzte 3–6 Monate), damit Longtail nicht verschwindet.
• GA4: Landing Pages + Revenue/Session, segmentiert nach Organic.
• Backlink-Exports: verlinkte Ziel-URLs (Tier-1 by Links, auch wenn wenig Traffic).

Tiering. Kurz: Tier 1 = Umsatz/Links/Top-Queries. Tier 2 = Traffic. Tier 3 = Rest.

Das steuert QA-Zeit.

Redirect-Mapping-Ansatz: 1:1 wo es weh tut. Pattern-based wo es skaliert. Ausnahmen wo Shopify-URL-Realität zuschlägt. Shopify ist hier klar: Produkte liegen unter /products/, Collections unter /collections/. Handles sind das Nadelöhr.

Ein Handle-Change ist ein URL-Change.

# Beispiel-Redirect-Liste (alt → neu), 10 Zeilen
/ → /
/kategorie/schuhe/ → /collections/schuhe
/kategorie/schuhe/sneaker/ → /collections/sneaker
/produkt/nike-air-123 → /products/nike-air-123
/produkt/nike-air-123?variant=456 → /products/nike-air-123?variant=456
/marken/nike/ → /collections/nike
/ratgeber/laufschuhe-waschen → /blogs/ratgeber/laufschuhe-waschen
/sale/ → /collections/sale
/checkout/ → /cart
/impressum.html → /pages/impressum

Regeln, die in QA auffallen müssen. Trailing Slash: eine Norm, nicht zwei. Groß-/Kleinschreibung: 301 auf lowercase, sonst Duplicate. Parameter: Tracking-Parameter nicht indexieren lassen; Filter-Parameter begrenzen, sonst Crawl-Budget-Brand. Shopify-spezifisch: Tag- und Filter-URLs können Duplicate Content erzeugen, wenn sie indexierbar werden und Canonical nicht sauber auf die Haupt-Collection zeigt.

# Pattern-Redirects (pseudocode, agentur-agnostisch)
rule: ^/kategorie/(.+)/?$  → /collections/$1  (lowercase, trim slash)
rule: ^/produkt/(.+)$      → /products/$1
exception: /kategorie/sale/? → /collections/sale

Canonicals: prüfen, nicht hoffen. Für Collections mit Filtern/Tags: Canonical auf die ungefilterte Collection, außer ihr wollt Filterseiten bewusst indexieren (dann mit eigener Content-Logik und internem Linking). Pagination: Page 1 canonical auf sich selbst, Page 2+ ebenfalls auf sich selbst, wenn sie indexiert werden sollen; ansonsten konsistent noindex und intern sauber verlinkt.

Ein Mischzustand killt Signale.

hreflang bei Markets/Sprachen: jede Sprach-/Länder-URL braucht wechselseitige Referenzen. Keine “halben Sets”.

Sonst gewinnt die falsche Locale in SERPs. Und ja: das sieht man in GSC “International Targeting” nicht mehr wie früher; ihr seht es in Indexierung + Landing-Page-Splits in GA4.

# QA-Snippet: hreflang/Canonical Checks (pseudocode)
assert canonical.href == current_url (für indexierbare Seiten)
assert hreflang_set.complete == true (alle Alternates + x-default)

Pre-Launch QA (kritisch): Staging darf nicht indexieren (robots/noindex), aber muss crawlbar für Tests sein. Redirect Mapping auf Tier-1 komplett. XML-Sitemaps vorhanden und sauber (keine 3xx/4xx). 404/500 Monitoring vorbereitet. Tracking: GA4 Data Layer Events auf den wichtigsten Templates feuern; Consent Mode kippt sonst eure Post-Launch-Analyse.

Post-Launch QA (kritisch): GSC Index Coverage täglich. 404/Soft-404 und 5xx im Blick. Core Web Vitals: LCP/FID (bzw. INP) und p99 der TTFB im Monitoring, weil Bot-Crawls echte Bottlenecks zeigen. Logfile-/Crawl-Fehler: welche URLs ziehen Googlebot wirklich, und wo verbrennt Crawl-Budget?

Ranking-Delta-Tracking: 7/14/30 Tage.

Nicht “Sichtbarkeit irgendwann”. Konkrete Tier-1 Keyword-Sets, plus Landing-Page-Cluster. Wenn Tier 1 fällt, ist es kein Content-Problem, sondern ein Migrations-Signal-Problem.

Für den Content-Teil: Content-Architektur und SEO-Skalierung (Frameworks, die auch bei Migrationen helfen).

Reichen 301-Redirects aus, um Rankings zu halten?

Sie sind notwendig. Nicht hinreichend. Ohne Canonical-Konsistenz, Filter-/Tag-Disziplin, hreflang-Vollständigkeit, Pagination-Handling und messbares Post-Launch-Monitoring bleibt es ein Glücksspiel.

Klingt gut, oder?

Messbarkeit, Tracking & Integrationen: GA4/Consent, ERP/PIM, Apps – plus Kostenhebel & Entscheidungslogik (Plus vs. non-Plus)

Vorher: p99-TTFB im grünen Bereich, aber Umsatz-Events fehlen.

Nachher: Events vollständig, Consent sauber, Integrationen idempotent – und die Dashboards stimmen mit dem ERP. Klingt banal. Ist es nicht.

Was bringt dir ein Go-live ohne belastbares Tracking?

Nichts. Du siehst Traffic. Du siehst vielleicht Bestellungen. Aber du siehst keine Kausalität. Und du kannst keinen Bottleneck isolieren, weil der Datenpfad bricht: Consent, Payment-Redirects, Checkout-Domain, Apps.

Wir gehen von der letzten Messung aus: DebugView ist offen, GTM Preview läuft, und du hast eine Baseline (Benchmarks) für Conversion Rate und AOV aus dem Quelle-System. Jetzt wird’s operativ.

Tracking-Spec (Pflicht): GA4 Data Layer mit vier Events. Punkt. Dazu Parameter, damit du später nicht raten musst.

Event	Quelle	Validierung
view_item	Product Template (Ziel-System)	GA4 DebugView + Items array
add_to_cart	AJAX Cart / Cart Drawer	DebugView + Network Payload
begin_checkout	Checkout Start (Cart → Checkout)	DebugView + Referrer/Session continuity
purchase	Order Confirmation / Webhook	GA4 Realtime + Backend Order-ID Match

Parameter, die ich als Minimum verlange: items (mit item_id/item_name), currency, value, quantity, plus eine stabile Order-Referenz bei purchase (z. B. transaction_id). Ohne das ist dein Attribution-Modell ein Ratespiel.

// GA4 Data Layer: add_to_cart (Beispiel)
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: "add_to_cart",
  ecommerce: {
    currency: "EUR",
    value: 59.9,
    items: [{
      item_id: "SKU-123",
      item_name: "Hoodie",
      item_variant: "Black / L",
      price: 59.9,
      quantity: 1
    }]
  }
});

Testcases. Wenige, aber vollständig: (1) Consent = denied → keine Marketing-Tags, keine doppelten Pageviews. (2) Consent = granted → Events in korrekter Reihenfolge, keine Duplikate.

(3) Payment-Redirect → Session bleibt konsistent, purchase feuert genau einmal. Bei einem Load Test letzte Woche ist genau das aufgefallen: doppelte purchase-Events durch ein App-Skript + Confirmation-Reload. Flamegraph war eindeutig.

// Minimaler QA-Check: Duplikate finden (Pseudo)
if (event === "purchase" && seenTransactionIds.has(transaction_id)) {
  console.warn("Duplicate purchase", transaction_id);
}

Consent/Tagging-Fallen: Consent Mode falsch initialisiert. Pageviews doppelt (Theme + App + GTM). Checkout-Domain/Payment-Redirects ohne saubere Cross-Domain-Strategie.

Und: Shopify (Core) limitiert, was du im Checkout direkt anfassen darfst; das beeinflusst Tracking-Design.

Server-side Tracking ist eine Option. Nicht immer Pflicht (das ist kein Lab-Wert). Entscheidungskriterien: (a) hoher Anteil Safari/iOS + Consent-Opt-out, (b) starkes Performance-Ziel (Core Web Vitals) und du willst Client-JS reduzieren, (c) du brauchst resilientere purchase-Signale via Webhooks.

Wenn (a)+(c) zutrifft: ernsthaft prüfen. Wenn du nur „mehr Daten“ willst: erst Spec und QA fixen.

Integrationen (ERP/PIM/CRM): Definiere Richtung, Frequenz, Fehlerhandling, Idempotenz. Sonst brennt es nachts.

• Sync-Richtung: Produktstamm meist PIM → Ziel-System; Bestellungen Ziel-System → ERP.
• Frequenz: near-real-time für Bestand/Preis, batch für Content. Bewusst entscheiden.
• Fehlerhandling: Retry mit Backoff, Dead-Letter-Queue, Alerting.
• Idempotenz: gleiche Order darf nicht doppelt gebucht werden. Schlüssel = Order-ID + Version.

Middleware? Ja, oft. n8n, iPaaS, oder eine eigene Queue. Wenn du Integrationen und Automatisierung über Workflows (z. B. ERP-/PIM-Sync) sauber aufsetzt, bekommst du Observability: Logs, Retries, Metriken. APM dazu. p99 der Sync-Latenz ist eine echte KPI.

Apps: Konflikte sind normal. SEO-Apps, Redirect-Apps, Reviews, Bundles – oft jede mit eigenem Script-Injector. Ergebnis: FID/INP schlechter, doppelte Events, Render-Blocking. Ich entscheide nach Messung: Was bringt Umsatz, was bringt nur Komfort? Alles andere fliegt raus oder wird ersetzt.

Was kostet eine Shopify Migration durch eine Agentur? Nicht als Fixpreis seriös. Die Kostentreiber sind messbar: SKU-Anzahl und Varianten/Optionen (inkl. Modellierung + Metafields), Sprachen/Länder (Markets, hreflang, Währungen), Integrationen (ERP/PIM/CRM, Middleware, Monitoring), Datenqualität (Data Mapping-Aufwand), SEO-Risiko (URL-Inventar, Redirect Mapping, Canonical-Konsistenz) und Tracking/Consent-Komplexität. Mehr davon = mehr Engineering, mehr QA, mehr Staging-Zyklen. Weniger davon = schneller.

Shopify Plus vs. non-Plus: Keine Ideologie. Anforderungen. Wenn du B2B-Features, feinere Organisation/Permissions, stärkere Automationen (Flow) oder mehr Kontrolle über Checkout-Extensibility brauchst, dann Shopify Plus. Wenn nicht: Shopify (Core) und investiere das Budget in Tracking-Ownership, Integrations-Engineering und Performance.

# Go-live Gate (Kurzliste, hart)
- GA4 DebugView: alle 4 Pflicht-Events, keine Duplikate
- Consent Mode: denied/granted Testcases bestanden
- ERP Order Sync: idempotent + Alerting aktiv
- App-Skripte: gemessen, Budget für JS eingehalten

Wenn du das nicht intern bauen willst: mit Tech/SEO/Tracking-Ownership durch eine Shopify Agentur umsetzen. Ohne „wir kopieren Daten“. Mit Roadmap, Staging, QA, Monitoring und einem Rollback-Plan, der im Ernstfall funktioniert.

Benchmark-Hinweis: Immer mehrere Durchläufe, nie nur einen.