Something has shifted in the future-of-PLM conversation over the past few years. The diagnosis is no longer contested. A widely shared independent report catalogues the challengers positioned to replace the Big Three. A veteran commentator answers that the future is a system of context above the systems of record. The vendors themselves are announcing intelligence layers over their own portfolios. Twenty years of polite disagreement about whether legacy PLM can deliver has collapsed into rough consensus that it cannot, and the argument has moved to what happens next.
Most versions of what happens next assume the same: replacement. The old platform goes out, a better one comes in. The challengers assume it, the migration roadmaps assume it, and two decades of programme plans assumed it. It is worth asking what that assumption's track record actually looks like.
The track record
Replacement has been tried, continuously, at industrial scale, since the term PLM was raised. The multi-year programme, the runaway customisation, the phase two that never ships: these are not stories about bad tools. Most of the failed migrations of the last two decades involved perfectly capable software. They are stories about a political mechanism, and that mechanism repeats.
I watched it up close in a post-merger consolidation. Two large industrial organisations, each with its own PDM environment, committed to a single shared platform. The technical work of designing the consolidated data model went to a working group with representatives from both sides. The model that emerged was not a model either side recognised as their own. The distinctive features each legacy environment had developed over years (the configuration semantics, the change-control granularities, the supplier-interface patterns) had been smoothed away in negotiation, because keeping them all would have produced a model neither side could operate. The compromise satisfied the working group, but did not, unfortunately, meet the requirements of the practitioners on the ground. In the end neither organisation moved. Years later the consolidation system existed as a shelved investment, and the operational landscape remained unchanged.
The mechanism is displacement politics. A replacement requires an authority decision about whose object semantics survive, and that decision touches every engineering function on every side. Executive sponsors will not accept the displacement of their organisation's distinctive features, working groups have no authority to impose it, and the installed base wins the fight by doing the one thing it does effortlessly: not moving. A genuinely better data model in the incoming platform does not change this arithmetic. The migration still runs through the same politics, and the politics have a twenty-year winning streak.
The industry that stopped trying
One engineering industry looked at this problem and took the other road, and it is worth studying precisely because its coordination problem is harder than manufacturing's, not easier.
A construction project coordinates dozens of independent firms: architect, structural engineer, mechanical, electrical, plumbing, each running its own authoritative model in its own tools, each a separate company with its own commercial interests. Nobody proposes that they all migrate to one platform, because no firm could impose one on the others. Instead, over roughly two decades, the industry built federation as a discipline. The discipline models stay authoritative where they are. A coordination layer federates them for clash detection, interface verification, and integrated review; it does not own the models, it federates them. IFC gives the pattern a tool-agnostic data model. BCF, a small open format, captures an issue at a specific location in the federated model, with a discipline owner, a status, and a resolution lifecycle, and moves it between tools from different vendors. ISO 19650 names the roles, the responsibilities, the deliverables, and the cadence of information exchange.
Three things about this deserve to be noted. First, no single vendor built it; standards bodies, industry organisations, software vendors, and major clients converged on it because projects forced them to. Second, it works across vendors, geographies, and project sizes, which is exactly the property a negotiated single platform can never have. Third, construction gave something up to get it: the dream of one system holding everything. What it got in exchange was coordination that actually operates.
Manufacturing has nothing equivalent. Parts of the standards picture exist (STEP, ISO 15926, the MBSE stack), but they do not form a federation pattern the way IFC, BCF, and ISO 19650 do. There is no manufacturing BCF: no lightweight, tool-agnostic way to attach an interface issue to a location in a federated representation and route it across company and tool boundaries. That absence is not a tooling gap. It is the missing pattern.
What this means for the current debate
Read the challenger landscape against this precedent and a dividing line appears that matters more than old versus new. Some of the new platforms replicate data within themselves and aim, explicitly or implicitly, to become the next system that everything migrates into. Others keep source data connected where it lives and sit above the landscape. The second group is often described, including by its admirers, as a transitional strategy: federate now, replace later, once customers are ready to cut the cord. The AEC precedent says the opposite. Federation is not the way towards replacement. It is the actual destination, and it is the only destination with an existence proof at industrial scale.
The same test applies to the system providers' intelligence layers. A federation layer scoped to one vendor's portfolio is partial context by construction, the same trap in more modern clothes. The context an engineering organisation needs spans PLM, ERP, MES, MBSE, and the supplier boundary, and the layer that carries it has to be neutral about whose tools sit underneath, the way a construction coordination model is neutral about whose CAD produced each discipline model.
And what actually lives in that layer is the argument of this series: the primitives. Interface contracts, verification with lineage, configuration history, decisions with their rationale, judgment with its standing. The layer does not replace the estate. It gives the estate the objects it never had, and leaves authority where it belongs.
One consequence for the sponsor of the next programme
If you are holding budget for the next move, the liberating implication is that you can stop funding replacement guilt. The estate is not your failure. Twenty years of programmes have treated the surviving installed base as evidence of insufficient will, and the next migration as the act that finally fixes it. The base rate says otherwise, and construction says it is not a tragedy. The productive question for any proposal on your desk, from a challenger, an incumbent, or a consultancy, is not whether it can replace what you have. It is whether it leaves authority in your source systems, adds the missing objects above them, and can name which ones.
You will probably not replace your PLM. The organisations that make peace with that first will spend the next decade building the layer that matters, while the others fund another round of migrations and discover the installed base is still undefeated.
One more thing
The AEC precedent gets a full chapter in Beyond the BOM: A Federation Architecture for Complex Engineering Data, which is now available on Amazon, alongside the seven primitives and the deployment path for the layer this article advocates. The earlier articles in this series argued that the digital thread, the AI copilot, and the knowledge-retention programme all fail on the same missing substrate. This one is about where that substrate can actually be built: above the estate you already have, not on the rubble of another replacement.