Are You Considering a PLM Migration (CAD Data Migration)?
Migrating and replacing existing part structures and CAD is a challenge. You need the right strategy and know-how for a successful migration. Without an effective strategy, moving large amounts of design data becomes increasingly difficult. Defining the best strategy, such as ‘big bang’ or ‘incremental’ migration, along with leveraging the right toolset, will ultimately enable a smooth and successful migration. To get a full understanding of your PLM migration, you need to make sure that you ask the right questions. From a systems architecture view:
- Are you replacing or re-aligning your current PLM system?
- Will a brand new target system be set up or are you migrating to an existing system?
- What interfaces to other systems will you need?
From an organizational view:
- What are the deadlines and timeframes for your migration?
- Do you have the right internal and/or external resources?
- Will this be completed in-house or will you hire someone?
- What is your budget?
From a process view:
- Which processes are you implementing?
- Which cross-system processes are you implementing?
- Which data are you sharing between old and new systems?
From a data view:
- What data are you providing? How much data are you providing?
- What is the quality of your meta data and CAD data?
- Are you migrating the whole history? What is the quality of historical data?
- How will you transform old data to fit new processes?
What is the best PLM migration / CAD Data Migration strategy?
Each use case is different, and some cases may benefit from a ‘one time’ migration instead of an incremental migration. But what benefits do we see with each?
‘Big Bang’ Migration
Get the Migration Blueprint
What is a ‘big bang’ data migration? Two definitions exist:
- Big Bang Data Centric – All data is moved to the new system.
- Big Bang User Centric – All users are moved at one point in time to the new system.
‘Big Bang’ Data Centric Migration
Advantages The migration process is executed only once. The migration does not have to deal with delta calculations migration. Disadvantage Blackout time for business can be very high.Training all users at once for the new system can be challenging.
Big Bang Data Migration Process
One-time migrations, aka ‘Big Bang’ or bulk migrations, give you the ability to export data from the source system to a staging database (extract). Data is then mapped to the target system format and any data issues are fixed (transform). Once completed, the entire staging database is imported to the production system.
- The source system is locked for any changes.
- All relevant data is moved to the new system.
- After the data movement all users work in the new system.
Note the blackout time is the critical factor for a big bang data migration approach. During a big bang migration, the longest that a business may not have access to data is a weekend plus 2-3 working days.
Big Bang User Centric Data Migration
Though this strategy is more complex, the added advantage of this migration is a reduction in your blackout time. All users will start working in the new system at a certain point in time. However, this is NOT true for the data.
Typically, this approach is separated by:
Frontloading
- Your source system is locked for changes or cloned to a test system to maintain a snapshot of the product system.
- After export of relevant data, the system is unlocked again.
- The snapshot is migrated to the new system (long migration period), the users remain in the source system and continue working in it while frontloading runs.
Delta Migration
- Your source system is locked for changes.
- Delta of the snapshot to the current system is migrated.
- After delta migration, all users start working in the new system.
Advantage
- The blackout time for the business is reduced significantly.
Disadvantages
- The migration needs to identify the delta in the source system and export only this delta.
- The migration needs to import the delta incrementally of the target system.
- Cloning the production system and locking the system until all data is exported.
- Training all users to the new system simultaneously is a challenge.
Incremental Data Migration
Incremental migrations allow more complex enterprises to transition from one PLM to another. Migration does not need to happen all at once. Instead, it moves at a pace of your choosing. Users can move to the new system with a new project or remain on the old system until the completion of the existing work. Data ownership is transferred from the old system to the new system and information is synced from the owning system based on the system of record. The following requirements may lead you to implement this approach:
- Your legacy system has a large user and data base which can’t be moved in a single ‘big bang’
- Your customer has multiple sites to migrate one after the next to the new system
- Each site can be migrated as a separate migration chunk.
If you’re moving forward with this migration strategy, you need to understand how the source system data (and users) can be allocated into migration chunks – per project, per program, etc. – and the order in which your migration is executed. Your migration process must be centered around the goal of moving all data into the new system. You must understand that each object knows the exact location of its master, which is often a great technical and organizational challenge.
Advantages
- The migration is split up into smaller migration chunks which are better maintainable for a migration process.
- Training end users can be planned per migration chunk
Disadvantages
- Moving migration chunks instead of the complete database causes additional effort on organization and technical level
- The migration has to deal with already migrated data (reuse when migration chunks overlap)
- An organizational and technical solution must be defined to lock migrated data in source system (one master principal)
- For overlapping data in the migration chunks a process is required to bring new revisions from target system to source system
Coexistence Data Migration
From a technology point of view, a coexistence data migration is the most complex and challenging approach for data migration. In this strategy, the legacy system and the new system must be kept in sync long enough to move all data to the new system. As this strategy focuses on minimizing the impact of the migration process for the business, it involves a bi-directional interface to enable a continuous business process. Both systems ‘coexist’ while your migration process occurs.
In short, coexistence is a mix of incremental migration for large data migrations and bi-directional synchronization processes. The approach must ensure that each object knows exactly where the master is.
Advantages
- Enables staged migration data
- Staged migration allows for easier PLM adoption strategies
- Errors are more easily controlled and corrected
- Enables migration to move at the pace of the business
Disadvantages
- GIGO – garbage in, garbage out – If your old data is bad, you will have bad data in your new system
- Order of import operations is not always transparent
- Performance is not as good
- Testing can be cumbersome
Regardless of your chosen strategy, the route to a successful migration includes careful project planning, defined requirements, and identification of the correct deliverables and tasks. Given the considerable complexity of migrations, what tools are best suited to help migrate your data?
OpenPDM Migrate for PLM/CAD Data Migration
Whether your chosen method of PLM migration is one time, staged or incremental, you need a tool that increases the likelihood of success. When you replace a PLM system, you want to ensure:
- Project success
- Manageable data migration
- High level of performance for future viability
- Optimal process monitoring
- Individualized solutions
- High level of economic efficiency
OpenPDM Migrate is your tool for product data migration.