One of the things we like to do at xLM Solutions is to share resources we think will help our clients. This week, we want to make sure you know about Engineers Rule, a publication of Engineering.com where you can find all kinds of articles about technology for design and engineering.
xLM Solutions is proud to announce that our content can be found there as well.
We recently published an article – which can be found here – on the challenges, strategies, and best practices when performing the used during SOLIDWORKS PDM data migration. Read on for a snippet then click over to Engineers Rule to read the article in its entirety.
Loading or migrating data into SOLIDWORKS PDM can be a daunting task. However, with diligent planning and thorough testing, the process can proceed smoothly. The following strategies should help ease the migration pain.
With any migration project, the first task—and perhaps the key to the entire project—is analyzing the data to be loaded. This will establish the scope of the migration effort and what the reasonable expectations should be. Depending on the project size or how it will be executed, an initial cursory review can be undertaken to get a feel for what is involved. However, in most cases, a more detailed review will need to occur.
When performing such reviews, we break them down into four different areas of analysis:
1. Where is the legacy data coming from? Determine the legacy data, its location, and the nature of the data.
- Does the data exist solely on the company’s network and is it primarily folder/file-based?
- Is the data coming from a legacy PDM or PLM system? In such cases, there is usually a database behind them, such as a file vault or file storage system. Typically, there is more involved in a migration project than pure files and folder-based data. Sometimes the migration may be comprised of a combination of files, network folders, and metadata contained in Excel spreadsheets or output from an ERP system. When dealing with a legacy system, we have seen everything from a proprietary customer database to commercial PLM systems with familiar names like ENOVIA SmarTeam, Autodesk Vault, PTC Windchill, and more.
- Is there hard copy data, such as a file cabinet with physical files in it? If so, part of the migration involves scanning the files and loading them into the system. This doesn’t happen often these days, but it does happen.
- Understanding the types of data that will be migrated. Is it pure metadata or possibly bill of materials information with no files behind it? Is it CAD data with internal links and relationships between the files (such as model to drawing links or assembly to sub-assembly and parts links)? Are there more “flat” files that do not have relationships (such as PDFs, JPEGS, Word, and Excel files)?
2. Determine how to best extract the data. Obtain access to the data and anticipate extraction.
- If the data is in a third party or a legacy system, can we get access to the database?
- Can we read the data in the database? Most legacy system databases are human-readable; typically, we can reverse-engineer them and get the data out. However, sometimes the system is proprietary and needs the involvement of a third party to help retrieve the data.
- Determine any missing data. When dealing with legacy systems that can be 10, 20 years old or more, data may be missing. This could be due to a number of reasons, including a backup and recovery gone wrong, bad data management practices, etc.
- How should we handle these issues? Are we going to ignore missing data? Is the end customer going to create or find the missing data?
- Bring in outside experts if necessary. Just like building a house, one person cannot perform all of the required functions. It makes sense to bring in outside experts to help in specific areas of the migration, or who have expertise in a particular proprietary system being migrated.
Read the rest of the article here: Challenges and Strategies of SOLIDWORKS PDM Data Loading.
Let us know what you think of the article and what subjects you’d like us to cover next.