Von Excel zu Golden Record - PIM-Migration in 90 Tagen

06.05.2026: 90 Tage klingen sportlich. In der Praxis sind sie ein realistisches Ziel, wenn der Fokus stimmt: nicht „das ganze Sortiment migrieren", sondern „ein Pilot-Sortiment so sauber im PIM haben, dass es produktiv arbeitet - und der Rest Schritt für Schritt nachzieht".

Das typische Problem

Die Produktdaten liegen in 47 Excel-Sheets. Sechs Personen pflegen parallel, drei davon hatten Urlaub in derselben Woche und keiner weiß, welche Version aktuell ist. Das Shop-System zieht nachts einen Export, der morgens teilweise kaputt ist. Ein PIM wurde vor zwei Jahren gekauft - und liegt ungenutzt auf einem Server. Jetzt soll „endlich migriert werden".

Die Methodik, die wir anwenden

Im Folgenden stellen wir den Phasenplan vor, den wir bei PIM-Migrationen in B2B-Sortimenten anwenden - von Industrieherstellern bis zu technischen Großhändlern. Die Schritte sind nicht abstrakt, sondern aus realen Projekten destilliert.

Unser sichtbarstes Beispiel: der Pimcore-Rollout bei Zumtobel - 500.000 Produktdatensätze, 14.000 Kategorien, 50 Produktklassen, Italien als erster Markt nach drei Monaten live, SAP und eine Produktdatenbank als angeschlossene Systeme. Die folgenden Seiten zeigen, wie wir solche Migrationen aufsetzen.

Warum 90 Tage realistisch sein können

Das Missverständnis: „90 Tage" bedeutet nicht, dass das gesamte Sortiment nach drei Monaten im PIM lebt. Es bedeutet, dass ein klar abgegrenztes Pilot-Sortiment produktiv im PIM arbeitet, alle angeschlossenen Kanäle es von dort bekommen, und die Infrastruktur steht, um das Restsortiment in Wellen nachzuziehen.

Der Schlüssel zu 90 Tagen: Phasen mit jeweils eigenem Nutzen. Keine Phase ist nur Vorbereitung für die nächste. Jede Phase liefert ein konkretes Ergebnis, das das Team erlebt und das Management messen kann.

Phase 1 - Discovery & Sortiment (Woche 1 - 2)

In den ersten zwei Wochen klären wir drei Dinge: Welche Daten haben wir heute wirklich - und wo? Welches Sortiment migriert zuerst? Und welche Systeme hängen dran, die wir beim Go-live anschließen müssen?

Der häufigste Fehler in dieser Phase: zu viel Zeit mit einer vollständigen Ist-Aufnahme verbringen. Wir fokussieren stattdessen auf das Pilot-Sortiment - ein bewusst kleiner Anteil der Artikel, der einen großen Teil des Umsatzes trägt oder für einen bestimmten Kanal strategisch ist. Für dieses Sortiment machen wir eine komplette Datenquellen-Inventur: Wo liegen die Attribute? Wer pflegt sie? Wo sind Lücken? Wo widersprechen sich Quellen?

Das Ergebnis nach Woche 2: ein Migrations-Umfang, den alle kennen - und ein dokumentiertes Mapping zwischen den Altsystem-Feldern und dem kommenden PIM-Datenmodell. KI-Tools können in dieser Phase die Quellen-Inventur beschleunigen - etwa Duplikat-Erkennung über fuzzy-matching von SKUs in mehreren Excel-Sheets oder das automatische Aufspüren von Spalten mit ähnlicher Semantik.

Phase 2 - Datenmodell & Target Operating Model (Woche 3-4)

Jetzt entsteht das Datenmodell im PIM. Taxonomie, Variantenhierarchie, Pflicht- und Kann-Attribute, Klassifikationen (ETIM, eCl@ss oder branchenspezifisch - siehe Deep Dive 03 für die Standard-Auswahl), Multi-Language-Felder. Gleichzeitig: das Target Operating Model (TOM) - wer pflegt was, wer gibt frei, wer verteilt.

Der Grundsatz hier: Das Modell muss tragen - nicht perfekt sein. Wir bauen es so, dass es das Pilot-Sortiment vollständig abbildet und eine saubere Erweiterung für das Restsortiment erlaubt. Variantenhierarchie und Klassifikation werden früh fixiert, damit Phase 3 nicht ins Stocken gerät und das Modell danach in Wellen wachsen kann.

Pimcore bietet dafür das Modul „Data Quality Management" - wir konfigurieren es früh, damit die Redaktion in Phase 3 sofort sieht, wo welche Produkte stehen und welche Lücken zuerst geschlossen werden müssen. Wo Lieferantendaten ohne Klassifikation hereinkommen, setzen wir bereits hier KI-gestützte Klassen-Vorschläge auf - Details dazu im Deep Dive zu Klassifikationen.

Phase 3 - Pilot-Import & Qualität (Woche 5-6)

Zwei Wochen für den ersten echten Import. Die Pilot-Artikel werden aus den Altsystemen extrahiert, nach dem in Phase 2 definierten Mapping transformiert und ins PIM geladen. Dabei läuft zum ersten Mal das Qualitäts-Scoring gegen echte Daten - und zeigt in aller Regel: Die Quellen sind schlechter, als das Team dachte.

Das ist ein gutes Zeichen. Die Lücken werden sichtbar, priorisierbar und zuweisbar. Redakteur:innen bekommen Arbeitslisten („Produkt X hat keine Leistungsaufnahme - bitte ergänzen"), Lieferanten bekommen Rückmeldungen („Ihr BMEcat-Feed liefert IP-Schutzart ohne Einheit"). Wichtig: In dieser Phase geht noch nichts live. Der Pilot-Bestand existiert im PIM, wird aber noch nicht an Shop, Marktplatz oder Katalog ausgeliefert.

KI als Beschleuniger. Genau hier setzen wir KI gezielt ein - als zusätzliche Schicht, die wir auf das PIM obendrauf bauen: fehlende Texte aus PDF-Datenblättern und Lieferanten-Dokumenten extrahieren, Übersetzungen für Multi-Language-Felder vorschlagen, Klassifikations-Vorschläge auf Basis bestehender Beschreibungen generieren, Duplikate über Vektor-Ähnlichkeit erkennen. Die Vorschläge gehen nicht direkt in den Golden Record - sie landen in der Reviewer-Queue der Redaktion. Das Qualitäts-Scoring entscheidet anschließend, ob ein Wert ausreichend belastbar ist, und der Mensch bestätigt. So beschleunigen wir die Lückenschließung um ein Vielfaches, ohne die Datenhoheit aus der Hand zu geben.

Das Ergebnis nach Woche 6: ein Pilot-Sortiment im PIM, dessen Qualitätsstand pro Artikel und pro Kanal sichtbar ist - und ein klarer Maßnahmenplan für die verbleibenden Lücken.

Phase 4 - Sync & Schatten-Betrieb (Woche 7-10)

Jetzt wird das PIM zum Schatten-Betrieb. Daten fließen zwischen Altsystem und PIM bidirektional - Änderungen im Altsystem werden übernommen, Änderungen im PIM werden zurückgeschrieben (oder umgekehrt, je nach Richtung der Migration). Das ist der heikelste Teil des Projekts und der, bei dem Mehrarbeit entsteht, wenn man ihn schlecht plant.

Unser Ansatz: Change Data Capture (CDC) - das Altsystem schickt Änderungs-Events an eine Message-Queue (Apache Kafka, RabbitMQ oder äquivalent), das PIM konsumiert sie. In die Gegenrichtung dasselbe. Genauso wichtig: idempotente Schnittstellen.

Warum idempotent? Jede Nachricht hat eine eindeutige ID (idempotency_key). Empfängt das Ziel-System dieselbe Nachricht zweimal - etwa nach einem Netzwerk-Timeout -, wird der zweite Versuch ignoriert. Ohne diese Disziplin entstehen Duplikate, wenn der Broker aus Sicherheitsgründen erneut zustellt.

In dieser Phase testen die Redakteur:innen parallel in beiden Systemen. Sie merken, wo das neue Datenmodell schneller ist, wo es Fragen aufwirft, wo Abläufe angepasst werden müssen. Das Sync-Konzept fängt die Doppelpflege auf: niemand verliert Änderungen, auch wenn parallel gepflegt wird.

Phase 5 - Cutover & Stabilisierung (Woche 11-12)

Die letzten zwei Wochen sind der eigentliche Go-live und die unmittelbare Nachbetreuung. Der Cutover ist technisch oft unspektakulär - er ist eher eine Umschaltung von Read-Ownership: Ab jetzt liest der Shop seine Produktdaten aus dem PIM, nicht mehr aus dem Altsystem. Die Pflege erfolgt ab sofort im PIM; das Altsystem wird read-only oder läuft gar nicht mehr.

Kritisch in dieser Phase: die Stabilisierung. Wir bleiben für mindestens 30 Tage nach Go-live im engen Monitoring: Wie viele Produkte gehen pro Tag durch die Qualitätsregeln? Wo stockt der Sync? Welche Redakteur:innen brauchen weitere Schulung? Welche Kanal-Konfiguration muss nachgezogen werden?

Das Ergebnis nach Woche 12: Der Pilot ist live, der Betrieb ist stabil, und die Infrastruktur steht für die nächste Welle des Sortiments. Auf dieser Basis lässt sich die Restmigration in weiteren Wellen ausrollen - etwa international, kategorienweise oder kanalbezogen.

Was wir konkret liefern

Vier Bausteine, die wir je nach Projekt-Konstellation kombinieren:

1. Phasenplan-Workshop und Discovery. Wir starten mit einem strukturierten Discovery-Prozess: Sortiments-Inventur, Stakeholder-Mapping, technische Bestandsaufnahme der Quell- und Ziel-Systeme. Ergebnis nach zwei Wochen ist ein detaillierter Phasenplan inklusive Pilot-Auswahl und Risiko-Map.

2. Datenmodell-Design und Pimcore-Setup. Wir entwerfen das PIM-Datenmodell auf Basis Ihres Sortiments und der angeschlossenen Kanäle: Taxonomie, Klassifikationen, Pflicht- und Kann-Attribute, Multi-Language. Die Konfiguration erfolgt im Pimcore Classification Store und im Data Quality Management.

3. Sync-Architektur und Implementierung. Wir bauen die CDC-basierte Sync-Schicht zwischen Altsystem und PIM - inklusive Idempotenz, Retry-Logik und Monitoring. Bei Bedarf implementieren wir auch die Anbindung an angeschlossene Systeme (ERP, Shop, DAM, Marktplatz-Konnektoren).

4. Stabilisierungs-Care und Wissens-Übergabe. Die ersten 30 Tage nach Go-live begleiten wir aktiv: Monitoring, Schulung der Redakteur:innen, Optimierung der Qualitätsregeln. Danach erfolgt die geordnete Übergabe an Ihren Betrieb - inklusive Runbooks und Eskalations-Pfaden.

Voraussetzungen, ohne die 90 Tage nicht reichen

Der Phasenplan setzt drei Dinge auf Kunden-Seite voraus. Fehlen sie, dehnt sich das Projekt deutlich - nicht weil die Methodik schwächer wird, sondern weil Themen, die nicht parallel zur Migration zu klären wären, in die Migration hineinrücken.

1. Erstens: ein klarer Daten-Owner aus dem Fachbereich. Eine Person mit Entscheidungsmandat über das Pilot-Sortiment - meist aus Produktmanagement oder kategorialem Einkauf. Wenn jeder Konflikt nach oben eskaliert wird, kostet jede Detail-Frage Tage. Die IT kann das nicht kompensieren.

2. Zweitens: ein CDC-fähiges Altsystem oder ein klar definierter Workaround. Wenn das Altsystem keine Änderungs-Events liefern kann (häufig bei reinen Excel-Setups oder bei sehr alten ERPs), muss ein Polling-basierter Workaround mit Hash-Vergleich die Sync-Logik ersetzen. Das funktioniert, ist aber langsamer und braucht mehr Operations-Aufmerksamkeit. Diese Entscheidung kommt in Phase 1, nicht in Phase 4.

3. Drittens: eine TOM-Bereitschaft. Das neue Datenmodell zwingt zu klaren Rollen: wer pflegt, wer prüft, wer gibt frei. Wenn diese Diskussion erst beim Cutover stattfindet, geht der Betrieb in die Streitigkeit. Die TOM-Klärung läuft spätestens in Phase 2 und bindet Personalressourcen, die parallel zum laufenden Geschäft frei sein müssen.

Anti-Patterns, die wir aus Projekten kennen

Sechs Muster, die regelmäßig zur Verzögerung führen - jedes davon haben wir schon gesehen, jedes lässt sich mit klarer Methodik vermeiden.

• Big-Bang-Migration über das gesamte Sortiment. Klingt nach „endlich aufräumen", endet in 18-Monats-Projekten ohne Zwischenergebnis. Stattdessen: Pilot + Wellen.

• Datenmodell perfektionistisch designen, bevor echte Daten reinkommen. Das Modell wird in Phase 3 auf Belastbarkeit getestet, nicht im Workshop. Wer Phase 3 hinauszögert, weil das Modell „noch nicht fertig" ist, verliert die Lernkurve.

• Sync-Schicht ohne Idempotenz. Klassischer Operations-Killer. Jede Re-Delivery erzeugt Duplikate; nach drei Wochen sind die Daten korrupt und niemand weiß, wo die Wahrheit liegt.

• Cutover ohne Schatten-Betrieb. Hart umschalten ohne Parallel-Phase ist eine Wette gegen die eigene Datenqualität. Bei der ersten Auffälligkeit fehlt der Vergleichsstand.

• PIM-Auswahl ohne TOM. Das neue Tool soll alles ändern, aber die Rollen bleiben unklar. Resultat: Das PIM wird wie das alte System genutzt - die erhoffte Wirkung bleibt aus.

• Keine 30-Tage-Stabilisierung. Das Projekt-Team ist nach Go-live „durch", aber der Betrieb fängt gerade an. Ohne Care-Phase verlieren die Redakteur:innen das Vertrauen ins neue System – und kehren zu den alten Excel-Workarounds zurück.

Was nach den 90 Tagen kommt

Mit dem Pilot-Go-live ist die Migration nicht abgeschlossen - sie ist replizierbar geworden. Drei Pfade, die typischerweise als nächstes greifen:

• Welle 2 und 3 - Sortiments-Skalierung. Das nächste Sortiments-Segment läuft in der Regel deutlich schneller als der Pilot, weil Datenmodell, Sync-Architektur und Pflege-Prozesse stehen. Wir begleiten typischerweise auch die Folge-Wellen, bis Ihr Team den Prozess autonom trägt.

• Internationale Skalierung. Sobald die DACH-Märkte stabil sind, wird das Modell auf weitere Länder ausgerollt – mit länderspezifischen Übersetzungen, lokalen Klassifikationen und ggf. abweichenden Compliance-Anforderungen. Die Pilot-Infrastruktur trägt das.

• Aufbau auf der Datenbasis. Saubere Stammdaten sind die Voraussetzung für die nächste Reife-Stufe: KI-Agenten, semantische Suche, dynamische Preise, Compliance-by-Design. Diese Schicht baut auf dem PIM auf und nutzt es als Quelle – beschrieben im Deep Dive 02 zum Decision-Ready Data Layer.

• Ergebnis: Ein produktives Pilot-Sortiment im PIM nach 12 Wochen, angebundene Kanäle, stabile Syncs - und eine Infrastruktur, die die Restmigration in Wellen tragen kann, ohne jedesmal neu zu denken.

Welches Sortiment würde bei Ihnen als Pilot funktionieren - und welche Fragen sind vorher noch zu klären?