Multiple Generations of PLM Within a Single Company: Why?

Two, three or even four product lifecycle management environments sometimes coexist within a single industrial organisation. What might appear to be an IT malfunction is in fact a complex operational reality, shaped by decades of industrial, regulatory and strategic developments.

Across major aerospace, naval and defence groups, the coexistence of several PLM generations is far from an exception. It has become the norm. Yet the situation raises central questions for business and IT leaders alike: should convergence toward a single PLM be pursued at all costs, or can this plurality be organised sustainably?

This three-part series explores the question from every angle. From the diagnosis of root causes (article 1) to the analysis of hidden costs (article 2), and on to the adaptation and exit strategies available (article 3), we explore the implications of a situation that many endure, but few genuinely master.

Let’s start at the beginning. Several factors can lead a company to run multiple information systems supporting PLM. The first set of factors is internal to the company.

I. Industries with Long Product Life Cycles

When the product outlives the system that designed it

In sectors such as aerospace, naval and nuclear, products have very long life cycles, sometimes measured in decades. A combat aircraft remains in service for 40 years. A nuclear submarine, 50 years. A power plant, longer still. Design data must therefore remain continuously accessible, whether for legal reasons or for product maintenance. This reality often means keeping the original system in which the product was developed, rather than migrating the data to a new PLM.

Within a single company, some programs or products are in the development phase, others are in serial production for several years, and others still are in the maintenance phase. It is common for a given PLM to be reserved for one specific stage in a product’s life cycle, or for a new program, which makes coexistence with other systems inevitable.

This natural separation between design PLM and in-service PLM reflects genuinely distinct business needs. The first supports development and industrialization. The second takes over during the service phase, with typically lighter management of in-service change notices.

Layered on top are the strict regulatory constraints imposed by authorities in aerospace or defence (EASA, the DGA (France’s defence procurement agency), and equivalent national authorities) on data management, traceability and process security. Migrating a certified program to a new PLM can require partial recertification, generating a cost and a risk that many manufacturers are not prepared to shoulder for programs approaching end of life.

Keeping obsolete legacy systems that are no longer maintained by their vendors nonetheless raises significant issues in terms of maintenance and evolution.

Ultimately, several generations of PLM coexist not due to a lack of strategy, but through alignment with the life phases of the products themselves.

II. Strategic and Organizational Transformations

Mergers, acquisitions and industrial reconfigurations

During a merger, an acquisition, a business combination or the absorption of another entity, the resulting company typically launches harmonization projects. These projects cover processes, working methods and, naturally, information systems, which are typically heterogeneous at the outset.

The purpose of this convergence phase is to ensure operational consistency and collaboration between teams, and to guarantee business continuity within a shared organizational framework. Harmonization is also frequently motivated by the pursuit of lower operational costs, those recurring in-service costs that weigh on IT budgets year after year.

In some cases, however, the decision may be to keep two distinct PLMs, particularly when the underlying needs and business models are too different to justify full convergence. Preserving the independence of these tools helps to maintain specific know-how, and to facilitate potential future divestitures.

Technology legacy also plays a major role. Each company arrives with its own ecosystem: a historical PLM, business customizations, interfaces with ERP or MES. Architectural differences between PLM generations (on-premise vs cloud, monolithic vs microservices) make technical integration complex. Add to this the diversity of vendors: an application portfolio can include Siemens, Dassault Systèmes, PTC or SAP solutions, each with its own standards and ecosystems. Harmonizing this landscape represents a multi-year undertaking, with a return on investment that can be hard to find.

Finally, a new PLM system may be introduced to address evolving operational needs tied to a new program, to technologies that render existing systems obsolete, or simply to a deep transformation of the company. Whatever the trigger, implementation does not automatically lead to the decommissioning of existing systems, particularly when the rollout was insufficiently prepared or when an ongoing project was interrupted. Once again, different PLMs end up coexisting.

III. Value Chain Constraints and Diversification Strategies

Adapting tools to market realities

Beyond factors internal to the company, external ecosystem constraints also come into play. The use of multiple PLMs often stems from the structure of the value chain, particularly when a Tier-1 supplier (a direct supplier, with no intermediary, to an OEM) collaborates with several OEMs.

Some clients require the use of specific digital solutions, forcing the supplier to run several environments in parallel. A single aerospace supplier may need to work with different OEMs through distinct, parallel systems, while maintaining an internal environment for its own developments.

This approach is not necessarily a problem. It can reflect a legitimate business segmentation, where technical uniformity would simply bring no significant operational value.

The coexistence of several PLM generations is therefore not a monolithic phenomenon: it can be the rational consequence of multiple factors and constraints.

But beyond the causes, the real question is the actual cost of this coexistence.

Licenses, skills, interoperability, governance. In our next article, we will lay out a full audit of the financial and operational impacts of multi-PLM. It is by precisely measuring these impacts that you will be able to determine whether your situation calls for action and, if so, what kind.

Questions? Our experts are here to help.