Migrating to ENOVIA V6

This white paper provides a comprehensive business and technical perspective

on what is involved and what issues need to be considered when planning and
then implementing a data migration to ENOVIA V6.

Copyright © 2014 xLM Solutions, LLC. All rights reserved.

 Page 2

Introduction
Migrating to ENOVIA® V6 is a logical PLM direction for companies that are looking to evolve
their PLM system and expand its functionality. ENOVIA V6 provides scalability together with a
rich portfolio of out of the box modules and a set of configuration and customization tools
allowing companies to tailor the solution to their unique business process. Migrating data from a
legacy PLM system is not always a simple task. Indeed, it requires extensive due diligence as
well as careful advance planning to ensure the migration’s success. However, a well-planned
transition will result in happy users and a meaningful value added for the organization.
This paper will address both business and technical implementation aspects when migrating data
into ENOVIA. Some examples will be based on xLM Solution’s recent experience with
migrating a very large SolidWorks® SmarTeam environment to ENOVIA V6. However, the
points in this paper apply to any data migration to ENOVIA V6, regardless of the CAD system.

Things to Consider
1) Ask yourself and your organization what is the business driver for moving to ENOVIA
V6? Common answers might be: (1) taking advantage of the integration features with
CATIA® V6 for companies interested in moving to CATIA V6 or required by their
OEM, or (2) taking advantage of the rich out of the box portfolio in ENOVIA V6 such as
project management, quality control, engineering and manufacturing BOM management,
supply chain integration, variant management (configurator) and so on.

The answers to these questions will allow your migration consultant to better estimate the
effort required and time involved, allowing you to better prepare for the migration. The
greater the number of modules of ENOVIA V6 to be implemented and the more legacy
data to support such modules, the longer the time will be to complete the migration.
Also, clearly, greater data volume adds to the complexity of the project. Migrating
legacy data to different modules of ENOVIA V6 can facilitate a roll out using a phased
approach. By doing so, we can break the project down into smaller and more manageable
sub-projects.

2) How will ENOVIA V6 be implemented and configured?

a. Will it be based on or close to the ENOVIA V6 out of the box data model? This
of course makes the ENOVIA V6 implementation easier though it entails a
greater learning curve for users. For example, users will need to learn the new
terminology (changes of life cycle, state names, class/type names, operation
names, etc.) and changes in the user interface. The creation / update of work
procedures will need to be in place to demonstrate how operations are performed
in the new system. Additional focus needs to be put on mapping source data
(attributes, states, etc.) to the out of the box ENOVIA V6 equivalent objects.
b. Will it be based on a custom data model; i.e., something similar to the legacy
system? This option will make the company’s transformation easier from a

© xLM Solutions, LLC. 2014 All rights reserved. www.xlmsolutions.com. Email: [email protected]. Tel: (248) 926-5932.
 Page 3

business stand point, but will require additional configuration/customization on

the ENOVIA V6 implementation side. This also may have an impact on the level
of effort involved in upgrading ENOVIA V6 to newer versions.
c. Or does the company take some type of hybrid approach where they take the best
aspects of the out of the box ENOVIA V6 design and only tweak aspects of the
out of box design to support their unique business models and/or address lessons
learned from their legacy PLM system design and work processes.

3) What is the scope of the migration? Are you looking to migrate documents/CAD data
only, BOMs, workflow (engineering changes) history, other data types? The more you
plan on migrating, the longer the migration will take and the higher level of effort that
will be required. What you decide to migrate will determine the order in which the data is
migrated and any special mapping of types, states and attributes that need to be set. For
instance:
a. If a document’s data and item/BOM data will be migrated, you will need to make sure
that the proper relationships are created between such objects. Otherwise, ENOVIA
V6 behaviors such as EBOM synch will not be functional. If workflow data will be
migrated, most likely there will not be a direct one to one mapping of the legacy
workflow data to the ENOVIA workflow functionality such as ECO or ECR types,
routes, etc. If workflow mapping is necessary, xLM Solutions provides the
following options:
 Map workflow object’s meta-data to matching ECO/ECR object in ENOVIA V6.
 Export workflow history into Excel or any other format and migrate it as a Sketch
object in ENOVIA V6.
 Create PDF files to represent the legacy data workflow form (metadata) and save
the PDF file as a document object in ENOVIA V6.
 Recreate relationships between the legacy workflow object and its associated
affected objects (documents, items, etc.)
 We recommend migrating only completed workflows in (ended or terminated
status as released in ENOVIA V6). Running/in process workflows should be
manually implemented in an ENOVIA V6 post migration.
b. We recommend using out of the box ENOVIA V6 types for CAD objects to avoid
complications and untested special cases. This is even more important when dealing
with a SolidWorks® integration.

4) Phased approach – Depending on the size of the data to be migrated and the time to
conduct the migration, companies may want to split the migration across multiple
windows to minimize down time, but still have users use and modify data in both the
legacy PLM system and ENOVIA V6. While this will reduce the down time for the end
users, it makes the migration effort extremely complex. In such situations we

© xLM Solutions, LLC. 2014 All rights reserved. www.xlmsolutions.com. Email: [email protected]. Tel: (248) 926-5932.
 Page 4

recommend companies find temporary solutions for working during the production
migration down time. In the very unusual situation where it is anticipated that the
migration may extend beyond a weekend (note: we have seen only a very few cases
where a migration takes longer than a weekend), we recommend the following: (i) work
with the legacy system in read only mode and (ii) update the data in local folders and
manually merge such changes post migration. The effort to automate a migration by
“deltas” almost is never worth the effort.

Another matter to consider is the order of rolling out ENOVIA V6 modules. For
example, if a company is starting with Program Management, the module may have no
impact on any legacy data and this functionality can be turned on live with the need to
first conduct a migration. However, if the company starts with Quality Management,
and wants to execute the various quality processes around existing data, you may need to
migrate the legacy items data. In addition, if the legacy items are related to documents,
it makes sense to migrate the documents as well, so plan accordingly. Make sure you
explain this to all stakeholders and users of the system, even if it means you must wait a
little longer to go live. Setting correct user expectations has proven to be a success or fail
factor in many migration projects.

5) How do you data map from a legacy PLM environment to ENOVIA V6 and
translate/convert the legacy data?

a. Handling unique names and serialization of migrated data in ENOVIA V6 —

ENOVIA V6 object’s uniqueness is defined by the combination of type, name and
revision. For any migration, you need to ensure the migration methodology
addresses this object uniqueness. In the tools xLM Solutions has developed, we
allow the use of both serial numbers (i.e. an incremental number generator) and
the actual file name itself (specifically to the SolidWorks integration) to be used
to populate the name attribute of the object. Serial numbers will allow you to
carry over the data as is (including duplications around file name) and will require
less cleanup effort, though it does allow for possible duplicate ‘bad data’ to be
migrated in the process.
b. Data manipulations – Merging multiple source attributes from the legacy system
into a single attribute in ENOVIA V6, merging multiple data categories ( i.e.
classes from SmarTeam) into a single type in V6 or converting attribute types
(i.e. Boolean to Yes/No string, etc.), are available through customization and will
increase the level of effort involved. This being said, many companies see
migrations as a good opportunity to clean up data as well as to standardize based
on new procedures and processes. In these cases, it makes sense to go through
the data manipulation process. We have implemented such data manipulations /
merges rules successfully per our customer migration rules. It is important to
communicate with users and stakeholders that it is not just a migration anymore,
but a data manipulation project as well and will affect how the users use the
system and may affect the overall company’s business processes.

© xLM Solutions, LLC. 2014 All rights reserved. www.xlmsolutions.com. Email: [email protected]. Tel: (248) 926-5932.
 Page 5

c. Revision schema adjustments – ENOVIA V6 out of the box CAD objects

revisions are alphabetical, versions are numeric and non-CAD document type
revisions are numerical. Parts revisions are also numeric. If you decide to use the
ENOVIA V6 out of the box revisions or simply use the migration as an
opportunity to update revision schema based on some standards, how revisions
are mapped need to be considered. It is also possible to change the revision
schema in the policy in ENOVIA V6 to match what the revisions schema is in the
legacy system.

6) Cut Over Plan – When the production migration and the actual switching of systems
occur, the end users’ needs should be carefully thought out. Always discuss downtime
implications and restrictions with your customer/end users and stakeholders. Although
most average sized legacy migrations can be completed over a weekend or a holiday
weekend, some large migrations may require extended downtime.
a. It is critical to set proper expectations with the users and stakeholders in this case.
b. Dedicate a full test cycle prior to the production migration and perform it in a test
environment similar to the production environment to measure the actual
migration time (time the system will need to be down).
i. Develop a plan with the users to access data during down time. For
instance, set the legacy system to be read-only.
c. Make sure that the cut over plan allocates time and resources to ensure that any
required software be installed on each end user’s computer and that all end users
have been adequately trained and have supporting documentation so they will be
proficient in the new ENOVIA system.

7) Data Clean Up – Data cleanup is one of the key tasks during migrations. This is normally
a time when companies wake up and realize the messy state of their data. There is always
a discussion about data clean up as they see this as an opportunity to clean up the bad
data in the legacy system. “Bad data” may be characterized in two ways:
a. Logical/Business issues – These are typically cases of inconsistent data in context
of how the business wants to see the data but not really “broken” data in the
legacy system (such bad data will not corrupt anything in the legacy or ENOVIA
system). Such examples may be a revision in that it is not aligned with the
migration’s mapping rules. Another business related example is inconsistent
projects or folders structure, i.e. in SmarTeam all data should be linked to a
project or folder but some objects have no links to these objects. These examples
are normally a result of bad practices in SmarTeam.
b. Low-level corrupted data – These are typically issues that have resulted from a
crash of SmarTeam during an operation or bad automation (scripts and
customizations). Almost every database will have such issues. Such issues, even
though only a very few, may cause problems with the migration. Fixing these
issues can be done (i) by the administrator manually fixing the data, (ii) deletion
of the problematic data or (iii) direct database updates. For instance, with
SmarTeam these issues may cause issues with the daily use of SmarTeam and
may pose problems when migrating the data to ENOVIA V6. Examples would be
a shared file ID across different revisions of a file, changing a CAD reference

© xLM Solutions, LLC. 2014 All rights reserved. www.xlmsolutions.com. Email: [email protected]. Tel: (248) 926-5932.
 Page 6

name between revisions, etc. xLM Solutions has developed tools to identify such
bad data and possible solutions for resolution.

Dealing with data cleanup is always a heated topic. How far do you go with cleaning
up data? We encounter the typical: "if we are going to do this we might as well also
do this." There is no exact formula for how much to undertake. There is a tradeoff
between the cleanup and the level of effort involved. There are multiple variables in
the equation: a) business need for cleanup, b) how large is the data set to migrate, c)
how much bad data is there, and lastly, d) project deadlines.

xLM Solutions has developed a set of analysis tools and queries to help identify such
problematic data. Though our tools mainly deal with issues that would prevent data
migration to ENOVIA V6, there may be bad data that is business specific. In such
cases, we can develop customer specific queries to analyze and report on such data.
Data analysis should be an ongoing process through the entire migration process.
Performing data validation (normally through sampling of data) is another critical
milestone in identifying issues ahead of time and dealing with them pre-migration.
Every migration process should have a data analysis stage early on.

8) Data Validation – Data validation is probably the most “neglected” part (by companies)
of a migration project. Companies normally tend to put too much confidence and faith in
tools and technology providers. This is a mistake! You know your business and data
better than anyone else and only you should validate migration results. The level of effort
invested in data validation should be proportional to the volume of the migrated data set.
Normally days, possibly weeks, should be invested in testing, and preferably, by more
than one user, if possible. Data validation should include two components:
a. Validate as is migrated data – For example, verify (i) attributes mapping, revision
history, and confirm that relations show up as expected, and (ii) check out and
opening of files (specifically CAD files) to make sure they open and their links
are correct.
b. Document and validate specific use cases in ENOVIA V6 post migration. For
example, if you migrated documents and parts from SmarTeam to ENOVIA V6,
ensure that the EBOM synch works in the V6 post migration. Document your use
cases carefully and test them. Make sure you can perform the ‘new’ ENOVIA
functions on the migrated data.

Other Aspects to Consider

1) File Name vs. Serial number as part of the document object’s unique name in ENOVIA
V6 – As mentioned, ENOVIA V6 allows you to control a document’s name, more
specifically, CAD document object names by file name or by serial numbers. There is no
golden rule as to what to implement in ENOVIA V6. If the decision is to use a file name
as a unique object name in ENOVIA V6, refer back to the clean-up section. For example,
if the legacy system allowed duplicate file names (SmarTeam allows this), any data with
a duplicate file name being migrated will have to be changed. It is one thing to change a

© xLM Solutions, LLC. 2014 All rights reserved. www.xlmsolutions.com. Email: [email protected]. Tel: (248) 926-5932.
 Page 7

name of a flat file like an MS office document where there are no references. However,
for CAD files that have references, you would need to update all “where-used”
referencing files including history data, which, cannot be done manually. For cases
involving SmarTeam, xLM Solutions has developed custom programs to update “where
used” referencing files directly in the vault without changing the file revision or state in
SmarTeam.

2) Latest revision vs. full history –This is another dilemma to deal with and the decision
may change per company. Full history is a significantly more involved migration
process. However, it allows the company to disengage completely from the legacy system
(no need to maintain hardware, licenses, maintenance, etc. for the legacy system). Also,
the company will now be able to consider its ENOVIA V6 system the full system of
record. Migrating the latest revisions only may also break ‘as built’ designs or
constraints and mates when dealing with CAD data. For instance, consider what
happens if a non-latest part was used in an assembly. If migrating latest only, the non-
latest part would now be represented by the latest part which could break the integrity of
the data.

I personally believe that if you take the time and effort to migrate to a new system the full
history migration is the right way to go. At the end of the day it will justify the
investment.

3) Migration environment – If possible budget for at least two full migration test
environments. One of the two systems would mimic the to-be production environment to
enable accurate performance analysis and measuring of migration down time. The other
system can be used for changes and evaluation of such changes without affecting current
test migration data. For example, one machine can be used for communicating issues
with users or support, while the other can be used for testing new modules, etc. Always
check with Dassault Systèmes latest documentation regarding recommended hardware
and software for your business needs and use cases. In addition, with the use of virtual
machines the cost to create such environments can be greatly reduced.

4) Set permission and grants in V6 – It is not recommended to migrate users, groups or

grants during the migration. Though possible, this process is not always trivial due to the
data model discrepancy between the legacy system and ENOVIA V6. We at xLM
Solutions normally do that in ENOVIA V6 manually post migrate and pre go-live.

5) SolidWorks® (“SW”) Data – When dealing with migrating SolidWorks data there are a
few things you want to consider when developing a migration strategy:

© xLM Solutions, LLC. 2014 All rights reserved. www.xlmsolutions.com. Email: [email protected]. Tel: (248) 926-5932.
 Page 8

a. Families and instances – In ENOVIA V6, SW data has both family objects (file
level properties) and instances (config. specific objects). When dealing with
SmarTeam on the other hand, it normally manages data either as configurations
(if the CFO mechanism is enabled), and in that case there is no matching family
object; or when the CFO mechanism is disabled as file level objects only (no
configuration objects). When migrating to ENOVIA V6, SLW/DEK (the
SolidWorks Integration) is the module you want to ensure that your solution
“invents” the missing objects required by ENOVIA V6.
b. “Inventing” family objects – When creating the family object for the migration, it
should be the object that carries the revision history of the family for the file (the
file itself, not the specific configuration). In the case of SmarTeam, it is not trivial
to identify such objects, especially in many cases, configuration objects were
deleted in SmarTeam and there is inconsistent history to follow. As a result, the
revision history of the family object may not be correct. Therefore, building the
family object requires unique algorithms to determine what to use. xLM
Solutions has developed an algorithm to provide a best possible solution in
determining what object to use at the family object.

Technologies
There are multiple available custom migration technologies promoted by Dassault Systèmes:

 V5C Tools for CATIA V5 design data migration. V5C = FBDI + DBDI – set of
out-of-the box tools for CATIA V5 design data migration and coexistence with
CATIA V6. This set of tools can be used not only when SmarTeam is used for
CATIA design management, but also for VPM V4/V5, or in the case when there
is no PDM is used (file based).
o FBDI - File Based Design Import. Used to import CATIA V4/V5 data into
V6
o DBDI - Database Design Import. Used to import ENOVIA SmarTeam /
VPM V4/V5 (product structure / meta data / representation data) into V6
 JPO (using ENOVIA V6 API), MQL and TCL scripts are good as they make use
of the ENOVIA API and can perform data integrity checks before
loading/creating objects in ENOVIA V6. However, they tend be slower and may
drag the migration time past a weekend for larger migrations.
 Spinner – Spinner is a tool provided by Dassault Systèmes Services and it
requires a license (extra cost). Spinner is useful for small data migrations, data
model updates and upgrades, but it is not a good solution for a large data set
migration to V6 due to downtime constraints.

© xLM Solutions, LLC. 2014 All rights reserved. www.xlmsolutions.com. Email: [email protected]. Tel: (248) 926-5932.
 Page 9

 The ENOVIA V6 adaplet is provided free of charge as part of the ENOVIA

solution library and is probably the best fit for large migrations that require short
downtime periods. Configuring the adaplet to map the legacy data to the
ENOVIA V6 types and attributes mapping requires its own craft as well as a very
good understanding of both the legacy system and ENOVIA V6 data models and
behaviors. xLM Solutions has been using this technology and gained experience
in conducting SmarTeam ENOVIA V6 migrations with it. We have migrated
data on a scale of tens of millions of objects being migrated in just a few days
(over an extended weekend). That being said, the configuration process is a craft
not everyone excels at. Like any other tool, there are known issues and
limitations with adaplets. xLM Solutions has developed file import workarounds
and other tweaks to complete the import process using the adaplet technology.

As for data extraction out of the legacy system, there are two common ways:
 Legacy System API – This is good for small size migrations and does not require an
understanding of the underlying database structure; however, extracting data via the API
is usually slower than accessing the database directly.
 Direct database queries to extract the data– If the database structure can be understood,
this is the fastest way to extract data. In the case of SmarTeam, xLM Solutions has a
very good understanding of the SmarTeam tables and has proven that direct database
extraction is the fastest way (by far) to extract data from SmarTeam. For example, an
extraction of parts documents and folder structure in accordance to the V6 mapping rules
took only a few hours for a data base with over 2 million document objects as well as a
high number of items objects.

Available Solutions
As far as we are aware there are no other solutions out there promoted by Dassault or its partners
and resellers to conduct such migrations. At xLM Solutions we developed our own tool set and
proven methodologies specifically to migrate SmarTeam environments to ENOVIA V6 with
specific emphasis also for non-CATIA users (support for SLW/DEK) which is currently not
supported by most solutions available today. We also have the technologies and know how to
migrate any data into ENOVIA V6.

As with any other project, make sure that the solution you pick has been used successfully before
and that your service provider has very high skills on both the legacy system side and ENOVIA
V6. Be sure to thoroughly check references. At xLM Solutions we have accumulated over 30
years of SmarTeam implementation experience and over 11 years of ENOVIA V6 (previously
MatrixOne) experience. xLM Solutions, with its inventory of custom tools developed over the
years to facilitate migration issues and overcome problems, together with our broad experience
across many industries and involving all types and sizes of PLM data migration, is uniquely
positioned to work with you on any of your migration needs.

© xLM Solutions, LLC. 2014 All rights reserved. www.xlmsolutions.com. Email: [email protected]. Tel: (248) 926-5932.
 Page 10

We also believe that no one migration is ever identical to another migration. Every company has
its own flavors, data model nuances and unique migration requirements. We therefore designed
our solutions to be 70% generic and 30% customer specific. We believe that a one button
migration tool will always be limited in customer specific functionality. For additional
information about our migration SmarTeam to ENOVIA V6 solution, please go to
http://www.xlmsolutions.com/wp-content/uploads/2014/06/ENOVIA-SmarTeam-to-ENOVIA-
V6-web.pdf.

Conclusion
As stated earlier in this paper, migrating data from a legacy system to ENOVIA V6 is not only a
natural next step in the PLM evolution, but also allows companies to take advantage of the rich
portfolio of ENOVIA V6 as well as gain proven scalability and improved performance. Smooth
migrations must be well planned ahead of time to avoid any hurdles. Often times a poorly
planned migration will go over budget, experience delays and leave a bad taste with the projects’
stake holders and sponsors. However, if done right, companies will realize the potential and
returned value of their new system. This paper has exposed the main issues to consider in
planning for a migration with the ultimate goal of minimizing risk and ensuring a smoother
migration process.

About the Author

Ilan Madjar has been implementing PDM/PLM solutions for over 16 years for a wide range of
customers across different industries. Through the years, Ilan has conducted and led teams in
many large data migrations projects, from a variety of legacy systems and network drives files,
into Dassault Systemes’ family of PDM/PLM products (ENOVIA SmarTeam, ENOVIA V6,
SolidWorks EPDM and SolidWorks (WG)). Ilan and his colleagues at xLM Solutions not only
master technologies and tools, but developed methodologies based on his vast data migration and
PLM implementations experience to excel in such processes. Ilan holds an MBA in Technology
and BSc. in Industrial Engineering. Ilan can be reached at [email protected].

About xLM Solutions

xLM is a consulting company with extensive experience in delivering innovative solutions and
customizations to solve difficult PLM and IT challenges. It is our goal to assist you with your
PLM implementations and to partner with you in developing and deploying the best PLM and
collaboration solutions for your environment. Contact us and let us show you how we can meet
your challenges with our solutions, and make things simpler and more efficient with a true
bottom line benefit.

© xLM Solutions, LLC. 2014 All rights reserved. www.xlmsolutions.com. Email: [email protected]. Tel: (248) 926-5932.
 Page 11

To contact us, please visit our web site at:

http://www.xlmsolutions.com
call:
(248) 926-5932
or send email to:
[email protected]

xLM Solutions, LLC.

6689 Orchard Lake Road, Suite 112
West Bloomfield, MI 48322-3404

© Copyright xLM Solutions, LLC., 2014. All rights reserved.

© xLM Solutions, LLC. 2014 All rights reserved. www.xlmsolutions.com. Email: [email protected]. Tel: (248) 926-5932.