SMARTEAM to 3DEXPERIENCE data migration

I wanted to share with you our recent experience with yet another successful migration of CAD legacy data from SMARTEAM to 3DEXPERIENCE with CATIA V5 data. We solidified our migration tool and methodology even further, providing additional flexibility and options. The result? A happy customer.  We conducted this migration in a record breaking 2-month timeline, from project start date to go-live.

Here we share the process, methodology and some of the technical aspects of the project. Due to confidentiality restrictions, I cannot mention the customer name.


We used xLM’s generic migration tool. We first configured our tool and format to clean up the legacy data.  We then tested the tool against the legacy data set to work out any issues and make sure we had an accurate and clean process for the production migration.  Finally we conducted a final production migration over a weekend. In the case of large data sets, the file processing can be handled post migration as specified below.

The migration is driven by an XML configuration file and takes place in two phases.  Phase 1 is for “Staging/Extracting” data from the source database (in this case, a SMARTEAM database) and the second phase is to load the data into 3DEXPERIENCE (ENOVIA). Building the staging tables is done via a program written in .NET.  It creates tables/views in the staging database based on data in the source.  Phase 2 is to load the staging data into the ENOVIA database. This is done via a Java program (generic program across migrations) that connects to the staging database and loads data utilizing the ENOVIA APIs.

 Migration Process

  1. Pre-development – analyze source data and profile bad data.
  2. Test in Lab – conduct vanilla migration.
  3. Customer site – pretest configuration using small data sets.
  4. Run preliminary test to flush out errors from the lab test.
  5. Formal – perform the test run.
  6. Review error logs and generate respective SQL analysis queries as needed
    • Fix bugs – xLM
    • Fix bad data – Customer
  7. Repeat steps 3-5 on test cycle
  8. Using configuration files – run production migration on the SAME environment used for testing.


We encountered three main challenges in this project:

  1. Timeframe – customer requested to migrate all data and go-live in less than three months – this risk was mitigated by xLM’s extensive experience in migrating legacy SMARTEAM data (SOLIDWORKD, CATIA, DOCUMENTS, ITEMS, etc.) to 3DEXPERIENCE, its proven methodologies and its migration tools.
  2. Change of migration rules – about a third of the way into the project, the customer requested to change the migration strategy from full history to latest revision only, without changing the project timeframe. This risk was mitigated by the fact that our migration tools support the latest or full history, and by making fairly minor adjustments to the configurable views used by our tool.
  3. ITAR account – we could not get access to the customer environment using VPN and so remote access was not an option. We had to test our tools and methodologies on a vanilla environment, and later adjust (i.e., modify configurable settings and views) and test the process over Webex sessions with our customer. Time was always limited, adding to the overall time restriction challenge.

Technical Aspects of the Project

  • Users were not migrated in this project.
  • In this specific project, there was no data in ENOVIA prior to go-live.
  • If CAD_REF_FILE_NAME changed between revisions in SMARTEAM, we only used the latest revision CAD_REF_FILE_NAME.
  • Revisions outside of the revision schema in ENOVIA were not migrated, but were reported (and cleaned pre-migration in this project).
  • No change order was implemented and no migration of ECO from SMARTEAM, although xLM tools can support that as well.
  • Part number in CATIA was mapped to an attribute along with other attributes the customer requested.
  • File Name (without extension) was mapped to NAME.
  • If any duplicate file names are found, the NAME attribute of all duplicates are changed to “filename-DUPLICATExxx” in ENOVIA.  This may cause issues with referencing files.
  • Since only a SMARTEAM database was used as the master (source data) Embedded CATIA Component (virtual) were not migrated and any duplicate file names found in SMARTEAM were changed to “filename-DUPLICATExxx” in ENOVIA. Customer agreed to manually fix those discrepancies post migration.
  • Since viewable (CGR) metadata was not stored in the SMARTEAM database, CGR  viewable files were not migrated.
  • Basic Environment was used (one click).
  • Since migrating only the latest revision, if parent assembly (CATProduct) is released and child CATPart is not, the user would need to release children manually in SMARTEAM ahead of the migration. A report is provided for them to identify such cases.
  • Project and folder structure in SMARTEAM was migrated into Workspaces/Workspace Vaults. Only desktop objects in SMARTEAM were linked to the Workspace Vaults. Other documents were floating in the database (available through searches).
  • All data was migrated to a single collaborative space and company security contexts, though xLM tools can support multiple collaborative spaces.

This record-breaking two-month project with specific customer requirements was a challenge, but our team of experts and xLM tools and methodology proved equal to the challenge.  Our customer is delighted with the timing and results of this major data migration project.

Are you ready to start a migration project? Contact xLM Solutions.


Notify of
Newest Most Voted
Inline Feedbacks
View all comments

Contact Us