Die Migration von Daten in ein neues PLM-System beschränkt sich selten auf einen einfachen Prozess, bei dem die Daten exportiert, transformiert und in eine neue Umgebung importiert werden. Tatsächlich beginnen die komplexesten Projekte oft dort, wo Standard-Migrationsszenarien enden.

Dies gilt insbesondere für PLM-Ausgliederungen und -Fusionen, bei denen Unternehmen einen Teil ihres Geschäfts ausgliedern, PLM-Umgebungen nach einer Übernahme konsolidieren oder eine Transformation schrittweise durchführen. In solchen Fällen ist das Zielsystem sehr oft nicht leer. Bevor die eigentliche Datenmigration beginnt, enthält Windchill möglicherweise bereits Bibliotheken, Referenzobjekte, Produktstrukturen oder Dokumentationen, die von den Entwicklungsteams genutzt werden.

Dies verändert den Charakter des gesamten Projekts. Das Ziel besteht nicht mehr nur darin, Daten zu migrieren. Ebenso wichtig wird es, diese korrekt in die bereits in der Zielumgebung vorhandenen Informationen zu integrieren.

In einem unserer Projekte für ein Unternehmen, das sich auf Stromübertragungs-, -verteilungs- und -managementsysteme für die Luft- und Raumfahrtindustrie spezialisiert hat, sahen wir uns genau diesem Szenario gegenüber.

Warum sind PLM-Ausgliederungen und -Fusionen anspruchsvoller als eine Standardmigration?

Bei einer herkömmlichen Migration werden Daten in eine neue, leere Umgebung übertragen. Natürlich muss auch dabei sichergestellt werden, dass Datenmodelle korrekt abgebildet, Beziehungen zwischen Objekten erhalten und Versionshistorien beibehalten werden. Das Risiko von Konflikten ist jedoch relativ gering.

PLM-Ausgliederungen und -Fusionen sind anders.

Unternehmen implementieren eine neue PLM-Umgebung oft schrittweise. Einige Daten werden früher geladen, da das Unternehmen nicht auf den Abschluss der gesamten Migration warten kann. Es werden Bibliotheken mit Standardkomponenten, Referenzdaten, Klassifikationen, ersten Produkten oder technischer Dokumentation angelegt. Erst später ist es an der Zeit, historische Daten aus dem Vorgängersystem zu migrieren.

Infolgedessen existieren zwei Sätze von Produktinformationen nebeneinander und müssen zu einem einzigen, konsistenten Datenmodell zusammengeführt werden.

Diese Phase erweist sich sehr oft als die größte Herausforderung des gesamten Projekts.

Migration von Oracle Agile PLM zu Windchill

Das Projekt umfasste die Migration von Daten aus Oracle Agile PLM zu PTC Windchill.

Die Arbeit begann mit der gemeinsamen Festlegung der Migrationsstrategie. Dazu gehörten die Analyse der geschäftlichen Anforderungen, die Erstellung von Datenzuordnungen und die Festlegung, wie einzelne Objekte zwischen den Systemen transformiert werden sollten.

Die Datenextraktion erfolgte über Skripte, die von einem externen Anbieter erstellt wurden, während unser Team für deren Ausführung verantwortlich war. Von Beginn an waren wir zudem aktiv an der Definition der Anforderungen für den gesamten Migrationsprozess sowie an der Festlegung beteiligt, wie potenzielle Datenkonflikte behandelt werden sollten.

Nach Abschluss der Extraktion bestand der nächste Schritt darin, die Daten zu transformieren und für das Laden in Windchill vorzubereiten.

An dieser Stelle wurde deutlich, dass ein Standardansatz nicht ausreichen würde.

Wenn Windchill keine leere Umgebung ist

Bevor die eigentliche Migration begann, hatte der Kunde bereits einige Daten in Windchill geladen. Dabei handelte es sich in erster Linie um Bibliotheksobjekte, die vom Unternehmen als Referenzelemente verwendet wurden.

Obwohl sie nur einen kleinen Prozentsatz des gesamten Datensatzes ausmachten, mussten die anschließend aus Oracle Agile PLM migrierten Informationen diese Objekte verwenden und Beziehungen zu ihnen herstellen.

Das bedeutete, dass das Zielsystem bereits Objekte mit denselben Identifikatoren oder Namen enthielt wie die für die Migration vorbereiteten Daten.

In der Praxis warf dies eine Frage auf, mit der viele Unternehmen bei der Durchführung von PLM-Ausgliederungen und -Fusionen konfrontiert sind:

Was ist zu tun, wenn dasselbe Objekt bereits in Windchill vorhanden ist, aber auch im zu migrierenden Datensatz vorkommt?

Warum hat der Windchill Bulk Migrator das Problem nicht gelöst?

Wir haben den „Windchill Bulk Migrator“ (WBM) verwendet, das von PTC entwickelte Tool für umfangreiche Datenmigrationen.

In Standardszenarien funktioniert es sehr gut. Es ermöglicht den Import neuer Daten und unterstützt inkrementelle Migrationen für Objekte, die zuvor mit dem WBM geladen wurden.

In unserem Projekt war die Situation jedoch anders.

Einige der bereits in Windchill vorhandenen Objekte waren außerhalb des WBM-Prozesses erstellt worden. Die anschließend aus Oracle Agile PLM migrierten Daten mussten mit diesen Objekten verknüpft werden, wobei die korrekten Beziehungen, der Versionsverlauf und die Integrität des gesamten Datenmodells erhalten bleiben mussten.

Der Standard-WBM-Mechanismus war für diese Art von Szenario nicht ausgelegt.

Die Herausforderung bestand daher nicht einfach darin, die Daten zu importieren, sondern zu entscheiden, wie zwei nebeneinander existierende Sätze von Produktinformationen zusammengeführt werden sollten.

Entwicklung einer maßgeschneiderten Zusammenführungsstrategie

Anstatt zu versuchen, das Projekt an die Einschränkungen des Standardtools anzupassen, beschlossen wir, einen eigenen Ansatz für den Zusammenführungsprozess zu entwickeln.

Während der ersten Testiteration verwendeten wir einen einfacheren Ansatz, bei dem die migrierten Objekte vorübergehend umbenannt wurden. So konnten wir uns auf die Überprüfung der verbleibenden Elemente des Migrationsprozesses konzentrieren und den ersten vollständigen Testlauf abschließen, ohne das Kollisionsproblem lösen zu müssen. In der nächsten Iteration, nachdem der Rest des Prozesses validiert worden war, definierten wir gemeinsam mit dem Kunden die Anforderungen für den Umgang mit Kollisionen und entwickelten die endgültige Zusammenführungslogik.

Dies war kein Prozess, der sich auf ein paar einfache Regeln reduzieren ließ.

Fast eine Woche lang analysierten wir verschiedene geschäftliche und technische Szenarien und legten fest, wie sich das System in jeder möglichen Situation verhalten sollte.

Jede Kollision erforderte eine andere Entscheidung

Die größte Herausforderung bestand darin, eine Logik zu entwerfen, die nicht nur einen Konflikt erkennt, sondern auch die richtige Entscheidung darüber trifft, was als Nächstes geschehen soll.

Wenn ein Objekt in Windchill noch nicht existierte, wurde es über den Standardprozess geladen.

Erkannte das System jedoch eine Kollision, analysierte der Zusammenführungsprozess, welches Objekt die primäre Informationsquelle bleiben sollte.

In einigen Fällen stellten die Daten aus Oracle Agile PLM die aktuellste Version des Produkts dar. In solchen Situationen identifizierte unsere Lösung die neueste Version des in Windchill vorhandenen Objekts und importierte die migrierten Daten als nachfolgende Versionen desselben Elements. Alle Beziehungen zwischen den Objekten und deren Historie blieben erhalten.

In anderen Fällen blieb das bereits in Windchill vorhandene Objekt die primäre Informationsquelle. Die migrierten Daten wurden dann nicht als Duplikat importiert. Stattdessen wurden alle Beziehungen, die auf das migrierte Element verwiesen, automatisch auf den bereits im System vorhandenen Datensatz umgeleitet.

Dadurch erhielten die Endanwender ein einheitliches Datenmodell anstelle von zwei konkurrierenden Versionen desselben Objekts.

Automatisierung des Migrationsprozesses

Die PLM-Migration ist ein iterativer Prozess. Vor dem Produktivstart werden mehrere Testläufe durchgeführt, um die Korrektheit der Daten, Beziehungen und Produktstrukturen zu überprüfen.

Aus diesem Grund wurden alle Skripte, die für die Datentransformation und den Zusammenführungsprozess zuständig sind, von unserem Team entwickelt und vollständig automatisiert.

Der gesamte Prozess – vom Import der Daten aus CSV-Dateien über die Transformation und die Kollisionsauflösung bis hin zur Vorbereitung der Daten für das Laden in Windchill – konnte automatisch ausgeführt werden.

Dieser Ansatz reduzierte den Zeitaufwand für die Vorbereitung nachfolgender Migrationsiterationen erheblich, stellte die Wiederholbarkeit des Prozesses sicher und verringerte das Risiko von Fehlern, die durch die manuelle Ausführung einzelner Vorgänge entstehen können.

Ein sicherer Go-Live

Aufgrund der Vertraulichkeit der Daten hatte unser Team keinen Zugriff auf die Windchill-Produktionsumgebung. Der Go-Live wurde gemeinsam mit dem Kunden durchgeführt: Der Kunde führte die Vorgänge in der Produktionsumgebung durch, während wir den gesamten Prozess in Echtzeit überwachten, den korrekten Ablauf überprüften und technischen Support leisteten.

Die von uns entwickelte Strategie zur Datenumwandlung, die Zusammenführungslogik und die Automatisierungsmechanismen kamen bei der abschließenden Migration wie geplant zum Einsatz.

Die Datenmigration ist nur der Anfang

Dieses Projekt zeigt, dass bei PLM-Ausgliederungen und -Fusionen die größte Herausforderung oft nicht in der Datenübertragung zwischen den Systemen selbst liegt.

Wesentlich schwieriger erweist es sich, die Kontinuität der Produktinformationen zu gewährleisten, wenn die neue PLM-Umgebung bereits in Betrieb ist, bevor die Migration abgeschlossen ist. Dies erfordert eine intelligente Zusammenführung zweier Datensätze unter Beibehaltung der Versionshistorie, der Beziehungen zwischen Objekten und der Integrität des gesamten Produktinformationsmodells.

Eine effektive PLM-Migration erfordert daher nicht nur Kenntnisse über Tools wie den Windchill Bulk Migrator, sondern vor allem eine gut durchdachte Strategie zur Datentransformation. Bei PLM-Ausgliederungen und -Fusionen entscheidet diese Strategie darüber, ob ein Unternehmen am Ende über eine konsistente, für die weitere Entwicklung bereitgestellte PLM-Umgebung verfügt oder sich jahrelang mit den Folgen inkonsistenter Daten und der manuellen Behebung von Problemen auseinandersetzen muss, die während der Migration entstanden sind.

„Die größte Herausforderung bei einem PLM-Carve-Out- oder PLM-Fusionsprojekt ist selten die Datenübertragung selbst. Viel schwieriger ist es, die Konsistenz der Produktinformationen zu wahren, wenn das Zielsystem bereits in Betrieb ist und eigene Daten enthält. Jede Entscheidung darüber, welches Objekt als maßgebliche Quelle gilt, wirkt sich auf die Integrität des gesamten Datenmodells und die spätere Arbeit der Anwender damit aus. Deshalb ist eine gut durchdachte Fusionsstrategie genauso wichtig wie die Migration selbst.“

Wichtige Erkenntnisse

Bei PLM-Ausgliederungen und -Fusionen werden Daten häufig in eine Umgebung migriert, die bereits Objekte enthält, die vom Unternehmen aktiv genutzt werden.
Standard-Migrationswerkzeuge unterstützen nicht immer Szenarien, in denen migrierte Daten mit Objekten zusammengeführt werden müssen, die zuvor im Zielsystem angelegt wurden.
Ein wesentlicher Bestandteil des Projekts ist die Festlegung einheitlicher Regeln zur Auflösung von Konflikten, zur Beibehaltung der Versionshistorie und zur Aufrechterhaltung der Beziehungen zwischen Objekten.
Die Automatisierung des Transformations- und Zusammenführungsprozesses verbessert die Wiederholbarkeit nachfolgender Migrationsiterationen, verringert das Fehlerrisiko und verkürzt die Zeit, die für die Vorbereitung der Daten zum Laden benötigt wird.
Bei einer effektiven PLM-Migration geht es nicht nur um die reine Datenübertragung – ihr Ziel ist es, die Kontinuität der Produktinformationen zu gewährleisten und eine konsistente Umgebung zu schaffen, die für die weitere Entwicklung bereit ist.

PLM-Ausgliederungen und -Fusionen: Was tun, wenn das Windchill-Zielsystem bereits Daten enthält?

Die Datenmigration in ein neues PLM-System lässt sich selten auf ein einfaches Schema reduzieren: Daten exportieren, transformieren und in die neue Umgebung importieren. Tatsächlich beginnen die komplexesten Projekte genau dort, wo Standard-Migrationsszenarien enden.

Dies gilt insbesondere für PLM-Carve-Outs- und Merger-Projekte, bei denen Unternehmen Teile ihres Geschäfts ausgliedern, PLM-Umgebungen nach der Übernahme eines anderen Unternehmens zusammenführen oder eine schrittweise Transformation durchführen. In solchen Fällen ist das Zielsystem sehr oft nicht leer. Bevor die eigentliche Datenmigration beginnt, gibt es in Windchill bereits Bibliotheken, Referenzobjekte, Produktstrukturen oder Dokumentationen, die von den Ingenieurteams genutzt werden.

Dies verändert den Charakter des gesamten Vorhabens. Das Ziel ist nicht mehr ausschließlich die Datenmigration. Ebenso wichtig wird die korrekte Verknüpfung dieser Daten mit den Informationen, die bereits in der Zielumgebung vorhanden sind.

Bei einem der Projekte eines Unternehmens, das sich auf Systeme zur Übertragung, Verteilung und Verwaltung von elektrischer Energie für die Luft- und Raumfahrtindustrie spezialisiert hat, sahen wir uns genau mit einem solchen Szenario konfrontiert.

Warum sind PLM-Projekte im Zusammenhang mit Ausgliederungen und Fusionen anspruchsvoller als eine Standardmigration?

Bei einer klassischen Migration werden die Daten in eine neue, leere Umgebung übertragen. Natürlich muss auch dann auf die korrekte Abbildung der Datenmodelle, die Beibehaltung der Beziehungen zwischen Objekten sowie der Versionshistorie geachtet werden, doch ist das Risiko von Konflikten relativ gering.

PLM-Projekte im Zusammenhang mit Ausgliederungen und Fusionen sehen anders aus.

Häufig führt ein Unternehmen die Einführung einer neuen PLM-Umgebung schrittweise durch. Ein Teil der Daten wird bereits vorab geladen, da das Geschäft nicht auf den Abschluss der gesamten Migration warten kann. Es entstehen Bibliotheken mit Standardkomponenten, Referenzdaten, Klassifikationen, erste Produkte oder technische Dokumentationen. Erst später erfolgt die Migration der historischen Daten aus dem Vorgängersystem.

Infolgedessen entstehen zwei nebeneinander existierende Produktinformationsbestände, die zu einem einheitlichen Datenmodell zusammengeführt werden müssen.

Gerade diese Phase erweist sich sehr oft als die größte Herausforderung des gesamten Projekts.

Migration von Oracle Agile PLM zu Windchill

Das Projekt umfasste die Datenmigration von Oracle Agile PLM zu PTC Windchill.

Die Arbeiten begannen mit der gemeinsamen Festlegung einer Migrationsstrategie. Diese umfasste die Analyse der geschäftlichen Anforderungen, die Erstellung einer Datenzuordnung sowie die Festlegung der Art und Weise, wie einzelne Objekte zwischen den Systemen transformiert werden sollten.

Für die Datenextraktion waren Skripte zuständig, die von einem externen Anbieter erstellt wurden, während unser Team für deren Ausführung verantwortlich war. Von Beginn an waren wir zudem aktiv an der Definition der Anforderungen für den gesamten Migrationsprozess sowie an der Vorgehensweise beim Umgang mit potenziellen Datenkonflikten beteiligt.

Nach Abschluss der Datenextraktion begann die Phase der Transformation und Aufbereitung der Daten für den Import in Windchill.

Genau zu diesem Zeitpunkt stellte sich heraus, dass der Standardansatz nicht ausreichen würde.

Wenn Windchill keine leere Umgebung ist

Noch vor Beginn der eigentlichen Migration hatte der Kunde einen Teil der Daten selbstständig in Windchill geladen. Dabei handelte es sich vor allem um Bibliotheksobjekte, die von der Organisation als Referenzelemente genutzt wurden.

Obwohl sie nur einen geringen Prozentsatz der Gesamtdaten ausmachten, sollten die nachfolgend aus Oracle Agile PLM migrierten Informationen auf sie zurückgreifen und Beziehungen zu ihnen herstellen.

Das bedeutete, dass im Zielsystem bereits Objekte existierten, die dieselben Identifikatoren oder Namen hatten wie die für die Migration vorbereiteten Daten.

In der Praxis stellte sich eine Frage, mit der viele Unternehmen konfrontiert sind, die PLM-Carve-Outs- und Mergers-Projekte durchführen:

Was ist zu tun, wenn dasselbe Objekt bereits in Windchill vorhanden ist und gleichzeitig im migrierten Datensatz auftaucht?

Warum hat der Windchill Bulk Migrator dieses Problem nicht gelöst?

Für die Migration haben wir den Windchill Bulk Migrator (WBM) verwendet, ein PTC-Tool, das für die Abwicklung umfangreicher Datenmigrationen ausgelegt ist.

Diese Lösung bewährt sich sehr gut in Standardszenarien. Sie ermöglicht den Import neuer Daten sowie inkrementelle Migrationen für Objekte, die zuvor mit dem WBM geladen wurden.

In unserem Projekt sah die Situation jedoch anders aus.

Ein Teil der in Windchill vorhandenen Objekte wurde außerhalb des WBM-Prozesses angelegt. Die aus Oracle Agile PLM migrierten Daten mussten mit diesen Objekten verknüpft werden, wobei die korrekten Beziehungen, die Versionshistorie und die Integrität des gesamten Datenmodells gewahrt bleiben mussten.

Der Standardmechanismus von WBM war nicht für ein solches Szenario ausgelegt.

Es ging also nicht nur um den Datenimport an sich, sondern darum, zu entscheiden, wie zwei nebeneinander existierende Produktinformationsbestände zusammengeführt werden sollten.

Entwicklung einer eigenen Zusammenführungsstrategie

Anstatt zu versuchen, das Projekt an die Einschränkungen des Standardtools anzupassen, haben wir uns entschieden, einen eigenen Ansatz für den Zusammenführungsprozess zu entwickeln.

Während der ersten Testiteration haben wir einen einfacheren Ansatz gewählt, bei dem die migrierten Objekte vorübergehend umbenannt wurden. So konnten wir uns auf die Überprüfung der übrigen Elemente des Migrationsprozesses konzentrieren und einen ersten vollständigen Testdurchlauf liefern, ohne das Konfliktproblem zu lösen. Erst in der nächsten Iteration, nachdem der übrige Teil des Prozesses bereits verifiziert war, haben wir gemeinsam mit dem Kunden die Anforderungen für den Umgang mit Kollisionen definiert und die endgültige Merge-Logik ausgearbeitet.

Dies war kein Prozess, der sich in wenigen einfachen Regeln zusammenfassen ließ.

Fast eine Woche lang analysierten wir verschiedene geschäftliche und technische Szenarien und legten fest, wie sich das System in jeder möglichen Situation verhalten sollte.

Jede Kollision erforderte eine andere Entscheidung

Die größte Herausforderung bestand darin, eine Logik zu entwerfen, die nicht nur den Konflikt erkannte, sondern auch die richtige Entscheidung über das weitere Vorgehen traf.

Wenn das Objekt noch nicht in Windchill vorhanden war, wurde es standardmäßig geladen.

Wenn das System jedoch eine Kollision erkannte, analysierte der Merge-Prozess, welches der Objekte die übergeordnete Informationsquelle bleiben sollte.

In einigen Fällen stellten die Daten aus Oracle Agile PLM die aktuellste Produktversion dar. In einer solchen Situation suchte unsere Lösung die letzte Version des in Windchill vorhandenen Objekts und importierte die migrierten Daten als weitere Versionen desselben Elements. Dabei blieben alle Beziehungen zwischen den Objekten sowie deren Historie erhalten.

In anderen Fällen blieb das bereits in Windchill vorhandene Objekt die übergeordnete Informationsquelle. In diesem Fall wurden die Migrationsdaten nicht als Duplikat importiert, sondern alle Beziehungen, die zu dem migrierten Element führten, wurden automatisch auf den im System vorhandenen Datensatz umgeleitet.

Dadurch erhielten die Endbenutzer ein einziges, konsistentes Datenmodell anstelle von zwei konkurrierenden Versionen desselben Objekts.

Automatisierung des Migrationsprozesses

Die PLM-Migration ist ein iterativer Prozess. Vor der Inbetriebnahme in der Produktion werden zahlreiche Testläufe durchgeführt, um die Korrektheit der Daten, Beziehungen und Produktstrukturen zu überprüfen.

Daher wurden alle Skripte, die für die Datentransformation und den Merge-Prozess zuständig sind, von unserem Team erstellt und vollständig automatisiert.

Der gesamte Prozess – vom Import der Daten aus CSV-Dateien über die Transformation, die Behebung von Kollisionen bis hin zur Vorbereitung der Daten für den Import in Windchill – konnte automatisch gestartet werden.

Dieser Ansatz verkürzte die Vorbereitungszeit für nachfolgende Migrationsiterationen erheblich, stellte die Wiederholbarkeit des Prozesses sicher und reduzierte das Risiko von Fehlern, die durch die manuelle Ausführung einzelner Vorgänge entstehen können.

Sicheres Go-Live

Aufgrund der Vertraulichkeit der Daten hatte unser Team keinen Zugriff auf die Windchill-Produktionsumgebung. Der Go-Live wurde gemeinsam mit dem Kunden durchgeführt – der Kunde führte die Vorgänge in der Produktionsumgebung durch, während wir den gesamten Prozess laufend überwachten, seinen Ablauf überprüften und technische Unterstützung leisteten. Die von uns erarbeitete Strategie zur Datentransformation, die Merge-Logik sowie die Automatisierungsmechanismen wurden bei der abschließenden Migration wie geplant eingesetzt.

Die Datenmigration ist erst der Anfang

Das durchgeführte Projekt zeigt, dass bei PLM-Projekten im Rahmen von Carve-Outs und Fusionen die größte Herausforderung oft nicht die eigentliche Datenübertragung zwischen den Systemen ist.

Weitaus schwieriger erweist es sich, die Kontinuität der Produktinformationen zu gewährleisten, wenn die neue PLM-Umgebung bereits vor Abschluss der Migration in Betrieb ist. Genau dann entsteht die Notwendigkeit, zwei Datensätze intelligent zusammenzuführen, die Versionshistorie, die Beziehungen zwischen den Objekten sowie die Integrität des gesamten Produktinformationsmodells zu bewahren.

Daher erfordert eine erfolgreiche PLM-Migration nicht nur die Kenntnis von Tools wie dem Windchill Bulk Migrator, sondern vor allem eine entsprechend konzipierte Strategie zur Datentransformation. Bei Projekten vom Typ „PLM Carve-Outs & Mergers“ entscheidet genau diese Strategie darüber, ob das Unternehmen eine konsistente, für die weitere Entwicklung bereitgestellte PLM-Umgebung erhält oder ob es sich über Jahre hinweg mit den Folgen inkonsistenter Daten und der manuellen Behebung von während der Migration entstandenen Problemen auseinandersetzen muss.

„Die größte Herausforderung bei PLM-Carve-Out- oder PLM-Merger-Projekten ist selten die Datenübertragung an sich. Wesentlich schwieriger ist es, die Konsistenz der Produktinformationen zu gewährleisten, wenn das Zielsystem bereits in Betrieb ist und eigene Daten enthält. Jede Entscheidung darüber, welches Objekt als „Quelle der Wahrheit“ gilt, wirkt sich auf die Integrität des gesamten Datenmodells und die spätere Arbeit der Anwender aus. Daher ist eine gut durchdachte Merge-Strategie genauso wichtig wie die Migration selbst.“

Die wichtigsten Erkenntnisse

Bei PLM-Projekten im Rahmen von Carve-Outs und Fusionen erfolgt die Datenmigration häufig in eine Umgebung, die bereits Objekte enthält, die von der Organisation genutzt werden.
Standard-Migrationswerkzeuge unterstützen nicht immer Szenarien, die eine Verknüpfung der migrierten Daten mit zuvor im Zielsystem erstellten Objekten erfordern.
Ein Schlüsselelement des Projekts ist die Definition einheitlicher Regeln zur Lösung von Konflikten, zur Beibehaltung der Versionshistorie und zur Aufrechterhaltung der Beziehungen zwischen Objekten.
Die Automatisierung des Transformations- und Zusammenführungsprozesses erhöht die Wiederholbarkeit nachfolgender Migrationsiterationen, verringert das Fehlerrisiko und verkürzt die Vorbereitungszeit für den Datenimport.
Eine erfolgreiche PLM-Migration besteht nicht nur in der Übertragung von Daten – ihr Ziel ist es, die Kontinuität der Produktinformationen zu gewährleisten und eine einheitliche Umgebung zu schaffen, die für die weitere Entwicklung bereit ist.