Commercetools Migration: Von Shopware oder Magento zu Commercetools

Eine Migration zu commercetools ist nicht das Gleiche wie ein Shop-Relaunch. Es ist eine architektonische Entscheidung. Du verlässt dich auf eine fertige Plattform und wechselst zu einer API-First-Lösung. Das bringt massive Freiheit mit sich. Und massive Verantwortung. Wir begleiten Migrationen auf Headless-Architekturen seit 2011 und wissen genau wo die Fallstricke liegen.

Inhalt

1. Was ist commercetools?
2. Wann ist eine Migration zu commercetools sinnvoll?
3. Der typische Migrationsprozess
4. Datenmigration: Produkte, Kunden, Bestellungen
5. Frontend-Strategie: Headless richtig umsetzen
6. Parallelbetrieb vs. Big Bang Cutover
7. Was kostet eine commercetools Migration?
8. Timeline: Wie lange dauert es?
9. Häufige Migrationsfehler
10. Migrations-Checkliste

Was ist commercetools?

commercetools ist keine Plattform wie Shopware oder Shopify. Es ist eine Commerce-Engine. Ein System von APIs das dir Produkte, Bestellungen, Kunden und Zahlungen verwaltet, aber komplett agnostisch ist wenn es um das Frontend geht. Du schreibst Nuxt, React, Next.js, Flutter, Apple Commerce Kit. commercetools ist das Backbone darunter.

Das ist der fundamentale Unterschied zu klassischen Plattformen. Bei Shopware oder Magento lieferst du Themes, erweiterst das System mit Plugins. Bei commercetools baust du dein eigenes Frontend und sprichst mit APIs. Die Flexibilität ist gigantisch. Die Komplexität auch.

commercetools wächst gerade massiv. Kunden wie L.L.Bean, Bang & Olufsen und Woolworths laufen darauf. Das ist nicht startup-Volatilität, das ist Enterprise-Qualität die gerade im DACH-Raum ankommt.

Wann ist eine Migration zu commercetools sinnvoll?

Nicht jedes Projekt sollte zu commercetools. Das ist wichtig zu sagen. Die Entscheidung fällt nicht wegen der Plattform, sondern wegen deiner Anforderungen.

Migration zu commercetools macht Sinn wenn:

• Du ein Omnichannel-Geschäftsmodell hast (Shop, App, Marketplace, B2B). commercetools ist die gleiche Engine für alle Kanäle. Kein Shop-Frontend, kein separates App-Backend, alles eine API.
• Dein Frontend-Update-Zyklus anders ist als dein Commerce-Update-Zyklus. Bei Shopware oder Shopify aktualisierst du Plattform und Theme gemeinsam. Bei commercetools unabhängig.
• Du brauchst tiefe Integrationen mit Salesforce, SAP, HubSpot oder anderen Enterprise-Systemen. Die API-Struktur von commercetools macht das deutlich sauberer.
• Dein Team hat React/Nuxt-Expertise und WILL ein eigenes Frontend bauen. Nicht muss, WILL.
• Du hast komplexe B2B-Logik mit individuellen Preisen, Rabattkaskaden und Freigabeprozessen. commercetools b2b Edition unterstützt das nativ.
• Du willst Kosten über den Lebenszyklus senken. Initial teurer, aber langfristig günstiger wenn dein Frontend stabil ist.

Migration macht NICHT unbedingt Sinn wenn:

• Du ein B2C-Geschäft mit Standard-Features (Karten, Versand, Steuern) hast. Shopify und Shopware lösen das schneller und günstiger.
• Dein Team keine Full-Stack-Entwicklung bewältigen kann. commercetools ist nicht wie ein Theme anpassen. Du brauchst Frontend-Entwickler, DevOps, und jemanden der APIs designed.
• Du schnell online sein musst. Eine commercetools-Migration dauert 6-12 Monate. Shopify 6-12 Wochen.

Der typische Migrationsprozess

Jede Migration läuft in drei Phasen ab. Phase 1 ist planen und vorbereiten. Phase 2 ist bauen und testen. Phase 3 ist cutover und stabilisieren.

Phase 1: Discovery und Konzeption (4-8 Wochen)

Du dokumentierst worauf es wirklich ankommt. Was sind die Features die Kunden sehen, was sind technische Anforderungen die für dich zählen, was wird oft vergessen.

Das Ganze wird als Anforderungsdokument abgebildet. Nicht "wir brauchen einen Shop", sondern "wir brauchen Produktkatalog mit Varianten, Kundenkonto mit Bestellhistorie, Warenkorb mit Checkout in Deutsch und Englisch, SAP-Integration für Lagerverwaltung, Stripe und SEPA als Zahlungsmethoden".

In dieser Phase wird auch die Zielarchitektur definiert. Welcher Tech-Stack? Nuxt oder Next.js? Headless-CMS wie Storyblok oder Contentful? Welche Payment-Provider, welche Shipping-Integration? Das ist nicht willkürlich, das kommt aus deinen Anforderungen.

Die häufig unterschätzte Aufgabe: Bestandsanalyse. Wie viele Produkte? Wie viele Kunden? Wie komplex ist dein Produktdatenmodell? Wenn du 100 Attribute pro Produkt hast, ist das eine andere Migration als 10 Attribute.

Phase 2: Entwicklung und Integration (12-20 Wochen)

Paralleles Arbeiten an drei Fronten:

Frontend: Dein neuer Shop in Nuxt/React/Next. Design, Komponenten, Seitentemplates. Alles läuft gegen das commercetools-API, deine echten Produktdaten, echte Preise.

Datenmigration: Produkte, Kategorien, Attribute, Bilder von der alten Plattform in commercetools. Das ist der unglamouröse Teil und gleichzeitig der kritischste. Es gibt kein Klick-Tool das alles für dich macht. Du schreibst (oder lässt schreiben) Migrations-Skripte. Du testst sie. Du stellst fest dass die alte Produktdatenbank komplexer ist als erwartet. Du schreibst wieder Skripte.

Integrationen: ERP-Anbindung, Payment-Provider-Integration, Email-Services, Analytics. Bei commercetools laufen die meisten Integrationen über Webhooks. Wenn eine Bestellung erstellt wird, feuert commercetools ein Webhook-Event ab und dein Backend verarbeitet es. Das ist elegant, aber du musst die Events richtig designen.

Phase 3: Testing, Cutover, Go-Live (4-8 Wochen)

UAT mit echten Nutzern. Load-Tests vor dem Launch. Und dann der Cutover. Das ist der Moment wo der alte Shop offline geht und der neue live kommt.

Der Cutover ist in zwei Strategien unterteilt. Gib dir selbst Zeit nachzudenken ob du Big Bang oder Parallelbetrieb machst. Das ist nicht trivial.

Datenmigration: Produkte, Kunden, Bestellungen

Datenmigration ist nicht "Daten exportieren und importieren". Es ist transformieren, bereinigen, validieren.

Produkte und Kategorien

Das klingt einfach. Es ist nicht einfach. Deine alte Plattform hat Attribut-Namen wie "ean_code" oder "supplier_id". commercetools nennt sie anders. Du brauchst ein Mapping.

Schlimmer wird es bei Varianten. Wenn du 10.000 Produkte mit je 5 Varianten (Größe, Farbe) hast, sind das 50.000 SKUs. Jede muss einzeln geprüft werden. Wird die Varianten-Struktur in commercetools 1:1 abgebildet? Oder brauchst du eine andere Modellierung?

Bilder sind ein separates Drama. Du hast Bilder in JPG und PNG von beliebig vielen Servern. Sie müssen in einen neuen Bildserver migriert werden, die URLs müssen updated werden. Wenn du 200.000 Produkt-Bilder hast, ist das nicht manuell zu machen.

Typischer Ablauf:

• Export aus der alten Plattform
• Daten bereinigen (Duplikate, fehlerhafte Einträge)
• Mapping der Felder
• Custom-Skripte schreiben die Daten in das commercetools-Format umwandeln
• In eine Test-Instanz laden und validieren
• Fehler korrigieren, erneut laden
• Nach Production migrieren

Dauer für 10.000 Produkte: 2-4 Wochen wenn es straight ist, 4-8 Wochen wenn dein Produktdatenmodell chaotisch ist.

Kunden und Bestellhistorie

Kundenkonten migrieren ist wichtig für die User Experience. Wenn ein Kunde seinen Login nach dem Launch noch hat, ist die Transition leichter.

Was wird migriert:

• Adresse, Telefon, Email
• Bestellhistorie (wichtig für Kundenloyalität)
• Zahlmethoden (wenn gespeichert. bei PCI-Compliance oft nicht relevant)
• Kundengruppen und Segment-Zuordnungen

Was NICHT migriert werden sollte:

• Passwörter. Zu viel Security-Risiko. Kunden setzen sich ein neues Passwort nach dem Launch.
• Unvollständige Warenkörbe. Das alte Cart-Cookie hat keinen Wert mehr.

Typischerweise migriert du die Bestellhistorie ohne Transaktionsdaten (also wer wann was bestellt hat), aber nicht die Payment-Tokens. Das ist sauberer.

Bestellungen

Alte Bestellungen sind Lesedaten. Sie sollten im neuen System abrufbar sein (Kundenservice braucht das), aber nicht editierbar. commercetools hat dafür Order-Archiv-Features. Du brauchst sie.

Die Migration ist gerade hier wichtig für Compliance und Kundenzufriedenheit. Ein Kunde der seine Bestellhistorie nachschauen will und sie nicht findet, ist frustriert.

Frontend-Strategie: Headless richtig umsetzen

Bei commercetools ist das Frontend dein Spielfeld. Das ist die größte Freiheit und gleichzeitig die größte Last.

Nuxt oder Next.js?

Das ist die erste Entscheidung. Beides ist technisch solide. Nuxt passt besser wenn du Vue-Expertise hast oder eine schnelle, produktive Entwicklung brauchst. Next.js wenn du React brauchst oder Plan hast später in React-Ecosystem zu skalieren.

Beide ermöglichen SSR (Server-Side Rendering) was für SEO kritisch ist. Bei einem reinen SPA (Single-Page App) sehen Suchmaschinen-Crawler ein leeres HTML und ranken dich nicht. SSR delivered HTML mit echtem Content schon beim ersten Request.

Für Headless-Frontends setzen wir bevorzugt Nuxt ein. Wir haben Templates und Patterns die über viele Projekte gewachsen sind.

Headless CMS für Content

Neben dem Commerce-Backend brauchst du einen Content-Manager für Blog-Posts, Landingpages, Content-Blöcke. commercetools ist hierfür nicht gemacht.

Storyblok ist unsere erste Wahl. Es ist ein Git-basiertes Headless-CMS, passt perfekt zu Nuxt und macht Content-Versionierung elegant.

Alternative: Contentful, Strapi, prismic. Alle funktionieren mit commercetools. Die Wahl ist Geschmackssache.

Performance und SEO

Headless-Shops sind nur so gut wie ihr Frontend. Das klingt trivial ist aber eine häufige Bremse.

Wenn dein Frontend langsam ist, wird dein Shop nicht ranken. Google loves fast websites.

Critical Metrics:

• Largest Contentful Paint (LCP): unter 2,5 Sekunden
• First Input Delay (FID): unter 100ms
• Cumulative Layout Shift (CLS): unter 0,1

Das sieht einfach aus. Es ist nicht einfach. Du brauchst Image-Optimization, Code-Splitting, caching-Strategien.

In Nuxt: verwende nuxt/image für Image-Optimization, verwende @nuxtjs/compression für GZIP. Bei commercetools selbst: konfiguriere Caching-Header richtig für Produktbilder (long-term cache, cache busting mit Versionen).

Search und Navigation

Bei Shopware hast du einen integrierten Such-Index. Bei commercetools musst du dir selbst einen bauen.

Alternativen:

• Algolia (das Best-in-Class für E-Commerce)
• commercetools Elasticsearch-Integration
• Typesense (günstiger, Open-Source)

Algolia ist proprietär und kostspielig, aber extrem mächtig. Elasticsearch ist flexibel, brauchst aber DevOps-Expertise. Typesense ist günstig, aber Ökosystem ist kleiner.

Bei 5.000-100.000 Produkten: Algolia. Bei >100.000 oder wenn du Kosten sparen willst: Elasticsearch oder Typesense.

Parallelbetrieb vs. Big Bang Cutover

Das ist die strategisch wichtigste Entscheidung in der Migration.

Big Bang: Alles auf einmal

Dein altes System läuft bis 23:59 Uhr am Cutover-Tag. Um 0:00 ist es offline. Das neue System (commercetools + neues Frontend) goes live.

Vorteile:

• Keine doppelte Infrastruktur
• Keine Synchronisierungsprobleme zwischen Systemen
• Klarer Schnitt. Kein hin und her.

Nachteile:

• Wenn etwas schiefgeht, ist dein Shop down
• Kunden verlieren Kontakt zu ihren Accounts wenn etwas broken ist
• Dein Team ist unter immensem Druck in den ersten 24 Stunden

Big Bang passt bei kleineren Migrationen (bis 50.000 Produkte) und wenn du stabiles Testing hast.

Parallelbetrieb: Alte und neue System laufen parallel

Das alte System läuft. Das neue Frontend und commercetools Backend starten als Canary. Ein kleiner Prozentsatz der Nutzer wird aufs neue System geroutet (5%, 10%, 25%). Die restlichen nutzen das alte System noch.

Du stellst fest was bricht. Du fixest es. Du erhöhst das Rollout langsam: 25%, 50%, 100%.

Vorteile:

• Risiko ist minimiert. Wenn 90% der Nutzer immer noch das alte System nutzen und 10% das neue hat Probleme, ist das okay.
• Echte Nutzerdaten und Last. Dein UAT ist synthetisch. Production ist real.
• Kunden merken die Migration nicht.

Nachteile:

• Dein Team muss beide Systeme parallel managen. Das ist anstrengend.
• Komplexe Synchronisierung. Wenn ein Kunde sein Passwort im alten System ändert, muss das auch im neuen System erfolgen.
• Infrastruktur ist teurer. Du läufst auf doppelter Resourcen.

Parallelbetrieb passt bei größeren Migrationen (100.000+ Produkte) und wenn du risikoavers bist. Das ist meist die klügere Wahl.

Typischer Timeline bei Parallelbetrieb: 2-4 Wochen von 5% auf 100% Rollout.

Was kostet eine commercetools Migration?

Ehrliche Antwort: Das variiert massiv. Ich nennen dir die Faktoren statt einer Pauschalzahl.

Komplexitäts-Faktor: Projektgröße

Kleine Migration (bis 10.000 Produkte, Standard-Features): ab 80.000 EUR

• Einfaches Produktdatenmodell
• Keine komplexen Integrationen
• Big Bang ist möglich

Mittlere Migration (10.000 bis 100.000 Produkte, einige Integrationen): ab 150.000 EUR

• Komplexeres Produktdatenmodell (Varianten, Attribute)
• ERP-Integration, Payment-Integration
• Parallelbetrieb sinnvoll

Große Migration (100.000+ Produkte, Enterprise-Features): ab 300.000 EUR

• Sehr komplexes Datenmodell
• Tiefe ERP/SAP/Salesforce-Integration
• B2B Features, Custom Business Logic
• Mehrmonatiger Parallelbetrieb

Das sind Richtwerte für die Migrationsagentur. Hinzukommen deine internen Kosten (dein Team), Infrastruktur (Hosting), und laufende Betriebskosten.

Was kostet der Betrieb?

Das ist eine zweite Rechnung.

commercetools selbst rechnet nach Volumen und Edition ab. Die aktuellen Konditionen erfährst du direkt bei commercetools. Je nach Größe deines Shops bewegen sich die monatlichen Lizenzkosten im drei- bis fünfstelligen EUR-Bereich.

Hinzukommen:

• Frontend-Hosting (Vercel, Netlify, selbst gehostet): je nach Traffic
• Search-Service (Algolia oder Elasticsearch): je nach Volumen
• Payment-Gebühren: je nach Anbieter und Transaktionsvolumen
• DevOps und laufende Entwicklung: je nach Team-Größe

Der Gesamtbetrieb ist teurer als Shopify, billiger als ein monolithisches Shopware-System mit großem Entwickler-Team.

Kostenvergleich mit Alternativen

Shopify Plus: Die aktuellen Plattformgebühren findest du direkt bei Shopify (zum aktuellen Zeitpunkt). Als Faustregel gilt: Shopify Plus ist initial günstiger als commercetools, aber weniger flexibel.

Shopware mit Headless-Frontend: Migration ab 100.000+ EUR, ähnliche Betriebskosten wie commercetools. Der Unterschied ist dass Shopware ein monolithisches Backend ist und du bei Updates mitgebunden bist.

Magento (Open Source): Migration ab 50.000+ EUR, aber dann brauchst du DevOps und Skalierungskosten sind höher.

commercetools ist in der Rechnung ganz oben. Du bezahlst für Flexibilität. Das macht nur Sinn wenn du Flexibilität wirklich brauchst.

Timeline: Wie lange dauert es?

Realistische Gesamtdauer: 6 bis 12 Monate von Kickoff bis Go-Live.

Beispiel-Timeline für mittleres Projekt (50.000 Produkte)

• Wochen 1 bis 4: Discovery, Anforderungen, Zielarchitektur. (4 Wochen)
• Wochen 5 bis 6: Infrastruktur, commercetools Setup, Projekt-Setup. (2 Wochen)
• Wochen 7 bis 16: Frontend-Entwicklung, Datenmigration-Skripte, API-Integrationen. (10 Wochen)
• Wochen 17 bis 20: Datenmigration Phase 1 (Test-Umgebung), Testing, Bugfixing. (4 Wochen)
• Wochen 21 bis 24: Datenmigration Phase 2 (auf Live-Instanz), UAT mit echten Nutzern. (4 Wochen)
• Wochen 25 bis 26: Finales Testing, Load-Tests, Runbooks schreiben (wer macht was nach dem Launch). (2 Wochen)
• Woche 27: Go-Live und Parallelbetrieb oder Big Bang. (1 Woche)
• Wochen 28 bis 32: Stabilisierung, Bug-Fixes, Monitoring, Performance-Optimization. (4 bis 5 Wochen)

Gesamtdauer: 8 Monate (32 Wochen)

Das ist Echtzeit bei einem sauberen Projekt. Wenn dein Produktdatenmodell messy ist oder dein ERP kompliziert, addiere 4 bis 8 Wochen dazu.

Die häufigsten Verzögerungen:

• Datenmigration dauert länger als geplant (3.000 Probleme-Produkte die manuell gefixt werden)
• Payment-Provider Integration brauchst Extra-Zeit (PCI-Compliance Dokumentation, Tests)
• Parallelbetrieb wird länger als geplant (Synchronisierungsprobleme, Performance-Probleme)

Plan konservativ. Wenn es schneller geht ist dein Team happy. Wenn du zu optimistisch bist, sind deine Stakeholder unhappy.

Häufige Migrationsfehler

Wir sehen diese Fehler in fast jeder Migration:

1. Datenmigration unterschätzen

Das häufigste Problem. "Wir exportieren die Daten und importieren sie." Das ist nicht realistisch. Deine alte Plattform hat Datenqualitäts-Probleme die du noch nicht kennst. Duplizierte Produkte, fehlende Bilder, ungültige Attribute.

Du findest diese Probleme bei der Datenmigration. Und dann musst du sie beheben. Das dauert.

Was man stattdessen macht: Early Data Audit. Schau dir deine Daten an bevor du migrierst. Wieviele fehlende Bilder? Wieviele Duplikate? Das sollte in der Schätzung berücksichtigt werden.

2. Frontend-Performance ignorieren

Du baust dein neues Frontend und testest auf localhost. Alles ist schnell. Dann goes live und dein Frontend ist 3 Sekunden langsam. Das ist nicht dein Browser, das ist echte Netzwerk-Latenz und commercetools-API-Latenz.

Was man stattdessen macht: Early Performance Testing. Nutze dein echtes frontend-Hosting schon während der Entwicklung. Teste gegen echte commercetools-APIs. Installiere New Relic oder Datadog früh um Performance zu monitoren.

3. Integrationen zu spät testen

Payment-Integration, ERP-Integration, Email. diese sind kritisch für Go-Live. Du testest sie erst in Week 20 und stellst fest dass es nicht funktioniert.

Was man stattdessen macht: Integrationen sind nicht "Phase 2" sind, sondern "Phase 1". Erste Zahlung sollte in Week 10 bereits über commercetools laufen. Nicht gegen Testdaten, sondern gegen echte Liveumgebung (mit Testzahlarten natürlich).

4. Change Management ignorieren

Du migrierst den Shop. Aber dein Support-Team kennt die neue Plattform nicht. Dein Marketing-Team weiß nicht wie man Produkte anlegt. Das ist nicht technisch, das ist organisatorisch – das ist ein klassisches Thema für Change Management im E-Commerce.

Was man stattdessen macht: Training 4 bis 6 Wochen vor Go-Live. Dokumentation. Ein interner "Schalter-Tag" wo dein Team die neue Plattform kennenlernt bevor Kunden es sehen.

5. Zu ambitioniert sein

"Während wir migrieren, bauen wir auch noch folgende Features: neue Payment-Methode, neue Marketingtechnologie, neue Kundengruppen-Preislogik."

Das ist eine Sache zu viel. Migration + Features = verschwundenes Budget und verschwundenes Timeline.

Was man stattdessen macht: Migration ist nur Migration. Neue Features kommen nach Go-Live. Das erste Ziel ist Parität. Der alte Shop läuft, der neue Shop läuft, Kundenerlebnis ist mindestens so gut. Dann iteriert man.

Migrations-Checkliste

Nutze diese Liste bevor du dich zu einer Migration verpflichtest.

Pre-Project (vor Vertragsunterzeichnung)

• Geschäftliche Gründe sind klar. Warum commercetools? (nicht "weil es trendy ist")
• Budget ist realistisch geplant (mit 20 bis 30% Buffer)
• Timeline wird nicht überoptimistisch (6 bis 12 Monate einplanen)
• Team-Ressourcen sind verfügbar (dein Team ist nicht gleichzeitig 5 andere Projekte)
• Stakeholder verstehen dass Feature-Freezes während Migration nötig sind

Discovery Phase

• Anforderungsdokument ist abgeschlossen
• Zielarchitektur ist definiert (Frontend-Framework, CMS, Search-Lösung)
• Alte Plattform wurde analysiert (Datenmengen, Komplexität, Probleme)
• Payment-Strategie ist geklärt (welche Provider, Migration der Zahlmethoden)
• Integration-Plan ist dokumentiert (ERP, Email, Analytics, etc.)

Development Phase

• Frontend-Environment ist gesetzt und produktiv (nicht auf localhost)
• Datenmigrations-Skripte sind getestet (zuerst in Test-Umgebung)
• Payment-Integration funktioniert Live (mit Testdaten)
• Search ist konfiguriert und indexed
• CDN und Image-Delivery sind optimiert

Testing Phase

• UAT mit echten Nutzern (kein reines internes Testen)
• Load-Tests sind durchgeführt (mindestens 2x erwarteter Traffic)
• Disaster-Recovery Plan ist geschrieben (was passiert wenn etwas schiefgeht)
• Rollback-Plan ist dokumentiert (wie gehen wir zurück zum alten System)
• Support-Team ist trainiert

Go-Live

• Parallelbetrieb oder Big Bang Strategie ist gewählt
• Runbook ist geschrieben (Schritt-für-Schritt Guide für den Cutover)
• On-Call Team ist für erste 48 Stunden verfügbar
• Monitoring ist gesetzt (New Relic, Datadog, oder ähnlich)
• Kommunikation mit Kunden ist geplant (warum der neue Shop besser ist)

Post-Launch (erste 4 Wochen)

• Tägliche Performance Checks
• Bug-Report Prozess ist aktiv (Support hat direkten Draht zu Entwicklung)
• Analytics sind am Laufen (nicht erst später)
• Conversion-Rate ist gleich oder besser als vorher (du willst kein Traffic-Loch)

Fazit: Migration ist Strategie, nicht Technologie

Eine Migration zu commercetools ist nicht eine Frage von "können wir das machen". Natürlich können wir das. Die Frage ist "sollten wir das machen". Und die Antwort hängt von deinem Geschäftsmodell ab.

commercetools macht Sinn wenn du Omnichannel brauchst, wenn Headless Commerce die richtige Architektur ist, wenn du Langzeit-Investment in dein Frontend sehen willst. Wenn du ein Standard-B2C-Shop bist und schnell online sein willst, ist Shopify die bessere Wahl.

Die Migration selbst ist eine neun-Monate-Sache. Nicht für die Ungeduld. Nicht für kleine Budgets. Aber wenn du das durchziehst, hast du ein System das mit dir wächst statt dich zu begrenzen.