How to migrate into “future PLM platform”?

How to migrate into “future PLM platform”?

plm-platform-migration

One of the topics I touched in my yesterday post about future PLM platforms is platform migration. The ability of customer to make a move is significantly dependent on how existing environment can be migrated. You can catch up on some of my earlier thoughts about PLM migrations by reading the following posts – PLM upgrades, release cycle and legacy softwarePLM migration and product data rock-n-rollPLM cloud and future of upgrades.

Most of large manufacturing companies (and even smaller companies) already made some sort of investment in PLM products. What is ROI of move to a new platform? How to calculate it? How not to get troubled by supporting multiple versions of applications and environment? These are good questions. Customers and PLM vendors are equally interested how to manage it in a right way.

My attention caught Dassault Systemes’ 3Dperspective blog post – Top Three Considerations for Planning Your Move to the 3DEXPERIENCE Platform. It speaks about how customer can migrate into new 3DEXPERIENCE platform. Here is an interesting passage:

The same data model and business process rules that power the 3DEXPERIENCE platform also powered the ENOVIA platform. In fact, the same basic approach also powered the MatrixOne platform. This is why so many of ENOVIA’s current customers have been able to successfully upgrade since their first implementation in the mid to late 1990’s.

The following picture shows the history of 3DEXPERIENCE platform evolution. It basically means that the say foundation platform used by all MatrixOne and ENOVIA customers and migration is effortless. I’m not sure if I’m happy to know that the same data technology used by all generation of systems from mid 1990s. However, it is clear benefit for customers looking how to migrate data between different versions of MatrixOne and ENOVIA V6.

3D-experience-platform-evolution

Dassault System’s rival – Siemens PLM and its TeamCenter platform also has long history of transformations. I didn’t find specific public references on compatibility between data models and application among TeamCenter versions. However, the following article from Tech-Clarity blog by Jim Brown presents an interesting diagram of TeamCenter evolution – Siemens PLM vision 2014+.

TeamCenter platform evolution

More information about evolution of TeamCenter can be found in the following CIMdata document – TeamCenter “unified”. The following passage speaks about “migration” issues:

Siemens PLM will continue to support Teamcenter Engineering and Enterprise for those customers that have them in production. Importantly, with each release of these older products, they have updated the underlying architecture and technology so that when a customer decides to change, the transition to the unified Teamcenter solutions will be easier. They have also developed a robust suite of migration tools that can be used when moving from earlier versions of Teamcenter products to the unified platform.

What is my conclusion? The migration is a complex topic. It is probably one of the most important topics that will define ability of large vendors to move into bright future of next generation PLM platforms. Regardless on what platform customer is going to move, migration will have cost that must be calculated and validated. The idea of “federated platforms” brings some promise of minimizing of migration cost. However, the mechanics of this process is not very clear. At the end of the day, data must be brutally dumped out and transferred. Application migration is even more complex. Users must be re-trained. All together, it is not a simple task. Just my thoughts…

Best, Oleg

Share

Share This Post