PLM-Datenmigration strukturiert planen

Vorgehensmodell für eine sichere Migration von Produktdaten in PLM-Systeme – von Datenanalyse und Bereinigung bis zur Testmigration und zum kontrollierten Go-Live.

Vorgehensmodell für eine sichere PLM-Datenmigration

Viele PLM-Einführungen scheitern nicht an der Software, sondern an der Datenmigration.
Unvollständige Stammdaten, inkonsistente Stücklisten oder ungeklärte Revisionsstände führen häufig zu erheblichen Projektverzögerungen.
Fehler in der Datenmigration wirken sich direkt auf Engineering-Prozesse, Stücklisten und Änderungswesen aus.
Eine erfolgreiche PLM-Datenmigration beginnt lange vor der eigentlichen technischen Umsetzung. Sie erfordert ein klares Zielbild, eine definierte Migrationsstrategie und eine systematische Datenvalidierung.

Der folgende Leitfaden zeigt ein praxiserprobtes Vorgehensmodell in drei Phasen.

Phase 1 – Vorbereitung der PLM-Datenmigration (Risiken früh reduzieren)

1.1 – Ziel dieser Phase der PLM-Datenmigration

Die Migration wird planbar, weil Zielbild, Umfang und Regeln feststehen. Ohne diese Phase wird jede Migration zum Projekt mit offenem Risiko.
Ziel ist nicht nur eine erfolgreiche Migration, sondern eine Migration, die reproduzier-bar und dokumentiert durchgeführt werden kann.

1.2 – Zielbild und Migrationsstrategie für die PLM-Datenmigration festlegen

Kernfragen

  • Welche Objekttypen werden im Zielsystem geführt (Artikel, Baugruppen, Dokumente, eBOM)?

  • Welche Attribute sind Pflicht? Welche Standards gelten für Benennung, Nummern, Klassifikation?

  • Welche Prozesse setzen saubere Daten zwingend voraus (Änderungswesen, Freigaben, Service)?

Ergebnisartefakte

  • Ziel-Datenmodell (fachlich, nicht nur technisch)
  • Migrationsstrategie: selektiv vs. Vollmigration, Big Bang vs. Stufenmigration
  • Klarer Scope-Entscheid inkl. Begründung (Risiko, Nutzen, Aufwand)

1.3 – Migrationsumfang definieren: Welche Daten in die PLM-Migration übernommen werden

Leitprinzip: Nicht alle vorhandenen Daten müssen migriert werden.

Typische Regeln (Beispiele)

  • Migrieren: aktive Produkte, servicekritische Ersatzteile, aktuell gültige Dokumentati-on
  • Selektiv migrieren: ältere Produktgenerationen mit Servicepflicht, definierte Mei-lensteinstände
  • Nicht migrieren: Altprojekte ohne Servicebedarf, redundante CAD-Stände, „Archiv-schrott“

Ergebnisartefakte

  • Migrationsumfangliste (Objektklassen + Kriterien)
  • „Nicht-Migrieren“-Regeln (explizit dokumentiert)
  • Business-Freigabe des Umfangs (Managemententscheid)

1.4 – Datenqualität für die PLM-Datenmigration analysieren

Ziel: Objektiv messen, wo Risiken liegen.

Typische Prüffelder

  • Dubletten (Artikel, Dokumente, Nummernkreise)
  • fehlende Pflichtattribute (Material, Einheit, Status, Verantwortliche)
  • inkonsistente Benennung/Klassifikation
  • Stücklistenstruktur (Tiefen, Varianten, Phantompositionen, Mengeneinheiten)
  • Dokumentenzuordnung (verwaiste Dokumente, falsche Verknüpfungen)

Ergebnisartefakte

  • Datenqualitätsbericht (kurz, priorisiert)
  • Bereinigungskonzept inkl. Zuständigkeiten
  • Priorisierte Fehlerliste (was muss vor Go-Live sauber sein)

1.5 – Aufwand und Kosten einer PLM-Datenmigration realistisch einordnen

Datenmigration ist nicht nur ein technisches Thema. Ein erheblicher Teil des Aufwands entsteht durch fachliche Datenbereinigung und Validierung im Unternehmen.

Typische Aufwandsquellen

  • manuelle Korrektur fehlerhafter oder unvollständiger Stammdaten
  • Bereinigung von Dubletten und inkonsistenten Nummernkreisen
  • Prüfung und Harmonisierung von Stücklistenstrukturen
  • Klärung fachlicher Verantwortlichkeiten für Datenobjekte
  • Validierung kritischer Baugruppen und Dokumentationen durch Engineering oder Service

In vielen Projekten unterschätzen Unternehmen diesen Aufwand deutlich. Erfahrungs-gemäß entsteht ein großer Teil der Migrationsarbeit nicht im Migrationstool, sondern im Fachbereich.

Konsequenz für die Planung

  • ausreichende Fachbereichskapazitäten für Datenbereinigung und Validierung einplanen
  • klare Verantwortlichkeiten für Datenobjekte definieren
  • den Migrationsumfang bewusst begrenzen, wenn Datenqualität oder Ressourcen nicht ausreichen

Ergebnisartefakte

  • grobe Aufwandsschätzung für Datenbereinigung
  • Ressourcenplanung für Fachbereiche
  • Managemententscheidung über Umfang und Priorisierung der Migration

1.6 – Revisions- und Versionsstrategie für die PLM-Migration definieren

Hier entstehen die teuersten Fehler, wenn es nicht sauber entschieden wird.

Kernentscheidungen

  • Migrieren wir nur den aktuell freigegebenen Stand oder auch Historie?
  • Wie behandeln wir WIP-Stände?
  • Gibt es „Revisionswildwuchs“ im Altsystem, der harmonisiert werden muss?

Pragmatische Empfehlung (häufig richtig)

  • Nur valide, freigegebene und nachvollziehbare Stände migrieren
  • Historie nur dort, wo regulatorisch/servicebezogen erforderlich

Ergebnisartefakte

  • Revisionsregelwerk (kurz, verbindlich)
  • Migrationsregel: „Welche Revisionen/Versionen je Objektklasse“

1.7 – Governance und Abnahmekriterien für die Datenmigration festlegen

Datenmigration ist kein reines IT-Projekt, sondern ein Unternehmensrisiko.

Zu klären

  • Wer entscheidet bei Zielkonflikten (Engineering vs. IT vs. Operations)?
  • Wer nimmt Daten fachlich ab?
  • Welche Abnahmekriterien gelten je Objektklasse?

Ergebnisartefakte

  • Rollen & Verantwortlichkeiten (RACI light reicht)
  • Abnahmeplan (wer prüft was, wann, mit welchen Kriterien)
  • Eskalationsweg und Entscheidungslogik

1.8 – Checkliste Phase 1 – Vorbereitung der PLM-Datenmigration

  • Ziel-Datenmodell definiert
  • Migrationsumfang inkl. „nicht migrieren“ beschlossen
  • Datenqualitätsanalyse + Bereinigungskonzept vorhanden
  • Revisionsstrategie dokumentiert
  • Abnahmekriterien + Verantwortlichkeiten geklärt

Phase 2 – Umsetzung und Test der PLM-Datenmigration

2.1 – Ziel dieser Phase der Datenmigration

Die Migration wird reproduzierbar und abnahmefähig. Entscheidend ist nicht die erste Testmigration, sondern die Fähigkeit, Fehler systematisch zu reduzieren.

2.2 – Technisches Migrationsdesign für die PLM-Datenmigration

Bestandteile

  • Extraktionsformat (z. B. strukturierte Tabellen/Exports)
  • Feldmapping + Transformationsregeln
  • Validierungsregeln (Pflichtfelder, Referenzen, Statuslogik)
  • Reihenfolge der Objektanlage (z. B. Stammdaten vor Strukturen)

Wichtige Trennung der Verantwortlichkeiten

  • Kunde liefert Quellinformationen/Exports
  • Anbieter transformiert, validiert, spielt ein
  • Fachbereich prüft und nimmt ab

Ergebnisartefakte

  • Migrationsspezifikation (Mapping + Regeln, versioniert)
  • Validierungsregeln / Prüfreports

2.3 – Testmigrationen als Qualitätsprozess der PLM-Datenmigration

Zykluslogik

  • 1
    Testmigration #1 → Fehler sichtbar machen
  • 2
    Fehlerklassifikation (kritisch / relevant / kosmetisch)
  • 3
    Bereinigung + Regelanpassung
  • 4
    Testmigration #2 → messbare Qualitätsverbesserung
  • 5
    Optional #3 nur, wenn Qualitätsziel nicht erreicht

Ergebnisartefakte

  • Fehlerlog mit Ursachen (nicht nur Symptome)
  • Qualitätsmetriken (z. B. Pflichtfeldquote, Dublettenreduktion, Strukturvalidität)
  • Entscheid „go/no-go“ für Cutover-Vorbereitung

2.4 – Fachliche Validierung der migrierten PLM-Daten

Kritische Prüfungen

  • Stichproben kritischer Baugruppen inkl. Strukturvergleich
  • Revisionsstände plausibilisieren
  • Dokumente/Zeichnungen korrekt verknüpft?
  • „Teständerung“ im Zielsystem durchführen (Änderungsprozess praktisch prüfen)
  • Service-/Ersatzteil-Szenario prüfen (wenn relevant)

Ergebnisartefakte

  • Fachliches Validierungsprotokoll
  • Freigabeempfehlung für Cutover-Planung

2.5 – Checkliste Phase 2 – Test und Validierung der Datenmigration

  • Migrationsdesign dokumentiert (Mapping + Regeln)
  • Validierungsregeln implementiert
  • Mindestens 2 Testmigrationen durchgeführt
  • Fehlerlog + messbare Qualitätsverbesserung vorhanden
  • Fachliche Validierung inkl. Stichproben abgeschlossen

Phase 3 – Cutover und Go-Live der PLM-Datenmigration

3.1 – Ziel dieser Phase der Datenmigration

Der Wechsel wird als kontrolliertes Szenario geplant – inkl. Rückfalloption und fachlicher Abnahme.

3.2 – Cutover-Plan für die PLM-Datenmigration definieren

Typische Elemente

  • Freeze-Zeitpunkt (ab wann keine Änderungen mehr im Altsystem)
  • Delta-Konzept (falls zwischen Tests und Cutover Änderungen entstehen)
  • Finaler Migrationslauf (Ablauf, Verantwortliche, Zeitfenster)
  • Zeitliche Validierung: realistische Laufzeit (z. B. Vorgabe „innerhalb 48 Stunden“ als Prüfkriterium)
  • Kommunikationsplan (wer informiert wen, wann)

Zwischen letzter Testmigration und Cutover entstehen häufig neue Datenstände. Das Delta-Konzept definiert, wie diese Änderungen identifiziert und im finalen Migrationslauf übernommen werden.

Ergebnisartefakte

  • Cutover-Runbook (Schrittfolge, Zuständigkeiten)
  • Zeitplan inkl. Puffern und Entscheidpunkten

3.3 – Rollback- und Notfallkonzept für die Datenmigration

Zu klären

  • Was ist der Abbruchpunkt?
  • Wie wird zurückgeschwenkt, wenn kritische Fehler auftreten?
  • Welche Mindestkriterien müssen erfüllt sein, damit Go-Live erfolgt?

Ergebnisartefakte

  • Rollback-Regeln
  • Entscheidungsmatrix „Go / No-Go“

3.4 – Go-Live-Validierung nach der PLM-Datenmigration

Direkt nach Go-Live

  • definierte Abnahmeprüfungen (kritische Objekte, Top-Baugruppen)
  • Prozessdurchlauf im Alltag (Änderung, Freigabe, Ausgabe, Viewer, Suche)
  • Nachkorrekturen geregelt (wer darf was, wie dokumentiert)

Ergebnisartefakte

  • Abnahmeprotokoll
  • Stabilisierungskonzept (z. B. 2–4 Wochen Monitoring)

3.5 – Lessons Learned dokumentieren

  • typische Datenfehler identifizieren
  • Verbesserungen für Folgeprojekte ableiten
  • Governance für zukünftige Datenqualität definieren

3.6 – Checkliste Phase 3 – Go-Live der PLM-Datenmigration

  • Freeze/Delta/finaler Lauf geplant und abgestimmt
  • Laufzeit des finalen Durchlaufs validiert
  • Rollback/Notfallplan dokumentiert
  • Abnahmeprotokoll vorbereitet und durchgeführt
  • Stabilisierung und Verantwortlichkeiten geregelt

PLM-Datenmigration frühzeitig richtig aufsetzen

Die Datenmigration gehört zu den kritischsten Teilen einer PLM-Einführung.
Viele Probleme entstehen nicht in der technischen Migration selbst, sondern durch unklare Datenstrukturen, fehlende Governance oder unterschätzte Datenqualität.

Eine strukturierte Vorbereitung reduziert Projektrisiken erheblich und schafft eine belastbare Grundlage für die spätere PLM-Nutzung.

Wenn Sie vor einer PLM-Einführung oder einer größeren Datenmigration stehen, kann eine frühzeitige fachliche Einordnung helfen, typische Fehler zu vermeiden und den Migrationsumfang realistisch zu planen.