Summer Is the Worst Time to Buy PLM and the Best Time to Evaluate It

A few weeks ago I was on a call with an engineering manager at a 60 person industrial equipment company. He told me his team had been “about to look at PDM” for two years. Every time they got close, a launch slipped, a customer escalation landed, or the quarter ended and nobody had budget authority to sign anything. His exact words were that they never had a week where enough people were in the building to actually try something.

Then he said the thing that made me want to write this article. He said: it is July, half my team is out, and for the first time in two years I have nothing on fire.

That is the real reason summer matters for a PDM or PLM decision. Not because it is a good time to buy. It is usually a terrible time to buy, because the people who sign are on vacation and the fiscal calendar is not pushing anyone. It is a good time to evaluate, because evaluation is the part that requires unhurried attention, your own CAD files, and engineers who have time to click around and get confused in front of you.

Most PLM selections fail on the evaluation, not on the purchase. Companies compress three months of testing into two vendor demos in November because a budget window is closing. Then they spend three years living with the result.

So if your summer is slower than usual, here is how I would use it.

The market just handed you more evidence than it has in almost two decades

On June 9, 2026, Gartner published the Magic Quadrant for PLM Software in Discrete Manufacturing Industries. It was the first time Gartner assessed this market in this form in many years, and it covered a vendor set that included Aras, Autodesk, Bluestar, CONTACT Software, Dassault Systèmes, OpenBOM, Oracle, Propel, PTC, and Siemens.

We were included (OpenBOM included in Gartner MQ 2026), and I am glad we were. But I want to be careful about what that report is useful for.

A Magic Quadrant tells you how a group of analysts assessed a group of vendors against a market definition those analysts wrote. It is a map of the market’s shape. It is not a shortlist, and it does not know that your BOMs live in Excel, that your ERP is NetSuite, or that your contract manufacturer in Mexico needs read access to drawings without a license.

A vendor can sit far to the right on completeness of vision and still be entirely wrong for a 40 person company that needs to stop losing revisions. The inverse is also true. The report is one input. Treat it as market context, not as a decision.

The same discipline applies to customer review platforms. G2 and Gartner Peer Insights will show you what people actually experienced after the contract was signed, which is genuinely more than any demo will tell you. But read the reviewer, not just the review. A five person hardware startup and a global aerospace supplier reviewing the same product are describing two different universes. Reviews that explain the reviewer’s environment are worth ten reviews that say “great product, steep learning curve.”

LinkedIn threads, Reddit, YouTube walkthroughs, and independent PLM commentary will surface problems that never appear in a vendor deck. They also carry undisclosed commercial interests, three year old experiences described in the present tense, and anonymous frustration.

What works is triangulation. When a customer review, an implementation consultant, a community thread, and a reference customer all describe the same friction, that is a finding. When a dramatic claim appears in exactly one anonymous post, that is a question to bring to the vendor, not a fact.

Asking AI which PLM is best guarantees you a useless answer

You should absolutely ask ChatGPT or Claude for help with this. I use both constantly. But the failure mode is predictable, and I see it in the questions people bring me.

“What is the best PLM system?”

There is no best PLM system. There is a system that fits your company, your products, your existing tools, and your people, and a great many systems that do not. An AI model asked that question will produce a plausible ranking assembled from vendor marketing and analyst summaries, and you will have learned nothing except which vendors write the most content.

Compare it to this:

We are a 100 person industrial equipment company. Fifteen mechanical engineers on SOLIDWORKS. BOMs live in Excel. ERP is NetSuite. We manufacture through two contract manufacturers and need cloud to access everywhere. Our four real problems are file version control, BOM accuracy, engineering change approval that survives an audit, and getting released BOMs into ERP without retyping. Compare suitable PDM and PLM options. State your assumptions explicitly, tell me what information you are missing, and propose an evaluation plan I could run in six weeks.

That question produces something you can work with. It also produces something you can argue with, which matters more.

Then push further. Ask the model to separate what it knows from what it is inferring. Ask it where its product information might be out of date, because for fast moving cloud products it very often is. Ask it to make the strongest case against each option, including the one it recommended.

Use AI to sharpen your questions. Do not use it to outsource your decision.

Your requirements list should be a problem list, not a feature list

The single most common mistake I see is a company that opens the evaluation by building a spreadsheet of 400 features and sending it to eight vendors. Everyone checks almost every box. You learn nothing, and you have created three months of work for yourself.

Start instead by writing down the five to ten things that are actually costing you money right now. In an earlier article I wrote about the hard problems engineering and manufacturing teams still face in 2026, and they show up in almost every evaluation conversation I have: design data still trapped in files, products that combine mechanical and electronics and software, supply chain complexity pushed back into design, ERP integration that never quite works, and contract manufacturer collaboration that degrades into emailed spreadsheets.

Your version might read: engineers cannot find the current revision, we have three part numbers for the same resistor, the BOM in ERP does not match the design, changes are approved in email and cannot be audited, procurement works from stale data, and a new engineer needs four months before they understand why anything was designed the way it was.

Now define what improvement looks like for each one. That list is your evaluation. Everything else is decoration.

The ten things I would test this summer

Company size and process complexity. Headcount is a weak proxy. A 30 person medical device company can carry more configuration, traceability, and compliance weight than a 500 person consumer products firm. Look at engineers and total users, sites, suppliers, BOM depth, change frequency, configuration count, approval complexity, and where you expect to be in three years. Do not buy an enterprise implementation to solve three problems. Do not buy something that will break the moment your product structure gets real.

Industry, regulation, geography, and data residency. Medical devices need design controls and audit trails. Aerospace and defense bring export control and data residency. “It is cloud” is not an answer to any of these. Ask where the data physically sits, what the tenancy model is, how identity and access are handled, what happens to backups, and whether a supplier can be given exactly the visibility you intend and nothing more.

Your actual problems, turned into scenarios. Do not ask whether the system supports change management. Every system says yes. Ask the vendor to run this: an engineer proposes a change, the system identifies affected files, items, BOMs and open orders, three people review, one rejects and asks for cost impact, the engineer revises, it gets approved, new revisions release, the BOM updates in ERP, and the whole history is still auditable a year later. A checkbox tells you nothing. That sequence tells you everything.

CAD integration, tested with your assemblies. This is where PDM and PLM decisions are won and lost. Do not accept a slide with a CAD logo on it. Install the add-in, open your largest real assembly, check it in, branch a revision, change a configuration, regenerate the BOM, and see what breaks. Test derivative generation, property mapping, duplicate part detection, and large assembly performance with your naming conventions rather than the vendor’s demo data.

Downstream integration, including the failure paths. Product data does not stop at release. Decide which system owns item numbers, which owns released engineering data, which owns inventory and cost, and which owns the manufacturing BOM. Then ask the harder question: what happens when the ERP connection fails at 2am, who finds out, and how is the partial transfer corrected. An export button is not an integration.

Openness, APIs, and what an AI agent can actually reach. Gartner’s market definition now includes APIs, multidomain CAD integration, digital thread enablement, and AI assisted data management. Evaluate REST coverage, webhooks, bulk access, authentication, rate limits, and whether you can get all of your data out on the day you decide to leave. MCP is genuinely interesting, and it is also becoming a logo on slides. Ask what an agent can read, what it can change, how permissions are enforced, and whether every action is audited. MCP makes a good API easier for agents to use. It cannot rescue a closed platform.

Deployment architecture. Ask whether it is real multi-tenant SaaS or hosted legacy software with a new login page. How often does it upgrade, are upgrades included, can customers refuse them, who operates the infrastructure, and what happens to your configurations when a major version lands.

Data model flexibility versus customization. These get conflated constantly. Configuration means changing the system with supported administrative tools. Customization means someone writes code for you specifically. During the trial, ask the vendor to add an item type, add a validated property, create a relationship between a requirement and a part and a change, add a BOM type, modify a workflow, and build a report while you watch. Then ask what happens to all of it at the next upgrade. Unlimited customization is how companies end up frozen on a version from 2019.

Trial, implementation, and who helps you after go live. Use your own CAD files, parts, BOMs, revisions, and one real ERP scenario. Measure how much work happens before you get any value at all. Find out whether the vendor helps directly or whether an implementation partner is mandatory, what training is included, whether documentation is public, and how fast support actually responds in August.

Price and the incentives the pricing model creates. Build a three year model covering paid users, read-only users, supplier access, CAD and ERP connectors, API access, storage, sandbox environments, AI usage, implementation, migration, training, and internal administration. Then look at what the pricing model encourages. If everyone who needs to see a BOM requires a full license, your BOMs will stay in email. If API access sits behind an enterprise agreement, your integration will never get built. The business model is part of the architecture, because it determines how people actually use the system.

A rough map of the landscape, offered without a ranking

This is not comprehensive and it is not a scorecard. It is a sense of where various products place their center of gravity, and every line of it should be verified against your own requirements.

Siemens Teamcenter, PTC Windchill, and Dassault Systèmes ENOVIA are the large enterprise platforms, each attached to a broad portfolio of CAD, simulation, and manufacturing software. They offer enormous breadth and are typically evaluated by organizations with complex products, global processes, and the internal capacity to run a multi year program.

Aras Innovator and CONTACT Software both compete from a configurability and CAD neutrality angle, emphasizing flexible data models, low code, and open APIs. Both reward organizations that have or intend to build real internal platform skills.

Autodesk Fusion Manage is Autodesk’s cloud PLM, alongside Vault for PDM and Fusion’s own data management. Companies standardized on Autodesk design tools should map carefully how those pieces relate for their situation. Propel is built on Salesforce and combines PLM, QMS, and PIM. Oracle Fusion Cloud PLM sits inside Oracle’s supply chain suite and matters most to companies already committed to Oracle Cloud or migrating off Agile. Bluestar PLM is embedded natively in Microsoft Dynamics 365. In each case the question is the same: does aligning with Salesforce, Oracle, Microsoft, or Autodesk simplify your architecture, or does it add a dependency you were not planning to take on.

PTC Arena is a cloud PLM and QMS offering centered on items, BOMs, changes, quality, and supplier collaboration, with a direct connection to Onshape. Duro focuses on cloud PLM for hardware companies and was acquired by Altium in December 2025, which makes the relationship between electronics design and PLM worth watching. Bild started in cloud design review and has expanded toward CAD file management, ECOs, and BOMs.

OpenBOM is where I spend my time, so I will be direct about our position rather than pretending to neutrality. We built OpenBOM to combine cloud PDM, BOM management, change management, procurement, inventory, and ERP connected workflows for small and midsize engineering teams that need design, purchasing, and production connected without starting a two year implementation. Our integration list spans multiple CAD and ERP systems, and you can create an account and load your own assembly today without talking to a salesperson. That last part is the claim I would most encourage you to test, on us and on everyone else.

The trial is the evaluation

Everything above is preparation. The evaluation itself is six weeks of hands on work, and summer is when you can get it.

Establish a baseline first, because without one you cannot demonstrate improvement to anyone who controls budget. How long does it take you to release a BOM today, how many corrections follow, how often does manufacturing build to the wrong revision, how many engineering hours go into preparing data for ERP.

Then shortlist three or four candidates. Not fifteen. Use size, industry, CAD environment, ERP environment, and deployment requirements to eliminate aggressively, and accept that you will eliminate something good. That is fine.

Give every vendor identical scenarios with your assembly, your workflow, and your roles, so that you are comparing the same thing rather than each vendor’s strongest demo. Then take the keyboard. Your engineers, your administrator, and someone from procurement should be the ones clicking, while you watch where they hesitate. Adoption is not a soft criterion. A powerful system that people quietly avoid produces worse data than the spreadsheet it replaced.

Most importantly, test what happens when things go wrong. Import a file with bad data. Feed it an assembly with duplicate part numbers. Change a released object. Kill the ERP connection mid transfer. Remove an approver who has three pending reviews. Ask for a full export of everything you have loaded. Systems reveal their architecture under failure, never under a demo.

And talk to customers who resemble you, without a salesperson moderating. Ask what took longer than expected, what cost more than quoted, and whether the vendor was still responsive in month eight.

What should make you walk away

No trial. No public documentation. CAD integration that only exists in slides. Reluctance to touch your data. Pricing that quietly excludes required modules. Out of the box claims with no working demonstration. Every configuration request turning into a services quote. No clear path to export your own data. APIs that require a separate contract. AI answers with no sources, no permission model, and no audit trail. A modern interface over an architecture from 2011. Implementation estimates that omit migration. A vendor who cannot introduce you to a comparable customer. A salesperson who will not name a single thing the product does badly.

No product satisfies every requirement. A vendor worth working with can tell you exactly where theirs does not fit.

Conclusion

The decision starts with basics: how big and complex you are, what problems are actually costing you money, what regulations apply, what CAD you run, what you need to connect downstream, and what you can realistically administer.

Then you research, you shortlist, and you try things with your own data. Not the happy path. The broken one.

There is no magic bullet, and there is no best PLM. There is a system that solves your most expensive problems on an architecture that will still be standing in five years, sold by people you can call and trust.

At OpenBOM we think the fastest way to learn whether a system fits is to load your own data into it. Start a free OpenBOM trial, connect your CAD, import a real BOM, and find out this summer instead of next November.

Good luck with your evaluation.

Best, Oleg

FAQ 

How do you evaluate a PLM system? 

Start with a list of five to ten business problems that are costing you money, not a feature matrix. Shortlist three or four vendors using company size, industry, CAD environment, and ERP environment. Give every vendor the same test scenarios, then run a hands-on trial with your own CAD files, BOMs, revisions, and one real ERP integration path. Test failure conditions, not just the happy path, and speak to reference customers without a salesperson present.

What is the difference between PDM and PLM? 

PDM manages engineering design data: CAD files, versions, revisions, assembly references, and derivative outputs. PLM manages the product across its lifecycle: items, bills of materials, engineering changes, approvals, suppliers, cost, and the connection into ERP and manufacturing. Most companies need both, and many modern cloud platforms combine them rather than selling them as separate systems.

Is there a best PLM system? 

No. There is a system that fits your company size, products, existing CAD and ERP tools, regulatory requirements, and team capability, and many systems that do not. Any ranking that answers “best PLM” without knowing your environment is reproducing vendor marketing.

Which vendors were included in the 2026 Gartner Magic Quadrant for PLM software? 

The Gartner Magic Quadrant for PLM Software in Discrete Manufacturing Industries, published 9 June 2026, assessed a vendor set including Aras, Autodesk, Bluestar, CONTACT Software, Dassault Systèmes, OpenBOM, Oracle, Propel, PTC, and Siemens. Gartner does not endorse any vendor depicted in its research and the report should be treated as market context rather than a shortlist.

How long should a PLM evaluation take? 

Four to eight weeks of hands-on work is realistic for a small or midsize company evaluating three or four products. Compressing this into two vendor demos is the most common reason PLM selections fail, because demos test the vendor’s happy path rather than your data.

Can AI help choose a PLM system? 

Yes, but not by asking which PLM is best. Describe your headcount, CAD tools, ERP, manufacturing model, regulatory requirements, and the four or five specific problems you need solved, then ask the model to state its assumptions, identify missing information, and propose an evaluation plan. Ask it to argue against its own recommendation. Product details for fast-moving cloud software are often out of date in model training data, so verify anything specific.

How much does a PLM system cost?

 Build a three year model rather than comparing seat prices. Include paid and read-only users, supplier access, CAD and ERP connectors, API access, storage, sandbox environments, AI usage, implementation, data migration, training, support, and internal administration time. Also examine the incentives: if viewing a BOM requires a full license, collaboration stays in email regardless of what the software can do.