Most Agile PLM users underestimate how much work hides behind a PLM migration. On the surface, it looks like a technical exercise: extract the data, move it to a new system, reconnect integrations, and you are done. In reality, a PLM transition touches some of the most critical processes in the organization – how products are defined, how changes are controlled, and how engineering collaborates with manufacturing, quality, and suppliers.

With Oracle announcing that Premier Support for Agile PLM will end in December 2027, many companies are starting to realize that the question is not simply how to replace a tool. The real question is how to move forward without disrupting the systems and processes that support product development.

Done well, this kind of migration is not just a replacement project. It can be an opportunity to modernize how product data is managed across the organization.

What the end of support really means for Oracle Agile PLM users

Oracle confirmed in 2025 that Agile PLM will reach the end of Premier Support in December 2027. After that point, the platform will no longer receive updates or security patches, and only limited sustaining support will remain available.

Technically, the system will continue to run. But running a critical enterprise platform without vendor support introduces a number of challenges that tend to grow over time.

The first concern is security. Once patches stop arriving, newly discovered vulnerabilities remain unresolved. In a PLM environment this can expose highly sensitive data – product designs, engineering documentation, supplier information, and compliance records.

There is also a compliance aspect. Many industries depend on strict traceability and auditability of product data. When core systems are no longer supported by the vendor, questions often arise during regulatory reviews or certification audits.

Finally, there is the operational reality. Maintaining legacy systems becomes progressively harder as surrounding systems evolve. Integrations become fragile, customizations accumulate, and internal teams spend more time maintaining the system than improving it.

For many organizations, the issue is therefore not whether Agile will suddenly stop working after 2027. The issue is that the system gradually becomes harder to secure, harder to integrate, and harder to evolve.

Agile users looking beyond a like-for-like replacement

When Agile customers begin evaluating their options, Oracle naturally encourages them to migrate to Oracle Fusion Cloud PLM.

For some organizations this can be a viable path. But many companies take a step back and ask a broader question: if we need to invest in a major PLM transition anyway, should we reassess the whole landscape?

A Product Lifecycle Management platform is not just another IT system. It sits at the center of product development processes and connects engineering, manufacturing, quality, and service. Migrating to a new platform therefore affects not only PLM data, but also processes, integrations, and ways of working. 

Because of this, many organizations choose to evaluate several leading PLM solutions before deciding on their long-term direction.

Why Windchill often becomes part of the discussion

One platform that frequently enters these evaluations is PTC Windchill.

Windchill has been used for years in industries where products are complex and engineering processes require strict control – aerospace, defence, industrial equipment, automotive, and high-tech manufacturing.

From the perspective of Agile customers, one of the key differences lies in how the system manages product data. Agile environments are often centered around records, documents, and approval workflows. Windchill approaches the problem differently by embedding lifecycle management directly into the product structure and configuration.

This structure-centric approach provides stronger control over how products evolve across engineering, manufacturing, and service.

Integration is another important aspect. Modern engineering environments depend on consistent data exchange between PLM, CAD, ERP, MES, and other enterprise systems. Windchill provides mature integration capabilities, open APIs, and CAD-neutral tools that help maintain these connections across the digital landscape.

Another factor many organizations appreciate is deployment flexibility. Unlike some PLM platforms that are strictly SaaS-based, Windchill can support different deployment strategies depending on regulatory, security, or infrastructure requirements.

A PLM migration is never just a data migration

One of the biggest misconceptions about PLM projects is that migration primarily means moving data from one database to another.

In reality, the most important part of the project usually lies elsewhere: defining how the new system should support product development going forward and establishing a clear data migration strategy that aligns with future processes and business goals.

Oracle Agile and Windchill are built around different conceptual models. Agile implementations tend to be record-centric and workflow-driven. Many processes revolve around documents, items, and approval flows.

Windchill is fundamentally structure-centric. Product configurations, lifecycle states, and change management are closely linked to the product structure itself.

Because of this difference, it rarely makes sense to replicate Agile workflows one-to-one in Windchill. Most organizations instead take the opportunity to review existing processes and adapt them to modern PLM practices.

That redesign work may initially seem like extra effort, but it is usually where the real value of a migration project appears.

What a real migration process looks like in practice

To illustrate the complexity behind such transformations, the following example outlines a typical migration from Oracle Agile PLM to Windchill. It highlights the key differences in data models and the types of decisions required to ensure a clean and usable result.

Parts and documents

In Agile, both parts and documents are stored as generic Items and differentiated by a class attribute. In Windchill, they are distinct object types with different behaviors.

This requires:

  • Mapping Agile classes to Windchill soft types
  • Assigning product contexts based on product lines
  • Reconstructing missing attributes such as object names from descriptions
  • Normalizing free-text revisions into a structured revision scheme

Files and attachments

Agile allows files to be attached to both parts and documents without distinguishing primary content. Windchill enforces a more structured approach.

During migration:

  • Primary content must be defined explicitly
  • Files attached to parts must be converted into document objects
  • Rules are needed to decide whether files are grouped or separated

Change management

Agile uses a single object type for all change processes, while Windchill distinguishes between different change objects.

This requires: 

  • Classifying changes using attributes such as change type
  • Mapping them to appropriate Windchill objects (e.g., change notices, deviations)
  • Ensuring only relevant changes affect part revisions

BOM structures

The difference in BOM handling is one of the most significant challenges.

  • Agile stores a full BOM snapshot for each revision
  • Windchill links BOMs to the parent part revision and resolves child versions dynamically

Migration must therefore:

  • Preserve quantities and structure
  • Derive missing attributes such as units of measure
  • Transform reference designators into structured occurrences

Manufacturers and AML

Agile stores manufacturer and approved manufacturer list (AML) data in relatively flat structures.

To preserve traceability:

  • Manufacturer data is mapped to dedicated objects
  • AML history is reconstructed by comparing revisions and tracking changes over time

Part–document relationships

In Agile, relationships between parts and documents share the same underlying structure as BOM links.

During migration, these relationships must be interpreted and reclassified so that in Windchill they correctly represent:

  • Descriptive documents
  • Reference documents

Result

Because of these differences, a successful migration requires more than data transfer. It depends on careful mapping, data cleansing, and transformation logic.

When done correctly, the result is a clean, consistent, and Windchill-native dataset that preserves engineering intent while providing a stronger foundation for future development.

A well-planned migration strategy – an opportunity to simplify the system landscape

In many companies, Agile PLM does not exist in isolation. Over time, additional systems are introduced to manage CAD data, manufacturing information, supplier collaboration, or service documentation.

These tools often grow through customization and internal development. While they solve specific problems, they also increase complexity and maintenance costs.

Moving to a modern PLM solution creates an opportunity to simplify this landscape and consolidate product information into a single environment.

When done properly, the result is a clearer product data backbone and a much stronger foundation for what many organizations now call the Digital Thread.

Plan your Oracle Agile PLM migration with confidence

See how TT PSC can help

Check

Why planning early matters

Although 2027 may appear distant, PLM transformations are rarely short projects. Depending on the complexity of the environment, they often take 12 to 24 months from assessment to full adoption.

Organizations that begin planning early have time to evaluate options, define the future architecture, and carry out the migration in a controlled way.

Those that wait too long often find themselves making reactive decisions under time pressure.

To summarize…

The end of support for Oracle Agile PLM is a significant milestone, but it does not have to be a crisis.

For many organizations it becomes a moment to step back and reconsider how product data should be managed across the entire lifecycle.

Continuing on unsupported software gradually increases operational and security risks. Moving to a modern PLM platform, on the other hand, offers an opportunity to improve governance, strengthen collaboration, and create a more resilient digital backbone for product development.

The key is to approach the transition early and treat it not simply as a technical migration, but as a chance to evolve the role of PLM in the organization.