Eine Commercetools-Implementierung ist keine Standardausbuchung. Je nachdem wie groß deine Anforderungen sind, dauert so ein Projekt zwischen 6 und 18 Monaten. Wir bei dasistweb begleiten Headless-Projekte seit 2011 und haben dabei gelernt, worauf es wirklich ankommt. Dieser Artikel zeigt dir, wie so ein Projekt realistisch abläuft und welche Fallstricke du vermeiden solltest.
Inhalt
- Das Wichtigste in Kürze
- Der typische Implementierungs-Ablauf
- Realistische Timelines nach Projekt-Größe
- Team-Zusammensetzung
- Die 5 häufigsten Stolperfallen
- Frontend-Wahl: Nuxt vs Next.js
- Wann Parallelbetrieb sinnvoll ist
- Wie dasistweb Headless-Projekte angeht
Das Wichtigste in Kürze
- Kleine Projekte dauern 6-8 Monate, komplexe B2B-Lösungen 12-18 Monate
- Die Discovery-Phase entscheidet über Erfolg oder Misserfolg
- Frontend-Wahl (Nuxt vs Next.js) hat großen Einfluss auf Entwicklungsgeschwindigkeit
- Die 5 häufigsten Fehler: unklare Anforderungen, schlechte API-Planung, zu wenig Testing, fehlende Content-Strategie, unterschätzte Datenmigration
- Aus langjähriger Erfahrung wissen wir: Parallelbetrieb kostet Zeit, spart aber Nerven
Der typische Implementierungs-Ablauf
Eine Commercetools-Implementierung folgt immer den gleichen Phasen. Die Reihenfolge ist fest, die Dauer variiert.
1. Discovery und Requirements (4-8 Wochen)
Hier stellst du sicher, dass beide Seiten von den gleichen Dingen sprechen. Du brauchst klare Anforderungen, sonst läuft dein Projekt aus dem Ruder.
In der Discovery klärst du:
- Business-Ziele und KPIs (z.B. wie viel Umsatz soll deine neue Plattform generieren?)
- Feature-Umfang (wie viele Produktkategorien? Wie komplexe Pricing-Logik?)
- Integrationen (ERP-Integration, PIM, DAM, CRM, Payment-Provider)
- Datenmigration (wie viele Produkte? Wie viele Kunden-Daten?)
- Nutzer-Gruppen (interne Teams, Kunden, B2B-Partner)
Tipp: Dokumentiere alles. Die besten Commercetools-Implementierungen starten mit einer klaren Requirements-Dokumentation. Keine vagen Ziele wie "wir brauchen ein modernes System". Sondern: "wir brauchen API-First-Commerce, weil wir auf 3 verschiedenen Channels verkaufen und die Produkt-Daten nur einmal pflegen wollen".
Weitere Informationen zur Architektur findest du in unserem Guide zur MACH-Architektur.
2. Architektur und Designphase (4-6 Wochen)
Die Architektur ist wie das Fundament eines Hauses. Eine schlechte Architektur-Entscheidung kostet dich am Ende Hunderttausende.
Hier machst du:
- Technologie-Stack (Frontend-Framework, Backend-Services, Hosting)
- API-Struktur und Daten-Modellierung
- Integrationsplan
- Security und Performance-Anforderungen
- Content-Strategie
Eine wichtige Entscheidung: Welches Frontend-Framework nimmst du?
Nuxt 3: Beste Wahl für komplexe deutsche B2B-E-Commerce-Shops. Performance-freundlich, SSR von Haus aus, große deutschsprachige Community. Bei uns Standard für eCommerce-Frontends.
Next.js: Flexibler, etwas steiler zu lernen, sehr großes Ökosystem. Besser wenn du viel Custom-Development brauchst oder in einen bestehenden Node.js-Stack passen musst.
Die Architektur-Phase kostet Zeit, ist aber Geld wert. Viele Agenturen sprinten hier drüber und merken später, dass die Dezentralisierung zu 30 verschiedenen APIs führt. Das ist teuer zu warten.
3. Build-Phase (16-24 Wochen)
Die längste Phase. Hier wird dein Shop gebaut.
Was passiert hier:
- Frontend-Entwicklung (Shop-Interface, Admin-Interfaces, Customer-Accounts)
- Backend-Services (Custom-APIs, Geschäftslogik, Datenebene)
- Integrationen bauen und testen
- Content-Strukturen aufbauen
Die Build-Phase ist parallelisierbar. Während das Team das Frontend baut, können die Backend-Devs schon an den Integrationen arbeiten.
Typische Zeitaufwendung:
- Einfacher Shop (unter 200 Produkte, wenige Integrationen): 8-12 Wochen
- Mittelgroßer Shop (200-5000 Produkte, 3-4 Integrationen): 12-16 Wochen
- Großer Multi-Channel-Shop (1000+ Produkte, 5+ Integrationen, B2B-Logik): 20-24 Wochen
4. Testing und Optimierung (4-8 Wochen)
Kein seriöses Projekt geht live ohne ordentliche Testing-Phase. Das ist nicht verhandelbar.
Du brauchst:
- Funktionales Testing (funktionieren alle Features wie versprochen?)
- Performance-Testing (lädt die Seite unter Last noch schnell genug?)
- Security-Testing (sind die Zahlungsdaten geschützt? Funktioniert die Authentifizierung richtig?)
- Penetration-Testing (wenn es um sensible Daten geht)
- UAT (User Acceptance Testing mit deinem Team)
Bei Performance gibt es konkrete Benchmarks: Page Load Time sollte unter 3 Sekunden liegen, Checkout unter 5 Sekunden. Manche Shops sind dabei nach Commercetools-Implementierung 40% schneller als mit der alten Legacy-Lösung.
5. Go-Live und Launch (2-4 Wochen)
Der Launch ist nicht der Endzustand, sondern der Anfang des Supports.
Was hier passiert:
- DNS-Migration (bestehender Traffic wird auf neue Plattform umgeleitet)
- Datenmigration (Produkte, Kunden, Bestellungen in den neuen Shop)
- Staff-Training (dein Team lernt die neue Plattform)
- Monitoring und erste Bugs
Go-Live-Strategien:
- Big Bang: Altes System wird komplett abgeschaltet, neuer Shop geht live. Schnell, aber riskant.
- Parallelbetrieb: Altes und neues System laufen parallel. Sicherer, aber komplizierter. Bei uns Standard für größere Projekte.
- Graduelle Migration: Zuerst eine Kundengruppe oder eine Kategorie auf das neue System migrieren. Am längsten, aber am sichersten.
Die beste Wahl hängt von deinen Anforderungen ab. Für komplexe B2B-Shops empfehlen wir immer Parallelbetrieb, auch wenn das extra 2-4 Wochen kostet. Das ist die Versicherung gegen Datenverlust und Kundenverlust.
6. Post-Launch und Optimierung (laufend)
Nach dem Launch brauchst du:
- Monitoring und Performance-Optimierung
- Bug-Fixes und kleine Nachbesserungen
- Feature-Requests umsetzen
- Skalierbarkeits-Checks (wie viele gleichzeitige Nutzer kann dein Shop ab?)
Die erste Woche nach dem Launch ist kritisch. Wir haben immer Support-Slots in den ersten 2 Wochen frei, um schnell auf neue Probleme reagieren zu können.
Realistische Timelines nach Projekt-Größe
Kleine Projekte (6-8 Monate)
- Bis 500 Produkte
- 1-2 Integrationen
- Kein B2B
- Beispiel: Mittelständischer B2C-Shop mit Standard-Integrationen
Discovery: 4 Wochen / Architektur: 3 Wochen / Build: 12 Wochen / Testing: 4 Wochen / Go-Live: 2 Wochen
Mittlere Projekte (10-14 Monate)
- 500-5000 Produkte
- 3-4 Integrationen
- Einfache B2B-Logik
- Beispiel: Multi-Marken-Shop mit PIM, DAM und CRM
Discovery: 6 Wochen / Architektur: 5 Wochen / Build: 16 Wochen / Testing: 6 Wochen / Go-Live: 3 Wochen
Große Projekte (14-18 Monate)
- 5000+ Produkte
- 5+ Integrationen
- Komplexe B2B-Logik, mehrere Märkte
- Beispiel: Großes E-Commerce-Unternehmen mit Channels wie Marketplace, Shop und B2B-Portal
Discovery: 8 Wochen / Architektur: 6 Wochen / Build: 24 Wochen / Testing: 8 Wochen / Go-Live: 4 Wochen
Die Zahlen sind realistisch aus unserer Praxis. Sind die Anforderungen klarer als angenommen, kann es schneller gehen. Sind sie vager, wird's länger.
Team-Zusammensetzung
Welche Rollen brauchst du im Projekt?
Auf der dasistweb-Seite:
- Product Manager (Strategy, Requirements-Klärung)
- Architect (Technologie-Stack, API-Design)
- 2-4 Backend-Developer (APIs, Integrationen, Geschäftslogik)
- 2-3 Frontend-Developer (Shop-Frontend)
- QA Engineer (Testing)
- DevOps / Infrastructure (Hosting, Monitoring)
Auf deiner Seite (Kunden):
- Projektmanager (übergeordnete Koordination)
- Business Owner / Stakeholder (Anforderungen, Go/NoGo-Entscheidungen)
- Shop-Manager oder Merchandiser (Produktdaten, Content)
- IT-Lead (Integrationen, Security)
- ggf. Fachexperten (wenn spezielle Anforderungen wie B2B-Pricing oder Multi-Währung)
Rollen können doppelt besetzt sein, müssen aber alle vertreten sein.
Die 5 häufigsten Stolperfallen
1. Unklare oder sich ständig ändernde Anforderungen
Das Problem: Der Kunde hat am Anfang keine klare Vorstellung, was er wirklich braucht. Im Lauf des Projekts kommen dann ständig neue Anforderungen. Der Scope wächst, die Timeline platzt.
Wie wir das vermeiden: Discovery-Phase mit Tiefgang. Wir arbeiten mit Use-Case-Maps, User-Journeys und Product-Specifications. Jede neue Anforderung wird gemessen an Aufwand und Nutzen. Änderungen sind möglich, aber dokumentiert und zeitlich geplant.
Tipp: Verwende eine Feature-Liste mit Prioritäten (Muss, Soll, Kann). Alles Unverzichtbare ist Teil des Projekts, optionale Features kommen in Phase 2.
2. Falsche oder zu optimistische API-Planung
Das Problem: Die API-Struktur wird unzureichend geplant. Dann merkt man erst während der Entwicklung, dass bestimmte Szenarien nicht abgedeckt sind. Nachträgliche API-Änderungen kosten doppelt so viel Zeit.
Beispiel: Der Shop braucht später tausende von Varianten pro Produkt. Die ursprünglich geplante Datenstruktur skaliert nicht. Umarbeiten kostet 4 extra Wochen.
Wie wir das vermeiden: API-Design ist nicht eine halbe Stunde, sondern dauert 2-3 Tage für komplexe Szenarien. Wir verwenden GraphQL für flexible Abfragen und denken von Anfang an an Performance. Wir simulieren auch Traffic-Szenarien: Wie viele API-Calls pro Stunde? Welche Response-Zeiten sind akzeptabel?
3. Zu wenig oder falsches Testing
Das Problem: Das Projekt ist "irgendwie" fertig, aber keiner hat richtig getestet. Dann gehen nach dem Launch innerhalb von 24 Stunden die Fehler-Tickets rein. Checkout funktioniert nicht, Payment-Integration ist fehlerhaft, Performance ist katastrophal.
Wie wir das vermeiden: Testing beginnt nicht erst am Ende. Wir testen während der Entwicklung (Unit Tests, Integration Tests) und haben eine dedizierte QA-Phase. Wir automatisieren auch viel mit Cypress oder Playwright.
Tipp: Performance-Testing ist nicht optional. Nutze Tools wie Lighthouse, WebPageTest oder GTmetrix. Page Load Time unter 3 Sekunden ist das Minimum. Bei B2B-Shops noch wichtiger.
4. Datenmigration wird unterschätzt
Das Problem: Am Anfang schätzt man die Datenmigration auf "2-3 Wochen". Dann stellt sich heraus: Die Produktdaten sind in 5 verschiedenen Systemen verteilt, die Struktur ist chaotisch, es gibt Duplikate. Auch die Kundendaten sind in schlechtem Zustand. Plötzlich dauert die Migration 8 Wochen.
Beispiel: 50.000 Produkte mit unterschiedlichen Kategorisierungen, Preisen für 5 Märkte, ungültigen Bildern und fehlenden SEO-Daten. Das ist nicht "Upload und fertig".
Wie wir das vermeiden: Datenmigration beginnt sehr früh im Projekt, nicht erst am Schluss. Wir machen Data Audits: Welche Daten brauchen wir wirklich? Was können wir bereinigen? Was muss manuell nachbearbeitet werden? Wir bauen auch Daten-Validierungen ein.
Tipp: Nimm die Zeit für Datenmigration in deiner Timeline ernst. Bei 50.000 Produkten rechnest du mit mindestens 6-8 Wochen.
5. Fehlende Content-Strategie
Das Problem: Der neue Shop ist technisch perfekt, aber die Content-Struktur ist genauso chaotisch wie im alten System. Kategorien sind verwirrend, Produktbeschreibungen sind dünn, SEO ist nicht optimiert.
Wie wir das vermeiden: Content-Strategie ist Teil der Architektur-Phase. Wie strukturierst du Kategorien? Welche Inhalte brauchst du für Conversion? Wie wichtig ist SEO? Wie bauen wir die neue Content-Struktur auf?
Tipp: Content-Migration ist ein separates Projekt. Nicht alle alten Inhalte sind es wert, in das neue System migriert zu werden.
Frontend-Wahl: Nuxt vs Next.js
Das ist eine häufige Frage. Beides sind moderne Frameworks, beides funktionieren mit Commercetools.
Nuxt 3:
- Aufbau: Vue 3 basiert, Composition API
- Dateisystem-Routing (fast wie Nuxt 2)
- Performance: Sehr schnell, Auto-Splitting
- SSR: Von Haus aus
- Learning Curve: Mittel (wenn du Vue kennst, sehr flach)
- Best for: Deutsche B2B-E-Commerce, Mittelstand, Performance-kritisch
- Unser Standard für eCommerce
Next.js:
- Aufbau: React basiert, Hooks
- App Router oder Pages Router
- Performance: Gut, wenn man es richtig optimiert
- SSR und SSG: Flexibel konfigurierbar
- Learning Curve: Mittel bis steil
- Best for: Complex Custom-Development, viel JavaScript, Ökosystem wichtig
- Besser für datengetriebene und content-schwere Seiten
Unsere Empfehlung für Commercetools: Nuxt 3. Die Performance ist besser, die Developer Experience ist angenehmer, und für E-Commerce-Szenarien ist es überlegen.
Aber: Wenn dein Team React-Experten sind und kein Vue können, ist Next.js auch eine gute Wahl. Team-Fit ist wichtiger als die beste Technologie.
Wann Parallelbetrieb sinnvoll ist
Parallelbetrieb bedeutet: Der alte Shop läuft noch, der neue Shop läuft auch schon. Beide sind gleichzeitig aktiv. Kunden können noch im alten Shop bestellen.
Parallelbetrieb brauchst du bei:
- Großen Shops (5000+ Produkte)
- Komplexer Geschäftslogik (Multi-Currency, B2B, Subscriptions)
- Bestehenden Kunden-Bases (du kannst nicht einfach 100.000 Kunden auf ein neues System migrieren)
- Hohem Bestellwert (je höher der AOV, desto wichtiger die Sicherheit)
Parallelbetrieb ist übertrieben bei:
- Neuen Shops (unter 6 Monate live)
- Einfachen Shops (unter 500 Produkte)
- Startups mit wenigen Kunden
Kosten des Parallelbetriebs: 2-4 Wochen extra Zeit, etwas höhere Infrastruktur-Kosten. Das ist die Versicherung wert.
Wie dasistweb Headless-Projekte angeht
Wir begleiten Headless Commerce und Composable-Commerce-Projekte seit 2011. Hier unsere Best Practices:
- Fundament zuerst: Wir investieren Zeit in Discovery und Anforderungs-Klärung. Saubere Anforderungen sind der beste Schutz vor Überraschungen.
- Klare Architektur: API-First, Cloud-Native, SSR-Frontend. Wir denken nicht in Legacy-Kategorien, sondern in Microservices-Architektur.
- Daten-Qualität: Datenmigration ist eine Kunst. Wir prüfen deine Daten, bevor wir sie migrieren.
- Testing ist nicht optional: Automatisierte Tests für Regressionsprobleme, Performance-Tests für Speed, Sicherheits-Tests für Payment.
- Zusammenarbeit: Regelmäßige Sync-Calls, klare Kommunikation, Transparenz über Fortschritt. Keine Überraschungen am Launch-Tag.
Fazit
Eine Commercetools-Implementierung ist kein Sprint, sondern ein Marathon. Je nach Komplexität brauchst du 6-18 Monate. Die wichtigsten Erfolgsfaktoren sind:
- Klare Anforderungen und Scope-Management
- Saubere API-Architektur von Anfang an
- Ernsthafter Testing-Prozess
- Datenqualität und Datenmigrations-Planung
- Richtige Frontend-Wahl (Nuxt 3 ist unsere Empfehlung für E-Commerce)
- Parallelbetrieb bei großen oder komplexen Projekten
- Gute Zusammenarbeit zwischen dir und deinem Agentur-Partner
Eine Commercetools-Implementierung ist eine Investition. Mit den richtigen Partnern und dem richtigen Plan rentiert sie sich schnell. Mehr über die Kosten findest du in unserem Artikel zu Commercetools Kosten oder in unserem Guide Commercetools vs. anderen Plattformen.
Nächste Schritte
Wenn du über eine Commercetools-Implementierung nachdenkst:
- Kläre deine Anforderungen. Keine vagen Ziele.
- Denke an Datenmigration früh.
- Wähle ein Team, das bereits Commercetools-Projekte gebaut hat.
- Plane mit realistischen Timelines. Der Druck ist in den ersten Wochen, nicht am Ende.
- Investiere in die Discovery-Phase. Das ist keine vergeudete Zeit.
Bei dasistweb begleiten wir dich durch den ganzen Prozess. Lass uns über dein Projekt sprechen.