The Watchtower Brief | AI Tech Sales
On December 31, 2027, Oracle stops issuing new security patches, bug fixes, and certifications for Agile PLM. The last real release, version 9.3.6, shipped back in 2017; the planned 9.3.7 was quietly cancelled, and Oracle made the end-of-life decision official in October 2023. After the 2027 cutoff, Agile drops into "sustaining support" - you can still run it, but nothing new comes.
That single date is about to trigger one of the largest forced re-platforming events the chip industry has seen in years. Agile PLM has quietly run the product record for a huge slice of high tech since Oracle acquired it in 2007 for roughly half a billion dollars, and its core buyer, by design, was fabless semiconductor companies: complex product definitions, fast-changing components, and regulatory traceability that isn't optional. Bill of materials structure, engineering change orders, supplier collaboration, compliance history - for two decades, Agile has been the system of record underneath all of it.
Every PLM vendor on earth has noticed the same expiration date. Teamcenter, Windchill, Aras, Arena, Propel, and Oracle's own Fusion Cloud PLM all have a "switch to us" playbook ready to go, and the migration-guide content marketing machine is in full swing. Which is exactly the problem. The entire conversation has been framed as a vendor swap: which modern PLM should replace the old one. That's the wrong question, and answering it well will still leave most semiconductor companies exactly where they started.
Agile PLM governs a real and important slice of the semiconductor lifecycle: the product record, the BOM, the engineering change process, supplier-facing collaboration, compliance history. It's the layer that answers "what is this product made of, and what changed, and who approved it."
What it has never done, in fact what no PLM tool was architected to do, is connect that record back to why the product exists in the first place, or forward to how well it actually performs once it ships. Agile PLM knows a part number changed. It has no idea whether that change traces back to a customer requirement, what it does to verification coverage, or how it shows up in yield six months later at the fab. That's not a criticism of Agile specifically; it's a description of the entire PLM category. PLM systems were built as system-of-record tools for a tool-centric, siloed era, sitting apart from architecture, RTL, verification, and yield data by design.
That gap is tolerable when a PLM system is stable, invisible infrastructure nobody thinks about. It stops being tolerable the moment you're forced to rip it out and rebuild - because rebuilding on the same architectural assumptions just re-creates the same gap, with a nicer interface, for another fifteen years.
Most Agile customers will do exactly what the migration guides tell them to: pick a modern PLM successor, map the data model, run a phased cutover, declare victory. It's the safe choice, and for plenty of organizations it will be the right one on a two-year clock.
But here's what makes this moment genuinely unusual: nobody is forced to touch their PLM system of record more than once every ten or fifteen years. When you are forced to touch it, you get a rare, board-sanctioned budget line and a rare, all-hands willingness to change process - the two things that never otherwise show up on the same calendar. Spending that window purely on "same category of tool, newer vendor" is the least ambitious thing you can do with it.
The more interesting question is the one the vendor comparison guides never ask: instead of replacing a system-of-record island with a newer system-of-record island, what if the replatforming event became the moment you connected the islands? Requirements and intent on one side. BOM, change control, and compliance in the middle. Verification coverage and yield data on the other. Today, in most semiconductor organizations, those three things live in three different tools maintained by three different teams, reconciled by spreadsheets and tribal knowledge. A forced PLM migration is the one moment where touching the middle layer is already sanctioned, which makes it the cheapest possible moment to also wire it to the layers on either side.
Concretely, that looks like requirements-traceability tooling (the kind of intent layer that captures why a spec exists and who signed off on it) feeding directly into the change-control and BOM layer that Agile's replacement will own, which in turn feeds forward into verification and yield systems - so that an engineering change order isn't just logged, it's traceable back to the requirement that drove it and forward to the yield or test impact it eventually produced. None of the individual pieces are exotic. What's missing across the industry is the connective tissue between them, because every tool in that chain was built to be excellent at its own layer and indifferent to its neighbors.
There's a second, quieter signal worth paying attention to: the people who deeply understand Agile's internals - its customizations, its integration quirks, its institutional history - are retiring, and the next generation of PLM talent has no reason to specialize in a platform Oracle has already sunset. That's a specific, well-documented staffing problem for Agile customers over the next two years.
It's also a preview of something larger happening across the entire EDA and PLM tool stack. A generation of specialists who could hold an entire tool-centric workflow in their heads is aging out, at the exact moment the industry needs someone - or something - to hold the whole lifecycle in view instead of just one tool in it. Swapping Agile for another single-purpose PLM doesn't solve that. It just restarts the clock on the same eventual problem.
Oracle didn't create a PLM vendor-selection exercise. It created a rare, budgeted, organizationally-sanctioned window to ask a bigger question: should the next system of record be another island, or should it be the moment your product record finally talks to your requirements and your yield data?
Most companies will spend the next eighteen months evaluating PLM replacements feature-by-feature against Agile's old checklist. The ones who instead ask what an intent-to-yield connected lifecycle should look like - and use this forced migration as the on-ramp to build it - won't just avoid doing this exercise again in 2040. They'll spend the next decade with a lifecycle management system that actually knows why every change happened and what it cost or earned them downstream. That's a materially different starting position than "we migrated to a newer version of the same idea."
The deadline is real. The vendor comparisons are useful but incomplete. The bigger question - what should actually govern a semiconductor product's life from intent through yield - is the one worth spending the window on.
Simon Bennett is CSO and Co-Founder of AI Tech Sales - former Synopsys and Intel, IP and EDA veteran.
Sources