Migrating data to a new PLM system rarely comes down to a simple process of exporting the data, transforming it, and importing it into a new environment. In fact, the most complex projects often begin where standard migration scenarios end.

This is particularly true for PLM Carve-Outs & Mergers, where organizations separate part of their business, merge PLM environments following an acquisition, or carry out a transformation in stages. In such cases, the target system is very often not empty. Before the actual data migration begins, Windchill may already contain libraries, reference objects, product structures, or documentation used by engineering teams.

This changes the nature of the entire project. The goal is no longer simply to migrate data. It becomes equally important to integrate it correctly with the information already present in the target environment.

In one of our projects for a company specializing in electrical power transmission, distribution, and management systems for the aerospace industry, we faced exactly this scenario.

Why Are PLM Carve-Outs & Mergers More Demanding Than a Standard Migration?

In a conventional migration, data is transferred to a new, empty environment. Of course, even then it is necessary to ensure that data models are mapped correctly, relationships between objects are preserved, and version history is maintained. However, the risk of conflicts is relatively low.

PLM Carve-Outs & Mergers are different.

Organizations often implement a new PLM environment in stages. Some data is loaded earlier because the business cannot wait for the entire migration to be completed. Libraries of standard components, reference data, classifications, initial products, or technical documentation are created. Only later does the time come to migrate historical data from the previous system.

As a result, two sets of product information coexist and need to be merged into a single, consistent data model.

This stage very often turns out to be the biggest challenge of the entire project.

Migration from Oracle Agile PLM to Windchill

The project involved migrating data from Oracle Agile PLM to PTC Windchill.

The work began with jointly defining the migration strategy. This included analyzing business requirements, preparing data mappings, and determining how individual objects should be transformed between the systems.

Data extraction was handled by scripts prepared by an external vendor, while our team was responsible for running them. From the outset, we also actively participated in defining requirements for the overall migration process and determining how potential data conflicts should be handled.

Once the extraction was complete, the next stage involved transforming the data and preparing it for loading into Windchill.

It was at this point that it became clear that a standard approach would not be sufficient.

When Windchill Is Not an Empty Environment

Before the actual migration began, the client had already loaded some data into Windchill. These were primarily library objects used by the organization as reference elements.

Although they represented only a small percentage of the overall dataset, subsequent information migrated from Oracle Agile PLM needed to use these objects and establish relationships with them.

This meant that the target system already contained objects with the same identifiers or names as the data prepared for migration.

In practice, this raised a question faced by many organizations carrying out PLM Carve-Outs & Mergers:

What should you do when the same object already exists in Windchill but also appears in the dataset being migrated?

Why Didn’t Windchill Bulk Migrator Solve the Problem?

We used Windchill Bulk Migrator (WBM), PTC’s tool designed to handle large-scale data migrations.

It works very well in standard scenarios. It enables the import of new data and supports incremental migrations for objects previously loaded using WBM.

In our project, however, the situation was different.

Some of the objects already present in Windchill had been created outside the WBM process. The data subsequently migrated from Oracle Agile PLM needed to be linked to these objects while preserving the correct relationships, version history, and integrity of the entire data model.

The standard WBM mechanism was not designed for this type of scenario.

The challenge, therefore, was not simply to import the data, but to decide how to merge two coexisting sets of product information.

Developing a Custom Merge Strategy

Instead of trying to adapt the project to the limitations of the standard tool, we decided to develop our own approach to the merge process.

During the first test iteration, we used a simpler approach that involved temporarily renaming the migrated objects. This allowed us to focus on verifying the remaining elements of the migration process and complete the first end-to-end test migration without addressing collision handling. In the next iteration, once the rest of the process had been validated, we worked with the client to define the requirements for handling collisions and developed the final merge logic.

This was not a process that could be reduced to a few simple rules.

For nearly a week, we analyzed different business and technical scenarios, determining how the system should behave in every possible situation.

Each Collision Required a Different Decision

The biggest challenge was designing logic that would not only detect a conflict but also make the right decision about what should happen next.

If an object did not yet exist in Windchill, it was loaded using the standard process.

However, if the system detected a collision, the merge process analyzed which object should remain the primary source of information.

In some cases, the data from Oracle Agile PLM represented the most up-to-date version of the product. In such situations, our solution identified the latest version of the existing object in Windchill and imported the migrated data as subsequent versions of the same item. All relationships between objects and their history were preserved.

In other cases, the object already present in Windchill remained the primary source of information. The migrated data was then not imported as a duplicate. Instead, all relationships referencing the migrated item were automatically re-linked to the existing object.

As a result, end users received one consistent data model rather than two competing versions of the same object.

Automating the Migration Process

PLM migration is an iterative process. Before production go-live, multiple test runs are carried out to verify the correctness of the data, relationships, and product structures.

For this reason, all scripts responsible for data transformation and the merge process were developed by our team and fully automated.

The entire process – from importing data from CSV files, through transformation and collision resolution, to preparing the data for loading into Windchill – could be run automatically.

This approach significantly reduced the time required to prepare subsequent migration iterations, ensured process repeatability, and reduced the risk of errors caused by manually performing individual operations.

A Safe Go-Live

Due to the confidential nature of the data, our team did not have access to the production Windchill environment. The go-live was carried out jointly with the client: the client performed the operations in the production environment, while we supervised the entire process in real time, verified that it was proceeding correctly, and provided technical support.

The data transformation strategy, merge logic, and automation mechanisms we had developed were used during the final migration as planned.

Migrating Data Is Only Part of the Challenge

This project demonstrates that in PLM Carve-Outs & Mergers, the biggest challenge is often not the transfer of data between systems itself.

What proves significantly more difficult is maintaining continuity of product information when the new PLM environment is already operational before the migration is complete. This creates the need to intelligently merge two datasets while preserving version history, relationships between objects, and the integrity of the entire product information model.

Effective PLM migration therefore requires not only knowledge of tools such as Windchill Bulk Migrator, but above all a properly designed data transformation strategy. In PLM Carve-Outs & Mergers, it is this strategy that determines whether an organization ends up with a consistent PLM environment ready for further development or has to deal for years with the consequences of inconsistent data and manually resolving problems created during the migration.

The biggest challenge in a PLM Carve-Out or PLM Merger project is rarely the data transfer itself. What is much more difficult is maintaining the consistency of product information when the target system is already operational and contains its own data. Every decision about which object remains the source of truth affects the integrity of the entire data model and how users work with it afterwards. That is why a properly designed merge strategy is just as important as the migration itself.

Key Takeaways

  • In PLM Carve-Outs & Mergers, data is often migrated into an environment that already contains objects actively used by the organization.
  • Standard migration tools do not always support scenarios where migrated data needs to be merged with objects previously created in the target system.
  • A key element of the project is defining consistent rules for resolving collisions, preserving version history, and maintaining relationships between objects.
  • Automating the transformation and merge process improves the repeatability of subsequent migration iterations, reduces the risk of errors, and shortens the time required to prepare data for loading.
  • Effective PLM migration is not simply about moving data – its goal is to ensure continuity of product information and create a consistent environment ready for further development.