What is data migration?
Data migration is the process of extracting, transforming, and injecting data from one system to another. Generally, migration is needed when there is an implementation of a new system to replace legacy systems or transformation for data needed to support the new technology.
Data Migration is one of the most important and critical parts of any PLM implementation project. Data is the most critical part of any organization. So if there is an implementation of a new system to handle the data, organizations prefer to preserve existing data as-is into the new system. The criticality or complexity of the migration process depends on the type of data, format of data, cross-data dependency, legacy system, and compatibility of a new system to support the format of legacy data.
In this article, we are going to learn different aspects of the Teamcenter data migration process. Go through it thoroughly to understand types of Teamcenter data migration, steps to migrate the data, and migration architecture.
Different scenarios for teamcenter data migration:
When it comes to data migration, as per our industry experience, we have categorized migration scenarios into three categories:
- Data migration from Legacy software’s to Teamcenter
Before PLM software’s, companies were dependent on legacy systems such as ERP software’s, Customized web portals, or any other third party software to manage their data. When a new PLM system is implemented then data is migrated from a legacy system to the new PLM Teamcenter system.
- Data migration from other PLM system to Teamcenter
Teamcenter is not the only PLM software available in the market. Companies also using other PLM software’s to manage their data. But functionality constraints, operating cost’s or incompatibility to incorporate with new technology, forces organizations to shift from existing PLM system to another. In such scenarios, data migration is needed to transfer data from the existing PLM system to Teamcenter.
- Data migration from one Teamcenter version to another
If there is a simple change in the Teamcenter version, then generally there is no need for data migration. Teamcenter up-gradation process automatically takes care of data transformation. But in some scenarios, where two business units of the company using separate Teamcenter software’s with a separate data model and they are planning to move to unified one Teamcenter latest version for both business units, then in this situation, simple up-gradation will not work. First data models will be merged and unified and then migrate data from both software into the unified new version.
Note: There could be other data migration scenarios that are possible. The above mentioned are only general scenarios based on our experience. Please feel free to mention in the comment section, if you have come across any other scenarios. We will note it down and update our article accordingly.
Teamcenter Data Migration Architecture
Following figure shows simple 3 phase migration architecture
Existing System: After data identification and extraction methodology finalization, data is extracted from the existing system into the staging area.
Staging Area: The staging area is the area where data is extracted from the existing system. The database can be installed and used to store metadata information. You can create as many tables as required to store object metadata into the database. You can also use Excel or CSV files to store metadata as per feasibility. Physical files can be stored in system folders and mention file path in the dataset staging table.
New System: New system is the system where is loaded from the staging area. You can develop custom utilities using ITK to load data into the new system. Teamcenter also provides OOTB functionalities to inject data into Teamcenter.
General Steps for Teamcenter Data migration:
Following are some of the general steps that are used while migrating the data.
1. Identify Data:
This is the very first step of any data migration process. In this step identify which object types to be migrated, take a count of the number of instances for each object type. Identify dependency of different object types with each other. If CAD data is available, then take the count of the size of the physical files. Analyze OOTB properties and custom properties information to be critical for migration.
2. Extract Data:
Extraction methodology can vary based on the type of source system you are using. You can extract the data into the required format using different tools. You can store extracted data into the staging table or CSV files or text files or any other format as per requirement and feasibility.
3. Validate Extracted Data:
Once data is migrated into the staging table, compare the count of objects in the staging database with the count taken in the first step. Make sure the count matches exactly. You can develop separate validation scripts to validate the extracted data. Take sample data for each object type and validate properties values with the As-Is system.
4. Transform Data:
Once the data is extracted, the next important task is to transform extracted data into an injectable format based on the to-be system environment and injection feasibility.
Transforming the data includes changing attribute values, attribute alignment, object dependencies, and data unification. There can be another transformation needed as per business process requirements. Transformation scripts can be developed and used to transform data in the staging area. Sometimes data alignment needs to be done to support injection methodology.
5. Inject Data:
You can use different methodologies to inject data into the Teamcenter environment. The most widely used methodology is to develop ITK utilities to load data into the Teamcenter environment. Some data can be imported using PLM XML. Multiple methodologies can be combined together to load the data.
6. Validate Injected Data:
Once the data is loaded. Use validation scripts to validate injected data and data available in the staging table. Some data can be tested manually. CAD files are tested by loading files into the integrated CAD applications.
Conclusion:
We hope this article was informative. Please do share your experience in the field of PLM data migration using the comment section or you can reach out to us using the contact form. We would be happy to hear from you.
