PLM Migration
What is PLM Migration?
PLM Migration is the process by which product lifecycle data is transferred to a new or existing PLM system because of consolidation, system end of life, or current system upgrade. PLM migration of data can include but is not limited to bills-of-materials (BOMs), CAD Documents, Change Data, Configurations and Effectivities, Classification, and more.
Factors to Consider BEFORE Your 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.
What is Your 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
PROSTEP Big Bang Data Migration
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
'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
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.
PLM Migration is the process by which product lifecycle data is transferred to a new or existing PLM system because of consolidation, system end of life, or current system upgrade. PLM migration of data can include but is not limited to bills-of-materials (BOMs), CAD Documents, Change Data, Configurations and Effectivities, Classification, and more.
Factors to Consider BEFORE Your 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.
What is Your 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
PROSTEP Big Bang Data Migration
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
'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
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.