About the Unified Typing Migration Tool

Unified Typing is the default typing mode as of R2014x and it is the only mode supported starting R2018x. If you had previously created data in former typing mode, it is recommended that you migrate this data to have your data consistent with the typing mode you operate. It is not mandatory to do so but it is highly recommended. You can also migrate the old data when you are ready to do so. To help you with this migration, a JPO (Java Programming Object) was developed.

This page discusses:

Migration Principles
Recommendations

Migration Principles

The migration process is broken down into four main phases:

Customer Files Generation Phase: Generates CSV files that can be modified by customers to set target types and attributes mapping. It is triggered using the –GenFiles or the –GenAllFiles option. The migration process cannot be performed if this phase is not executed.
The –GenFiles option must be run each time new objects to migrated are added to the database. If the database is not populated with new objects, it is not necessary to run this option again, even if the database is restored.

Migration Phase

The migration phase is made up of five steps:


Steps	Triggered by	Comment
Step_1	`-step 1`	Adds object migration extensions to the objects attributes to migrate.
Step_2	`-step 2`	Changes the object type, updates semantic relations (paths) and exchange status objects.
Step_3	`-step 3`	Adds customer and applicative extensions. Customer extensions to add are read from CSV files.
Step_4	`-step 4`	Does attributes mapping from customer extensions and applicative extensions.
Step_5	`-step 5`	Removes migration extensions.

Note: All the steps of this second phase can be performed in a single execution using the -step All option and can be explicitly committed using the –commit option.

Path Update Phase

In single process mode, paths were updated at step 2. In multi-process mode, paths are no longer updated on the fly at step_2. They are logged in a ".ntmpath" file created in the NTMPathFiles folder.

Note: The NTMPathFiles folder is located in the given migration directory (use the -dir option).

Each second step (step_2) of a migration loop generates a “.ntmpath” file that may be empty if there is no path to update. You must therefore update the paths launching the tool using the "-updateImpacted <N>" option, after migrating all data.

Cleaning Phase: Updates exchange status objects, updates and cleans migration information related to the migrated objects. It is triggered using the –Clean option and can be explicitly committed using the –commit option.

Tips:

In guide mode, you can limit the number of types to manage. It is useful to test a migration for some types. You can also limit the number of objects to migrate. It can be useful if you want to test the migration on a reduced number of objects.
The tool does not migrate all the objects in a single transaction, the migration is performed in several transactions. The number of objects per transaction can be controlled using the appropriate option.
By default the changes are not committed, it works as a simulator. The simulation mode can be used to check if the mapping between V1 and V2 is correct. The result of the simulation is MQL files. The -commit option is to be used with -Step and -Clean only.
When simulating the migration, the transactions are not committed: the memory consumption increases and the tool can fail. In simulation mode, it is recommended that you limit the number of objects.
The generated MQL scripts shall not be run manually by the administrator. It would break the migration. They can be used and archived to keep a trace of the migration process.

Note: Before beginning the migration, it is highly recommended that you back up the database and shut down the application server.

Recommendations

This section provides you with recommendations related to the migration itself.

Before the Unified Typing Migration

Deactivate the unique keys created by the user in Model Customization.
Run all usual migrations.
- VPLMDataMigration
- DMC migration (if it exists on the previous level) OR
- baseline behavior Parameterization (if it exists on the previous level).
- Prepare your data as described in Prepare the Data.
Always make a backup of your database before launching the Unified Typing Migration using emxNewTypingMigrationProgram.
Make sure the database is optimized.
Validate the indexes (MQL).
If possible, monitor the database and, if needed, add SQL indexes when possible.
Never add any line to the CSV sheets.

Validations and Checks Before the Full Unified Typing Migration

It is recommended that you validate the use of the Unified Typing Migration Tool using sample data before migrating the complete database:

Always run the –GenFiles option first.
In CSE cases, the modification of CSV sheets must be performed at this stage. Save the new updated CSV files at the GenFiles directory location. Never modify CSV files after the migration steps are started ( step -1-5, step -all).

Note: Data are migrated when migration step #5 has been executed using the -commit option.

Run some tests using the -Types and -limit options for objects of given types.
If you do not use the -commit option, use -limit with a small number to prevent the computer from running out of memory during the validation stage.
Use the -Step <x> option where x=1 to 5 for tests purposes only.
Check the subset of migrated data in 3DEXPERIENCE native apps.
Once you are done with the tests, restore the database to perform the full migration.

During Full Unified Typing Migration

Use the -Step All option to run the migration along with the -commit option. Do not run it step by step.
When the migration is started, including -GenFiles, do not add new data to the database.
Break down the migration into several runs according to the number of objects for each type using the -Types option.
Run the -Clean option only at the very end of the process. Do not run this option after each type migration.
If possible, monitor the database in real time and, if needed, add SQL indexes when possible.

After the Migration

Reactivate the unique keys you may have deactivated before running the migration.
Note: You may not be able to reactivate the unique keys depending on the user's specifications.