Trusted by many leading companies.
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.
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 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
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:
- 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.
- 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.
- The blackout time for the business is reduced significantly.
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.
- 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
- 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.
- 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
- 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?
Whether your chosen method of PLM migration is one time, staged or incremental, you need a
- Project success
- Manageable data migration
- High level of performance for future viability
- Optimal process monitoring
- Individualized solutions
- High level of economic efficiency
6 Steps to a Successful PLM Migration
1. AS IS ANALYSIS – Start with an AS-IS ANALYSIS of your current state and your existing processes. You’ll need to be able to map these to your new system. A common challenge PROSTEP experiences is data quality, and you should address any concerns for data quality before any migration.
Consider the following during this phase:
- What is your current PLM Architecture?
- How does your PLM information flow, and what are your capabilities?
- What is your current system challenges?
- How efficient and capable is your current system? Do you have performance, data, and usage statistics to compare?
- What is the quality of the data to be migrated?
2. TO-BE DEFINITION – Decide what your TO-BE DEFINITION of how your new system will be set up and running. When migrating to a new system, how will this impact and modify your current processes?
Consider the following during this phase:
- How does your business strategy align with this migration?
- What migration strategy makes the most sense given your use case?
- Will you need vendor support for the migration?
- Will you be following best practices, and how will you realign your business processes?
3. SYSTEM SELECTION – Determine what tools will best suit your project and have a project plan laid out.
Consider the following during this phase:
- Establish a pilot/proof of concept
- Understand and procure the required hardware and software
- Determine a solution partner if required.
4. IMPLEMENTATION – Verify and validate your data, so from an end-user perspective, migration to the new system works as expected.
Consider the following during this phase:
- IT project management
- detailed specification
- system configuration and customization
- data conversion and migration
The Leading Toolset Built to Migrate Product Data
OpenPDM Migrate is the platform that gives you the ability to organize the migration of existing PLM data from an old system to a new system via different methods depending on your use case.
The platform allows you to migrate data ‘all at once’ (big bang) or if you need a longer transitional period, via temporary coexistence of the old and new systems.
With OpenPDM Migrate, you can virtually migrate any data including:
- CAD models and structures
- Item/ item revision and derived objects
- Forms, relations, datasets, and files
- BOM view revision and BOM lines
- Release status
- Change object
- Incremental changes
- Workflows and tasks
OpenPDM Migrate provides best-in-class standard access to connected systems so that you’re able to export, map, and import data to your new systems. All connecters offer the same interface allowing system specific technologies to be encapsulated. Only external and official standard interfaces are used guaranteeing smooth connectivity and migration of data between systems.
OpenPDM’s microservices architecture, separation of mapping engine and connectors, means you get the flexible integration of external migration tools from manufacturers!
OpenPDM Migrate is the toolset that has proven itself in the most complex projects enabling loss-free migration of older systems to the current releases of your PLM.
Supported operations include:
- Query objects
- Create/Read/Update/Delete Business objects
- Create/Read/Update/Delete Relationships
- Check-In / Check-Out
- Login / Logout from backend
- Execute Transitions (change lifecycle states)
- Execute Workflows
- Modify Ownership/Security/Projects, etc.
- Download / Upload / Delete Files
- Bulk operational methods
Architecture: OpenPDM supports a micro-service-oriented architecture where every service can run standalone or in combination with one another. These services can be integrated in any process or engine.
Export/Import Worker: OpenPDM logic is part of the connector service and allows a boost in performance by reducing HTTP calls and direct access to backend specific API.
Mapping: OpenPDM can work standalone or integrated into any other service, supporting XML, Java, and Groovy mapping variants. New variants can easily be integrated.
OpenPDM has a distributed architecture based on microservices utilizing the OpenPDM Unified Component Architecture. Versioned PLM data (metadata, structures, and files) are handled by RESTful interfaces. Our business process engine uses the popular BPMN solution Camunda and is specialized to handle semantical data.