How to migrate into “future PLM platform”?

How to migrate into “future PLM platform”?


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.


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 This Post

  • Standards, standards, standards this will be to me the best way to reduce migration cost.

    PLM specialists in companies should always be able to migrate most of their systems through Standard formats (STEP for example) and evaluate the gap (inherent to some software specific capabilities that wouldn’t be available in the standard).

    Regarding the migration projects within the same editor, I have leads coming telling me that moving from a solution to another within the same editor or changing has comparable cost in terms of migration.

  • beyondplm

    Yoann, Thanks for your comment! I can only wish for more standards. However, I consider it as too generic approach. From that standpoint, XML and XLS formats are standards for the last 10 years. So what? Most of CAD systems supported STEP and IGES. At the same time, do you believe somebody can develop “standard” that will be capable to take TeamCenter database and move it into Aras? I guess such implementations are available, but it takes time, dedication and cost money. So, migrations are not impossible task. But… it is still a dedicated project activity you do once and move on. An interesting question – will future “federated PLM platforms” deliver better experience? Just a thought… Best, Oleg

  • Ketan Suri

    Especially with Dassault, I see a big move towards industry focus solutions. The mantra has been to get to as closer to OOTB as possible with any new upgrade. There might be some changes needed for sure, but it may be accomplished with a design which might be upgrade independent – like Technia components.

  • beyondplm

    Ketan, thanks for mentioning standards and OOTB! This is certainly one of the biggest believes of large vendors to provide “stable” environment and ensure migration. Customers prefer that because it is a promising way to keep migration cost low. However, do you think it really works in practice? I’ve seen some interesting approach by vendors (eg. Aras) to include “upgrade” into service offering. It obviously can help only for migrations between products of the same vendor. Another migration approach is cloud product. I guess PLM360 is collecting some practices in that space too. At the same time, migration between different vendors are still complex issue.

    I have a question about Technia components. How it can simplify migration? From what I know TVC is a layer on top of Enovia (MatrixOne) platform. Correct me if I’m wrong, but it can only add additional layer of complexity. Otherwise, Technia will insure migration by providing migration services.

    Thanks, Oleg

  • Ketan Suri

    Oleg, yes the beauty of Technia components is – it is Enovia upgrade independent. We have done couple upgrades for our clients with installed components and it was not that complex.

    Vendors approach: “upgrade” into service offering – I will have to explore more on this.

    I feel it is possible to take an enhancement (configure/customize) approach that would be upgrade agnostic. This is an idea that was floated within our team recently.

    But again reality is companies are flexible to adapt at times and other time they want to use their winning recipe and customize. Both has its own pros and cons. I always prefer to start building on the strength of an organization processes than try to turn the ship 180 degrees.

  • beyondplm

    Ketan, that make sense. As service provider Technia prefer to have a single point of upgrade and control it. So, TVC plays that role perfectly.